Transfer wiedzy w fazie discovery developmentu software

Transfer wiedzy w software development uderza mnie najmocniej na samym początku projektu - w momencie, gdy lead trafia na moje biurko i próbuję zrozumieć kilka zdań, PDF lub na wpół zapamiętaną rozmowę z korytarza konferencyjnego. Zanim istnieje jakakolwiek linia kodu, zanim rozpocznie się jakikolwiek oficjalny „projekt", między klientem a organizacją IT toczy się już intensywny proces uczenia się.

W naszym przypadku to zazwyczaj oprogramowanie szyte na miarę. Nie jesteśmy silnie sproduktyzowani jako organizacja usługowa. To oznacza, że za każdym razem flow odkrywania, design operations i podejście do zarządzania projektem muszą być dostosowane do konkretnego kontekstu.

Transfer wiedzy jako kręgosłup zanim powstanie jakikolwiek kod

Dopóki kod źródłowy nie zostanie napisany, operujemy głównie w przestrzeni interpretacji. Co klient mówi, co wysyła jako dokumentację, co słyszę, jak filtruję, jak opowiadam historię wewnątrz firmy - wszystko to jest wciąż transferem wiedzy, nie implementacją.

Myślenie o software development jako transferze wiedzy w pierwszej kolejności, a dopiero potem jako kodowaniu, daje zaskakująco potężne narzędzie diagnostyczne.

Od leada do pierwszego briefingu

W praktyce wszystko zaczyna się od leada. Ścieżka, którą podąża lead, jest już częścią historii. Już tutaj mamy wiele warstw transferu wiedzy.

Wiedza jawna i ukryta w pierwszych rozmowach discovery

Na powierzchni rozmawiamy o zakresie: jakie funkcje, jakie moduły, jacy użytkownicy. To wiedza jawna. Ale bardzo szybko zaczynam polować na wiedzę ukrytą - rzeczy, które nie są zapisane, ale kompletnie zmieniają sposób, w jaki powinniśmy podejść do projektu.

Tłumaczenie rzeczywistości klienta na wewnętrzne uczenie się organizacyjne

Gdy czuję, że mam wystarczający obraz, przechodzę w tryb wewnętrznego tłumaczenia. Transfer wiedzy zmienia kierunek: z „klient do mnie" na „ja do mojej organizacji".

Estymacja jako lustro jakości naszego transferu wiedzy

Estymacja w IT jest trudna nawet z idealnymi danymi. Gdy transfer wiedzy jest płytki, staje się w zasadzie wykształconym zgadywaniem. Ten krok estymacji to dla mnie rodzaj lustra.

Warsztaty discovery jako ustrukturyzowany transfer wiedzy

Są przypadki, gdy po prostu muszę powiedzieć: nie wiemy jeszcze wystarczająco dużo, żeby odpowiedzialnie wycenić to. Wtedy traktuję fazę discovery jako główny „produkt".

Oferta jako pierwszy współdzielony artefakt wiedzy

Ofertę postrzegam jako coś więcej niż artefakt sprzedażowy. To pierwsza stabilna, współdzielona ekspresja wspólnego modelu mentalnego między dwiema organizacjami.

Dlaczego ciągle wracam do tej perspektywy

To, co naprawdę odróżnia dobre organizacje IT od reszty, to jak celowo traktują transfer wiedzy. Discovery to nie formalność pre-sales. To kluczowy proces uczenia się.

Dalsze czytanie

Przeczytaj o podstawowych koncepcjach transferu wiedzy tutaj

Więcej o mojej przestrzeni badawczej i początku podróży doktorskiej tutaj