Ostatnio miałem kilka filozoficznych przemyśleń, które udało mi się podsumować do bardzo przyziemnych wniosków. Głównie dzięki temu, że miałem okazję bardzo niskopoziomowo pomagać w pewnym projekcie który się opóźnił.
Przemyślenia dotyczyły tego, jak łatwo się domyślić dlaczego projekty idą wolno.

Jakie mogą być tego przyczyny?

1. Projekt jest źle oszacowany.

I tak naprawdę, idzie szybko – ale nie będzie zrealizowany w terminie.
Widziałem niedawno świetną alegorię opisującą dlaczego tak się dzieje: http://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3.

Jeśli projekt jest typu fixed-price – dla klienta nie jest źle :) Firma wdrożeniowa pokryje koszty zwiększonego zakresu prac. Dla firmy wdrożeniowej może to oznaczać najgorsze. Tak czy siak nie będzie to prowadziło do najwyższej jakości.

2. Klient nie jest przygotowany i nie odpowiada.

Praca przy dużych projektach to nie jest zamówienie krzesła u stolarza, gdzie w najlepszym wypadku jedynymi pytaniami z jego strony będą: ile ma mieć nóg? jaki kolor? Projekty IT trwają kilkanaście miesięcy. W tym czasie pytania jakie się pojawiają są z zakresu: Czy mamy synchronizować stany magazynowe? do Jak wygląda specyfikacja metody API w Państwa systemie ERP służącej do zmiany statusu zamówienia które nie może być zrealizowane przez niedostępność wybranej metody dostawy w określonym regionie geograficznym

Serio. Pytań są setki. Współpraca musi być na bieżąco. Każde opóźnienie lub nieprzygotowanie po stronie właściciela biznesowego projektu – potrafi dosłownie rozbić prace. Jeszcze gorzej gdy odpowiedzi znajdują się, ale za późno. Czasami trzeba wtedy przebudować cały projekt.

Wbrew pozorom w dużych firmach nie jest łatwo o osoby decyzyjne. Decyzje zależą od konsultacji wielu działów. Czasami też ktoś po prostu boi się podjąć decyzji.

3. Zespół jest za duży.

Każdy zna pewnie zależność ścieżek komunikacji od rozmiaru zespołu?  Ilość ścieżek komunikacji wzrasta wykładniczo do tego ile osób bierze udział w projekcie.

W praktyce oznacza to tyle, że każdy musi wiedzieć o co chodzi – a że wiedza jest rozproszona nęka pytaniami wszystkich innych :) Jeśli zespół jest mały (3-4 osoby jednocześnie) problemu nie ma. Przy zespołach 10 osobowych zaczyna być trudno. Czasami niektóre osoby potrafią przez jakiś czas nie mieć nic do roboty lub wykonywać zupełnie niekluczowe w danym momencie zadania.

Pomaga dobra dokumentacja, jasno opisane zadania, kompletny backlog. Wszystko co porządkuje komunikację pomaga. Mniej dyskusji = szybsza praca zespołu i większa efektywność.

Bardzo ważne jest aby tę efektywność mierzyć. Na przykład za pomocą wykresów spalania znanych ze SCRUMa. Ilość szacowanych godzin / przepracowanych godzin w danym sprincie to najprostszy miernik tego, czy idziemy i czy dojdziemy do wyznaczonego celu.

4. Nie wiadomo, co jest do zrobienia.

Wbrew pozorom, oprócz błędnego szacunku to jest najczęstsza przyczyna tego, że projekty się opóźniają. Tak naprawdę, jest nią brak asertywności PMa :) Brak przygotowania do bycia asertywnym!

Aby być asertywnym trzeba mieć odwagę i trzeba mieć dane. Trzeba móc pokazać jaki jest pierwotny zakres prac i co się w nim zmieniło. Bez dobrej analizy i specyfikacji wymagań a także projektu łatwo popłynąć.

Niestety to sytuacja niebezpieczna dla obu stron (klienta biznesowego i działu IT). Łatwo o konflikt a koniec końców nikt nie dostaje tego co chciał. IT ponosi koszty a klient nie dostaje produktu na czas.

Kluczowe jest estymowanie i śledzenie wszystkich zmian w projekcie. Zadawanie sobie pytania jak to wpływa na termin. Bez odpowiedzi na to pytanie termin nigdy nie zostanie ustalony.

Jeśli projekt przechodzi do fazy testów i poprawek możemy wykonać dokładne całościowe testy. Na ich podstawie wyestymować wszystkie znane poprawki (i aktualizować te dane w miarę jak pojawiają się nowe zgłoszenia błędów). Na tej bazie iteracyjnie można wyznaczyć finalny termin.

Co to wszystko oznacza?

Wniosek jest taki, że faktycznie, inżynieria oprogramowania jest bardzo skomplikowaną dziedziną ludzkiej działalności. Moim zdaniem najpewniejszą metodą wyznaczania terminów i realizowania projektów informatycznych są metodyki zwinne (Agile) i metoda rozliczania time & material (realnie przepracowany czas zespołu).

W takim modelu to klient mówi kiedy można wydać pierwszą wersję – za pomocą miary szybkości zespołu można oszacować terminy i zakres funkcji. Klient ma pełną kontrolę nad tym co i kiedy się wydarzy.

 

Ostatnio głośno było wobec afery z PKW i firmą informatyczną przygotowującą system. Nie mnie oceniać. Sytuacja jest generalnie smutna, na pewno nie jest polem do wymądrzania się i wytykania palcem. Mam cichą nadzieję, że skłoni do refleksji i tych realizujących systemy IT i tych je zamawiających.

Zdrowy rozsądek i brak łudzenia się to najlepsze narzędzia do wyznaczania realnych terminów!