7 najczęstszych błędów podczas wyceny projektów
Estymowanie projektów IT to trudne zadanie. Najczęściej w estymowaniu chodzi o to, by trafić jak najbliżej faktycznej ceny projektu, by popełnić jak najmniejszy błąd. Okrągłe liczby kłamią! Znakomicie widać to podczas wyceny projektów, kiedy projekt jest oszacowany na 10, 50, 100, 200 tysięcy to najprawdopodobniej mamy do czynienia z niedoszacowaną lub przeszacowaną wyceną. Opiszę błedy, które są najczęściej popełniane podczas estymowania projektów.
Pssst… mam dla Ciebie prezent 🙂
1. brak rozpisanych tasków
Od klienta zazwyczaj dostajemy historię. To właśnie ta historia często bywa celem i zakresem projektu. Używając słowa historia, mam na myśli opowieść (dosłownie) klienta na temat funkcjonalności, które jego zdaniem projekt powinien realizować. Kluczową rolę w wycenie projektów będzie miało to, jak rozbijemy tą historię na zadania i podzadania. Możemy pogrupować historię na moduły, funkcjonalności lub widoki – odpowiedni podział trzeba dobrać w zależności do szczegółowości i specyfiki zakresu. Dobry podział zadań do projektu to połowa sukcesu. To pierwsza czynność, którą powinniśmy wykonać – od niej zależy dalsze powodzenie naszej wyceny, dlatego ten punkt jest na mojej liście jako pierwszy 🙂 Dobra struktura zadań da nam pogląd na ogrom systemu – uświadomimy sobie jakie czynności będzie musiał zrealizować developer (czynności, które nie są zauważalne z poziomu historii) by osiągnąć kryterium sukcesu.
2. nierozbite taski
Punkt drugi, ściśle powiązany z pierwszym. Rozbicie zadań na drobniejsze zwróci naszą uwagę na czynności poboczne do zadania – które też oczywiście nas kosztują. W celu lepszego zobrazowania problemu posłużę się przykładem przeniesienia krzesła między pokojami.
Czas przeniesienia krzesła z punktu A do B wynosi 15 sekund (nasza estymata przed rozbiciem na podzadania). Analizując i rozbijając zadanie mamy:
- ustawienie się w punkcie A – 5 sekund (powiedzmy, że musimy pójść do pokoju żeby wykonać czynność (przygotowanie do zadania też zajmuje czas)
- odstawienie krzesła, otworzenie drzwi, podniesienie krzesła żeby wyjść z pokoju – 3 sekundy (krótkie zadania przewidziane lub nieprzewidziane problemy)
- odstawienie krzesła w punkcie B oraz wyjście z pokoju B – 5 sekund (finalizacja zadania)
- droga między punktami z krzesłem zajmuje 15 sekund
Pierwotna estymata : 15 sekund, po rozbiciu na pod zadania – 28 sekund. To dość jaskrawy przykład pokazujący, w którym pomylilibyśmy się prawie o połowę. Ludzka psychika działa tak, że gdy mamy zdefiniowaną czynność ogólnie – zaniżamy nieświadomie czas. Nie wiem dokładniej jak to działa z punktu widzenia neurologicznego, ale potwierdzają to przykłady, które zapewne każdy z nas doświadczył. Mam tutaj na myśli przygotowanie się rano do wyjścia z domu. Moment estymowania następuje przed zaśnięciem gdy ustawiamy budzik („zjem śniadanie, ubiorę się i wyjdę – wyrobię się w 1h”). Natomiast życie to weryfikuje i często okazuje się, że czasu brakuje a my jesteśmy spóźnieni i robimy wszystko w pośpiechu. Wynika to z braku rozbicia zadań na mniejsze. Śniadanie przed zjedzeniem trzeba przygotować, ubrania wyprasować, między czynnościami też upływa czas (nie teleportujemy się z kuchni do łazienki) – nieprzewidziane zadania podczas tego przykładu mają wpływ na to czy będziemy punktualni (pokryje się nasza estymata), a w projekcie IT będzie to odpowiednio czas dostarczenia projektu oraz jego ostateczna rentowność. Z punktu widzenia Project Manager’a nawet 5% rozjazd ma znaczenie – gdy pomnożymy to przez ilość zadań może wyjść niezła suma.
3. zasięgnięcie porady tylko jednego eksperta
Powiedzenie „co dwie głowy to nie jedna” ma tutaj przełożenie. Mając odpowiednio przygotowaną listę zadań możemy zacząć ją wyceniać. Ilu ludzi tyle metod i różnych temp pracy – każdy ma inne umiejętności i predyspozycje. Najlepiej zasięgać rady developerów, których przypiszemy do projektu by wycenić każde z zadań – jednak nie zawsze mamy ten komfort. Często zdarza się, że nie wiemy kogo będziemy mogli przydzielić do zadania. W obu przypadkach istotne jest by zadania developerskie pomógł nam wycenić więcej niż jeden developer. Ubezpieczamy się tutaj na wypadek zastąpienia jednego developera drugim (np. urlop, choroba, zwolnienie), dodatkowo zyskujemy szerszy pogląd na zadania – jeśli developer A ocenił zadania na 2d, a developer B na 6d – to „wiedz, że coś się dzieje” 🙂 Jeśli rozjazd wynikałby z poziomu umiejętności – możesz ułożyć plan, którego zasobu będziesz potrzebował do jakich zadań (poziomy trudności) by skończyć projekt w planowanym czasie.
4. nie uwzględnienie czasu na analizę i projektowanie
Zadania developerów wymagają zaplanowania, ułożenia ich w ciąg przyczynowo-skutkowy. Według mnie planowanie i analiza jest najważniejszym i najtrudniejszym etapem realizacji projektu. Mając oszacowane zadania często zapominamy, że musimy je ułożyć w jakiś plan, rozdzielić zadania, porozmawiać z developerami (planowanie miękkie), kto czuje się lepiej w jakim zadaniu – to wszystko zajmuje czas. Nie wspominając o planowaniu twardym (harmonogramy/dokumentacje) – bo to jest oczywistym elementem projektu.
5. nie uwzględnienie czasu zarządzania projektem
Mając oszacowany development i inne aspekty, często zapominamy o doliczeniu naszego czasu (Project Manager’a). Każda metodologia prowadzenia projektów kosztuje nas czas (od strony organizacji pracy). Łatwo to wyjaśnić na przykładzie Scrum’a, planowanie sprintu (~20m), daily scrum (4 x 15m), podsumowanie (~20m), retrospekcja (~15). Czas potrzebny na organizację ~tygodniowego sprintu dla zespołu (przy założeniu, że jesteśmy jednocześnie Scrum masterem) wynosi – niecałe 2h. W skali miesiąca to cały dzień pracy. To był jeden z przykładów obowiązków Project Managera – podejrzewam, że znajdziecie więcej (nieprzewidziane call’e wewnętrzne nt. projektu / rozmowy z klientem itp) 😉 Podsumowując takie zadania w skali całego projektu wychodzą naprawdę spore liczby. Najłatwiej to uwzględnić szacując zaawansowanie projektu, ile średnio godzin dziennie będziemy musieli poświęcać na prowadzenie takiego projektu. To sprawa indywidualna, każdy ma inne metody – chodzi o to ile Ty na to poświęcisz czasu. Następnie liczbę godzin mnożymy przez liczbę dni na jaką oszacowaliśmy projekt – to najprostsza metoda uwzględnienia czasu opieki nad projektem.
6. nie uwzględnienie czasu integracji modułów
Zlecając część systemu podwykonawcy, należy uwzględnić czas na integrację go z systemem. Na przykład zlecając zewnętrznemu grafikowi render obiektów 3D, wynikiem jego pracy będą pliki graficzne. Strona internetowa by wyświetlać widok w 360 potrzebuje jeszcze kilka godzin pracy frontend developera, żeby wszystko wyglądało poprawnie. Kolejnym przykładem jest kupno licencji na gotowe pluginy/moduły, np. mailingu, a nie doliczenie czasu jego integracji z systemem ponieważ kupiony plugin spełnia nasze założenia funkcjonalne.
7. nie uwzględnienie podróży służbowych
Zdarza się to częściej przy większych projektach. Można nie uwzględnić np. potrzeby pojechania na kilka dni do klienta na drugi koniec kraju w celu dokonania analizy, przeprowadzenia UAT (user acceptance testing) czy wdrożenia produktu.
Nie ważne jak bardzo będziemy się przykładać do wyceny – faktyczny koszt wciąż pozostaje zagadką. Ważna jest zdrowa świadomość, że końcowa kwota naszej wyceny jest wyłącznie szacunkiem.
Co według Ciebie jest częstym błędem podczas wyceny projektu? Napisz w komentarzu 🙂
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
Mogę polecić bardzo ciekawe narzędzie do weryfikacji czasu pracy w IDE:
https://wakatime.com/dashboard
Ja jako tracking używałem https://toggl.com/ lub timetracker’a z Jira 🙂
Ok, z tym, że to co podałem można zintegrować z IDE i liczy czas spędzony na pisaniu kodu. Czyli od kiedy do kiedy było pisane coś w IDE. Do tego ładnie pokazuje statsy i podział na projekty i pliki
Wygodne 🙂 u nas bardziej operuje się na taskach i to jest wyznacznikiem końca i startu pracy (status task’u) – stąd jira timetracking sprawdza się dobrze.
Generalnie nie ma złych narzędzi, tylko użyte w niewłaściwych okolicznościach 🙂
Zasady o których piszesz moim zdaniem sprawdzają się dla dużych projektów (wiele osobowych) na początku określania czasu wykonania ale gdy dochodzi do estymacji tych małych sub-tasków gdy dochodzimy do układu jeden programista jedno zadanie. Wtedy wyżej przedstawione zasady tez się sprawdzą ale moim zdaniem blędem jest podawanie przez programistę wykonania danego zadania w konkretnych godzinach czy dniach.
Osobiście od jakiegoś czasu używam takiej techniki (do esymacji projektów jak i poprawy błędów) – podaje oczywiście 3 opcje, najgorszą, normalną i najlepszą oraz dla każdej z nich podaje rozkład prawdopodobieństwa czyli najgorsza opcja to na 70% zrobię to w 10 dni ale może to zająć więcej, dla normalnej piszę, że na 80% zrobię to w 5 dni.
Co to daje – przede wszystkim to, że nigdy nie mówię ile konkretnie mi to zajmie, bo tak naprawdę nie wiem ile mi to zajmie, dopóki nie zacznę pisać kodów. Mam czas na robienie testów itd. Nie biorę na siebie odpowiedzialności, że ja na na pewno zrobię w 8 dni, bo wtedy muszę to zrobić w 8 dni, nie zależnie od tego jak błędy po drodze wyjdą.
Minusem jest to, że na początku był opór PM-ów do takiego podejścia, bo nie dostają konkretów. Tylko rozkład prawdopodobieństwa byłem nie ugięty i jakoś to zaakceptowali.
Cześc, dzięki za komentarz 🙂
Sądząc po nick’u piszesz okiem programisty 🙂
Sposób, który opisałeś według mnie jest ciekawy – PM otrzymuje coś w rodzaju histogramu – według mnie ciekawe dane do analizy, można założyć najwcześniejszy i najpóźniejszy koniec. Nie rozumiem czemu w Twoim przypadku PM mieli problem z akceptacją tego.
Jeśli chodzi o odpowiedzialność za estymaty – według mnie programista powinien brać tą odpowiedzialność 🙂 To w końcu jego praca (:)) – realizować rzetelnie kod, w terminie, którym zadeklarował.
W komentarzu oczywiście opisuje „świat idealny” kiedy jesteśmy w stanie wszystko przewidzieć, a jak wiemy życie jest życiem i w pełni rozumiem rozjazdy w szacunku do 10-15%, ale jeśli ktoś myli się o 50% czy 100% to znak, że trzeba zrobić retrospekcję 🙂
Mi brakuje jeszcze tutaj narzutu na bug fixing
Cześć, dzięki za komentarz 🙂
oczywiście, brakuje tu wielu rzeczy, które trzeba uwzględnić 🙂 W tym wpisie opisałem 7 najczęstszych błędów, które się popełnia podczas estymowania projektów. Nie traktuj proszę artykułu jako checklisty – co włączyć w wycenę 🙂
Warto pamiętać jeszcze o:
1) Dodatkowy narzut na code review i na poprawki po code review
2) Koszt testowania przez testera lub napisania testów automatycznych UI
3) Koszt błędów analizy. Często developer dostaje dokument analizy, zaczyna implementację i zaraz okazuje się, że coś się tutaj nie spina…
4) Koszt konfiguracji środowisk testowych, serwera buildów itp
5) Koszt wystawiania paczek z oprogramowaniem do klienta (proces wdrażania na środowisko testowe/produkcyjne – w zależności od modelu współpracy z klientem).
5) W zależności od typu projektu koszt audytu bezpieczeństwa i/lub poprawek po audycie.
Ja zgadzam się z rzeczami dodanymi przez p. Cezarego.
Np. 4 ) – konfiguracje Buildów / środowisk testowych potrafią zeżreć masę czasu, a pozornie wydaje się że to takie proste.
Ja bym dodał : zbyt pośpieszne i optymistyczne wycenianie i próby wykonania obszarów typu 'reasearch’, czyli nieznanych technologicznie.
To co ostatnio sprawdza się u nas to _spokojny_ (!!!) tryb pracy w obszarze reaserchowym :
analiza -> reasearch -> analiza -> proof of concept -> analiza -> i wykonanie idzie wtedy piorunem .
Rzecz w tym że różne rzeczy 'reaserchowe’ muszą naturalnie 'dojrzewać’, często próba zaplanowania i wykonaniu 'już tu i teraz i za wszelką cenę’ to wielkie koszty, chaotyczna praca, efekt mizerny.
Cześć, dzięki za komentarz!
Co do podejścia optymistycznego i negatywnego w wycenie, nie jestem zwolennikiem zakładania pesymistycznych scenariuszy, projekt może być o wiele przeszacowany – tym samym mniejsza szansa, że klient wybierze naszą ofertę. Imho trzeba wyceniać realistycznie, czyli w miejscach gdzie zakres może wydawać się trudniejszy – wyceniajmy pesymistycznie. W miejscach obarczonych mniejszym ryzykiem – realistycznie.
Niestety ten świat idealny jest krzywdzący dla programisty. Dlaczego?
1. Firmy często zaniżają wycenę, bo chcą wsadzić but w drzwi. I często dopóki oferta nie zostanie zaakceptowana, a kwity podpisane programista w dużej firmie nawet nie ma szansy na odniesienie się do estymaty.
2. Często Head Architect i inne osoby odpowiedzialne za estymowanie czasu realizacji projektu już jest jedną nogą w biznesie i ich szacunki są raczej pobożnymi życzeniami lub są tak poważnymi fachowcami, że nie biorą pod uwagę, że ktoś może wykonywać zadanie 2, 3, 4 razy dłużej od niego.
3. Nieaktualna, nieprecyzyjna, wręcz kulawa dokumentacja – to jest to z czym stykałem się w dużej firmie.
4. W małych firmach, przy jednoosobowych projektach jest dużo łatwiej. Wyceniam wszystko sam, dogaduję z klientem wszystko sam i wiem na czym stoję. Jak dla klienta jest za drogo, robię wycenę bez UATów, które przerzucam na klienta, a poprawki idą w support. Liczy się czas i elastyczność.
Reasumując to chyba zawsze zależy. Niektórzy wolą duże molochy, inni zwinne maluszki. Dla wszystkich jest miejsce.
Dzięki za komentarz. Zgadzam się z tym co napisałeś – gdybym ten artykuł pisał dziś pewnie bym go rozszerzył o te punkty. Ważna sprawa żeby wyceniali projekt ludzie, którzy będą to robić, jednak czym większa organizacja tym trudniej o to. Problemem jest też to, że wyceny szacunkowe przyjmuje się jako pewne – a później jest rozjazd.