Oszacowanie czasu potrzebnego do wykonania danego projektu to odwieczny problem inżynierii oprogramowania. Być może w ostatnich latach coś się w tym względzie zmieniło, ale jeśli nie, to wciąż pozostaje aktualna sugestia, że najskuteczniejszym sposobem jest po prostu… zapytanie kogoś kompetentnego :) Najwyraźniej wypracowanie jakichś ścisłych i skutecznych metod oceny nakładu pracy i czasu przy tworzeniu oprogramowania jest wciąż poza naszym zasięgiem i trzeba się uciekać do metod typu – z naciskiem na drzwi.
Sam mam kilka teorii na temat tego, czemu tak jest. Jedną z nich jest postulat, że do różnego rodzaju projektów należy stosować różne modele przewidujące czas ich trwania. Owych rodzajów jest zaś dokładnie trzy i są to bardzo proste kategorie. Wyróżniam mianowicie projekty zbyt proste, odpowiednie i zbyt trudne. Określenia te odnoszą się – jak można się domyślić – do stopnia trudności danego projektu dla zespołu, który go wykonuje. Nie należy jednak traktować ich zbyt dosłownie ;)
I tak przez projekt zbyt prosty rozumiem taki, którego główne wyzwanie (czyli główna funkcjonalność) jest w gruncie rzeczy łatwe do zrozumienia i zaprojektowania, a co za tym idzie także do zakodowania. Spotykając się z takim zadaniem, możemy bez dużego wysiłku wypracować dla niego rozwiązanie, które wystarczy “tylko” zaimplementować.
Paradoksalnie jednak tutaj mogą zacząć się schody. Kiedy główny problem jest już za nami, i to bardzo szybko, motywacja do kontynuowania prac spada. Mimo że zwykle pozostaje jeszcze sporo do zrobienia, nie są to już czynności wymagające dużego wysiłku intelektualnego, więc często mogą być po prostu nudne. Tempo sukcesywnie więc spada w miarę zbliżania się do końca.
Dokładnie odwrotnie jest z kolei w przypadku projektów zbyt trudnych. Gdy główny problem jest tak skomplikowany, że przez długi czas nie wiadomo, jak właściwie się do niego zabrać, postęp prac jest nikły. W pewnym momencie jednak (miejmy nadzieje) przychodzi olśnienie – albo raczej seria mniejszym “eurek” – i od tego momentu wszystko nabiera bardzo dużego przyspieszenia. I nawet po rozwiązaniu głównego problemu nie musi ono wcale zwalnia, lub inaczej: nawet jeśli zwalnia, to efekt ten nie jest łatwo zauważalny w skali czasowej całego przedsięwzięcia.
Trzecia kategoria leży natomiast pośrodku między dwiema powyższymi. Projekt jest odpowiedni, jeśli przez cały czas trwania prezentuje mniej więcej podobny poziom trudności dla zespołu, który go wykonuje. Oznacza to, że jego główny problem daje się rozwiązać systematycznie i sekwencyjnie, nie zaś prawie automatycznie (w przypadku projektów zbyt łatwych) lub tylko za pomocą nagłego odkrycia (jak w przypadku projektów zbyt trudnych).
Tym trzem kategoriom projektów możemy przypisać krzywe określające poziom zaawansowania prac w zależności od czasu. Nietrudno jest zauważyć, że dla przedsięwzięć zbyt łatwych będzie to funkcja logarytmiczna, dla zbyt trudnych – wykładnicza, zaś dla odpowiednich będzie ona zbliżona do linii prostej:
Jeśli umiemy rozpoznać, do której z tych trzech kategorii należy nasz projekt, to niewykluczone, że możemy spróbować uniknąć niektórych pomyłek przy szacowaniu czasu pozostałego do końca projektu. Dla projektów zbyt łatwych można na przykład łatwiej niż zwykle ulec złudzeniu planowania i nie docenić czasu pozostałego do końca prac, kierując się tym, iż na początku “idzie jak z płatka”. Dla zbyt trudnych można natomiast błędnie ekstrapolować początkowe trudności w przyszłość i wnioskować, że projekt będzie trwał całe lata (podczas gdy może trwać miesiące lub… dekady, w zależności od tego, kiedy nastąpi “olśnienie”).
Najważniejszym wnioskiem – jeśli moje przemyślenia są prawdziwe – jest jednak korzyść, jaką daje zapewnienie, by projekt był odpowiedni. Wówczas szansa na wiarygodne oszacowanie pozostałego czasu jest znacznie zwiększona, bo mówimy wtedy o ekstrapolacji funkcji w przybliżeniu liniowej. Żeby jednak móc korzystać z tej pożytecznej cechy, musimy postarać się o odpowiednie dobranie zespołu do zadania… lub odwrotnie :)
Ładne wykresy, ale niestety nie ma to wiele wspólnego z rzeczywistością. :) Chociażby dlatego że wymagania (założenia) ciągle się zmieniają — “łatwy” projekt może łatwo zmienić się w trudny kiedy klient zażąda kluczowych modyfikacji na dwa dni przed goldem :) Pomijasz też etapy pre- i post-produkcji; bugfixów i testowania itp. W praktyce więcej mówią wykresy burndown (pozostałych ticketów/roboczogodzin w funkcji czasu). I na nich dobrze widać różnicę między dobrym i złym projektem — bo nie rozumiem sensu “łatwych/średnich/trudnych” projektów w profesjonalnym IT. Są projekty krótsze i dłuższe — i albo masz wystarczające zasoby (np. wystarczająco dobrych programistów) aby je zrealizować albo nie. Jako “trudne” projekty rozumiem bardziej jakiś research w przypadku którego trudno oszacować ramy czasowe bo robi się rzeczy nowe, a nie powtarza wyuczone.
Ja dawno przestałem przewidywać czas trwania projektu. Od 1990 roku gdy kupiłem małe Atari i zacząłem coś grzebać w Atari Basic widzę, że żaden projekt nie trwał tyle ile zakładałem. Z projektami jest tak jak z remonetm, naprawą samochodu czy budową – to zawsze trwa dłużej niż się przypuszcza. Nawet jak się weźmie bufor bezpieczeństwa to i tak będzie dłużej. :) Tak było, jest i zapewne zawsze będzie. Widzę to w swoich małych i średnich domowych projektach, oraz we wszystkich małych, średnich i dużych projektach w których coś tam robiłem we wszystkich miejscach pracy do której zmusiło mnie życie. Byłoby świetnie gdyby dało się przewidzieć czas trwania projektu. Niestety tego się nie da zrobić (a przynajmniej ja sobie tego nie wyobrażam). Nawet jak nie ma marudzącego i niekonsekwentnego klienta i robi się tylko na własny rachunek to i tak wyskoczy miliard niespodziewanych “eventów”, które całość opóźnią wielokrotnie.
Cała filozofia na temat przewidywania zupełnie do mnie nie trafia tak samo jak analizowanie wykresów giełdowych. :) Geometryczne przewidywanie kursów akcji/walut jest dla mnie równie śmieszne co zastanawianie się jakie liczby padną w totolotku. Nie jesteśmy w stanie tego przewidzieć i już.