Kluczowy inżynier składa wypowiedzenie. Projekt, który prowadził, opóźnia się o dwa lata. Nikt nie wie, dlaczego system działa tak, jak działa. Dokumentacja? Nieaktualna od trzech lat. Zespół traci czas na spłatę długu technicznego.
Trzy pytania, które warto zadać sobie teraz – nie po fakcie:
1. Kto w Twoim zespole jest jedyną osobą znającą kluczowy obszar?
2. Ile wiedzy istnieje tylko w głowach ludzi i co się stanie, gdy nie przyjdą jutro do pracy?
3. Jak tym zarządzać?
W zespołach R&D wiedza kluczowa dla projektów często nie istnieje nigdzie poza głową jednej osoby. Odejście może stanowić ryzyko o kolosalnym znaczeniu.
„Bus factor”czyli gdy wiedza jest w głowie jednej osoby
W czerwcu 1994 roku na liście mailingowej Pythona Michael McLay zadał pytanie, które dobrze oddaje sedno problemu: „Co się stanie, jeśli Guido zostanie potrącony przez autobus?”
Guido van Rossum był twórcą Pythona i jedyną osobą, która w pełni rozumiała architekturę języka. McLay wrócił właśnie ze spotkania biznesowego, na którym głównym argumentem przeciwko wdrożeniu Pythona była właśnie ta zależność od jednej osoby. Firmy nie chciały budować produktów na technologii, która mogła zniknąć wraz z jednym człowiekiem.
To pytanie spopularyzowało metrykę zwaną „bus factor” – liczbę osób, które musiałyby „wpaść pod autobus (albo odejść)”, aby projekt się zatrzymał.
Badania projektów open source pokazują, że większość z nich ma „bus factor” równy dwóm lub mniej. W środowisku produkcyjnym i R&D sytuacja często wygląda podobnie – krytyczna wiedza o produkcie koncentruje się w rękach nielicznych.
Sagrada Família: gdy wizja istnieje tylko w jednej głowie
7 czerwca 1926 roku Antoni Gaudí szedł ulicami Barcelony do kościoła. Potrącił go tramwaj. Wyglądał tak nędznie, że wzięto go za żebraka – trafił do szpitala dla ubogich. Rozpoznano go dopiero następnego dnia. Zmarł 3 dni później. .
Gaudí pracował nad bazyliką Sagrada Família przez 43 lata. W momencie śmierci ukończona była jedna wieża z osiemnastu planowanych. Projekt istniał głównie w formie modeli gipsowych i szkiców, ale pełna dokumentacja techniczna nigdy nie powstała.
Dziesięć lat później, podczas wojny domowej (1936), anarchiści spalili jego warsztat. Zniszczono modele, plany, fotografie. To, co pozostało z wizji Gaudíego, trzeba było rekonstruować z fragmentów.
Oczywiście na długość budowy wpłynęło wiele czynników: wojny, problemy z finansowaniem, zmieniające się technologie. Ale brak udokumentowanej wizji sprawił, że każdy kolejny architekt musiał interpretować intencje Gaudíego zamiast je realizować. Budowa trwa już 143 lata. Planowane zakończenie konstrukcji: 2026 – setna rocznica śmierci architekta.
Gdy wiedza krytyczna istnieje tylko w jednej głowie, jej utrata zmienia dobrze rokujący projekt w archeologię.
Tacit vs explicit: wiedza, której nie da się wygooglować
Wiedza w organizacji dzieli się na dwa rodzaje.
Wiedza jawna (explicit): dokumentacja, procedury, specyfikacje. Można ją zapisać, przeszukać, przekazać nowemu pracownikowi.
Wiedza ukryta (tacit): doświadczenie, intuicja, kontekst decyzji. „Wiem, że ten dostawca zawsze się spóźnia, więc zamawiamy wcześniej.” „Ten parametr ustawiamy na 7, bo przy 8 maszyna wibruje.” „Z tym klientem nie negocjujemy ceny, bo w 2018 roku prawie straciliśmy kontrakt.”
Problem: większość krytycznej wiedzy w R&D jest ukryta. Nie istnieje w żadnym dokumencie. Istnieje w głowach ludzi, którzy kiedyś odejdą.
Gaudí miał w głowie nie tylko wymiary i kształty – miał filozofię konstrukcji, rozumienie światła, symbolikę każdego elementu. Jego następcy mogli skopiować formy, ale nie mogli odtworzyć procesu myślenia, który do nich prowadził.
Sygnały ostrzegawcze – co sprawdzić
„Zapytaj Kowalskiego” – Jeśli na pytania techniczne odpowiedź brzmi „zapytaj Kowalskiego” – masz „bus factor = 1”.
Dokumentacja „do uzupełnienia” – Dokumentacja istnieje, ale jest nieaktualna. Ostatnia aktualizacja: dwa lata temu.
Onboarding trwa miesiące – Nowy pracownik potrzebuje pół roku, żeby „wejść w projekt”. Nie dlatego, że projekt jest skomplikowany – ale dlatego, że wiedza jest rozproszona i niejawna.
Decyzje bez śladu – Nikt nie pamięta, dlaczego wybraliśmy to rozwiązanie. „Tak było, jak przyszedłem.”
Ekspert jako wąskie gardło – Każdy projekt wymaga tej samej osoby. Projekty czekają w kolejce, bo „tylko Nowak to ogarnia”.
Co można z tym zrobić
1. Zmapuj wiedzę krytyczną Zidentyfikuj: które obszary projektu zna tylko jedna osoba? To nie wymaga skomplikowanych narzędzi – wystarczy uczciwa rozmowa z zespołem. Pytanie brzmi: „Gdyby X jutro odszedł – co by się zatrzymało?”
2. Rozdziel wiedzę świadomie Rotacje w zespole, wspólne przeglądy projektów, praca w parach nad krytycznymi obszarami. Nie chodzi o dokumentowanie wszystkiego – chodzi o to, żeby wiedza krytyczna była w więcej niż jednej głowie.
3. Dokumentuj decyzje, nie tylko wyniki Najcenniejsza dokumentacja to nie „co zrobiliśmy”, ale „dlaczego tak zdecydowaliśmy”. Kontekst decyzji to właśnie ta wiedza ukryta, która ginie pierwsza.
4. Standaryzuj język i metodykę. Kiedy zespół posługuje się wspólnym językiem rozwiązywania problemów, wiedza przestaje być zamknięta w jednej głowie. Metodyki takie jak TRIZ czy podejścia DFM/DFA dają zespołom wspólny framework – sposób myślenia, który jest transferowalny między osobami.
Koszt transferu wiedzy vs koszt jej utraty
Transfer wiedzy kosztuje czas. Dokumentacja wymaga wysiłku. Szkolenie następców zabiera godziny, które mogłyby iść na „prawdziwą pracę”.
Ale porównaj to z alternatywą. Przy „bus factor równy dwóm lub mniej” – wiedza koncentruje się w rękach nielicznych.
Koszt transferu wiedzy jest zawsze niższy niż koszt jej utraty. Różnica polega na tym, że transfer wymaga decyzji teraz, a utrata uderza później – i zwykle w najgorszym momencie.
Zadaj sobie pytanie: gdyby najważniejsza osoba w zespole jutro nie przyszła do pracy – co by się zatrzymało?
Jeśli odpowiedź Cię niepokoi – czas działać. Zanim będzie za późno.
Autor: Piotr Tetlak| Metodyka: TRIZ, TESE, walidacja strategiczna
