Pora na kolejny, trzeci już artykuł w ramach serii dotyczącej procesu estymacji w projektach i już na początku zadam Ci pytanie: czy zastanawiałeś się kiedyś dlaczego niektóre zespoły mają problemy z estymowaniem, a w wielu przypadkach nie radzą sobie z tym zadaniem? Nawet znajomość technik estymowania często okazuje się niewystarczająca. W czym zatem tkwi problem?
Estymacja jest poniekąd jak poker – o rezultacie decyduje nie tylko technika, ale też psychologia i czynnik ludzki. Dziś przedstawię pułapki czyhające na Ciebie podczas estymowania.
Nie daj się złapać… w pułapkę
Poniżej przedstawię całkiem subiektywne obserwacje – wnioski, dlaczego moim zdaniem rezultat estymowania często dość znacząco odbiega od rzeczywistych wartości (dotyczy to zarówno czasu, jak i kosztów).
Tendencja do bycia nadmiernie optymistycznym lub pesymistycznym
Podczas planowania pracy zespołu zarówno programiści, jak i kierownicy projektów szacują w sposób poniekąd właściwy z ich naturą. Optymiści na ogół zaniżają szacunki, pesymiści wręcz odwrotnie. W przypadku optymistów wynikać to może z przeceniania swoich umiejętności, niedoceniania potencjalnych przeszkód, czy zakładanie, że wszystko pójdzie sprawnie i żadne problemy nie spowolnią ich w osiągnięcia celu. Rzeczywistość często bywa bolesna i sprawia, że pojawiają się dodatkowe zadania czy chociażby zależności, które w fazie początkowej nie były uwzględnione, a także problemy, które były początkowo bagatelizowane, urastają do rangi, która wywraca pierwotne estymacje do góry nogami. Czasem też najzwyczajniej okazuje się, że pozornie łatwe zadanie takim nie jest… Pesymiści znów mają tendencję do demonizowania pewnych rzeczy, wyolbrzymiania zagrożeń, czarnowidztwa – tu wszystko może pójść źle. I czasem rzeczywiście idzie źle, a oni mogą powiedzieć: “A nie mówiłem?”. Z jednej strony można by rzecz, że lepiej być przygotowanym na najgorsze, a jak to najgorsze się nie wydarzy, to zaoszczędzić trochę czasu. Pytanie tylko czy sprzedamy klientowi projekt z takimi buforami na ryzyka i piętrzące się trudności?
Brak analizy historycznych danych i wyciągania wniosków
Project managerowie podczas planowania pracy zapominają o analizie danych historycznych z ukończonych projektów, a to właśnie analiza jest źródłem wiedzy, która pozwala na podejmowanie decyzji i planowanie skutecznych działań. Posiadając informacje na temat podobnego projektu zakończonego w przeszłości, jak chociażby występujące w nim ryzyka, odchylenia i ich przyczyny, wykorzystane zasoby itd., project manager może uwzględnić je (po odpowiedniej analizie tych danych) podczas etapu planowania nowego projektu i tym samym zminimalizować projektowe perturbacje. Z wieloletnich badań firmy QSM wynika, że dobre planowanie jest ważniejsze niż metodyka prowadzenia projektu i jest kluczem do osiągnięcia sukcesu.
Próba zbudowania trójkąta ograniczeń “na siłę”
Project managerowie często dostają z góry narzucony budżet i termin zakończenia projektu wraz z wymaganiami, które mają zostać dostarczone. Nazywam to estymowaniem “pod tezę”, czyli takim, gdzie nie pokazujemy ile rzeczywiście będą trwały prace, a pokazujemy estymacje tak, aby osiągnąć z góry założony wynik. To estymacja powinna być wartością wejściową do wyliczania budżetu i długości trwania projektu, a nie odwrotnie. Pisała o tym Karolina w artykule “Projekt z kapelusza”. W przypadku, gdy budżet jest zdefiniowany i jest jedyną stałą wejściową, musimy dostosować zakres i czas zgodnie z odwróconym trójkątem ograniczeń (często stosowanym w podejściu Agile’owym).
Nieuwzględnienie zależności
Przy estymowania pracy nad zadaniem często dodatkowe blokady i zależności mogą być niedostrzegane lub pomijane. Mamy wówczas do czynienia z sytuacją, w której zadanie wyestymowane na 10 dni pracy dewelopera głównie polega na czekaniu na innych. Ostatecznie przy wcześniejszym uwzględnieniu zależności to samo zadanie mogłoby trwać zaledwie 1 dzień. Taka praktyka może powodować naturalne przedłużanie się czasu trwania projektu, a co za tym idzie – niedostarczenie go na czas. Na wczesnym etapie prac dość trudno zdefiniować czy dostrzec wszystkie zależności, stąd bywa, że nie są one uwzględnione podczas estymowania. Chęć zaoszczędzenia czasu na planowaniu może się tu odbić czkawką, warto więc zainwestować w planowanie, co znów potwierdza przywołane wcześniej badania QSM.
Estymacja dokonywana w silosach
Estymacja nie jest procesem, który powinien być wykonywany przez jedną osobę, nawet jeżeli jest to najbardziej doświadczony pracownik w firmie i o danym projekcie wie wszystko. Z doświadczenia wiem, że najczęściej prośba o estymację trafia do team leaderów – osób doświadczonych, a zarazem niekoniecznie potem zaangażowanych w dewelopment. Pozwól, aby zespół deweloperski był zaangażowanych w rozmowy i proces estymacji. Uwzględnienie doświadczeń kilku osób pozwoli spojrzeć na zakres i zadania do wykonania z różnych perspektyw, lepiej uchwycić zależności, zidentyfikować luki w dokumentacji czy różnice w rozumieniu tego, co jest do wykonania. Pamiętaj też, że osoba z większym doświadczeniem podczas estymowania poda mniejszą wartość z uwagi na to, że dane zadanie będzie dla niej relatywnie łatwe, a niekoniecznie potem ta osoba będzie nad tym zadaniem pracować. W związku z tym warto przyjąć wartości, które wypracował zespół, a nie jego poszczególni członkowie.
Brak widoczności na wyniki estymacji
Zarówno dokumentacja projektowa, diagramy infrastruktury, standardy technologiczne powinny być udostępnione i łatwo dostępne dla członków zespołu deweloperskiego, tak samo powinno być z estymacją poszczególnych zadań projektowych. Oczekiwania, które nie są znane nie są zaakceptowane przez zainteresowane strony, stają się bezwartościowe, jak bowiem można oczekiwać, że deweloper zrealizuje zadanie w czasie, który nie jest mu znany lub z którym nie miał szansy się nie zgodzić? W zaistniałej sytuacji poszczególni członkowie zespołu nie mają możliwości zareagowania wystarczająco wcześnie, czy też nie są w stanie podjąć działań mających na celu np. zminimalizowanie opóźnienia. Zdecydowanie łatwiej rozmawiać o oczekiwaniach na początku, aniżeli wtedy, kiedy przysłowiowe mleko się rozlało. Deweloperzy nie tylko powinni znać wyniki procesu estymacji, ale również – nawiązując do punktu powyżej – powinni brać w nim udział.
Brak re-estymacji
Wraz z postępem prac w projekcie przybywa nam informacji, rzeczy niejasne na początku stają się klarowne, niedostrzeżone od razu zależności zaczynają się wyłaniać, rozumienie zadań i tego, co jest do wykonania rośnie, pojawiają się również nowe ryzyka, których nie byliśmy świadomi na początku i zaczyna wyglądać na światło dziennie jakość kodu. To wszystko może sprawić, że pierwotna estymacja okaże się nieaktualna. Tkwiąc przy nich, nie bacząc na pojawiające się nowe zmienne, na oślep dążymy ku katastrofie. Plan ma to do siebie, że powstaje w oparciu o dane jakimi dysponujemy w momencie, kiedy go robimy. Proces re-estymacji jest niezbędny dla tego, aby ten plan urealniać.
Mądry Polak…
Powyżej wymieniłem najczęstsze pułapki, w jakie zdarzało się wpaść mi lub moim kolegom po fachu podczas procesu estymacji. “Mądry Polak po szkodzie” mawiają, dlatego dzielę się dziś z Wami tym doświadczeniem i zwracam Waszą uwagę na aspekty, które mają ogromny wpływ na wynik końcowy. Lista ta nie jest skończona, stąd ciekaw jestem pułapek, w jakie Wam zdarzało się wpaść. Stwórzmy razem pakiet kontrolny – listę punktów, na które warto zwrócić uwagę, aby proces estymacji był prawie doskonały! ;)
W kolejnym artykule z tej serii przyjrzymy się niepewności oraz temu, jak jest powiązana z procesem estymacji.
