Przychodzi Klient z pomysłem do software house’u i pyta – ile to będzie kosztować?

To nie jest początek żartu tylko teraźniejszość w świecie IT. Bardzo często w naszej pracy musimy odpowiadać na pytania typu: ile to zajmie czasu, na kiedy to dowieziecie i ile to będzie kosztować. Odpowiedzi na te pytania nie są łatwe i zależą od wielu elementów. Lista tych elementów jest długa i moją intencją nie jest ich opisywanie, ale bardziej uruchomienie Twoich szarych komórek, chociaż w tym wypadku wysiłek intelektualny może być bolesnym procesem😊

Jednym z moich ulubionych pytań rekrutacyjnych jest pytanie dotyczące sposobów estymacji zadań/projektów. Najczęstszą odpowiedzią jaką słyszę jest coś w stylu – szacuję na podstawie swojego doświadczenia. A co jeśli nie masz większego doświadczenia lub robisz coś po raz pierwszy? Ale i nawet gdy masz już doświadczenie, estymował_ś kilka projektów, znasz wiele technik estymacji (np. analogii, PERT, planning poker itd.) to bierzesz odpowiedzialność za swoją wycenę, a to często wpływa na jej kształt. Ponieważ dochodzi do tego aspekt ludzki i obawa przed błędną estymą. 

Software development ma ca. 90 lat i jest stosunkowo młodą branżą, która dynamicznie się zmienia. Są różne statystyki dotyczące realizacji projektów, sporo z nich mówi, że ca. 60% projektów się nie udaje. Co jednak się nie zmienia w tym wszystkim? 

Frederick P. Brooks napisał w 1975 r. ponadczasową książkę o tytule „Legendarny osobomiesiąc”. Ponadczasowa dlatego, że po 48 latach ta książka nadal jest aktualna! Zawiera ona dużo ciekawych przemyśleń dotyczących szacowania, zachowania spójności koncepcji, komunikacji w zespołach itd. Elementy te nie zmieniają się przez lata! Dlatego uważam, że każda osoba pracująca przy produkcji oprogramowania powinna ją przeczytać żeby w swoich szacunkach uwzględniać elementy o których często zapominamy, albo zwyczajnie o nich nie wiemy. Poniżej przytoczę kilka wątków z tej książki:

• Osobomiesiąc jest bardzo niebezpiecznym i podstępnym mitem, ponieważ sugeruje on, że pracownicy i miesiące są wartościami wymiennymi.

• Dodawanie pracowników do projektu na 3 sposoby zwiększa niezbędne nakłady pracy: praca nad podziałem zadań, szkolenie nowych członków zespołu, zwiększenie ilości wzajemnej komunikacji.

• Problemy z harmonogramem, niedopasowanie funkcji i systemowe błędy powstają przede wszystkim dlatego, że lewa ręka nie wie, co robi prawa, a zespoły oddalaj się od siebie, przyjmując założenia.

Nasz potencjalny Klient czeka jednak na odpowiedź. Dlatego należy używać procesów i metod ułatwiających szacowanie zadań/projektów. Taki "narzędziownik" jest niezbędny jeśli chcesz profesjonalnie realizować projekty. Szacowanie projektów jest trudnym zadaniem i Frederick P. Brooks miał rację mówiąc, że ten "smolisty dół inżynierii oprogramowania jeszcze przez bardzo długi czas będzie prawdziwą pułapką".

Co myślisz o temacie estymacji projektów/zadań? Jakie techniki estymacji używasz? Czy Twoje estymacje się sprawdzają?

Link do postu na LinkedIn: https://www.linkedin.com/feed/update/urn:li:activity:7028683125681467392/