Budowanie wiedzy w zespole. Główne błędy i strategie.

Temat zarządzania wiedzą w zespole to obszar pustynny jeśli chodzi o liderów IT. Jest takie ciche założenie, że to dzieje się samo. I rzeczywiście w pewnym stopniu się dzieje, bo jako programiści jesteśmy przyzwyczajeni do tego, że w naszej działce, trzeba cały czas poznawać nowe rzeczy, żeby się utrzymać na fali. Jednak to nie wystarcza. Nie wystarczy, że każdy (a w rzeczywistości połowa), będzie coś tam sobie poznawać na własną rękę. Jeśli zespół ma działać efektywnie, potrzebna jest spójna i aktualna wiedza. I w tym przypadku wiedza o nowych technologiach/rozwiązaniach ma niewielką (choć pewną ma) wartość.

Zatem drogi liderze - świadome kierowanie rozwojem wiedzy w zespole jest ważne. Jest to często spychane na dalszy plan albo w ogóle ignorowane, no bo to nie jest kodowanie, trudno wrzucić w harmonogram, a poza tym ludzie sobie jakoś radzą. No właśnie, jak zwykle diabeł tkwi w szczegółach i to "jakoś" robi wielką różnicę. Osobiście najlepiej funkcjonujące zespoły, które spotkałem, miały bardzo dobrze rozwinięty sposób zarządzania wiedzą w zespole.

Dlaczego to ważne? Oto wybrane patologie, które się zdarzają i heurystyki, które się bardzo dobrze sprawdzają:

• brak dokumentacji odnośnie architektury - Tak... tak... wszyscy obecnie jesteśmy Agile, więc dokumentacja nam nie jest potrzebna. Czas definitywnie skończyć z takimi wymówkami. Dokumentacja jest potrzebna i to bardzo. Szczególnie ta high level. Mam na myśli rysunki, które z lotu ptaka dokumentują system - diagram/rysunek kontekstowy, diagram/rysunek komponentów, mantra architektoniczna, diagram/rysunek głównych mechanizmów, które stworzyliśmy (czytaj: frameworków). Jeśli nie ma tego typu dokumentów, rozmowa o rozwiązaniach, zmianach w systemie czy wprowadzenie nowej osoby jest szczególnie trudne, no bo gdzie jest wspólny punkt odniesienia, skąd wiemy, że mówimy o tym samym, skąd wiemy, jak nasz system jest zbudowany? Dokumentacja low level (diagramy sekwencji, diagramy dokumentujące konkretne funkcjonalności) jest nam potrzebna mało, jest to raczej dokumentacja tymczasowa, przydatna na czas dewelopmentu, więc wystarczy prosty rysunek adhoc na tablicy;
• brak strategii wprowadzenia nowych osób - czasami nawet jest, ale rzadko jest to robione dobrze. Najczęściej (jeśli taka strategia jest) polega ona na kilkudniowym chaotycznym wprowadzeniu, które i tak w większości schodzi na sprawy organizacyjne (procedury firmowe), skonfigurowanie środowiska, repo itp. No i może kilka słów o systemie... "A resztę znajdziesz w kodzie". I co taki gość robi? Poznaje system na podstawie kodu. Zamiast 2 tygodnie spędza na tym 3-4 miesiące, żeby mniej więcej zorientować się jak działa system, z jakich klocków jest zbudowany, jakie rozwiązania są preferowane w danym zespole, a które nie, na czym mniej więcej polega dziedzina, której system dotyczy. Tak! Poznawanie samodzielnie systemu, jest kilkukrotnie (często o rząd wielkości) dłuższe niż wprowadzenie poprowadzone przez osobę z zespołu (tzw. mentoring). "No tak, ale ktoś musi poświęcić na to tyle a tyle czasu, zamiast kodować".
  
  Tutaj najczęściej liderzy/kierownicy nieświadomie stosują lokalną optymalizację, która polega na tym, żeby nową osobą jak najszybciej zutylizować. A co z tego, jeśli przez pierwsze miesiące taki delikwent jest po prostu niewydajny.
  
  Oprócz strategii wprowadzania osób (czyli 2-3 tygodniowego planu określającego co, kiedy, od kogo i jak dużo powinien taki delikwent się nauczyć), potrzebna jest realizacja poprzedniego punktu - czyli dobra dokumentacja high level, która znacząco skraca czas potrzebny na wprowadzenie nowej osoby do projektu. ALE! Ważne bardzo jest do, że dokumentacja nie służy jako dokument do przeczytania ("No to masz - zapoznaj się"), ale jako narzędzie do dyskusji w rękach mentora. Sam dokument, nawet najlepszy, jest nic nie wart;
• ludzie nie znają kodu/systemu - ten problem jest naturalną konsekwencją powyższych dwóch problemów. Ponieważ ludzie się słabo orientują w systemie, mają fragmentaryczną wiedzę, toteż tracą mnóstwo swojego czasu na szukanie, a także czasu innych poprzez ciągłe dopytywanie. Poza tym ponieważ muszą uczyć się systemu "na żywo", najczęściej powielają rozwiązania, które znajdują, nie zawsze rozróżniając, które są pożądane, a które nie;
• brak spójnych zasad - obecnie uwspólniony standard kodowania w zasadzie stał się (nomen omen) standardem, jednak to nie wystarcza. Ponieważ jest wiele innych czynników, które wpływają na czytelność kodu czy też czystość architektury, które powinny być uspójnione - weźmy chociażby zasady czystego kodu, stosowane wzorce implementacyjne, bloki budujące (mantra architektoniczna). Jeśli to nie zostało ustalone i nie jest monitorowane w efekcie powoduje erozję architektury poprzez powstające niespójne rozwiązania. To jest praktycznie nieodczuwalne na początku, jednak wraz ze wzrostem skali projektu oraz upływem czasu, uzyskujemy efekt kuli śnieżnej;
• brak wymiany wiedzy w zespole/zespołach - często nie ma czasu czy też pieniędzy na szkolenia, natomiast mam wrażenie, że liderzy/kierownicy nie doceniają najcenniejszego narzędzia, jakie posiadają - wiedzę i doświadczenia ich własnych ludzi zdobytych na ich własnym projekcie. Czy jest gdzieś lepsze źródło dopasowanej do zespołu wiedzy? Stwórz zatem środowisko wymiany wiedzy - niech częścią review będzie zgłaszanie dobrych rozwiązań, które warto rozpowszechniać, twórz bazę przykładów kodu (np. jak wygląda dobrze napisany serwis, kontroler), stymuluj organizowanie wewnętrznych, krótkich szkoleń typu "czego się nauczyliśmy korzystając z biblioteki X", umożliwiaj pracę parami - nawet jeśli nie cały czas, to na początku i na końcu tworzenia rozwiązania. Ponieważ nie wszyscy programiści potrafią dobrze pracować razem - czasem trzeba włożyć wysiłek, aby ich tego nauczyć - chociażby tego, jak znaleźć wspólne rozwiązanie, kiedy mamy różne zdania.
  
  Zbudowanie środowiska ciągłej nauki powinno być jednym z głównych Twoich celów, liderze. Będziesz miał zmotywowanych i efektywnych ludzi, którzy będą tworzyć spójne rozwiązania.
  Co dostaniesz, jeśli nie zorganizujesz takiego procesu? Pewnie to znasz - będą powstawać implementacje tych samych mechanizmów w różnych miejscach. Będziesz miał problem, kiedy ktoś Ci odejdzie z zespołu, bo wiedza i doświadczenia będą skumulowane w poszczególnych osobach.
  
  Brak wymiany wiedzy, to brak motywacji, nudne środowisko, więc z czasem rotacja będzie dawała się we znaki, więc i wypływ wiedzy i doświadczenia będzie większy. Poza tym poziom merytoryczny Twojego zespołu będzie spadał. Tak naprawdę będzie stał w miejscu, a w działce programistycznej to oznacza regres;
• brak aktualizacji wiedzy o systemie - każdy programista czy lider, która ma już kilka lat doświadczenia za sobą, wie, że systemy się zmieniają - dużo szybciej niż nam się wydaje i najczęściej w innym kierunku niż przewidywaliśmy. Toteż ustalenia odnośnie architektury systemu, stosowanych bibliotek, mechanizmów - będą modyfikowane. Liderzy najczęściej zapominają o tym, że trzeba włożyć energię, aby zmiana została wdrożona i było utrzymana. Często powtarzanym błędem jest to, że tylko liderzy i (główni) architekci wiedzą w jaką stronę zmierza system i jaka jest obecna "poprawna wersja architektury". Czasem nawet zapominają to ogłosić (absurdalne, prawda?). Czasem napiszą maila lub wyślą dokument... A to za mało.
  
  Po pierwsze należy zebrać feedback od ludzi, odnośnie tego, jakie widzą trudności we wdrażaniu, jakie potrzebne są im zasoby. Po drugie należy przez pierwszy okres wdrażania znaleźć sposób monitorowania zmian. Szczególny nacisk na zmiany podczas przeglądów kodu, listy weryfikacyjne (checklisty) kluczowe założenia. I retrospekcje, które poprzez anlizę problemów i sukcesów, pozwolą monitorować efektywność wprowadzania zmian.
• brak miejsca na zdobywanie nowej wiedzy - wiele firm ma strategie - u nas ludzie sami się uczą. To jest bardzo w porządku. Sam jestem przedstawicielem tej rasy;-) Jednak takie podejście ma pewne wady.
  
  Po pierwsze - jeśli uczysz się sam, to ograniczasz się tylko do kontekstu, który znasz, trudno jest poza niego wyjść. W związku z tym trudniej o istotnie inne, nowatorskie rozwiązania, inne podejście do rozwiązywanych problemów, gdyż twoja percepcja jest ograniczona poprzez dotychczasowe doświadczenia. Po drugie samodzielne uczenie się najczęściej ma charakter fragmentaryczny, zdobywa się dużą ilość informacji, ale trudno je poskładać w spójną całość. Dlatego samouctwo prowadzi do efektu, że ma się wrażenie, że cały czas jeszcze jest bardzo dużo do poznania. Trudno określić, co jest rzeczywiście ziarnem, a co jest chwastem. Trzeba często kilku lat doświadczenia, aby nabrać umiejętności rozróżniania i stwierdzenia: to już wystarczy. Po trzecie inne osoby są najlepszym źródłem inspiracji, której nie zastąpi praca indywidualna. Większość naszych pomysłów, ma źródło w kontaktach z innymi osobami, jeśli nie osobiście (co uważam za najbardziej efektywne), to poprzez sieć.
  
  Dlatego nawet szkolenia, konferencje czy wydarzenia, które nie są w 100% związane z tym czym programiści zajmują się na co dzień, mają ogromną wartość. Twoim zadaniem lidera, jest zogniskowanie, skatalizowanie zdobytej wiedzy, doświadczenia: chociażby poprzez pytanie: "Jak to czego tam się dowiedziałeś, możesz wykorzystać?". I nie dawać się zbyć szybkimi, prostymi odpowiedziami. Drąż, a zdobędziesz bardziej świadomego członka zespołu.

Poniżej mała ściąga.

A tu wersja z książki Technical Leadership: