Coffee Coffee #29
Zarządzanie wiedzą: Mission impossible?
O odcinku
Zarządzanie wiedzą! Święty Graal organizacji. Źródlo rozwiazania wszystkich problemów ... czy po prostu kolejny proces w organizacji.
W tym odcinku 'CTO Morning Coffee', omawiamy kluczowe aspekty zarządzania wiedzą w dużych organizacjach. Rozmawiamy znaczenie zbierania, dzielenia się, zachowania i efektywnego wykorzystania wiedzy organizacyjnej. Dyskusja skupia się na wyzwaniach i strategiach związanych z zarządzaniem wiedzą, istotnych dla liderów technicznych i aspirujących CTO.
Posłuchaj, aby dowiedzieć się, jak zapewnić spójne podejście i uniknąć nieefektywności i chaosu w organizacji.
O czym rozmawialiśmy?
1. Znaczenie zarządzania wiedzą w organizacjach.
2. Metody zbierania i dzielenia się wiedzą.
3. Wyzwania w zachowaniu wiedzy organizacyjnej.
4. Strategie efektywnego wykorzystania wiedzy.
5. Rola liderów technicznych w zarządzaniu wiedzą.
6. Praktyczne podejścia do unikania nieefektywności.
Zapraszamy
=============================================
CTO Morning Coffe tworzą:
👉 Sebastian Gębski:
🔵 Twitter: https://twitter.com/liveweird
🔵 Blog: https://no-kill-switch.ghost.io/
👉 Wojtek Ptak:
🔵 Twitter: https://twitter.com/wjptak
👉 Tomek Onyszko:
🔵 Twitter: https://twitter.com/tonyszko
🔵 Blog: https://www.onyszko.com/
🔵 Newsletter: https://signup.onyszko.com/
Live long and prosper 🖖
---
To nagranie jest zapisem spotkania na Twitter Spaces, tak jak zostało przeprowadzone, bez dodatkowej obróbki. Zapraszamy do dołączenia do przyszłych spotkań na https://www.ctomorning.coffee
Transkrypcja
Brak wyników.
Dzień dobry Seb dzień dob c cześć cześć dobrze i znów się udało powinieneś O udało się wakacje nie ZW w komplecie Nie akurat wczoraj opublikowałem nas pod zwolnieniach to dla tych co Nie słuchali to jest na Spotify to nie wiem jak to odebrać Wojtek co powiedziałeś ale dobrze nie będę się na tym zastanawiał Halo jesteście Jesteśmy jesteśmy dobrze bo zapadła cisza na mój słaby żart i nie wiedziałem czy mnie rozłączyło czy nie Nie no żart był słaby No i tak pominąć milczeniem tak poważnie lepiej wchodzi jak taki żart przemilczy setup in progress ale widzę że sporo osób dołącza więc to jest chyba ulubiona część wszystkich czyli porana moją formułkę przypomnienie być może dla tych którzy są z nami po raz pierwszy to jest Coffee nasze Regularne co dwutygodniowe spotkania gdzie rozmawiamy sobie o tematach istotnych dla tak zwanych czy dla C ale nie tylko i również dla tych którzy do tego typu ró aspirują każdy odcinek ma swój temat
dzisiejszy będzie Management i jak to się ma do cto czyli temat chyba bardzo ciekawy Nasza dyskusja trwa dokładnie godzinę Każdy może zabrać głos każdy może zadać pytanie Każdy może skomentować odnieść się do tego co zostało powiedziane żeby to zrobić trzeba po pierwsze słuchać nazw aplikacji twitterowe Czyli jeżeli ktoś robi to przez przeglądarkę to sorry ale jeszcze cały czas Elon nie dał nam nie dał Wam tej możliwości natomiast przez aplikację mobilną Jak najbardziej można to robić Tam jest taka ikonka Gdzie można wyrazić chęć zabrania głosu więc proszę róbcie to my czasami tego głosu wam od razu nie damy po prostu możemy tego nie zauważyć C ktoś t łapkę podniósł ale nie należy się zniechęcać co do jakieś takiej powiedzmy naszej temperatury dyskusji to staramy się żeby ta dyskusja była przede wszystkim profesjonalna czyli bez jakiś osobistych podjazdów bez krytykowania osób nawet Firm Jeżeli krytykujemy to krytykujemy jakieś postawy ale w oderwaniu od powiedzmy z ciekawych rzeczy nasze odcinki są nagrywane jeszcze cały czas przez Twitter Spaces i są również publikowane później jako podcast natomiast na to trzeba poczekać parę ładnych tygodni w związku z tym zachęcamy do tego co
robicie w tym momencie czyli do udziału na żywo Co jeszcze mamy nasz Landing Page C morning Coffee tam można się nie tylko zapisać na powiadomienia nie tylko odsłuchać właśnie archiwalne odcinki ale też dowiedzieć się o różnych ciekawych rzeczach które będą się dział w najbliższym czasie Jedna z nich w sumie poszła wczoraj oficjalnie w eter Tomasz czy coś chcesz więcej na ten temat powiedzieć No tak wydarzyła się rzecz niesamowita czyli taki mój internal joke będę na def def to jedna z konferencji którą uważamy że robi robotę jeżeli chodzi o jakość i chłopaki zgodzili się raz przyjąć nas pod swoje skrzydełka na tym wydanie czyli City Coffee w jakimś tam w tym zestawie będzie na Jeżeli chcecie jakś nawet nie mamy kodów ale my tam będziemy tak Tak to jest z naszej strony oczywiście przycięcie niekomercyjne natomiast no będzie to jak zwał tak zwał c Coffee na żywo in person więc będzie okazja pogadać podyskutować i co tylko dobrze chodzi standardowe formułki to chyba wyczerpaliśmy temat
tak powiedzieć Czym jest to zarządzanie wiedzą czym jest ten Management kto się podejmuje do bycia dzisiaj naszą encyklopedią Wojtek jeszcze nic nie mówiłeś Ojejku zarządzanie wiedzą w organizacji tak Czyli tak naprawdę cały ogromny obszar chcemy dzisiaj dotknąć który dotyczy budowania i współdzielenia tak naprawdę wiedzy w organizacji Wiadomo że im większa firma bardziej skomplikowane produkty jest to bardziej ważne dla nas wszystkich ale tak naprawdę chcemy go dotknąć na kilku z kilku płaszczyzn i z kilku perspektyw więc myślę że ja też bardzo czekam na tą dyskusję W każdym razie jakbym spróbował chyba w jednym zdaniu chyba już spróbowałem powiedzieć Czym jest tak naprawdę to zarządzanie wiedzą No i teraz pytanie co się dzieje jeżeli zaniedbamy czyli w ogóle ignorujemy fakt istnienia [Muzyka] też Słuchajcie może czy ch dodać coś jeszcze do definicji samej to ja wejdę na chwilę żeby jeszcze rozruszać bo ty Wojtek pojechałeś taką trochę Znaczy nie encyklopedyczną ale taką formułą że to
jest to to to ja powiem życiowo kiedyś miałem projekt w dużej firmie za granicą 20000 ludzi i robiliśmy jakiś projekt generalnie jak potrzebowałem cowi zbudowane to wtedy było musimy iść do tej i po dwóch dniach się zorientowałem że z każdym pytaniem Lądujemy u tej samej jednej osoby i ta pani odpowiadała na wszystkie pytania o infrastrukturę Dys firmy w finansach z głowy całem niezłe zarządzanie wiedzą To był przykład zarządzania wiedzą i PR to nie tylko dozy produktów ale też infrastruktury wij organiz procesu dla mnie zarządzanie wiedzą to jest zagadnienie jak przekazać wiedzę na temat tego C ogó stan jak działa organizacja bo to nie dotyczy tylko technicznej wiedzy tylko jak działa organizacja Jak zbudowany jest produkt jakie mamy procesy i tak dalej w organizacji która się zmienia i ludzie przychodzą odchodzą wychodzą i trzeba w jaki sposób zachować to co tworzy tą organizację Czyli tak naprawdę wiedza o tym Ludzie robią co robimy i jak to robimy dotknąłeś też
bardzo dobrej rzeczy jeszcze zanim Sebastian wejdzie to bardzo chciałem to podkreślić że na pewno jest to proces który powinniśmy od razu świadomie rozpocząć albo raczej zestaw procesów który świadom powinniśmy rozpocząć i to powinno żyć z nami tak Czyli na pewno jedno podejście nie sprawdzi się do wszystkich rodzajów firm organizacji do wszystkich rodzajów zespołów każda firma chyba podchodzi do do tego na swój indywidualny sposób Natomiast są dobre złe i dobre praktyki o których pewnie powiemy Sebastian powie kilka fajnych rzeczy moż skomentuję tą panią któ powiedział Tomek tak była dobra sytuacja bo przynajmniej ludzie wiedzieli Gdzie jest w ogóle ta wiedza i była chociaż jedna osoba która tą wiedzę miała to tak nie był Znam też inne sytuacje Właśnie znam też inne sytuacje żyłem No właśnie teraz Jeż jak myślałem o tej definicji jakby jak ja bym ją chciał ukuć to wszystko mi się w końcu sprowadzało czasowników które trzeba z tą wiedzą robić i Wy w sumie żeście większość tych czasowników wymienili ja tylko powiem jakie są cztery dla mnie najważniejsze pierwszy taki może najmniej oczywisty to jest Capture w ogóle jak wizę złapać w organizacji Bo niektórzy Ja też tak miałem że jak ja w ogóle wchodziłem do robienia software i zaczynają być odpowiedzialny za jakieś większe części Tey potem projekty to Knowledge
Management to w ogóle nie był temat w sensie to nie było coś czego się nie wiem uczyłem to nie było coś co było jakąś wiedzą encyklopedyczną jakimś tam Body of którego się trzeba było nauczyć to było coś się robiło intuicyjnie w związku z tym O ty o tym Capture w ogóle jak tą wiedzę złapać jak tą wiedzę też jakoś skodyfikować zamknąć w jakieś ramy to też była taka totalna wolna Amerykanka więc dla mnie ten etap cap czy ten czasownik k jest też bardzo istotny jak już mamy k jak już tą wiedz łapiemy to teraz jej przechowanie zapisanie jej zapisanie to jest jedna rzecz bo to wcale nie jest takie proste bo tutaj pojawia się masa dylematów o których pewnie będziemy mówić tak potem Share czyli właśnie jak wydajny sposób podzielić się tą wiedzą podzielić się nią Nie wiem z nowymi osobami które wdrażamy ale podzielić się z innymi częściami organizacji bo to nie jest tak że Wiedza jest rozsmarowane równo po całej organizacji bo to tak nie może działać z różnych powodów więc szer to jest ten trzeci mój czasownik i ostatni czwarty bo powiedziałem o czterech ten czwarty się trochę wiąże z poprzednimi ale warto go wyróżnić bo to jest preserve czy jak zachować tą wiedzę bo to że my żeśmy tą wiedzę gdzieś tam zapisali to wcale nie znaczy że ona już jest zachowana Po pierwsze dlatego że ona może szybko stać się w związku z tym wiedza staje się śmieciowa po drugie to to że ona gdzieś jest to jeszcze musi być indeksowana
wyszukiwan musi być po prostu do niej w jakimś sensie przechowany dostęp i ostatnia rzecz Strasznie mi się podobało to co powiedział Wojtek na końcu więc chciał Też podkreślić że to nie jest Sprint tylko to jest to nie jest coś co da się zrobić jednorazowo że okej to teraz zrobimy projekt w organizacji Knowledge Management a potem już będzie dobrze no nie jednak cały czas trzeba pakować pakować pakować ładować wkładać ten wysiłek żeby miał sens ale to dlatego że do projektu jeszcze musisz zatrudnić odpowiednich konsultantów i wtedy będzie dobrze musiał ja jeszcze dodam jedną rzecz tutaj do tego co Sebastian powiedziałeś bo też warto podkreślić że mówimy o wiedzy prawda Czyli o jakimś zestawie zrozumienia tego co robimy jak robimy Dlaczego robimy I to dotyczy całego obszaru z reguły naszej działalności i pewnie jak jest mała firma to tą wiedzę bardzo łatwo ustnie współdzielić więc do pewnie kilkunastu osób można to tak zrobić Natomiast w miarę rośnięcia w miarę też tworzenia różnego rodzaju procesów No Musimy podejść do tego tematu na wielu na wielu na wielu wymiarach bo teraz chciałem powiedzieć że my jako inżynierowie
bardzo często No mamy świetne praktyki jak dokumentować wiedzę technologiczną tak I uczymy tych praktyk współ Dzielimy je opowiadamy sobie jak to robić Natomiast ja też chciałem dodać od razu żeby to wybrzmiał żebyśmy do tego mogli wrócić że to dotyczy też innych rodzajów praktyk tak czyli na przykład tutaj chciałem powiedzieć że to jak na przykład przeprowadzamy sobie Performance reviews albo robimy interview albo onboarding to też jest wiedza na przykład procesowa którą warto od razu też wziąć pod skrzydła i jakoś zacząć sobie dokumentować współdzielić ja włożę kij w szprychy może nawet go Zaparkuj Ale powiedziałeś taką rzecz z którą pozwolę się mocno nie zgodzić Praktycznie to znac powiedz jako inżynierowie doskonale wiemy jak tą wiedzę zbierać składować i tak dalej I moja obserwacja organizacji jest raczej nie wiemy ale podyskutujmy okej tutaj Jasne jasne oczywiście chodzi mi wies jako inżynierowie przynajmniej różnego rodzaju narzędzia do tego co powiedziałeś się odniosę to czy stosujemy to jest inne kwestie tak ale większość osób która studiowała na
przykład kierunki związane z szeroko pojętym it miała na pewno Chociaż był uml i miała projekty na studiach gdzie musiała dokumentować pewnego rodzaju projekty przy pomocy tego uml tak już nie mówię o później kolejnych kolejnych narzędziach które możemy wprowadzać więc do tego pewnie właśnie to zanim o narzędziach bo tutaj możemy myślę też o teorii informacji to długo by opowiadać Ale wróćmy do twojego pytania mś dobre pytanie czy co się dzieje jeżeli zaniedbamy temat Management co czy jakie wy macie sytuacje obserwacje co w ty może popsuć No ja bym powiedział że pierwsze i najważniejsze co co się dzieje to jest brak spójnego podejścia i to jest taki dla mnie Top do naszego odcinka tak także nieważne czy to jest podejmowanie decyzji czy to jest sposób wytwarzania oprogramowania czy właśnie te procesy o których wspomniałem bardziej związane z zarządzaniem ludźmi w organizacji No to mamy brak wspólnego podejścia brak wspólnego podejścia też bardzo często prowadzi do kilku innych rzeczy i tutaj tak chcę oddać Tomkowi też szybko głos
ale to tylko wspomnę dwie że bardzo często duplikuj swoje starania lub właśnie swoje jakieś procesy bardzo często przez to że jesteśmy nie mamy braku spójności w tym podejściu No to one są bardzo często różne i to nawet bardzo różne Co oczywiście prowadzi do tworzenia silosów i trzecia i najważniejsza rzecz z takiego mojego top 3 No to właśnie ta ograniczona współpraca i wspólne uczenie się na temat organiz użytkowników to takie moje Top TR Tomek no jedno mi dałeś bo miałem powiedzieć że to prowadzi do duplikacji na różnych poziomach nie I to duplikacji takiej że po prostu Im większa organizacja tym większej że zaczynamy wymyślać koło od nowa powtarzać Każdy robi myśli jaki software zbudować jaki zaczynają się procesy równoległe i tak dalej nie No bo ludzie po prostu nie wiedzą że ktoś coś robi więc myślą rozwiąże i nagle mamy pięci ludzi rozwiązujących ten sam problem może mniej może mniej oczywiste bo nie techniczne tak to jeżeli chodzi Tak z punktu widzenia
organizacji bo powiedział ale to powoduje generalnie szeroko pojęty chaos entropia wzrasta w organizacji No bo ludzie do niej wchodzą w szczególności to jest bardzo ważne w tej części i początkowego takiego kś wchodzi do organizacji musi zacząć działać w tej organizacji Jeżeli tego nie ma No to zaczyna działać chaotycznie jak zaczyna działać chaotycznie to robi taki albo się pyta wszystkich o co Jak zrobić Albo robi to po swojemu bo chce być efektywny i na końcu efektywność całej organizacji będzie spadać w na przykład my gdzieś tam w którymś momencie mocno przyłożyliśmy się do tej częściowej czy takiej wiedzy na temat jak niektóre rzeczy robimy bo je trzeba uwspólnić tak długoterminowo No to jest dokładnie ja bym to podsumował entropia rośnie tak jeżeli nad tym nie zapanuj No to wszystko co powiedziałeś się zgadza pod stą silosy w silosach będziemy mieli różne narzędzia różne procesy dla całej organizacji to krótko mówiąc powoduje że koszty rosną i efektywność spada takowa zanim też rzucę parę swoich uwag to też zachęcam wszystkich do podnoszenia łapki zabierania głosu
dzielenia się swoimi obserwacjami swoimi też jakimś doświadczeniami co ja bym dodał do tego co powiedzieliście czyli na przykład entropi to Dodałbym po prostu skrajną nieefektywność dlatego że jeżeli nie umiemy zapisywać wiedzy to to co się dzieje to my za każdym razem albo musimy tę wiedzę odkrywać na nowo uspać pomiędzy tym co sobie ludzie zapamiętali czyli na przykład nie znamy zamysłu oryginalnego który stał za jakimś modułem jakiegoś modelu logicznego modelu funkcjonalnego i musimy refakturować sobie w głowie z kodu i na samym początku To jest coś co jest naturalne dla nas No tak pracują Programiści jakby się na to specjalnie nie burzymy dlatego że to jest relatywnie proste bo te moduły są łatwe niewielkie nie ma tam jeszcze dużego complexity ale z czasem to się robi frustrujące węc oprócz bycia nieefektywny pojawia się też właśnie temat frustracji dlaczego jest taki termin jak cognitive load cognitive LO to jest tyle ile pojedyncza osoba jest w stanie ogarnąć w głowie powyżej pewnego poziomu systemy mogą stać ty skomplikowane że jest to po prostu nierealne WT powoli zaczynamy zapominać pewne szczegóły zaczynają nam Umykać w związku z tym Jeżeli nie umiemy zarządzać wiedzą w organizacji nie umiemy podzielić tej wiedzy podzielić jej na pewnego rodzaju moduły części
składowe z jasnymi odpowiedzialności to wiedza w naszej organizacji staje się jaką wielką nieokreślona chmurą której nikt tak naprawdę nie nie łapie ta frustracja się pojawia Ludzie z naszej firmy uciekają i wtedy nawet nie jesteśmy w stanie w ogóle zmierzyć tej wiedzy którą mamy w organizacji jak dużo na przykład urosło a i nawet nie wiemy jakie są konsekwencje tego czy na ile mniej efektywna stała się cała organizacja dlatego że my się nawet boimy zmiany czasami Czyli trzeba dotknąć jakiegoś modułu jakiegoś wycinka funkcjonalności dla którego ta wiedza z organizacji Już uciekła i teraz my wpadamy w taki Safe Mode i staramy się na przykład modyfikować Czy dawać tą funkcjonalność w sposób który minimalizuje ryzyko czyli na przykład dobudowuje gdzieś z boku Zamiast zmieniać ten model który był pod spodem także to taki powiedzmy Powiedziałbym to jeszcze ciekawy ciekaw ciekawa Sytuacja która może nastąpić a więc podsumowując wszelkiego rodzaju nieefektywności to jest dla mnie taki pierwszy efekt Cześć Robert Cześć wszystkim chciałem dorzucić troszkę może moich obserwacji z też może będzie dla was cieka z perspektywy trochę mniejszych teamów startupowych teamów czyli takich
teoretycznie troszkę szybciej i troszkę może mniej o tym faktycznie jak dokumentować No bo wydaje mi się że okej Dużo ludzi może patrzeć na No shing przez pryzmat dokumentacji ale wydaje mi się że są też takie rzeczy które Może są trochę mniej związane ale bardzo dobrze na to wpływają i właśnie jednej rzeczy fajne wspomniał Sebastian to znaczy jeśli jeden Team ma faktycznie za dużo wiedzy do ogarnięcia to jest na pewno jeden taki pierwszy bloker żeby faktycznie działa bo jak tej wiedzy jest po prostu za dużo w jednym teie to no po prostu ciężko jest tą wiedzę dzielić bo to się nie skaluje także tu pewnie każdy kto trochę miał do czynienia z DDD wie coś słyszę o Band kontekstach i to na pewno byś może pomóc ale jeszcze inne takie trochę może mniej oczywiste rzeczy które przyszły mi do głowy no to na pewno Wydaje mi się bardzo dużo pomaga jeśli Team Działa bardzo autonomicznie w sensie jeśli gdzieś pracujemy w jakimś teamie gdzie dostajemy taski do implementowania a nie funkcjonalności to też ciężko powiedzieć żeby gdzieś ten był tak po prostu jesteśmy osobami które wykonują coś i nawet nie znają za bardzo tego kontekstu i wydaje mi się to jest taka wiadomo dla niektórych to może być oczywiste że okej jak tak może być ale
też No gdzieś poza naszą bańką dalej jest sporo takich firm które mają z tym problem I wydaje mi się to też jest taka niby nieoczywista rzecz a bardzo ważna żeby faktycznie Team działa autonomicznie i sam rozwiązywał te problemy bo wtedy kiedy on jakby sam to rozwiązuje musi musi naby ten kontekst Jeśli on dostaje konkretny task do wykonania No to często to nie wymaga jakby zdobycia Tego kontekstu i ta wiedza No nie musi się za bardzo rozprowadzać po teie więc to to się po prostu nie dzieje druga rzecz która też mi przyszła do głowy to na pewno unikanie pewnego rodzaju głuchego telefonu to znaczy w momencie kiedy faktycznie Toś to to powiązane z powszednim punktem w sensie w momencie kiedy coś [Muzyka] ami czy biznesem to też mamy troszkę można powiedzieć zepsuty Obraz może tej wiedzy która może nie jest do końca wiedzą techniczną ale wydaje mi się wiedza techniczna Jak już wcześniej Wojtek wspomniał jest to może często mniejszy problem niż taka wiedza domenowa w sensie że jeśli mamy jakiegoś prod managera który ogarnia za nas logikę wszystkiego to też gdzieś część tej wiedzy znika My też nie mamy jakby motywacji żeby tą wiedzę zrozumieć i też
ta wiedza po prostu gdzieś ginie nie I to wydaje mi się że jest drugim wielkim problemem trzecią rzeczą którą gdzieś też czasem spotkałem problemem jest to że czasem organizacja jest zbudowana z takich samotnych Wilków któ implementują dane funkcjonalności i to też nie może się generalnie skończyć dobrze Jeśli chodzi o często jakby jest dużo jakiś ukrytych założeń jakś dużo ukrytych decyzji które toa jedna osoba Jeśli ona implementuje całą funkcjonalność No to prawdopodobnie gdzieś to zostanie w jego głowie i możemy skończyć z tą sytuacją kiedy Bardzo często ludzie chodzą do jakiejś jednej osoby która implementować bardzo ważne funkcjonalności tylko ona wie jak tylko ona wie jak do tego podejść swą drogą pewnie można polecieć tu Phoenix Project bo wydaje mi się tam ta sytuacja była dość fajnie opisana także tak i Czwarta rzecz może też nie do końca powiązana ale wydaje mi się że jest takim papierem posem ciekawym który pokazuje jak działa nas w organizacji to może od jakiegoś czasu trochę kontrowersyjna rzecz nie wiem czemu Chociaż może Wiem wiem czemu w niektórych organizacjach tak jest ale Code review w sensie Wydaje mi się że jeśli Dobrze zrobimy trzy poprzednie
punkty to znaczy faktycznie nie będziemy Meli za dużo wiedzy w teamie będziemy działać autonomicznie i będziemy unikać głuchego telefonu no i nie będzie to implementowany przez jedną osobę to cod RW powinno być generalnie raczej formalnością w sensie każdy powinien Wieć dje każdy powinien wiedzieć czemu to tak było zrobione a jeśli nie jest formalnością tylko ciężkim procesem którego ludzie unikają jakby przechodzą przez to jak najszybciej bo to marnuje czas to prawdopodobnie znaczy że coś mogło pójść nie tak wcześniejszych punktach z mojej strony Wielkie dzięki jeszcze raz dzięki Rober i zapraszamy wszystkich do dyskusji powiedziałeś sporo rzeczy ja bym chciał się którą powiedziałeś odnośnie autonomii To był chyba pierwszy punkt i tutaj powiem że w 100% o ile zrozumiemy i ustalimy pewien kontrakt między zespołami co współdziel tak i te współdzielone rzeczy powinny być na pewno US spójną i tutaj właśnie chociażby Myślę że to co jest bardzo ważne to chociażby zasady pewne zasady odis
jeż chodzi o pisanie oprogramowania utrzymywania na produkcji po chociażby zatrudnianie czy ocenianie jakieś kwartalne czy półroczne pracowników te zasady powinny być spójne i powinny być udokumentowane więc to warto wrzucić na warsztat Tomku Chyba chciałeś się też odnieść do kilku rzeczy chciałem się trochę odnieść wejdziemy podem techie narzę do Jeżeli ktoś dostaje taski nie zna kontekstu i tak dalej no to trudno jest tą wiedzę żeby ona się propagowała i tak dalej tut z mojego trochę doświadczenia jest tak że najlepszym sposobem znaczy jednym ze sposobów może nie najlepszym ale żeby ten kontekst był to jest właśnie to żeby wszyscy trzymali ten kontekst tam gdzie on żyje i te taski istnieją nie bo po prostu jeżeli ktoś dostaje task do wykonania nawet taki to powinien być w stanie prześledzić orygin tego tasku w tym samym miejscu nie Czyli okej to ten task jest częścią czego skąd to wynikało gdzie na końcu jest to gdzie na końcu jest to wymaganie do czego to kontrybuuje tak jeż moje doświadczenie było takie że jeżeli ktoś zadbał o to i pilnował tego przy produkcji projektu czy czy kodu No to to dobrze działało bo tylko to jest trudne
nie bo potem nawet jak właśnie nawet jak Robert powiedział Code review nie to jeżeli wykonujemy Code review to potem jest okej To gdzie gdzie wnioski z tego lądują i te wnioski nie powinny tylko ować w postaci komentarza do kodu ale do kontrybucji OK Słuchajcie zmieniliśmy to dlatego w taki sposób i tak dalej więc to trochę tak od strony narzędziowej i podejścia do całości tutaj wchodząc gładko w ten temat rozpocząłeś Ja bym chciał jeszcze jedną rzecz dotknąć Że też proponowałbym z praktycznego punktu widzenia Nie stosować J jednego sposobu rzęzi wszystkich tak jakby poziomów wiedzy w organizacji ja sobie stworzyłem tutaj takie kilka poziomów pierwszy poziom wiedzy to jest moja własna wiedza tak I tutaj każdy z nas pewnie myśli i funkcjonuje inaczej Więc też chętnie się pociągnę was za język czego wy używacie do tworzenia jakiś własnych notatek i budowania swojej własnej wiedzy drugi bym powiedział że to jest wiedza zespołowa gdzie też bardzo często ta wiedza zespołowa jest też podzielona na przykład na różnego rodzaju czy to platformę czyli na przykład wiecie czy Pracuj z danymi czy pracuj nad
infrastrukturą czy pracuj nad backendem czy na przykład właśnie nad frontendem czy może security i tak dalej i tak dalej trzecia to jest no i tutaj już wchodzimy jak jest zbudowana organizacja w jakieś triby lub departamenty No i czwarta ogólna wiedza w organizacji więc też pewnie różne narzędzia i różny sposób dokumentowania i różny sposób współdzielenia tej wiedzy jest więc pytanie do was jakie właśnie narzędzia na tych ewentualnie różnych poziomach Tak w wielkim skrócie bo tematów mamy sporo ale jakie narzędzia stosujecie i co byście polecali te narzędzia to może tak wejdę o poziom wyżej bo narzędzia to nie jest tylko i wyłącznie software narzędzia to są jakby trzy kategorie czegoś co możemy zaaplikować know Management dla mnie to te te trzy nie wiem typy to to są miejsca Czy formy zapisywania wiedzy techniki które są stosowane No i to trzecie to są jakieś narzędzia organizacyjne teraz może doprecyzuj co mam na myśli więc tak jeżeli chodzi o te miejsca Czy formy zapisywania informacji No to tu możemy mieć na przykład klasyczną dokumentację czyli piszemy dokumenty możemy mieć rekordy czyli dla transparencji listę czegoś co
chcielibyśmy komuś udostępnić co się wydarzyło po prostu Logi na przykład log podjętych decyzji architektonicznych to nie jest dokumentacja to jest po prostu log czego co się wydarzyło on może nie być doskonały ale on opisuje rzeczywist trzecia taka takie miejsce taki typ takiego miejsca to może być na przykład jakieś Wiki jakaś Baza Wiedzy czy coś co nie jest formalną dokumentacją coś co nie ma na przykład ą nie jest tylko coś co ma być Evergreen czyli opisuje na przykład stan rzeczy On nie jest idealny ale staramy się żeby ten g był jak najmniejszy i tutaj rodzaj tych tych narzędzi które można wpisać Jest ich bardzo dużo bo to można zacząć właśnie od jakś tam Wiki know Management systemy sharepoint portale aż po Development portals które ostatnio są bardzo bardzo modne o których pewnie sobie możemy tutaj powiedzieć tak jak chociażby backstage więc tutaj te miejsca i formuły druga to techniki i to o technikach te żeśmy już trochę powiedzieli czy Code review to nie jest artefakt to jest technika ale to jest też technika która służy zarzuceniu wiedzą inne tego typu techniki to są na przykład S meetings czyli spotkania na których synchronizuj stan wiedzy odnośnie na przykład jakiegoś projektu Nawet stupy to jest pewnego rodzaju jakaś forma zarządzania wiedzą radiacja informacji to też jest bardzo dobra technika czyli zastanawiamy się nad tym w jaki sposób my udostępniamy na
zewnątrz te informacje o nas które są niezbędne innym żeby mogli egzystować nawet głupie retrospekcje to też jest jakaś technika na managementu również też No i w ogóle jakieś formalne learning programs które mogą być w organizacji na przykład służące temu żeby up skillować ludzi którzy są nowi albo ludzi którzy są nowi w danej roli to też jest znowu jakaś tam technika No i koniec końców te mechanizmy organizacyjne No to tak mechanizm organizacyjny k jak dla mnie wymusza rzeczy odnośnie Management jest chociażby na przykład team lel Czyli że odpowiedzialność za coś na przykład nie za projekt produkt cokolwiek jest na poziomie jakiegoś zespołu bo to wymusza pewne zachowania w zespole żeby to Cały zespół był w stanie coś utrzymać a nie tylko i wyłącznie jen Hero który gdzieś tam sobie z boku jest in tak organizacyjna organizacyjny mechanizm to jest na przykład comm practi Czyli jeżeli zrobimy sobie organizację trochę powiedzmy bardziej formalnie bardziej macierzą nie jakieś nie wiem back endow APC czy cokolwiek to w ich pewnego rodzaju konstytucj będzie wpisane na przykład zachowanie wiedzy czy udokumentowanie wiedzy czy uspójnienie wiedzy odnośnie tego ich jakiegoś konkretnego obszaru więc tak idąc od góry to ja bym widział Takie tak taką taką klasyfikację rał do nas dołączył cześć cześć cześć cześć cześć Słychać mnie chba Słychać to
ja jeszcze bym tutaj zwrócił uwagę kilka w ogóle rzeczy wiele rzeczy z punktu widzenia kilku różnych osób w zespole na przykład Product managera ux designera czy też dewelopera ta wiedza jakby się troszeczkę inaczej kształtuje tak no bo jedna rzecz to jest to że ją gdzieś chcemy zapisywać być może właśnie szerować jak szuj to musimy zmienić ten cognitive load o którym tutaj mówiliście tak Czyli zmniejszyć zazwyczaj cognitive Tak żeby druga osoba nas zrozumiała I to ma miejsce w szczególności w sytuacji w których zamieniamy czy wymieniamy się czy różne role się ze sobą komunikują tak Czyli jak się Deweloper z deweloper komunikuje No to już nie ma czegoś takiego jest jakby możemy jechać dokładnie na tym samym poziomie W związku z tym nie ma tego problemu Natomiast jak mamy komunikację nie wiem Product manager versus inżynier no to wtedy musimy uprościć pewne koncepty druga rzecz którą tutaj też warto wydaje mi się powiedzieć to to jest to że to jest nie tylko Nor sharing ale też praca z tą wiedzą No bo jak ktoś mi przekaże tą wiedzę to być może potem ja chcę z tą wiedzą w jakiś sposób pracować w swoim
kontekście na przykład ją doprecyzować tak albo robić swoje jakieś eksperymenty więc więc to jest też pewien jakiś jakiś aspekt który na którym można byłoby się zastanawiać są różne oczywiście techniki modelowania tutaj można by było wejść w różne tego typu techniki już tutaj ktoś wspomniał o domain Driven Design ale siłą rzeczy w przypadku akurat modelowania mamy nie wiem event storming event modeling gdzie zespół pośrodku widzi dokładnie jak jak czy proces wygląda Czy jak aplikacja wygląda ale być może ktoś inny chce to sobie zaczerpnąć do swojego kontekstu No i na przykład Product manager mógłby zrobić sobie tranzycje doem user Story mappingu tak albo mógłby to w jakiś sposób inny urozmaicić tak w taki sposób w który po prostu on pracuje z danymi On potrzebuje tą tą wiedzę sobie wypracować zastanawiać się nie wiem nad jakimiś insi tak nad jakimiś metrykami nad może jakimiś impakt Tami Tak więc Knowledge sharing to nie tylko jest no hand off jakiegoś kontekstu ale
też potem praca w tym z tym kontekstem urozmaicenie go w jakieś specyficznej roli No i to wszystko dzięki Okej dzięki to ja wejdę trochę innym innym kontekstem właśnie bo tutaj dużo mówicie o tym jak to wygląda z punktu widzenia dewelopera czy zespołu pracującego nad kodem i to wcale nie dziwi nie tak trochę bardziej z organizacyjnego podejścia bo różne techniki na poziomie różnych tych elementów o których Sebastian powiedział ale jednym z lep jest bo jednym z dużych problemów zawsze przynajmniej z którym ja się borykał jest tak jakby znalezienie tego co już jest zebrane nie i z takich rzeczy który mi się są dwa elementy w zasadzie tak jeden to jest taki że procesy w firmie są jakimś sposobem dzielenia się wiedzą też nie czyli albo jej zapisywania bo to nie musi być dokument cokolwiek tylko układanie procesu który w jaki sposób działa jest powtarzalny To jest zapisywanie wiedzy organizacyjnej w postaci procesu to jest pytanie czy ten proces w głowach ludzi czy jest gdzieś opisany jak jest opisany i tak dalej taka technika która nam jakoś dobrze działała też jest taka że my standaryzowanie tego gdzie to jest w jaki sposób jest to dostępne i tak dalej tak A druga rzecz która jest bardziej
taka kulturowa ale się sprowadza do tego też jest taka że jak my tworzymy politykę czy kulturę dostępu do tego i tutaj przykład z mojego podwórka Generalnie cała informacja jest dostępna dla każdego na przykład w organizacji No może nie cała Ale założenie jest takie że jeżeli Tworzymy nową witrynę czegoś czy jeżeli tworzymy nowy projekt to on jest wyszukiwany i dostępny dla każdego tak a i na przykład my gdzieś tam próbowaliśmy w ten sposób to robić żeby Każda taka informacje dokumenty i tak dalej były jak najbardziej dostępne dla osób które mogą chcieć ją znaleźć nie więc to nie tylko same narzędzia ale też sposób w jaki podchodzimy do tego kto ma do tego dostęp w jaki sposób może to znaleźć i unifikacji tego w ramach organizacji że jeżeli czegoś szukasz to w taki sposób jeżeli to jest polityka to ona jest w tym miejscu i na pewno w tym formacie tak dotknąłeś kilku strasznie ciekawych rzeczy bo tak zacząłeś od tych właściwości jakie powinna spełniać ta wiedza żeby ona była użyteczna i te tradycyjne trzy właściwości to było tam indexable navigable i to jest kilka strasznie fajnych antyp na przykład ja znam takiego faila z bardzo dużej organizacji gdzie wdrożyli system zarządzania wiedzą ale on nie był hierarchiczny i to znaczyło że nie dało się go przegnać jak
struktury katalogów więc to że Kyś stworzył jakiś dokument to niekoniecznie wszyscy inni musieli o tym wiedzieć nawet jeżeli są z jego zespołu to się skończyło takim spektakularnym fejm coś niesamowitego ale no nie mamy czasu na wjeżdżania w takie takie tematy ale chciałem do tych bo powiedziałem o tych trzech właściwościach ale chciałem tylko zahin nować że do nich dochodzi czwarta właściwość i ona teraz dochodzi bardzo mocno to jest Machine readable dlatego że do tej pory my byliśmy przyzwyczajeni do tego że co najwyżej nasza przy wanem a w tym momencie My już coraz częściej opieramy się na jakichś modelach modelach również uwaga po raz pierwszy pojawiło dzisiaj coś zaczy mogę się podzielić bo zanim stało się modne pewnie w okolicach 17 2018 zrobiliśmy właśnie takie podejście też nie Czyli jako firma pracująca wiesz głównie na projektach z klientami to tworzymy jakieś dokumenty i mieliśmy takie podejście dokładnie żeby że indeksow Almy dokumenty ale nie w taki sposób że z indeksowy słowa kluczowe czy coś tylko przypuszczaliśmy je przez model tam zbudowany pod to na ma learning który starał się wyciągnąć czego ten dokument dotyczy nie i między
innymi wynikiem tego było to że w jakimś tam miejscu które miało te dokumenty mówił tego dokumentu wskazuje że on dotyczy takiego rozwiązania i takiego problemu nie I to generalnie automat leciał skanował iał na bieżąco Jak dotknąłeś Sebastian już kwestii modeli generative Ai to ja mogę powiedzieć że te modele świetnie się sprawdzają do dwóch rzeczy w tworzeniu dokumentacji na pewno do większej ilości ale do dwóch szczególnie pierwsza rzecz dobry angielski jest trudny tak i z reguły pracujemy po angielsku w firmach bardzo ciężko czyta się dokument który jest bardzo źle po angielsku napisany mogę powiedzieć ze swojego doświadczenia więc jeżeli mamy Draft jakiegoś tekstu można wrzucić to w w model niech przemielić bardzo ładny z automatu bardzo ładny tekst porównaniu do grammarly Możemy też nadać temu odpowiednią formę lub na przykład rozwinąć dane tematy więc te modele lub skrócić więc te modele są bardzo fajne do tego i polecam spróbować więc myślę że tutaj gramar dost dostało ode mnie przynajmniej
minusa w porównaniu tego co można zrobić z modelami druga rzecz bardzo trudno jest pisać dobry zwięzły tekst to jest też umiejętność którą Ja obserwuję w zespołach No wiele osób pisze w jedną lub drugą stronę tak w sensie Albo Mamy ogromne dokumenty 14 minut 15 minut szacowanego czytania żeby zrozumieć bardzo stosunkowo prostą rzecz lub w drugą stronę nie mamy tej treści więc też te właśnie dokument te modele świetnie się sprawdzają jeżeli tworzymy daną treść to żeby właśnie ją albo skrócić albo odpowiednio przygotować tak w danej danej formule więc serdecznie polecam takiego haka którego sam stosuję całkowicie się zgadzam z tym co powiedziałeś na temat Kon to trochę będę w kończ do tego co powiedziałeś wcześniej odnośnie modeli bo to jest uważam że to jest całkiem cwe i to jest taka jedna rzecz którą można z tego odcinka wynieść jak tak zastanowi się jakie byłoby fajne źródło wiedzy odnośnie tego jak na przykład dokumentować jak w ogóle robić Jak zapisywać dane jak upewniać się że te dane na przykład będą większą szansę być up to date bo to jest chyba największy cheng managementu bo zapisanie jakiegoś Snap shotu wiedzy dla na dany moment jest relatywnie proste powiedzmy no może też
nie jest trywialne jest relatywnie proste ale jak to utrzymać up to date przez dłuższy okres czasu tak żeby ta dokument nie trafiła bardzo nie traciła bardzo szybko na wartości to to jest wyzwanie No więc to co mogę tutaj zarekomendować i to co akurat stoi właśnie w tej opozycji do j to jest taka już dosyć stara bo to jest 2017 rok czyli 6 lat książka człowieka który się nazywa książka ma tytuł Living documentation i ona jest dosyć ciężko dostępna bo została opublikowana w singu wpie potem chyba ktoś jakiś duży wydawca na chwilę też to podchwycił W każdym razie ta książka Living documentation Ona właśnie opisuje w jaki sposób tworzyć dokumentację której która nie będzie owa która nie będzie stawała się updated No i tak żeby zowa nie to że tylko wam polecę do sprzedania do kupienia Przepraszam ale żeby powiedzieć jakie tam techniki są umawiane i na czym ta książka się koncentruje więc tak ona się koncentruje na tym że jeżeli my coś opisujemy w dokumentacji to opisujemy pewien zamysł pewien Design pewien Mental model i teraz jeżeli piszemy na przykład kod który to s odzwierciedla to w kodzie używamy konstruktów właściwych języka programowania C frameworka to znac na przy mamy jav to
ja jesteś Ja nie ma ciągle takiej abstrakcji jak serwis czy już pojawiły się moduły są klasy są interfejsy ale serwis nie ma natomiast często projektując coś używamy takie konc Mikros cwiek teraz mieli gdzieś tam jakieś mikroserwisy w głowie ale wyrazili to za pomocą klasy interfejsów to gdzieś być może sposób implementacji czegoś co oni mentalnie nazwali mikroserwis zmieni się w czasie może przestanie być spójny bo być może kilka osób będzie miało inny pomysł na to czym jest ten mikroserwis teraz w związku z tym jedną z tych technik o które opisuje kolega Mart to jest właśnie to żeby używać DSL domain specific langu do tego żeby tworzyć te same koncepty z naszego języka designerskiego że były one odwiercie w kodzie po to żeby można było mapować nasze koncepcyjne jakieś byty na to co faktycznie jest w artefaktach dzięki temu co jest dzięki temu możliwe dzięki temu możliwe jest kilka rzeczy po pierwsze dzięki temu możliwe jest automatyczne tworzenie przynajmniej częściowe dokumentacji dzięki temu możliwa jest automatyczna walidacja dokumentacji Czyli jeżeli na przykład tu ma być pięć modułów i teraz moduł A może korzystać tylko z modułu b to potem da się to sprawdzić w kodzie dlaczego Bo w kodzie nie tylko można
znaleźć klasy ale w kodzie można znaleźć te moduły bo ten moduł zaczyna być bytem żyjącym w tym kodzie dlatego że na przykład Java wprowadziliśmy właśnie ds czy co mamy automatyczną walidację mamy możliwość tworzenia jakieś asercji w tym kodzie mamy tak zwane mamy jakiegoś takiego dsla który przedstawia ten nasz zamysł designerski który mieliśmy wcześniej w związku z tym bardzo fajnym przykładem jest xwiki Nie wiem czy znacie xki to jest taki takie Wiki które po pierwsze ono meru generowane automatycznie wsadem który został wpisany ręcznie to oznacza że to nie jest tak że jeżeli my coś piszemy ręcznie w takim Wiki to myjemy to zostało wygenerowane automatycznie jest taki mechanizm który umożliwia tym dwó rzeczom istnieć jednocześnie i równolegle Także polecam Living documentation tam jest dużo fajnych hint te hinty jak ktoś jest fanem DD one są kompatybilne z podejściem DDD Dzięki nim można zacząć myśleć o tworzeniu dokumentacji która nie tylko jest automatycznie weryfikowana ale też jest w ogóle to ja bym tak Ja zdecydowanie też Polecam tą książkę więc dwa polecenia przechodzi do następnej rundy natomiast jeszcze tam była też
fajna rzecz że on Podkreślał też że właściwie różnego rodzaju różnego rodzaju artefakty Możemy też zaat inaczej ułatwić tworzenie ich też wizualizację diagramy co jest teraz bardzo proste przy pomocy Mermaid więc tak jak właśnie można to można to dosyć łatwo wszystko połączyć jak najbardziej Tomek czy jakieś ciekawe inne narzędzia byś ty polecił wiesz co narzędzia są trochę bardziej specyficzne do tego co gdzieś tam robiłem czy ten więc chyba nie do tego co dodaliście bo to już wchodzimy w bardzo specyficzne jak dana organizacja do tego podeszła czyli na przykład jak my to robiliśmy C ja to gdzieś tam widziałem nie takie chyba mam gdzieś tam na kolej tak bardzie myślę właśnie bo wy mówicie dużo o narzędziach dookoła kodu więc żeby było coś dooko z innej ten no to to są narzędzia procesowe nie czyli Wiesz jest takie Jak przeprowadzić onboarding jak go ustrukturyzować na przykład to było duża rzecz którą my mieliśmy nie Czyli jak Jak szybko spowodować że ktoś jest aktywny w organizacji i posiada właśnie tą podstawową wiedzę nie i też mu pokazanie gdzie ta dalsza Wiedza jest czyli na przykład powiedzenie Słuchaj Tutaj znajdziesz wszystkie informacje
których ci nie powiedzieliśmy w szczegółach nie Więc to już bardziej wchodzimy w temat procesu i tak dalej nie mogę się i to mi się bardzo podoba to co mówisz dlatego że ja mam wypisane tutaj gdzieś na boku w moich notkach też takie ryzyko że te mięśnie nieużywane one ulegają atrofii i teraz ryzykiem na przykład pójścia w takie Living automation jest to że my gdzieś mamy zapisaną tą naszą automatyzację w postaci jakichś reguł w postaci jakichś mechanizmów i koniec końców okazuje się że nasza firma rośnie jesteśmy na fajnej krzywej wznoszącej zatrudniamy dużo ludzi i po nagle półtorej roku okazuje się że ta wiedza specyficzna dla naszej organizacji będę nie mówię o wiedzy generycznej tylko wiedzo specyficzne w naszej organizacji ona uciekła jest gdzieś tam zapisana w jakiś narzędziach które są ciężkie do utrzymania i nagle okazuje się że nie jesteśmy w stanie zrobić jakiś atomowej elementarnej zmiany Więc strasznie ważne jest żebyśmy tego problemu nie obchodzili Tylko żebyśmy faktycznie poprzez wymuszenie czasami zmian w te w tej w tej w tej w tym kodzie w tej w tych narzędziach w tej automatyzacji żebyśmy jednak musieli tego Spy kać żebyśmy jednak musieli to refakturować żebyśmy jednak musieli coś z tym robić żeby ta wiedza w naszej organizacji zostawała to jest trochę procesowe tak powiedziałeś trochę nieprocesowe natomiast dla mnie ten ten taki element preserve jeżeli chodzi o zachowanie wiedzy w organizacji jest istotny bo jednak to się wydaje ale z
czasem jakiś turnover w naszych organizacjach jest to jest często powyżej 10 proc czasami powyżej kilkunastu procent i okazuje się że ta wiedza szybko znika Zwłaszcza jeżeli No my w żaden sposób nie pilnowali miy tego żeby ten bakor był ogan żebyśmy tutaj wiedzieli o czym mówimy turnover w naszej branży to jest powyżej 20 taki średni więc ten problem jest i on jest znaczący tak naprawdę no i tutaj jest coś co ja mogę polecić czyli na pewno coś co dobrze działa to jest identyfikacja tej wiedzy której nie mamy i adresowanie jej czyli na pewno jeżeli jeżeli Znajdziemy się w sytuacji w której widzimy że czegoś brakuje lub nie jesteśmy wanie znaleź No to jak mieć mieć sposób żeby to zaadresować tak czyli na przykład żeby to mogło być jakoś eskalowany lub dodawane do jakiegoś repozytorium z prośbą o uzupełnienie więc tutaj jest kilka technik które pewnie można zastosować ale na pewno zbudować kulturę w której zespół proaktywnie identyfikuje takie braki wiedzy i proaktywnie też działa żeby wizę uzupełnić to ja tutaj wejdę i spytam się bo ja Przyznam się szczerze kilka z rzeczy o których mówicie jest
moim Nemesis próbowałem do tego podejść nie udało się i w szczególności to co powiedziałeś bo Takie wyzwanie z którym ja się zawsze jakoś w organizacji mierzyłem też to jest to że ludzie którzy mają tą wiedzę to trochę chyba powiedział o takich samotnych wilkach nie ale nie musi być samotny wilk ale ludzie którzy mają tą wiedzę przeważnie uważają znaczy są zajęci nie i uważają że no nie Dokumentacja nie jest priorytetem Ustalmy nie bardzo często jest tak że ja bym z chęcią to robił ale dokumentować już nie i i pytanie właśnie z waszego doświadczenia jak podejść do tego żeby jednak ten proces się odbywał bo to chyba jest największe wyzwanie w tym wszystkim nie żeby ten proces odbywał się w sposób ciągły a nie w Zryw tak dokładnie podzielę się taką podzielę się taką właśnie bo mieliśmy taką spektakularną porażkę nawet No bo zespół mieliśmy problem z zachowaniem wiedzy takiej czysto projektowej ale znaczy nie projektowej ale technicznej ale specyficznej dla naszego kontekstu projektów i tak dalej nie i dzieleniem się nim no i zespół sam świat nad tematem i powiedział Okej to St overflow jest rozwiązaniem nie wż ten st overflow pół roku Później umarło właśnie z tego powodu o którym mówiłem na końcu ci którzy widzieli problem nie czuli potrzeby
kontrybuować czyli Project Phenix bo tam jest dokładnie opisana ta sytuacja tak Czyli ktoś jest na tyle zajęty że nie ma czasu przekazać swojej wiedzy i Ja powiem szczerze to nie jest to nie jest łatwy problem do rozwiązania tak bo z reguły zajętość tej osoby też z czegoś wynika natomiast jest kilka sposobów jakim możemy to zaadresować które ja widziałem że w różnych sytuacjach działały no pierwszy i najważniejsze to ta osoba powinna zrozumieć że to jest problem tak bo jeżeli ta osoba rozumie że jest zajęta wożeniem tych taczek zamiast tak naprawdę podzielić się jak załadować te taczki i rozdzielić to i nie widzi w tym problemu no to faktycznie to jest większy problem Natomiast jeżeli faktycznie już dojdziemy do sytuacji w której mamy pełną zgodę że okej to trzeba tą wiedzę współdzielić No to coś co może działać to jest małymi krokami nie robić takiego wiecie full stopu I teraz udokumentuj wszystko co robisz tylko małymi krokami na przykład w formie Nie wiem kwartalnego celu udokumentowanie pewnego rodzaju procesów gdzie też Podczas tego może być na przykład też właśnie zrozumienie wymagań innych zespołów więc to jest coś co osobiście widziałem że działa Seb nie chciałbym zabrzmieć tutaj
jako jakiś fan Boy jeffa bezosa ale ten gościu kilka fajnych rzeczy w życiu wymyślił jedną z rzeczy których powiedział to jest to że dobre intencje nie działają działają mechanizmy w związku z tym to co powiedziałeś Wojtek tam że jakby edukujemy ludziom żeby tam rozumieli i tak dalej No u mnie to nie działa może za słaby że żeby ludziom to tłumaczyć do tego przekonywać więc ja jestem ja raczej praktykował makiaweliczne praktyki na przykład no wpisuje w rolę seniora że rola senora to jest to że ma wdrożyć cały zespół że cały zespół ma to ogarniać tyż z tym jest problem jaki z tym może być problem No trzeba to supportować czasami to trzeba sortować więc ten jedor nie może tego sortować przez wszystkie dni tygodni na dobę Nie bo tutaj też są wprowadzone jakieś ograniczenia bo są wprowadzone w mechanizmie czyli na przykład że osoba może supportować maksymalnie nie wiem 24 godziny w tygodniu czy cokolwiek no już rzuciłem liczbą zupełnie losową w związku z tym jeżeli zespół ma ten problem że nie ma wystarczającej ilości ludzi którzy mają tą wiedzę i są w stanie sortować No to jest również odpowiedzialność tego seniora nie był w stanie przekazać tej wiedzy ludziom w zespole więc budując mechanizmy jesteśmy
w stanie w makiaweliczny sposób to dzielenie się tą wiedzą właśnie za pomocą takich przykładów jakich powiedziałem przed chwileczką także wierzę w mechanizmy ale to się nie wiesz to wręcz się nie wyklucza uzupełnia to co powiedzieliśmy bo właśnie powiedziałem że wiesz dajemy cel takiej osobie jeżeli dotychczas tego nie zrobiła i no i to jest cel który jest do dowiezienia Tak więc myślę że akurat tutaj dosyć podobnie na to patrzymy natomiast mi chodziło wiesz o to że dużo większy osoba nie widzi tego problemu to jest troszeczkę inny rodzaj problemu wtedy tak No dobra słuchajcie ale chciałem teraz jak już dotknęli takiego takiego takiej ciekawej sytuacji to chciałem was spytać o takie o takie inne inne sposoby dostrzegania jakiś silosów wiedzy i anty patternów jak jako Liderzy właśnie możemy dostrzegać takie sytuacje No jak możemy Sebastian No jest kilka tak można zauważyć wiw jest taki że po pierwsze ludzie nie chcą pracować z kimś konkretnym z jakąś konkretną osobą czyli
pojawiają się jakieś insynuacje że ktoś może być toksyczny że ktoś jest trudny współpracy że ktoś nie za bardzo się chce dzielić tym co tam ma w głowie to to jest taki może bym pierwszym to jest że gdzieś jakość spada spada i nie tylko pojawia się jakaś na przykład większa ilość incydentów ale też wzrasta czas rozwiązywania incydentów dlaczego Bo one się kolejk kują dlaczego się koleją bo może to rozwiązać tylko i wyłącznie jedna osoba albo dlatego że rozwiązywanie incydentu trwa długo dlatego że ono wymaga refactoring kodu czyli osoba musi w ogóle zrozumieć nauczyć się w ogóle jak to działa bo Jedynym miejscem gdzie to jest przechowane jest tylko i wyłącznie kod to też jest taki warning dla firm takich dosyć mocno szybko rosnących takim na pewno War też dużo zwrotek w momencie testowania wczesnych wersji jakś nowych ferów czyli ktoś coś zaprojektował jakiś proder to tam pielęgnował jakiś designer zaprojektował zostało to wrzucone w kod ale jest dużo niedomówień to nie tak miało działać czegoś brakuje i to ewidentnie widać że wtedy mamy problem z tą dokumentacją która ma odać rzeczywistość na chwilę obecną czy g
komunikacja albo to zostało Źle zapisane zostało nieefektywnie zapisane Może nie zostało zapisane nie zostało skomunikowane gdzieś tu jest jakiś problem komunikacyjny bo to jest w ogóle taka rzez kt żeśmy mało dotknęli nie Czyli w ogóle jak powinna wyglądać dobra dokumentacja czy dobra dokumentacja powinna opisywać tu i teraz czyli to jest twoje user Story to jest twój feature czy dobra dokumentacja powinna opisać pewien model stojący za tak żeby się dało z tego łatwo wywnioskować czy dobra dokumentacja powinna J coś innego W każdym razie tutaj ten nasz wybór może mieć dużo implikacji tak jedna z tych implikacji to już są właśnie na poziomie jakiś tam odbioru pseud odbioru jakieś jakieś jakieś takie tarcze które się pojawiają A inna inna sytuacja jest taka że jakby inny taki warning jest taki że No my po prostu możemy mierzyć ilość przecięć z tą dokumentacją Jak często ludzie z tego korzystają jeż się okazuje że tam w ogóle nie ma żadnych sezy na tym jeżeli się w ogóle okazuje że tam nikt z tego nie korzysta nikt nie przegląda w ogóle nikt tego nie aktualizuje bo to jest też ważne No jeżeli jest dokumentacja która niby teoretycznie jest okej ale nikt jej nie aktualizuje to coś jest nie tak albo nic nie robimy Nic nie zmieniamy No albo wszyscy mają ją gdzieś bo być może to źródło wiedzy jest gdzie indziej prostu w głowach więc niby taka prosta metryka typu Jak często ludzie coś tam medytują ale to też jest to też jest jakiś warning kolejny warning to są jakieś eskalacja w związku właśnie z zapisywaniem do dokumentacji Czyli jeżeli mamy takie tendencje w organizacji do tego że okej Wy możecie
nam zmieniać dokumentację ale musicie dostać nal to już jest coś dziwnego ale o co chodzi A jeżeli jest to bardziej zdrowej zasadzie Czyli że w sumie zmieniać może każdy i zmienia każdy albo to jest na jakiegoś requestu czy Dokumentacja jest tak w tym momencie Jestę bardziej zdrowe natomiast patologie potencjalnie kierunku Tomek doświadczenia albo Rafał i Rober Jeśli chodzi tutaj tutaj jest jeszcze kilka takich może ciekawych rzeczy odnośnie samej dokumentacji bo słowo dokumentacja padło C kilkanaście raz się zastanawiam tak a tak na dobrą sprawę to po co ta dokumentacja bo jak jesteśmy w zespole tak no to rozmawiamy w jaki sposób ten proces myślenia Być może dokumentujemy bo jest jakaś tablica tak I znowu właśnie być może są jakieś mechanizmy na to tak i właściwie jest całkiem ich sporo wyprzedzając tak pozwalające na to żeby sposób myślenia dokumentować żeby nie trzeba było specjalnie tworzyć dokumentacji ale ten sposób myślenia tak odnośnie czy to kodu tak nie wiem
właśnie event storming tak Czy to jakiś tego w którą stronę produkt ma na przykład pójść Tak jakie impakty ma wycisnąć można właśnie dokumentować w taki sposób że no robimy taki warsztat i z tego warsztatu mamy pewien kontekst oczywiście krytyką tego jest to że no po takim jakimś warsztacie i modelowaniu nie cała Wiedza jest mówiąc brzydko z angielska owana i i potrzebnie i czasem potrzeba troszeczkę więcej kontekstu żeby w to wejść natomiast Zaletą tego jest to że jeśli zespół nad tym ciągle pracuje i znowu tutaj była taka metryka że jak często ta wiedza się zmienia prawda a jeśli zespół Ciągle nad tym pracuje no to wtedy będzie to up to date i każdy będzie z tego korzystał i nie trzeba nie trzeba wtedy dodatkowych dokumentów robić które No jakby dokumentują no jakby Są to dokumenty żeby potem można było z tego w jakimś dłuższym okresie czasu skorzystać jeszcze jest jedna rzecz którą można by było tutaj wyciągnąć to znaczy niektóre dokumentacje tak można zaczerpnie zrobiliśmy modelowania tak Czyli weźmy sobie na przykład ten nasz
event storming domain Design diagramy mogą być zaczerpnięte jakby być jakby pochodną co zrobiliśmy na na event storming czy też tam na jakimś innej metod metodyce na przykład event modelingu więc w ten sposób jesteśmy w stanie to troszeczkę bardziej zautomatyzować No i dalej tak idąc tutaj troszeczkę do aia znowu tak jak mamy też diagramy No to ta wiedza już jest połączona I ona Poniekąd już jest nawet w sobie ten sposób jej reprezentowania To w jaki sposób te są między sobą połączone też pozwalają na to żeby potem narzędzia aow mogły z tego skorzystać wiesz to trochę w kontrze powiem bo to co powiedziałeś to to to generalnie dla mniejszych zespołów to to bardzo często spoko natomiast jedny z takich zagrożeń rzeczą która która powoduje dużo problemów to jest też information Overload A więc to że my produkujemy produkujemy dużo dokumentacji I zapisujemy nawet nasz proces myślowy jak to działa po kolei i tak dalej to to potencjalnie może oznaczać że nasza kultura nawet w sumie fajnie chyba ccie ostatnio jaki się produkował na ten temat nasza kultura staje się bardziej witing Culture niż Culture bo się tego
sprować nie da więc nie no absolutnie się z tobą zgadzam 100% dla mnie no i tutaj fajnie wchodzą Wchodzą te konteksty o których Robert wspomniał bo część wiedzy jest lokalna i to też nazwał nie nazwa tego kontekstem tylko bardziej nazwał to kontraktem A czyli że my rzeczywiście się bardzo mocno zastanawiamy nad tym co jest wiedzą wewnętrzną tak szczegółem implementacji nawet jeżel ta implementacja to jest po prostu nasz Design wewnętrzny Ale to nie są szczegóły które my chcemy wyciekać na zewnątrz bo nie chcemy żeby ktoś na N na nich polegał nie chcemy żeby ktoś na nich od nich zależał wsus chcemy opublikować na zewnątrz co jest jakieś wącz z tego tylko i wyłącznie tym na czym moża polegać bo to się nie zmieni w jakimś dłuższym terminie Kończy nam się czas ale ja bym jeszcze chciał dodać jedną bardzo istotną rzecz że świetnym papierkiem lakmusowym o którym powinniśmy pamiętać i z niego świetnie korzystać to jest onboarding i ja wykorzystuję onboarding tak że bardzo proszę osoby które są on bardowanie Dokument w którym spisują wszystko czego im brakowało co było niejasne co było trudne po to żeby móc faktycznie dokonać wie właściwych właściwych korekt a nie tego co nam się wydaje i zaraz obok
onboardingu instytucja badiego i mentorów czyli czyli osoby body to jest oczywiście osoba która z którą z reguły w większych organizacjach pracuj jestem on bardowanie to zostaje na dłużej czasami nie ale jest to osoba o podobnym seniority podobnym doświadczeniu która w organizacji jest trochę dłużej i pomaga nam zdobyć tą wiedzę natomiast mentoring jest bardzo fajny bo też z reguły Mentor jest osobą która jest jednak liderem i dzięki temu jest w stanie identyfikować zbierać Feedback i identyfikować braki w procesach nie tylko gdzie jest dokumentacja ale w tych procesach dokumentacji tak albo właśnie to co powiedziałeś Sebastian że też mieć dostęp do bezpośrednio do tego że tej dokumentacji może jest za dużo lub za mało więc to jest też coś co polecam wykorzystać dobrze Ja chyba zaparkuję temat Pingu bo chciałem się jeszcze wypowiedzieć bo my na to poświęciliśmy w firmie dużo czasu i faktycznie to nie jest proste może zrobimy sobie dedykowany odcinek o tym po prostu nie ma nie zaszkodzi bo to naprawdę nie jest proste i trzeba włożyć w to dużo energii i pomysłu jak to robić dobrze dzięki za rozmowę piątek wakacje
się wołają więc będziemy chyba zawijać Tak trzymajcie się wszyscy i miłego weekendu i trzymajcie się chłodno bo idą upł znikamy dzięki bardzo i Słuchajcie obserwujcie co się dzieje będzie działo w najbliższym tygodniu bo pewnie będzi ciekawe ogłoszenia i cieka materiały dla was więc ucie na social media będzie się działo Coś tam tworzymy patrzcie na Linkedin na Twittera coś tam wrzucimy ciekawego hej
