Software to najpierw transfer wiedzy, a dopiero potem kod

Większość zespołów mówi o dostarczaniu oprogramowania tak, jakby zaczynało się ono od kodu. Tak nie jest. Na długo przed pierwszym commitem projekt jest łańcuchem interpretacji: tego, czego chce klient, czego faktycznie potrzebuje, co ty usłyszałeś i co przekazałeś zespołowi. Ten łańcuch to transfer wiedzy i to on decyduje o wyniku bardziej niż jakikolwiek framework czy stos technologiczny.

To jest główna idea mojej pracy: wartość w oprogramowaniu jest tworzona lub tracona podczas transferu wiedzy, a nie w kodzie. Zadbaj o poprawne przekazywanie informacji, a realizacja stanie się łatwiejsza. Zrób to źle, a żadna inżynieria nie uratuje projektu.

Co oznacza, że „software to najpierw transfer wiedzy”?

Oznacza to, że prawdziwą pracą na wczesnym etapie jest przemieszczanie zrozumienia między ludźmi, a nie tworzenie artefaktów. Wymagania, szacunki i specyfikacje są tylko tak dobre, jak wiedza, która posłużyła do ich stworzenia. Nieprecyzyjna estymacja z przewymiarowanym buforem bezpieczeństwa nie jest w rzeczywistości ryzykiem projektowym. To sygnał, że transfer wiedzy był powierzchowny.

Gdzie ucieka wiedza w projekcie programistycznym?

Wiedza wycieka podczas przekazań (handovers). Za każdym razem, gdy zrozumienie przechodzi z jednej osoby na drugą, sens może zostać utracony. Zanim wymaganie dotrze do tech leada, często jest to już informacja z trzeciej ręki. Typowe punkty wycieku to:

• Klient do konsultanta, podczas discovery i sprzedaży.
• Konsultant do zespołu realizacyjnego, w ofercie i na kickoffie.
• Projektant do inżyniera, przy przekazywaniu projektów.
• Zespół do przyszłego zespołu, gdy ludzie odchodzą lub dołączają do projektu.

Świadomość istnienia tego łańcucha to połowa sukcesu. Gdy projekt zaczyna zbaczać z kursu, pomocne pytanie nie brzmi „gdzie zawiódł plan”, ale „przy którym przekazaniu zgubiono wiedzę”.

Wiedza jawna a ukryta: czego klient ci nie mówi

Wiedzę jawną łatwo uchwycić: zakres, moduły, integracje. Wiedza ukryta (tacit knowledge) to ta część, która rzadko trafia na papier: dlaczego podjęto daną decyzję, historia stojąca za ograniczeniem, obawy, które interesariusz ciągle powtarza. Większość nieudanych przekazań traci tę warstwę ukrytą. Dobre discovery to w dużej mierze polowanie właśnie na nią.

Mapa przekazań: prosta diagnostyka

Możesz przeprowadzić audyt kulejącego projektu, mapując jego punkty styku. Wypisz każdy moment, w którym wiedza zmienia właściciela, zaznacz, co było jawne, a co ukryte, i sprawdź, gdzie zniknęła część ukryta. Taka mapa zazwyczaj wskazuje prosto na przyczynę źródłową i jest znacznie bardziej przydatna niż kolejne spotkanie statusowe.

Jak sprawić, by transfer wiedzy stał się częścią procesu?

• Traktuj ofertę jako wspólny model mentalny, a nie dokument sprzedażowy. To pierwsze stabilne porozumienie między dwiema organizacjami.
• Gdy nie wiesz wystarczająco dużo, by odpowiedzialnie estymować, przeprowadź discovery jako płatny produkt. To pierwsza i najtańsza iteracja produktu.
• Uchwyć wiedzę ukrytą w krótkich, uporządkowanych rozmowach, a następnie promuj to, co przetrwa weryfikację, do żyjącej bazy wiedzy. Rejestracja musi wyprzedzać odzyskiwanie informacji.
• Stwórz listę kontrolną przekazań, aby kontekst nigdy nie zależał wyłącznie od pamięci jednej osoby.

Jak podaje badanie projektów IT z 2017 roku, „komunikacja jest najważniejszym czynnikiem sukcesu w projektach IT” (Stevenson i Starkweather, 2017). Transfer wiedzy to ten czynnik ujęty w konkretnej formie.

Jeśli twój zespół ciągle traci kontekst między discovery, designem a realizacją, jest to problem z transferem wiedzy, a nie z brakiem talentu. Zobacz, jak podchodzę do strony badawczej w Research Operations lub dowiedz się więcej o transferze wiedzy w discovery projektów IT.