Cała prawda o wycenach projektów IT – dlaczego jest, jak jest?

Tworzymy wyceny projektów, na podstawie których budujemy harmonogramy. Kolejnie te projekty się opóźniają, a my powtarzamy cały proces od początku. Zastanowiłem się głębiej nad tym procesem i opisałem swoje wnioski i wskazówki, które znacząco polepszyły statystyki terminowości projektów, które mamy w fresh-apps.com.

Czy potrafimy wyceniać projekty?

Przyczyn opóźnień projektowych może być wiele, ale to temat na osobny wpis. Według mnie większość z przyczyn opóźnień da się przewidzieć i im zapobiec.

Oczywiście istnieją też tzw. prawa Murphy’ego – „spodziewaj się niespodziewanego” ;). Opóźnienie mierzymy na podstawie tego, jaki plan zakładaliśmy pierwotnie dla projektu.

Gdybyśmy tego nie określili – nie można byłoby mówić o opóźnieniu. Jakiś czas temu zadałem sobie pytanie – czy potrafimy wyceniać projekty? Odpowiedzi w poniższych statystykach:

• 88% projektów się opóźnia;
• średnie przekroczenie kosztów – 190%;
• średnie przekroczenie czasu – 220%.

Badania są z przed kilku lat – chociaż myślę, że nie wiele się zmieniło w ubiegłym 2017 roku. Biorąc pod uwagę te statystyki i zadając sobie pytanie czy potrafimy wyceniać – odpowiedź jest prosta. Nie wychodzi nam to zbyt dobrze. Oczywiście, że jest to generalizacja, ale przybliża nam skalę problemu.

Czasy w wycenie są zbyt krótkie?

Wyciągając powyższe wnioski, zacząłem się zastanawiać skąd wynika takie przekroczenie czasowe i kosztowe. Zadałem sobie pytanie: może dajemy zbyt krótkie czasy? Gdybyśmy wszystkie wyceny mnożyli 2x to według statystyk projekty kończyłyby się w terminie. Niestety, tak by nie było bo:

• problemem nie są zbyt krótkie czasy tylko zupełnie błędne założenia podczas wycen (o tym w kolejnych akapitach). Większe bufory w wycenach powodowały by to, że projekty opóźniałyby się „później”, ale nie rzadziej. Dzieje się tak przez kilka mechanizmów m.in. presja/kary za przekroczenie terminów, prawo Parkinsona, prawo studenta. Napisałem serię artykułów na ten temat więc odeślę cię do nich:
  • bufory „bezpieczeństwa” w zadaniach
  • zbyt szybkie zamykanie zadań
  • centralizacja buforów projektowych
• nie bylibyśmy konkurencyjni – twoje projekty by się nie opóźniały bo prawdopodobnie żaden z klientów nie skorzystałby z twoich usług, więc nie miałoby się co opóźniać. Oczywiście, że generalizuję w tym miejscu – wszystko zależy od wymierności jakości i ceny, ale w przetargu z firmami na podobnym poziomie podbicie dwukrotne ceny/czasu to skazanie się na odrzucenie oferty.

Zadajemy zbyt mało pytań przed wyceną?

Bardzo często w sytuacji, w której wpływa zapytanie od klienta – zespół wyceniający przygotowuje pytania, jeśli coś jest niejasne. Te pytania są przesyłane do klienta, on je przesyła swoim specjalistom (często parafrazując i gubiąc sens), oni odpowiadają itd. Kolejnym pytaniem jakie sobie zadałem było to, że może zadajemy zbyt mało pytań? Gdybyśmy dociekali bardziej?

Odpowiedź w poniższym eksperymencie, mam nadzieję, że analogia do wycen nie będzie zbyt odległa.

Spróbuj odpowiedzieć sobie na pytanie: w ile czasu dojechałbyś do Berlina?

Pewnie odpowiedziałeś, że kilka godzin. Co jeśli po twojej odpowiedzi dodałbym, że chodziło o rozpoczęcie podróży z Budapesztu? Wtedy czas będzie prawdopodobnie inny od tego, który pomyślałeś bo musiałbyś wykonać inny zakres. Jako wartość domyślną początku trasy prawdopodobnie wziąłeś swoje aktualne położenie.

Można stwierdzić, że „przecież mogłem powiedzieć, że chodzi o podróż z Budapesztu”. Owszem, mogłem, ale równie dobrze mogłeś o to spytać przed podaniem wyceny.

A co jeśli powiedziałbym, że jako punktem pośrednim podróży ma być Wilno? Możesz się kłócić, że nie wspomniałem o tym na początku, ale też prawdopodobnie byś nie spytał przed rzuceniem wyceny czy chodziło o odwiedzenie jakichś punktów po drodze.

A co jeśli powiedziałbym, że chodzi o podróż rowerem? Wtedy czas jest kilkunastokrotnie wyższy. Sytuacja analogiczna do powyższych – nie powiedziałem/nie spytałeś.

Zapewne zauważasz, że tych wymogów, o których nie powiedziałem na początku może być nieskończenie wiele, które wpływają na wycenę. Zawsze twoim argumentem może być, że klient nie powiedział, ale jego z kolei jest „nie zapytałeś”.

Klient uważa nas za specjalistę, więc twierdzi, że zadamy mu odpowiednie pytania, żeby poznać 100% wymagań. W prawdziwym świecie mamy słowo przeciw słowu i dodatkowy zakres do wykonania. Oczywiście nie mówię tutaj o sytuacjach absurdalnych gdzie klient celowo zataja fakty.

Moje wnioski są takie, że wcale nie chodzi o to ile pytań zadamy przed wyceną – i tak może istnieć jakieś wymaganie, o które nie zapytamy, a wpłynie znacząco na wycenę.

Wyceniamy zbyt pochopnie?

To, że wyceniamy zbyt pochopnie było kolejnym pytaniem, które nasunęło mi się na myśl. Może zbyt krótko zastanawiamy się nad tym ile czasu powinno zająć dane zadanie i stąd te opóźnienia?

Aktualnie prowadzę software house fresh-apps.com, więc dostaję wiele zapytań o wyceny projektów. W poprzedniej pracy również byłem odpowiedzialny za wstępne wyceny, więc temat nie jest mi obcy.

Żeby wycenić projekt rzetelnie „z czystym sumieniem”, że zrobiłem co mogłem zajmowało to średnio 6-12h, były to wyceny szacunkowe, ale na tyle dokładne ile było wiadomo na temat projektów.

Czas na wycenę był oczywiście uzależniony od wielkości projektów – zdarzały się krótsze i dłuższe. Jak można łatwo policzyć, przy dwóch wycenach w tygodniu spędzałem około 3 dni roboczych na same wyceny.

Mimo, że poświęcałem mnóstwo czasu na wyceny, mało projektów dochodziło ostatecznie do realizacji. Zacząłem dociekać i pytać klientów, dlaczego nie zaakceptowali mojej oferty? Zazwyczaj padały odpowiedzi, że czasy były zbyt duże, inne firmy wyceniły to na 30% mniej czasu.

Zacząłem pytać klientów – czy konkurencja zadała te pytania, które ja? Odpowiadali, że nie. Wniosek dla mnie był oczywisty – sam sobie strzelałem w kolano.

Przez to, że chciałem dać wycenę bardziej dokładną – zdarzało się, że czas był większy niż u konkurencji. Konkurencja nie spytała o to co ja, więc nie wycenili tego – dlatego ich estymata była niższa.

Finalnie realizowali ten projekt… no i jakie są statystyki przedstawiłem na początku artykułu. Jeśli chcieli ukończyć projekt – musieli zrealizować te rzeczy, o które nie zapytali na początku.

Tyle, że okazało się to być dodatkowym zakresem/dodatkowymi kosztami. Bardzo często zdarzało się też tak, że ci klienci wracali po kilku miesiącach z prośbą o „dokończenie” bo firmy się wycofały w trakcie realizacji projektu. Prawdopodobnie przerósł ich ukryty zakres.

Wyceniając projekt musimy mieć też na uwadze kilka faktów. W interesie klienta jest, żeby zrealizować projekt jak najtaniej w akceptowalnej dla niego jakości.

Natomiast w interesie wykonawcy jest to, żeby zarobić na nim jak najwięcej. W większości przypadków te interesy są ze sobą sprzeczne, więc nie jestem zaskoczony kiedy po podpisaniu umowy zaczyna się „koncert życzeń klienta”. Trzeba umieć to odpowiednio pokierować.

Jakie popełniamy błędy podczas wycen?

Kilka lat temu napisałem artykuł 7 najczęstszych błędów podczas wycen projektów IT. Polecam żebyś rzucił na niego okiem – postaram się go teraz uzupełnić o nowe rzeczy:

Implikacja wymagań

Kojarzycie pewnie implikację z przedmiotów związanych z logiką i teorią mnogości. W implikacji wymagań chodzi o to, że jeśli mamy zdefiniowane wymaganie A i wymaganie B to realizacja tych dwóch wymagań może skutkować tym, że powstaje dodatkowe wymaganie – C.

Problem z implikacją wymagań jest taki, że najczęściej poznajemy dodatkowe wymagania dopiero w momencie realizacji – kiedy już harmonogram jest ustalony.

Każdy dodatkowy zakres może powodować opóźnienia względem harmonogramu. Zazwyczaj te „dodatkowe wymagania” nie są oczywiste i trudno je przewidzieć na etapie planowania. Poruszałem ten temat również w wpisie dotyczącym błędów w komunikacji email.

Wycena hurtowa zadań – ile kosztuje kilogram pomidorów? a ile jeśli wezmę ich tonę?

Zdarzało się wielokrotnie, że wyceniałem projekty jako programista – często spotykałem w wycenie takie punkty jak np. „moduł użytkowników”, „moduł raportów” itp.

Chodził o o to, że punkt w wycenie obejmował kilkanaście różnych wymagań i trzeba było podać jedną liczbę. Kiedyś przygotowywałem programistom wyceny właśnie w ten sposób – tworząc w nich zbiorowe podpunkty.

Kiedy rozbijałem ten zbiorczy punkt na drobniejsze i dawałem go ponownie do wyceny – okazywało się, że programiści wyceniali sumarycznie na 20-30% więcej czasu mając bardziej szczegółowe punkty. Nie wiem jak nazywa się ten mechanizm w psychologii – prawdopodobnie byli bardziej świadomi ilości prac jakie ich czekają, natomiast przy zbiorczym zadaniu nie było to takie oczywiste.

Wiem, że z punktu widzenia arytmetyki to nie powinno mieć znaczenia, jednak z mojego doświadczenia wyceny rozbite na drobniejsze zadania są zawsze bliższe harmonogramu po zakończeniu prac nad projektem. Poruszałem ten temat również w wpisie o tym dlaczego zadania powinny być krótkie.

Poproszę 80 kg programisty

W różnych firmach projekty wyceniają różni ludzie – czasami jest to kierownik projektu, czasami analityk, czasami „główny” programista.

Problem jest taki, że jest to generalizacja zasobów. Jeżeli Jacek wycenił zadanie na 4 godziny pracy, to to samo zadanie może zająć Markowi 2 godziny a Jankowi 8 godzin. Często zdarza się, że wyceny robią osoby, które kiedyś były techniczne, ale nie mają już na co dzień kontaktu z kodem, wtedy te wyceny bywają jeszcze bardziej oderwane od rzeczywistości.

Warto zauważyć, że to, że ktoś był programistą 5 lat temu nie znaczy, że jest w stanie realnie ocenić czas realizacji przy aktualnych warunkach (nie tych z przed 5 lat). Pamiętam, że w wieku 4 lat potrafiłem zrobić szpagat, gdy miałem 10 lat już nie byłem „taki cwany” – mam nadzieję, że rozumiesz analogię ;).

Najlepiej jakby wyceny dokonywała osoba, która będzie realizowała projekt. Zdaję sobie sprawę, że życie jest życiem i nie zawsze mamy ten komfort. Jakiś czas temu napisałem artykuł o tym jak dokładniej wyceniać zadania – nawiązuje do tego akapitu.

Sugerowanie się wyceną innych

Dobrze sprawdza się rozwiązanie, gdzie kilka osób wycenia równolegle ten sam projekt. Często wyceny bywają znacznie odbiegające od siebie (nawet 300%) – więc jest nad czym dyskutować.

Podczas takich rozmów zdarza się, że ktoś zauważy jakąś nową implikację wymagań – której nie dostrzegli inni. Pozwala to mieć bardziej obiektywne spojrzenie na projekt.

Problem jest wtedy – jeśli te osoby widzą swoje wzajemne wyceny. Często zauważałem, że osoby chciały się między sobą komunikować – „ile dałeś w tym, ile w tamtym?”.

Jeśli na to pozwalałem otrzymywałem różnicę w wycenach kilku procentową – zdecydowanie lepiej to działa kiedy programiści nie ustalają wspólnej wersji wydarzeń.

Pesymistyczna – realistyczna – optymistyczna

Jeśli nie mamy w pełni określonych wymagań – może sprawdzić się wycena w trzech wariantach:

• optymistycznym – gdzie wszystko idzie zgodnie z planem;
• realistycznym – tak jak podpowiada ci intuicja;
• pesymistycznie – gdyby większość rzeczy okazała się trudniejsza niż zakładaliśmy.

Rozjazd pomiędzy tymi trzema wycenami również może sięgać kilkaset procent – w zależności od tego jak dokładnie opisane są wymagania. Prawdopodobnie gdybyś wysłał wycenę w takiej formie klientowi nie wiele by mu powiedziała – „zrealizujemy projekty jak ten w czasie od 6 do 14 miesięcy”.

Chciałoby się odpowiedzieć: „no co ty nie powiesz” 😉 Wycena w trzech wariantach może być przydatna do stworzenia oferty (jeśli otrzymamy taką od developera) – wtedy to osoba tworząca ostateczną ofertę podejmuje decyzję, na temat ryzyka (czy czas będzie bliższy wycenie optymistycznej czy pesymistycznej).

Reality check

Zdarza się, że podchodzimy do wycen mechanicznie – dostajemy opis wymań, wyceniamy każdy z punktów, sumujemy je i mamy finalną ilość godzin. Warto spojrzeć na te liczby z innej perspektywy – podzielić je na ilość dni pracujących, na tygodnie lub miesiące pracy i zastanowić się ponownie czy projekt takiego pokroju faktycznie zajmie tyle czasu?

Często zdarzały mi się przeszacowane/niedoszacowane projekty ze względu na szablon wyceny. Jeśli wymagania były rozbite na bardzo drobne – często projekty były przeszacowane, ze względu na zaokrąglenia. Zdroworozsądkowe zastanowienie się czy naprawdę potrzebujemy X godzin by napisać ten projekt?

Być może gdzieś czas jest zbyt wysoki lub wręcz przeciwnie, dojdziemy do wniosku, że czasu, który podaliśmy jest zbyt krótki. Zdarzało się, że taki rzut okiem z innej perspektywy na wycenę powodowało korygowanie jej co finalnie wyszło mi na plus.

Wycenia się tylko development

Najgorsze w wycenach są rzeczy, które nie są wycenione – często dowiadujemy się o tym od developera gdy dostajemy pytanie: „w co zalogować czas spędzony nad XYZ?”.

Wtedy sobie uświadamiamy, że nie wyceniliśmy jakiejś rzeczy, która nie była widoczna na pierwszy rzut oka. Bardzo często zapomina się o koszcie procesu wytwarzania oprogramowania.

Wiele firm, ma różnego rodzaju procedury, oprogramowania, które porządkują proces wytwarzania oprogramowania, czyniąc go tym samym bardziej pracochłonnym. Freelancer prawdopodobnie przeciągnie pliki na FTP, w małej firmie zrobią git pull, w większej pewnie jest jakieś oprogramowania wdrażające.

Jeśli wiele osób będzie musiało pracować nad jednym modułem, gdzie korzystają z tych samych plików narażamy się na ryzyko błędów podczas łączenia kodu różnych osób. Rozwiązywanie tych konfliktów, pytanie autora kodu „czy wziąć w tym miejscu fragment Bartka?” zajmuje czas. Nie twierdzę, że są to duże liczby, ale kilka procent czasu developmentu na pewno. Nie twierdzę również żeby dodawać kilka procent ze względu na obsługę GIT, chodzi o to, żebyś zawarł w wycenie czas, jaki kosztuje cię wytwarzanie oprogramowania.

Przeanalizuj z jakimi problemami zmagaliście się we wcześniejszych projektach, które zabierały czas na ich rozwiązanie.

Czym bardziej projekt jest skomplikowany – tym więcej zespół ze sobą rozmawia. Warto zawrzeć w wycenie taki punkt jak np „komunikacja wewnętrzna” lub „komunikacja z klientem”.

Czasami dwóch developerów musi ze sobą ustalić pewne fakty przed realizacją, dopytać jak ktoś rozwiązał dany problem, żeby użyć jego rozwiązania itp, itd.

Takie rzeczy są tzw. komunikacją wewnętrzną. Nie spotkałem się z projektem, który by tego nie wymagał, natomiast spotkałem się z wieloma projektami, które nie miały na to przewidzianego czasu – wtedy taka komunikacja odbywała się kosztem developmentu.

Kolejną rzeczą jest komunikacja z klientem – w zależności od tego jak dokładnie mamy opisane założenia, jeśli wiesz, że będą potrzebne spotkania/call z klientem – uwzględnij to w wycenie.

Testy & poprawa błędów – jeśli taki punkt nie znajduje się w twojej wycenie, to znaczy, że masz nieomylnych programistów. Muszę cię zasmucić bo tacy nie istnieją, wszyscy popełniamy błędy, a ich naprawa również kosztuje nas czas. Warto uwzględnić odpowiednio wysoki % czasu realizacji na testy i poprawki. Wysokość powinna zależeć od twojego procesu testowania i skomplikowania projektu.

Zarządzanie projektem również zajmuje nasz czas i powinno być wycenione. Jeśli prowadzisz projekt metodyką Scrum, możesz w prosty sposób obliczyć ile godzin będzie cię to kosztowało. W tym miejscu chciałbym cię odesłać do mojego wpis: dlaczego większość projektów prowadzonych jest Scrumem?

Są też inne metodyki – jedne wymagają więcej czasu inne mniej, ważne żeby to uwzględnić. Przeanalizuj poprzednie projekty i zobacz na co spędzałeś czas jako kierownik projektu – być może masz „kłótliwy zespół” i musisz dbać wyjątkowo o dobrą atmosferę i rozwiązywać konflikty – uwzględnij to w wycenie, bo to będzie cię kosztowało czas.

Być może jest wręcz przeciwnie – wszystko idzie zawsze zgodnie z planem i zarządzanie projektem wymaga mało czasu bo masz dobrych leaderów.

Co zrobić żeby było dobrze?

Jakiś czas temu napisałem wpis o analizie i syntezie w dokumencie analitycznym.

Możesz go sobie odświeżyć – bo to właśnie analiza i synteza będą kluczowe w rozwiązaniu problemu. Jak wspomniałem we wcześniejszych akapitach – możemy zadawać więcej pytań przed wyceną w celu lepszego poznania wymagań – jednak w dalszym ciągu jest to leczenie objawów a nie przyczyny.

Na początku chciałbym odświeżyć czym jest analiza i synteza:

Inaczej mówiąc analiza jest rozbiciem problemu na wymagania. Możemy ich zdefiniować wiele, ale nigdy nie mamy pewności, że zdefiniowaliśmy wszystkie.

Część z nich może być „ukryta” (implikacja wymagań) – wtedy takie elementy nie zostaną wycenione. Zawsze istnieje ryzyko, że istnieją w projekcie rzeczy, z których nie zdawaliśmy sobie wcześniej sprawy – mimo naszych wszelkich starań dołożonych do tego żeby jak najlepiej poznać projekt.

Synteza jest natomiast tworzeniem rozwiązania z wymagań gdzie definiujemy to w jaki sposób zostanie zaprojektowany i zbudowany nasz projekt – oprócz tego jakie ma wymagania wiemy dokładnie jak go zrobimy.

Rozumiem przez to zaprojektowanie bardzo szczegółowych makiet, z przemyślanymi elementami takimi jak filtry, raporty i wszystko czego przeróbka zajmuje nam czas. Wyceniajmy rozwiązanie, a nie wymagania.

Mając same wymagania jeszcze nie wiemy jak zbudujemy nasz projekt, natomiast właśnie to na etapie analizy jest wyceniane – stąd te wszystkie rozbieżności. Wyceniamy to, jakie cele zrealizuje nasz projekt.

Natomiast liczba ścieżek, którymi możemy osiągnąć nasz cel jest nieskończenie wiele i każda z nich wymaga innego czasu realizacji. Przez ilość ścieżek możemy rozumieć chociażby alternatywne makiety do tej samej funkcjonalności – jedna będzie prostsza do realizacji, druga trudniejsza.

Wyceniając same wymagania – klient nie wie w jaki sposób zrealizujemy projekt. Musimy pamiętać, że klient nie wie czego chce, ale wie czego nie chce. Nie powie nam w jaki sposób mamy zrealizować projekt (bo to nasza działka), natomiast zgłosi ci błędy, gdy zobaczy jak to zaprojektowałeś (bo wie, czego nie chce).

Dlatego właśnie jestem zwolennikiem wycen rozwiązań, a nie wymagań. Klient widzi przed realizacją jaki będzie efekt finalny – i uwierz, mi, że taniej jest przerobić makietę niż napisaną aplikację po uwagach klienta. We fresh-apps.com rozwiązujemy ten problem tak, że w przypadku rozliczeń projektowych pierwszym etapem jest przygotowanie dokumentacji, którą klient akceptuję.

Dopiero w oparciu o nią układamy kosztorys, bo dopiero po akceptacji rozwiązania jesteśmy w stanie go w miarę dokładnie oszacować. Jedyną niewiadomą jest tutaj czas potrzebny na przygotowanie dokumentu analitycznego – to zakładamy procentowo (5-30%) czasu developmentu w zależności od skomplikowania projektu i jego ryzyk.

Poniżej moje wystąpienie w formie wideo, na którym omawiałem temat wycen.

Podsumowanie

Statystyki mówią, że ~9/10 projektów się opóźnia – problem jest widoczny gołym okiem. Często opóźnienia wyliczamy na podstawie harmonogramu, który przygotowujemy przed realizacją w oparciu o wycenę – według mnie ma więc ona kluczowe znaczenie na rentowność projektu.

Według mnie statystyki są, jakie są ze względu na to, że wyceniamy wymagania projektowe. Wtedy sposób w jaki zostanie zbudowany system odkładamy do momentu realizacji – a to właśnie wtedy występują wszystkie nieprzewidziane problemy.

Podchodząc do tematu inaczej – czyli wyceniając konkretne rozwiązanie klient ma większe pojęcie na temat ostatecznego efektu, a ty masz większą pewność, że mniej rzeczy zaskoczy cię podczas realizacji.