Ludzie dzielą się na dwie grupy: jedni chcą wszystko spisywać, harmonogramować, raportować i otabelować. Inni pracują głównie komunikacją i relacjami, tworząc środowisko do wymiany wiedzy. Do której grupy należysz Ty?
No dobra, na wstępie trochę przekoloryzowałem. Jednak jestem pewien, że nie raz jeszcze trafisz na kogoś kto z entuzjazmem zaproponuje „no to stwórzmy do tego dokumentację”, a potem okaże się to nietrafionym pomysłem. W dokumentacji nie ma nic złego, ale… I tak nikt tego nie przeczyta 😎
Na początek trochę mądrego nudzenia. Firmy mogą wybierać różne strategie zarządzania wiedzą. Jednak da się je wrzucić do dwóch kategorii – kodyfikacji i personalizacji wiedzy. Za nazwanie tych kategorii odpowiedzialni są: Dyrektor Brain & Company, Thomas Tierney oraz profesorowie Harvard Business School, Morten T. Hansen i Nitin Nohria. Koniec nudzenia 😉
Kodyfikacja, utrwalanie
W skrócie, w idei chodzi o to, że kodyfikacja wiedzy jest próbą usystematyzowania jej w jakiejś trwałej formie: baza wiedzy, WIKI, tabele, raporty, harmonogramy i podobne działania. Tu chodzi o takie skonstruowanie systemu, organizację jego elementów, aby każdy miał odpowiednie dostępy do wiedzy: w znanych mu źródłach, bez konieczności szukania jej u ludzi – wiedział gdzie tego szukać, umiał to odczytać itd.
W modelowej wersji firm IT może to pewnie przyjąć formę jakiegoś idealnego WIKI, w którym drzewo stron jest totalnie przejrzyste, artykuły są aktualne i dobrze napisane, a użytkownicy zawsze znajdą coś czego szukają, wiedzą też gdzie i jak coś redagować. Tylko czy takie coś istnieje?
Personalizacja, ludzie
Drugie podejście (personalizacja) stawia na interakcje między ludźmi i przepływ wiedzy między nimi. Personalizacja zakłada, że lepiej zbierać wiedzę i aktualizować w wyniku komunikacji między ludźmi. Po prostu, gadajmy, róbmy warsztaty, uczmy się na wspólnych doświadczeniach. Brzmi chaotycznie? Nie ma tu zakazu spisywania wiedzy, ale akcent stawiany jest na relacjach między ludźmi. Moim zdaniem to milion razy lepszy pomysł.
Kodyfikacja jest marnotrawstwem czasu, najczęściej
Takie konkretne kodyfikowanie wiedzy ma szanse powodzenia w pewnych okolicznościach: gdy sytuacja firmy zmienia się bardzo powoli, więc treści mogą być bardzo łatwo aktualizowane. W takiej firmie praca na wiedzy odbywa się najczęściej w sposób wtórny – czytanie, po to, aby wiedzieć jak wykonać jakieś zadanie itd.
Z czym innym będą mierzyły się zespoły IT, które rozwijają np. strony www i współpracują ściśle z marketingiem, obsługą klienta, dużą liczbą interesariuszy. Im bardziej dynamiczne środowisko firmy i takiego zespołu, tym trudniej będzie im utrzymać w dobrej formie skodyfikowany system wiedzy. Dlatego personalizacja jest lepszym rozwiązaniem dla takich zespołów. Moim zdaniem, im większa dynamika otoczenia tym mniejszy sens kodyfikowania czegokolwiek. I tak nikt tego nie przeczyta. A w gorszym scenariuszu przeczyta i będzie wprowadzony w błąd, bo w momencie spisywania coś już staje się nieaktualne.
Szerzenie wiedzy między ludźmi, zapewnienie im warunków do swobodnej wymiany doświadczeń, nie tylko powoduje, że przepływ wiedzy będzie odpowiedni. To dodatkowo sprawia, że ludzie więcej ze sobą rozmawiają, znają się lepiej i nawiązują dużo trwalsze relacje. Dobrzy menadżerowie będą to wiedzieli i stworzą fajne otoczenie dla swoich zespołów, aby mogły uczyć się jeden od drugiego, na błędach i sukcesach, z prezentacji czy warsztatów, z luźnych rozmów przy kawie, programowania w parach itd.
Jeszcze jeden przykład. Skrajny, ale prawdziwy. Firma sadza nowego pracownika przed toną dokumentacji, dziesiątkami artykułów na WIKI i daje mu miesiąc na “zapoznanie się z procedurami”. Czy to ma szanse powodzenia? Lepiej „zorganizować” nowemu pracownikowi kolegę, który będzie nowemu opowiadał “o wszystkim”, przeprowadzi przez pierwsze zadania. Nie dość, że się lepiej poznają i już na starcie powstanie jakaś relacja, to proces uczenia będzie szybszy. Co ważne: pracownik z doświadczeniem nauczy nowego tego, co jest realnie potrzebne, a nie tego, co ktoś sobie, gdzieś tam kiedyś wpisał, “bo może sie komuś przyda”. Korporacje często stosują podejście: “w ramach onboardingu musisz poznać nasze zasady” – dają takiemu świeżakowi pełno linków, bazę wiedzy i niech czyta. A co! Intencje najlepsze. Tylko, że bez praktyki, to co przeczytaliśmy miesiąc temu i było nudne, na pewno nie będzie pamiętane.
Przyznaję, czasem trzeba coś spisać
No dobra. Prawda jest też taka, że będą sytuacje, gdy będzie sensem, czy nawet koniecznością, coś zapisać. Nawet jeśli jest to mega dynamiczny zespół. Np. gdy są jakieś stałe w jego życiu, którymi nikt nie chce sobie zaprzątać głowy w przyszłości i przypominać sobie “jak to było?”. Czasem mogą być to dobrze napisany plik readme czy komentarz w kodzie. Jeszcze kiedy indziej jakaś strona w firmowym WIKI czy ogólnodostępny arkusz.
Ważne jest to, że gdy już utrwalamy wiedzę to forma powinna być przystępna – dokumentacja powinna znajdować się możliwie blisko codziennych narzędzi pracy, a nie np. w zupełnie odrębnej prezentacji w folderze, o którym nikt nie wie, w aplikacji z której korzysta tylko dział X.
Dobrze, aby danej wiedzy nie posiadała tylko jedna osoba – gdy pójdzie na urlop to ktoś powinien umieć ją zastąpić. Personalizacja może to załatwić, ale czasem mogą to być bardzo twarde rzeczy – jak skonfigurować system XYZ – wygodniej jest zrobić krótkiego tutka „krok po kroku” i mieć go zawsze pod ręką. I to też jest argument za utrwalaniem wiedzy.
Spisywać czy nie?
Wg mnie, przede wszystkim, należy tę decyzję zostawić tym, którzy z wiedzy będą korzystali. I najlepiej, gdy to oni zadbają o jej utrzymanie i obieg. Bardzo często widać odgórnie wprowadzane zasady, co trzeba spisywać, w jakim formacie itd. i to jest główny ból, w takich sytuacjach. Jestem zdania, że zespoły potrafią same spisać to, co realnie potrzebne i przez praktykę mogą tworzyć dobre wzorce, które potem będą powielane przez innych. Rzeczy, których nie trzeba spisywać, ogarniają na poziomie relacji. Może czasami trzeba im tylko pokazać problem, dać przykład, pokazać model. Niekoniecznie narzucać ideę „to stwórzmy dokumentację/raport/harmonogram”.
Chcesz jeszcze poczytać?
Do zilustrowania treści użyto grafik / zdjęć od: Nikolai Ultang