Ileż to razy w myślach osiągałem wszystko...
Przedłużająca się teoretyzowanie PRZED etapem implementacji to główny przeciwnik zwinności. Problemem jest tylko i aż to, że rzeczywistość nie jest tak prosta, jak analiza na kartce.
Co może pójść nie tak?
Techniczna wiedza
Podczas implemetacji dowiadujemy się takich rzeczy, jak:
- Nie da fizycznie tego zrobić
- Da się zrobić, ale jest trudniejsze niż myśliliśmy
- Da się zrobić, ale jest nieopłacalne
- Da się, ale pod pewnymi warunkami, których nie braliśmy pod uwagę przy analizie
- Musimy zmienić jeszcze to, to, i to.
- Znaleźliśmy lepsze / łatwiejsze rozwiązanie
- Wymagania nie są jasne
- Nie mamy ludzi / czasu / kompetencji na zrobienie tego w pełnym wymiarze
Bezpiecznie jest założyć, że zawsze tego typu sprawy wyjdą na etapie implementacji.
Biznesowa wiedza
To, co zaimplenentowaliśmy, powinno dawać wartość biznesową. Czy ją rzeczywiście daje, dowiemy się dopiero po dostarczeniu implementacji.
Dlatego mamy iteracje, żeby "reality check" realizować na bieżąco i korygować kurs.
Dlatego też im bardziej zwinni jesteśmy, tym bliżej rynku check powinien się odbywać. PO zrobi lepszą ocenę niż tester, end user lepszą ocenę niż PO, a cały rynek lepszą ocenę niż end user.
Jak nie bujać w obłokach
Jak najszybciej przejdź do pisania implementacji. Choćby małej jej części (negocjacje scope'u to twój najlepszy przyjaciel). Bo tylko implemetacja rzeczywiście redukuje niepewność.
Zwróc uwagę na etapy projektu, które zależą od implementacji (analiza, research, estymacja). Niezależnie jak dobrze realizujesz te tematy, zawsze istnieje ryzyko zaskoczenia przy implementacji. Szklany sufit implementacji. Czy wobec tego warto doskonalić się w spekulowaniu?
Zawsze zminimalizuj spekulację i szukaj zamienników bardziej osadzonych w rzeczywistości:
- analiza projektu -> analiza iteracji (jeśli nietrafiona, to przynajmniej w małej skali)
- research -> proof of concept, timebox
- estymacja -> forecast
Najlepszym sposobem na eliminację niepewności jest sprawdzić, a nie spekulować.