CTO Morning Coffee

Dzień dobry, Cześć.

Cześć.

Dobrze.

I znów się udało.

Sebastian już powinien być.

O, udało się.

Wakacje i nie zwolniamy.

Jesteśmy w komplecie.

No nie, znaczy akurat wczoraj opublikowałem nasz podcast o 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ę nad tym zastanawiał.

Halo?

Jesteście?

Tak, tak.

Jesteśmy, jesteśmy.

Dobrze, bo zapadła cisza.

Nam był słaby żart i nie wiedziałem, czy mnie rozłączyło, czy nie.

Nie, no żart był słaby, no i tak.

Chcieliśmy pomylić z milczeniem.

Tak poważnie.

Lepiej wchodzi, jak taki żart sobie przemilczysz.

Setup in progress, ale widzę, że sporo osób dołącza, więc to jest chyba ulubiona część wszystkich, czyli pora na moją formułkę.

Tak, przypomnienie, być może dla tych, którzy są z nami po raz pierwszy.

To jest CTO Morning Coffee, nasze regularne, co dwutygodniowe spotkania, gdzie rozmawiamy sobie o tematach istotnych dla tzw.

Senior Technical Leaders, czyli dla CTOs, ale nie tylko, i również dla tych, którzy do tego typu ról aspirują.

Każdy odcinek ma swój temat.

Dzisiejszym tematem będzie knowledge 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 twitterowej, czyli jeżeli ktoś robi to przez przeglądarkę, to sorry, ale jeszcze cały czas Elon 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ć, czy ktoś tę łapkę podniósł, ale nie należy się zniechęcać.

Co do naszej temperatury dyskusji, to staramy się, żeby ta dyskusja była przede wszystkim profesjonalna, czyli bez jakichś osobistych podjazdów, bez krytykowania osób, nawet firm.

Jeżeli krytykujemy, to krytykujemy jakieś postawy, w oderwaniu od powiedzmy personaliów.

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 cdomolning.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ły w najbliższym czasie.

Jedna z nich w sumie poszła wczoraj oficjalnie w ETHER.

Tomasz, czy coś chcesz więcej na ten temat powiedzieć?

No tak, wydarzyła się rzecz niesamowita, czyli taki mój internal joke, pędę na DevConf.

DevConf to jedna z konferencji, którą uważamy, że robi robotę, jeżeli chodzi o jakość i chłopaki spodzieli się przyjąć nas pod swoje skrzydełka na tym wydaniu, czyli cdomolning.coffee w tym zestawie będzie na DevConf.

Jeśli chcecie, to zajrzyjcie na devconf.pl.

Tam jest jakiś early bird nawet, nie mamy dyskont kodów, ale my tam będziemy.

Tak, tak, to jest z naszej strony oczywiście przedsięwzięcie niekomercyjne, natomiast będzie to, jak zwało, tak zwało, cdomolning.coffee na żywo in person, więc będzie okazja pogadać, podyskutować i co tylko.

Dobrze, jeżeli chodzi o standardowe formułki, to chyba wyczerpaliśmy temat.

Tak.

Awesome.

No i idziemy.

Knowledge management zatem, to chyba wypadałoby zacząć od tego, czym powiedzieć, czym jest to zarządzanie wiedzą, czym jest ten knowledge management.

Kto się podejmuje do bycia dzisiaj naszą encyklopedią?

Wojtek, ty jeszcze nic nie mówiłeś.

Ojejku.

Zarządzanie wiedzą w organizacji, 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 i im bardziej skomplikowane produkty, tym jest to bardziej ważne dla nas wszystkich, ale tak naprawdę chcemy go dotknąć 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 moim 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 też knowledge management.

Więc słuchajcie, może czy chcecie 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 zagranicą, 20 tysięcy ludzi.

I robiliśmy tam jakiś projekt.

I generalnie jak potrzebowałem coś się dowiedzieć, na przykład pytałem się, jak to jest 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ę dwudziestotysięcznej firmy w finansach z głowy.

Całkiem niezłe zarządzanie wiedzą.

Tak.

I to był przykład zarządzania wiedzą i praktyk, bo to nie tylko dotyczy produktów, ale też infrastruktury, co więcej, organizacji i procesów.

Więc dla mnie zarządzanie wiedzą to jest zagadnienie, jak przekazać wiedzę na temat tego, czy w ogóle stan, jak działa organizacja.

Bo to nie dotyczy tylko technicznej wiedzy, ale 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 ta organizacja, czyli tak naprawdę wiedza o tym, co ludzie robią, co robimy i jak to robimy.

Tutaj 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 powinien od razu świadomie rozpocząć albo raczej zestaw procesów, który świadomie powinien się rozpocząć i to powinno żyć z nami.

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 tego na swój indywidualny sposób.

Natomiast są dobre złe i dobre praktyki, o których pewnie powiemy.

Sebastian. 30 kilku fajnych rzeczy.

Ja chyba też skomentuję tą Panią, o której powiedział Tomek.

Tomek, to i 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.

Jak ja sobie myślałem o tej definicji, jak ja bym ją chciał ukłuć, to wszystko mi się w końcu sprowadzało do tych czasowników, które trzeba z tą wiedzą robić.

Wy w sumie, żeście większość tych czasowników wymienili.

Pierwszy, taki może najmniej oczywisty, to jest Capture, w ogóle jak wiedzę złapać w organizacji.

Ja też tak miałem, że jak ja w ogóle wchodziłem do robienia software'u i zaczynałem być odpowiedzialny za jakieś większe części projekty, to knowledge management to w ogóle nie był temat.

To nie było coś, czego się uczyłem.

To nie było coś, co było jakąś wiedzą encyklopedyczną, jakimś body of knowledge, którego się trzeba było nauczyć.

To było coś, co się robiło intuicyjnie.

W związku z tym, o tym Capture the knowledge, 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 Capture, czy ten czasownik Capture, to jest też bardzo istotny.

Jak już mamy Capture, 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ę masę dylematów, o których chyba nie będziemy mówić.

Bardzo trudno.

Tak.

Potem share, czyli właśnie, jak w 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 rozsmarowana jak masełko równo po całej organizacji, bo to tak nie może działać z różnych powodów.

Więc share 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ę outdated, w związku z tym wiedza staje się śmieciowa.

Po drugie, to, że ona gdzieś jest, to jeszcze musi być indeksowalna, wyszukiwalna, ona musi być po prostu do niej w jakimś sensie przechowany dostęp.

I ostatnia rzecz, strasznie mi się podobała to, co powiedział Wojtek na końcu, więc chciałbym też podkreślić, że to nie jest sprint, tylko 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.

To jednak cały czas trzeba pakować, pakować, pakować, ładować, wkładać na wysiłek, żeby miał sens.

Ale to dlatego, że do projektu jeszcze musisz zatrudnić odpowiednich konsultantów i wtedy będzie dobrze.

Musiałeś.

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 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 podać do tego tematu na wielu, na wielu, na wielu wymiarach, bo teraz chciałem powiedzieć, że my jako inni inżynierowie bardzo często mamy świetne praktyki, jak dokumentować wiedzę technologiczną, tak, i uczymy się tych praktyk, udzielimy je, opowiadamy sobie, jak to robić.

Natomiast ja też chciałem dodać od razu, żeby to wybrzmiało, ż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ć.

Nie, bo o rzeki, w szprychy, może nawet by zaparkujemy, ale powiedziałeś taką rzecz, z którą pozwolę się mocno nie zgodzić praktycznie, to znaczy powiedziałeś, że jako inżynierowie doskonale wiemy, jak tam wiedzę zbierać, składować i tak dalej, i moja obserwacja organizacji jest, że raczej nie wiemy, ale podeskupujmy.

Okej.

Tutaj jasne, jasne, oczywiście, bo chodzi mi o to, że wiesz, że jako inżynierowie przynajmniej powinniśmy znać różnego rodzaju narzędzia, do tego, co powiedziałeś się odniosę, to czy je stosujemy, to jest inna kwestia, tak, ale większość osób, które studiowała na przykład na kierunki związane z szeroko pojętym IT, miała na pewno, chociażby UML-a i miała projekty na studiach, gdzie musiała dokumentować pewnego rodzaju projekty przy pomocy tego UML-a, tak, już nie mówię o później kolejnych narzędziach, które możemy wprowadzać, więc do tego pewnie wrócimy.

Właśnie, to zanim o narzędziach, bo tutaj możemy, myślę, że też o teorii informacji, to długo by opowiadać, ale wróćmy do twojego pytania, bo masz dobre pytanie.

Czy co się dzieje, jeżeli zaniedbamy temat knowledge management?

Jakie wy macie sytuacje, obserwacje, co w tym momencie może się popsuć?

Ja bym powiedział, że pierwsze i najważniejsze, co się dzieje, to jest brak spójnego podejścia.

I to jest taki dla mnie top jeden, jak się przygotowywałem do naszego odcinka.

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ć temu kobietom szybko głos, ale to tylko wspomnę dwie.

Że bardzo często duplikujemy swoje starania lub właśnie swoje jakieś procesy.

Bardzo często przez to, że nie mamy braku wspólnoś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 takiego mojego top trzy, no to właśnie ta ograniczona współpraca i wspólne uczenie się na temat organizacji produktów, użytkowników.

To takie moje top trzy.

Tomek.

No jedno mi zdałeś, bo miałem powiedzieć, że to prowadzi do duplikacji na różnych tematach.

I to duplikacji takiej, że po prostu im większa organizacja, tym większej.

Zaczynamy wymyślać koło od nowa, powtarzać.

Każdy robi, myśli jaki software zbudować, jak zaczynają się procesy równoległe i tak dalej.

No bo ludzie po prostu nie wiedzą, że ktoś coś robi, więc myślą, o jest problem, to go rozwiąże.

I nagle mamy pięciu ludzi rozwiązujących ten sam problem.

Takie może mniej oczywiste, bo nie techniczne, tak, to jeżeli chodzi tak z punktu widzenia organizacji, bo ty powiedziałeś o rzeczach od strony software'u, 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 onboardingu i początkowego takiego body of knowledge, które ktoś musi wejść, bo ktoś wchodzi do organizacji i musi zacząć działać w tej organizacji.

Jeżeli tego nie ma, no to on zaczyna działać chaotycznie.

Jak zaczyna działać chaotycznie, to robi taki disruption, tak, bo albo się pyta wszystkich o co, jak zrobić, albo robi to po swojemu, albo chce być efektywny.

I na końcu efektywność całej organizacji będzie spadać.

Więc na przykład my gdzieś tam, w którymś koniecie mocno przełożyliśmy się do tej części onboardingowej, czy takiej wiedzy na temat jak niektórych rzeczy robimy, bo je trzeba uwspólnić, tak.

Długoterminowo, no to jest dokładnie, ja bym to podsumował, że koszta rośnie, tak.

I jeżeli nad tym nie zapanujemy, no to wszystko, co powiedziałeś, się zgadza.

Podstaną 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 jej efektywność spada.

Tak bym podsumował.

Zanim też rzucę parę swoich uwag, to też zachęcam wszystkich do podnoszenia łapki i zabierania głosu, dzielenia się swoimi obserwacjami i swoimi też jakimiś doświadczeniami.

To, co ja bym dodał do tego, co powiedzieliście, czyli np. entropii, 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, albo uwspólniać pomiędzy tym, co sobie ludzie zapamiętali.

Czyli np. nie znamy zamysłu oryginalnego, który stał się jakimś modułem, jakiegoś modelu logicznego, modelu funkcjonalnego i musimy go refaktorować sobie w głowie z kodu.

I na samym początku to jest coś, co jest naturalne dla nas, no tak pracują programiści i 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żej kompleksy, ale z czasem to się robi frustrujące.

Więc oprócz bycia nieefektywnym pojawia się też właśnie temat frustracji.

Dlaczego?

Jest taki termin jak cognitive load.

Cognitive load to jest tyle, ile pojedyncza osoba jest w stanie ogarnąć w głowie.

Po wyżej pewnego poziomu systemy mogą stać się na tyle skomplikowane, że jest to po prostu nierealne.

Powoli zaczynamy zapominać, pewne szczegóły zaczynają nam umykać.

W związku z tym, jeżeli nie umiemy zarządzać wiedzą w organizacji i nie umiemy podzielić tej wiedzy, podzielić jej na pewnego rodzaju moduły, części składowe z jasnymi odpowiedzialnościami, to wiedza w naszej organizacji staje się jakąś wielką, nieokreśloną chmurą, której nikt tak naprawdę 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 nam na przykład urosło, a 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.

Czy trzeba dotknąć jakiegoś modułu, jakiegoś wycinka funkcjonalności, dla którego ta wiedza z organizacji już uciekła i teraz my wpadamy w jakiś safe mode i staramy się na przykład modyfikować, czy dawać tą funkcjonalność w sposób, który minimalizuje ryzyko.

Czyli na przykład dobudowując gdzieś z boku, zamiast zmieniać ten model, który był pod spodem.

Także to taki, powiedzmy, powiedziałbym, to jeszcze ciekawy, 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 rzucić troszkę moich obserwacji, też może będzie dla was ciekawa perspektywa trochę mniejszych teamów, start-upowych teamów i takich teoretycznie próbujących iść troszkę szybciej.

I troszkę może mniej o tym faktycznie jak dokumentować, bo wydaje mi się, że dużo ludzi może patrzeć na moment sharing przez mat 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 fajnie wspomniał Sebastian, to znaczy jeśli jeden team ma faktycznie za dużo wiedzy do ogarnięcia, to jestem na pewno jeden taki pierwszy bloker, żeby faktycznie ten knowledge sharing działa, bo jak tej wiedzy jest po prostu za dużo w jednym teamie, to 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łyszał o band-aid kontekstach i to na pewno też 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ę, że bardzo dużo pomaga, jeśli team działa bardzo autonomicznie.

W sensie, jeśli gdzieś pracujemy w jakimś teamie, gdzie dostajemy taski do zaimplementowania, a nie funkcjonalności, to też ciężko powiedzieć, żeby gdzieś ten knowledge sharing był, bo po prostu jesteśmy osobami, które wykonują coś i nawet nie znają za bardzo tego kontekstu.

Wydaje mi się, że to jest taka, wiadomo, dla niektórych to może być oczywiste, że okej, jak tak może być, ale też spoza naszym bańkom dalej jest sporo takich firm, które mają z tym problem i wydaje mi się, że to też jest taka niby nieoczywista rzecz, a bardzo ważna, żeby faktycznie team działał autonomicznie i sam rozwiązał te problemy, bo wtedy, kiedy on jakby sam to rozwiązuje, musi nabyć ten kontekst.

A jeśli on dostaje konkretny task do wykonania, no to często to nie wymaga jakby zdobycia tego kontekstu i ta wiedza nie musi się za bardzo doprowadzać po teamie, więc 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 coś implementujemy, to jest to powiązane z poprzednim punktem, w sensie w momencie, kiedy coś implementujemy i nie mamy za bardzo kontaktu z naszymi stakeholderami czy biznesem, to też mamy troszkę, można by powiedzieć, zepsuty obraz może tej wiedzy, która może nie jest do końca wiedzą techniczną, ale wydaje mi się, że ta wiedza techniczna, jak już tak wspomniałem, jest to może często mniejszy problem niż taka wiedza domenowa, w sensie, że jeśli mamy jakiegoś product managera, który ogarnia zaraz 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ś gije, nie?

I to wydaje mi się, że jest drugim wielkim programem.

Trzecią rzeczą, którą gdzieś też czasem spotkałem, problemem jest to, że czasem organizacja jest zbudowana z takich samotnych wilków, które implementują dane funkcjonalności i to też nie może się skończyć dobrze i średnio, często jakby jest dużo jakichś ukrytych założeń, jakichś dużo ukrytych decyzji, które tobie 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ła jakieś bardzo ważne funkcjonalności i tylko ona wie, jak tylko ona wie, jak do tego podejść.

Z drugą stroną pewnie można powiedzieć tu Phoenix Project, bo wydaje mi się, że 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 lakosowym ciekawym, który pokazuje jak najlepsze ludzie u nas w organizacji, to może od jakiegoś czasu trochę kontrowersyjna rzecz, nie wiem czemu, chociaż może 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 mieć za dużo wiedzy w teamie, będziemy działać autonomicznie i będziemy unikać głuchego telefonu, no i nie będzie to implementowane przez jedną osobę, to Code Review powinno być generalnie raczej formalnością.

W sensie każdy powinien wiedzieć, co się dzieje, każdy powinien wiedzieć, czemu to tak było zrobione, a jeśli Code Review nie jest formalnością, tylko ciężkim procesem, którego ludzie unikają, przechodzą przez to jak najszybciej, bo to marnuje czas, to prawdopodobnie znaczy, że coś mogło pójść nie tak w tych wcześniejszych punktach.

To jest moje zdanie.

Wielkie dzięki.

Jeszcze raz dzięki Robert i zapraszamy wszystkich do dyskusji.

Powiedziałeś sporo rzeczy.

Ja bym chciał się odnieść do jednej, którą powiedziałeś odnośnie autonomii.

To był chyba pierwszy punkt.

I tutaj powiem, że w stu procentach o ile zrozumiemy i ustalimy pewien kontrakt między zespołami, co współdzielimy, i te współdzielone rzeczy powinny być na pewno uspójnione.

I tutaj właśnie chociażby myślę, że to, co jest bardzo ważne, to chociażby zasady, pewne zasady od pisania właśnie good practices, jeżeli chodzi o pisanie oprogramowania, utrzymywania go na produkcji, po chociażby zatrudnianie, czy ocenianie jakichś kwartalnych, czy półrocznych pracowników.

Te zasady powinny być spójne i powinny być udokumentowane.

Więc to warto wrzucić na warsztat.

Tomku, ty chyba chciałeś się też odnieść na kilku rzeczy.

Chciałem się trochę odnieść, ale to wejdziemy też może już w kolejny temat, pod tytułem techniki, jakieś narzędzia do tego, bo co Robert powiedział, że jeżeli ktoś dostaje task i nie zna kontekstu i tak dalej, no to trudne jest taką wiedzę, żeby ona się propagowała i tak dalej.

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ą, bo po prostu, jeżeli ktoś dostaje task, to wykonania nawet, to powinien być w stanie prześledzić orygin tego tasku w tym samym miejscu, czyli ok, to ten task jest częścią czego, skąd to wynikało, gdzie na końcu jest to wymaganie, do czego to kontrybuuje.

Moje doświadczenie było takie, że jeżeli ktoś zadbał o to i pilnował tego przy produkcji projektu, czy kodu, no to dobrze działało, tylko to jest trudne, bo potem nawet jak Robert powiedział o code review, to jeżeli wykonujemy code review, no to potem jest ok, to gdzie wnioski z tego lądują i te wnioski nie powinny tylko lądować w postaci komentarza do kodu, ale do kontrybucji, ok, słuchajcie, zmieniliśmy to dlatego w taki sposób i tak dalej, nie?

Więc to trochę tak od strony narzędziowej i podejścia do całości.

Ja bym tutaj, wchodząc gładko w ten temat, bo już rozpocząłeś, ja bym chciał jeszcze jedną rzecz dotknąć, że też proponowałbym z pierwszego punktu widzenia nie stosować jednego sposobu, jednego rodzaju narzędzi dla 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 jakichś własnych notatek i budowania swojej własnej wiedzy.

Ja 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 platformy, czyli na przykład, wiecie, czy pracuję z daniemi, 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.

A trzecia to jest, no i tutaj już wchodzimy, jak jest zbudowana organizacja, jakieś tribe'y lub departamenty, no i czwarta to jest ogólna wiedza w organizacji, więc też pewnie różne narzędzia i różny sposób dokumentowania i różny sposób spółdzielania tej wiedzy jest.

Więc moje pytanie do was, jakie właśnie narzędzia na tych ewentualnie różnych poziomach?

W wielkim skrócie, bo tematów mamy sporo, ale jakie narzędzia stosujecie?

I co byście polecali?

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ć do knowledge management.

Więc dla mnie to te trzy, nie wiem, typy, 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 ono 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 rzeczywistość.

Trzecia taka, taki typ takiego miejsca, to może być na przykład jakiejś wiki, jakaś baza wiedzy.

Czyli coś, co nie jest formalną dokumentacją, coś, co nie ma na przykład, idealnie jest to capture the project, to capture the scope of the project, tylko coś, co ma być evergreen, czyli opisuje na przykład stan rzeczy, on nie jest idealny, ale staramy się, żeby ten gap był jak najmniejszy.

I tutaj rodzaj tych narzędzi, które można tutaj wpisać, jest ich bardzo dużo, bo tu można zacząć właśnie od jakiejś tam wiki, poprzez jakieś knowledge management systemy, sharepointy, portale, aż po development portals, które ostatnio są bardzo, bardzo modne, o których pewnie sobie możemy tutaj powiedzieć, takie jak chociażby backstage.

Więc tutaj te miejsca i formuły.

Druga to techniki.

I tu o technikach też już trochę powiedzieli, czyli code review to nie jest artefakt, to jest technika, ale to jest też technika, która służy zarządzaniu wiedzą.

Inne tego typu techniki to są na przykład sync meetings, czyli spotkania, na których synchronizujemy stan wiedzy odnośnie na przykład jakiegoś projektu.

Nawet stand-upy, 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 od nas, które są niezbędne innym, żeby mogli egzystować.

Nawet głupie retrospekcje, to też jest jakaś technika knowledge managementu, również też.

A my w ogóle jakieś formalne learning programs, które mogą być w organizacji, na przykład służące temu, żeby upskillować ludzi, którzy są nowi, albo ludzi, którzy są nowi w danej roli, to też jest znowu jakaś tam technika.

No i końc końców te mechanizmy organizacyjne.

No to takim mechanizmem organizacyjnym, który jak dla mnie wymusza rzeczy odnośnie knowledge managementu jest chociażby na przykład team level accountability, czyli że odpowiedzialność za coś, na przykład, nie wiem, za projekt, produkt, cokolwiek jest, na poziomie jakiegoś zespołu, bo to wymusza pewne zachowania w zespole, żeby ten cały zespół był w stanie coś utrzymać, a nie tylko i wyłącznie jeden hero, który gdzieś tam sobie z boku jest.

Inny taki organizacyjny mechanizm, to jest na przykład community of practice, czyli jeżeli zrobimy sobie organizację trochę powiedzmy mniej lub bardziej formalnie, bardziej macierzową i wyodrębnimy w niej jakieś community of practice, nie wiem, backendowców, API-owców, czy cokolwiek, to z ich pewnego rodzaju konstytucje będzie wpisane na przykład zachowanie wiedzy, czy udokumentowanie wiedzy, czy uspólnienie wiedzy odnośnie do jakiegoś konkretnego obszaru.

Więc tak idąc od góry, to ja bym widział taką klasyfikację.

Cześć, cześć, cześć, cześć.

Słychać mnie?

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 pole, na przykład product managera, UX designera, czy też dewelopera, ta wiedza jakby się troszeczkę inaczej kształtuje, bo jedna rzecz to jest to, że ją gdzieś chcemy zapisywać być może, właśnie share'ować i jak share'ujemy, to musimy zmienić ten cognitive load, o którym tutaj mówiliście, czyli zmniejszyć zazwyczaj cognitive load 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ę opowiedzieć, to to jest to, że to jest nie tylko knowledge 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ą doprecyzowywać, tak, albo robić swoje jakieś eksperymenty, więc to jest też pewien jakiś aspekt, który nad 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, no ale siłą rzeczy w przypadku akurat modelowania mamy, nie wiem, event-storming, event-modeling, gdzie zespół po środku widzi dokładnie, 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 tranzycję do, nie wiem, 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ą wiedzę sobie wypracować, zastanawiać się, nie wiem, nad jakimiś insightami, tak, nad jakimiś metrykami, a może jakimiś impaktami, tak, więc knowledge sharing to nie tylko jest hand-off jakiegoś kontekstu, ale też potem praca z tym kontekstem, urozmaicenie go w jakiejś specyficznej roli.

No i to wszystko, dzięki.

Ok, dzięki.

To ja wejdę trochę 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 rzeczy jest, bo jednym z dużych problemów zawsze, przynajmniej z którymi ja się porykałem, jest takie jakby znalezienie tego, co już jest ze bramy, nie?

I z takich rzeczy, z którymi 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 i zapisywania, bo to nie musi być dokument, cokolwiek, tylko układanie procesu, który w jakiś sposób działa, jest powtarzalne, to jest zapisywanie wiedzy organizacyjnej w postaci procesu, to jest pytanie, czy ten proces istnieje 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 z tym zrealizowaliśmy opisywanie 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 wyszukiwalny i dostępny dla każdego, tak?

A na przykład my gdzieś tam próbowaliśmy w ten sposób porobić, żeby każda informacja, 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 była użyteczna i te tradycyjne trzy właściwości, to było tam indexable, searchable i navigable.

I tu jest kilka strasznie fajnych antypaternów, 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ć jako struktury katalogów, więc to, że ktoś 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 failem, niesamowitego, ale my nie mamy czasu na wjeżdżania w takie tematy, powiedziałem o tych trzech właściwościach, ale chciałem tylko zachintować, ż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 nasze przegnanie tej wiedzy to było wspierane searchem, a w tym momencie my już coraz częściej opieramy się na jakichś modelach, modelach również, uwaga, po raz pierwszy się pojawiło dzisiaj dżem jajowy.

I to się zaczyna być...

Mogę się tu podzielić, bo my zanim jaja stały się modne, pewnie w okolicach 2017-2018 zrobiliśmy właśnie takie podejście też, czyli jako firma pracująca głównie na projektach z klientami tworzymy jakieś dokumenty dla klientów i tak dalej.

Mieliśmy takie podejście dokładnie, że indeksowaliśmy dokumenty, ale nie w taki sposób, że zindeksowaliśmy słowa kluczowe czy coś, tylko przepuszczaliśmy je przez model tam spodawany pod to na machine learning, który starał się wyciągnąć z czego ten dokument dotyczy.

I między innymi wynikiem tego było to, że w jakimś tam miejscu, które miały te dokumenty mówił, 70% tego dokumentu wskazuje, że on dotyczy takiego rozwiązania i takiego problemu.

I to generalnie automat leciał, skanował i update'ował na bieżąco.

Jeśli chodzi o kwestię modeli generycji 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.

Z reguły pracujemy po angielsku w firmach.

Bardzo ciężko czyta się dokument, który jest bardzo źle po angielsku napisany, mogę powiedzieć z mojej doświadczenia.

Więc jeżeli mamy draft jakiegoś tekstu, można wrzucić to w model, niech przymieli i możemy zrobić bardzo ładny, z automatu bardzo ładny tekst.

W porównaniu do Grammarly możemy też nadać temu odpowiednią formę lub na przykład rozwinąć dane tematy, więc te modele, a lub skrócić, więc te modele są bardzo fajne do tego i polecam spróbować.

Więc myślę, że tutaj Grammarly dostało ode mnie przynajmniej minusa w porównaniu do 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.

Wiele osób pisze w jedną lub w drugą stronę.

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 dokumenty, 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 formule, więc serdecznie polecam takiego haka, którego sam stosuję.

O ile całkowicie się zgadzam z tym, co powiedziałeś na temat conciseness, to trochę będę w kontrze do tego, co powiedziałeś wcześniej odnośnie modeli, bo to jest i uważam, że to jest całkiem ciekawe i to jest taka jedna rzecz, którą można z tego odcinka wynieść.

Jak tak zastanowicie się, jakie byłoby fajne źródło wiedzy odnośnie tego, jak na przykład dokumentować, jak w ogóle robisz, jak zapisywać dane, jak upewniać się, że te dane na przykład będą największą szansą być up-to-date, bo to jest chyba największy challenge w knowledge managementu, bo zapisanie jakiegoś naprzodu wiedzy na dany moment jest relatywnie proste, powiedzmy, może też nie jest trywialne, ale jest relatywnie proste.

Ale jak to utrzymać up-to-date przez dłuższy okres czasu, tak, żeby ta dokumentacja 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 Gen AI, to jest taka już dosyć stara, bo to jest 2017 rok, czyli 6 lat, książka człowieka, który się nazywa Sidney Martre.

Książka ma tytuł Living Documentation i ona jest dosyć ciężko dostępna, bo została opublikowana w self-publishingu w LinkedIn, potem chyba 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óra nie będzie ekspirowała, która nie będzie stawała się outdated.

No i tak, żeby zachintować, nie to, że tylko wam polecę do sprzedania, do kupienia, przepraszam, ale żeby powiedzieć, jakie tam techniki są omijane 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 samo odzwierciedla, to w kodzie używamy konstruktów właściwie dla danego języka programowania czy dla danego frameworka.

To znaczy, że jeżeli na przykład mamy Javę, to w Javie, Wojtek popraw mnie, jeśli jesteś moim tutaj dyżurnym ekspertem Javą, w Javie nie ma ciągle takiej abstrakcji jak serwis.

Czyli już pojawiły się moduły, są klasy, są interfejsy i tak dalej, ale serwis nie ma.

Natomiast często projektując coś, nie używamy takiej koncepcji jak serwis.

Serwis, mikroserwis czy cokolwiek.

I teraz, jeżeli nasi designerzy mieli gdzieś tam jakieś mikroserwisy w głowie, ale wyrazili to za pomocą kreacji interfejsów, to gdzieś być może sposób implementacji czegoś, co oni mentalnie nazwali mikroserwisem, 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órej opisuje kolega Martle, to jest właśnie to, żeby używać DSL, Domain Specific Language, do tego, żeby tworzyć te same koncepty z naszego języka designerskiego, żeby były one odzwierciedlane 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 jest możliwe kilka rzeczy.

Po pierwsze, dzięki temu możliwe jest automatyczne tworzenie, przynajmniej częściowo, dokumentacji.

Dzięki temu możliwe 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 on the top of, na przykład, Java wprowadziliśmy właśnie DSL-a.

Czyli co?

Mamy automatyczną walidację.

Mamy możliwość tworzenia jakichś asercji w tym kodzie.

Mamy tzw. executable specifications.

Mamy jakiegoś takiego DSL-a, który przedstawia nasz dany swój design, który mieliśmy wcześniej.

W związku z tym, to bardzo fajnym przykładem jest X-Wiki.

Nie wiem, czy znacie.

X-Wiki to jest takie wiki, które, po pierwsze, ono merżuje informacje, które są generowane automatycznie, z wsadem ręd, który został wpisany ręcznie.

To oznacza, że to nie jest tak, że jeżeli my coś piszemy ręcznie w takiej wiki, to my overwritujemy.

To zostało wygenerowane automatycznie.

To jest taki mechanizm, który umożliwia tym dwóm rzeczom istnieć jednocześnie i równolegle.

Także polecam Living Documentation.

Tam jest dużo fajnych hintów.

Te hinty, jak ktoś jest fanem DVD, one są kompatybilne z podejściem DVD.

Dzięki nim można zacząć myśleć o tworzeniu dokumentacji, która nie tylko jest automatycznie weryfikowana, ale też jest w ogóle refactor friendly.

To ja bym, tak, ja zdecydowanie też polecam tę książkę, więc dwa polecania 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ż inaczej ułatwić tworzenie ich.

Też wizualizacje diagramy, co jest teraz bardzo proste przy pomocy Mermaida, więc tak jak opowiadasz, właśnie można to dosyć łatwo wszystko połączyć.

Jak najbardziej.

Tomek, czy jakieś ciekawe inne narzędzia byś ty polecił?

Narzędzia są jeszcze chyba 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 specyficznie, jak dana organizacja do tego podeszła, czyli na przykład, jak my to robiliśmy, czy jak ja to gdzieś tam widziałem, nie?

Takie, chyba mamy gdzieś tam na kolejce takie narzędzia.

Bardziej myślę właśnie, bo wy mówicie dużo o narzędziach dookoła kodu, więc żeby było coś dookoła z innej, ten, no to są narzędzia procesowe, nie, czyli wiesz, takie jak przeprowadzić onboarding, jak go ustrukturyzować, na przykład, to była duża rzecz, którą my mieliśmy, nie, czyli 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.

I to mi się bardzo podoba, i to mi się bardzo podoba to, co mówisz, dlatego, że ja mam wypisane tutaj gdzieś na boku w moich narzędziach też takie ryzyko, że te dnieśnie nieużywane one odegają 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, bo ja nie mówię o wiedzy generycznej, tylko wiedza specyficzna dla naszej organizacji, ona uciekła.

Jest gdzieś tam zapisana w jakichś narzędziach, które są ciężkie do utrzymania i nagle okazuje się, że nie jesteśmy w stanie zrobić jakiejś atomowej, elementarnej zmiany.

Więc strasznie ważne jest, żebyśmy tego problemu nie obchodzili, tylko żebyśmy faktycznie poprzez wymuszanie czasami zmian w tym kodzie, w tych narzędziach, w tej automatyzacji, żebyśmy jednak musieli tego dotykać, żebyśmy jednak musieli to refaktorować, ż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 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%, czasami powyżej kilkunastu procent i okazuje się, że ta wiedza szybko znika, zwłaszcza jeżeli my w żaden sposób nie pilnowaliśmy tego, żeby ten buzz factor był jakiś ograniczony.

Ż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 znajdziemy się w sytuacji, w której widzimy, że czegoś brakuje lub nie jesteśmy w stanie znaleźć update'u, no to mieć sposób, żeby to zaadresować, czyli na przykład, żeby to mogło być jakoś eskalowane 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 w wiedzy i jej proaktywnie też działa, żeby tę wiedzę 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ę, no 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 dokumentacja nie jest prawdopodobnie ustalmy, nie?

Bardzo często jest tak, że ja bym z chęcią to robił, ale dokumentować już nie.

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 zrywach.

Tak, dokładnie.

Mieliśmy 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 siadł nad tematem i powiedział, ok, to stackoverflow jest rozwiązaniem, nie?

Wydarzyli ten stackoverflow, u 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 kontrybuowania, nie?

Ja bym powiedział że dokładnie tutaj o tym jest książka, którą Robert już polecił, czyli Project Phoenix, 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 łatwy problem to rozwiązanie, tak?

Bo z reguły ta zajętość tej osoby też z czegoś wynika.

Natomiast jest kilka sposobów, w jakich możemy to zaadresować, które ja wiedziałem, że w różnych sytuacjach działały.

No pierwsze i najważniejsze, to ta osoba powinna zrozumieć, że to jest problem, tak?

Bo jeżeli ta osoba rozumie, że jest zajęta włoż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 ok, to trzeba tę wiedzę spół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 udokumentowania pewnego rodzaju procesów, gdzie też podczas tego celu 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.

Sebastian?

Nie chciałbym zabrzmieć tutaj jako jakiś fanboy 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 edukujmy ludziom, żeby rozumieli i tak dalej, no u mnie to nie działało.

Może ja jestem za słaby, żeby ludziom to tłumaczyć i ich do tego przekonywać.

Więc ja jestem, ja raczej praktykowałem makiaweliczne praktyki.

Na przykład, no wpisuję na kole seniora, że dla seniora to jest to, że on ma wdrożyć cały zespół, że cały zespół ma to ogarniać.

Więc jeżeli z tym jest problem, a jaki z tym może być problem?

You build it, you run it, więc trzeba to supportować.

Czasami to trzeba supportować 24-7.

Więc ten jeden senior nie może tego supportować przez wszystkie 7 dni w tygodniu, 24 godziny na dobę.

Nie, bo tutaj też są wprowadzone jakieś ograniczenia.

Są wprowadzone w mechanizmie.

Czyli na przykład, że osoba może supportować maksymalnie, nie wiem, 24 godziny w tygodniu, czy cokolwiek.

Już wrzuciłem liczbę losu, 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 supportować, no to jest również odpowiedzialność tego seniora, że nie był w stanie przekazać tej wiedzy ludziom w zespole.

Więc budując mechanizmy jesteśmy w stanie w makiaweliczny sposób trochę wymusić to dzielenie się tą wiedzą.

Właśnie za pomocą takich przykładów, o jakich powiedziałem przed chwileczką.

Także ja wierzę w mechanizmy.

Ale to się nie wiesz, to wręcz się nie wyklucza, uzupełnia to, co powiedzieliśmy.

Bo właśnie ja powiedziałem, że wiesz, dajemy cel takiej osobie, jeżeli dotychczas tego nie zrobiła.

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 problem mamy, jeżeli ta 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śmy takiej ciekawej sytuacji, to chciałem was spytać o takie inne sposoby dostrzegania jakichś silosów wiedzy i antypaternów.

Jak jako liderzy właśnie możemy dostrzegać takie sytuacje?

No i jak możemy z nimi sobie radzić?

Sebastian.

No, tu jest kilka takich early warnings, które można zauważyć.

Więc pierwszy early warning jest taki, że po pierwsze ludzie nie chcą pracować z kimś konkretnym, z jakąś konkretną osobą.

Czyli pojawiają się jakieś insyluacje, że ktoś może być trochę toksyczny, że ktoś jest trudny w współpracy, że ktoś nie za bardzo się chce dzielić tym, co tam ma w głowie.

To to jest taki early warning.

A drugi early warning, który być może nawet powinien być tym pierwszym, to jest to, że gdzieś jakość spada.

Jakość spada i nie tylko pojawia się jakaś większa ilość incydentów, ale też wzrasta czas rozwiązywania incydentu.

Dlaczego?

Bo one się kolejkują.

Dlaczego się kolejkują?

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 refaktoringu 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 early warning.

Dla firm takich dosyć mocno szybko rosnących takim na pewno early warningiem było też dużo zwrotek w momencie testowania wczesnych wersji jakichś nowych feature'ów.

Czyli ktoś coś zaprojektował, jakiś product manager to tam pielęgnował, jakiś designer to zaprojektował, zostało to wrzucone w kod, ale jest dużo niedomówień, to nie tak miało działać, tutaj czegoś brakuje i to ewidentnie widać, że wtedy mamy problem z tą dokumentacją, która ma odwzorować rzeczywistość już na chwilę obecną, czyli gdzieś tu nie działa komunikacja, albo to zostało źle zapisane, jest to nieefektywnie zapisane, może nie zostało zapisane, nie zostało skomunikowane, gdzieś tu jest jakiś problem komunikacyjny.

To jest w ogóle taka rzecz, którą możemy tu mało dotknęli, czyli w ogóle jak powinna wyglądać dobra dokumentacja, czy dobra dokumentacja powinna opisywać to i teraz, czyli to jest twoje user story, to jest twój feature, czy dobra dokumentacja powinna opisywać pewien model stojący za, tak żeby się dało z tego łatwo wywnioskować, czy dobra dokumentacja powinna opisywać coś innego.

W każdym razie tutaj ten nasz wybór może mieć dużo implikacji i taką jedną z tych implikacji to już są właśnie na poziomie jakiegoś tam odbioru, pseudo-odbioru, jakieś takie tarcze, które się pojawiają.

Inna sytuacja jest taka, że jakby inny taki early warning jest taki, że my po prostu możemy mierzyć ilość, przecień z tą dokumentacją, jak często ludzie z tego korzystają, że się okazuje, że tam w ogóle nie ma żadnych searchy nad tym, że się w ogóle okazuje, że tam nikt z tego nie korzysta, nikt nie przygląda, w ogóle nikt tego nie aktualizuje, bo to jest też ważne, jeżeli jest dokumentacja, która niby teoretycznie jest okej, ale link jej nie aktualizuje, to coś jest nie tak, albo my nic nie robimy, nic nie zmieniamy, albo wszyscy mają ją gdzieś, bo być może to źródło wiedzy jest gdzie indziej, po prostu w głowach.

Więc niby taka prosta metryka, typu jak często ludzie coś tam edytują, ale to też jest jakiś taki early warning.

Kolejny early warning to są jakieś eskalacje w związku właśnie z zapisowaniem dokumentacji, czyli że mamy takie tendencje w organizacji do tego, że okej, wy możecie nam zmieniać dokumentację, ale musi zostać nasz apruwal, to już jest coś dziwnego, ale to już jest to, o co chodzi.

Jeżeli jest to na bardziej zdrowej zasadzie, czyli że może każdy jej zmienia, albo to jest jakaś pól requestu, czyli dokumentacja jest traktowana jak kod, to w tym momencie to już jest trochę bardziej zdrowe, natomiast jeżeli pojawiają się jakieś patologie, to potencjalnie jest taki sygnał, że to idzie w złym kierunku.

Tomek?

Jest trochę doświadczenia?

Albo Rafał i Robert?

Tutaj jest jeszcze kilka takich może ciekawych rzeczy odnośnie samej dokumentacji, bo słowo dokumentacja tutaj padło kilka czy kilkanaście razy.

Jak się zastanawiam, a tak na dobrą sprawę, to po co ta dokumentacja?

Jak jesteśmy w zespole, to rozmawiamy, w jaki sposób ten proces myślenia być może dokumentujemy, bo jest jakaś tablica.

I znowu właśnie być może są jakieś mechanizmy na to, i właściwie jest ich całkiem sporo, wyprzedzając, pozwalające na to, żeby sposób myślenia dokumentować, żeby nie trzeba było specjalnie tworzyć dokumentacji, ale ten sposób myślenia, jakiś warsztat odnośnie czy to kodu, właśnie event storming, czy to jakiegoś tego, w którą stronę produkt ma na przykład pójść, jakie impakty ma wycisnąć, można właśnie dokumentować w taki sposób, że robimy taki warsztat i z tego warsztatu mamy pewien kontekst.

Oczywiście krytyką tego jest to, że po jakimś warsztacie i modelowaniu niecała wiedza jest, mówiąc brzydko z angielska, skapturowana.

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, a jeśli zespół ciągle nad tym pracuje, to wtedy będzie to up-to-date i każdy będzie z tego korzystał.

I nie trzeba wtedy dodatkowych dokumentów robić, które są tą dokumentacją po to, ż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 można zaczerpywać z tego, że właśnie zrobiliśmy modelowanie.

Czyli weźmy sobie na przykład ten nasz event storming z Domain Driven Design.

Diagramy umelowe mogą być zaczerpnięte, czy jakby być pochodną tego, co zrobiliśmy na event stormingu, czy też tam na jakiejś innej 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 AI, 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 node'y są między sobą połączone, też pozwalają na to, żeby potem narzędzia AI'owe mogły z tego skorzystać.

A wiesz, to ja trochę w kontrze powiem, bo to, co powiedziałeś, to generalnie dla mniejszych zespołów to bardzo często spoko.

Natomiast jeden z takich zagrożeń i rzeczy, która powoduje dużo problemów, to jest też information overload.

A więc to, że my 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 to na czacie ostatnio się produkowałem na ten temat, że nasza kultura staje się bardziej writing culture niż reading culture, bo się tego sprocesować nie da.

Nie, no absolutnie.

Zgadzam się z Tobą 100%.

No i tutaj fajnie wchodzą te bounded konteksty, o których Robert wspomniał, bo część wiedzy jest lokalna.

Nawet inaczej bym to nazwał.

Nie nazwałbym tego bounded kontekstem, tylko nawet bardziej nazwałbym to kontraktem.

Czyli, że my rzeczywiście się bardzo mocno zastanawiamy nad tym, co jest wiedzą wewnętrzną, takim pseudo szczegółem implementacji.

Nawet, że 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 nich polegał, nie chcemy, żeby ktoś od nich zależał.

Wersus to, co my chcemy opublikować na zewnątrz, co jest jakimś wysączem z tego, tylko i wyłącznie tym, nad czym można polegać, bo to się nie zmieni po 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.

Ja wykorzystuję onboarding tak, że bardzo proszę osoby, które są onbordowane, żeby tworzyły sobie 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ć właściwych korekt, a nie tego, co nam się wydaje.

Zaraz obok onboardingu jest instytucja Buddy'ego i mentorów, czyli osoby Buddy, to jest oczywiście osoba, z którą z reguły w większych organizacjach pracuję, jestem onbordowany.

Czasem 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 zbierać feedback i identyfikować braki w procesach, nie tylko gdzie jest dokumentacja, ale w tych procesach dokumentacji.

Albo właśnie to, co powiedziałaś Sebastian, że też mieć dostęp 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ć.

Ja chyba zaparkuję temat onboardingu, ale 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 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ę dołają, więc będziemy chyba zawijać, tak?

Trzymajcie się wszyscy i miłego weekendu.

Znikamy, dzięki bardzo za udział i słuchajcie, obserwujcie, co się będzie działo w najbliższym tygodniu, bo pewnie będziemy mieć ciekawe ogłoszenia i ciekawe materiały dla Was, więc tłoczujcie na social media, będzie się działo.

Coś tam tworzymy, patrzcie na LinkedIn, na Twittera, coś tam wrzucimy ciekawego.

Cześć.

Cześć.

Cześć.

Cześć.

Cześć.

Cześć.

Cześć.

Cześć.

Cześć.

Cześć.