Dlaczego programiści źle estymują?

10 Oct 2015 | Adam Przymusiała

We wrześniu tego roku miałem swój debiut na konferencji InternetBeta jako mówca. Było to niesamowite doświadczenie które chciałbym jeszcze kiedyś powtórzyć! Jako że włożyłem sporo serca w przygotowania (przy dużym zaangażowaniu Bartka Kużyka) i nie chciałbym żeby ta wiedza się zmarnowała zapraszam do lektury tego co powiedziałem / chciałem powiedzieć w Rzeszowie.

Wyglądało to mniej więcej tak ;)

12006648 739168012856270 5624144088183459124 O

Dlaczego programiści źle estymują?

Chciałem Wam opowiedzieć o tym, dlaczego nawet bardzo dobrzy programiści tak słabo szacują czas na wykonanie swoich zadań. Zacznę jednak od pewnej przygody którą przeżyłem kilka lat temu, myślę że pozwoli ona spojrzeć na ten problem od trochę innej, mniej technicznej perspektywy.

Projekt: Rowerem z Zakopanego do Gdańska w 6 dni.

Wszystko zaczęło się w sierpniową sobotę zaraz po północy kiedy wsiadłem z rowerem i pełnymi sakwami w nocny pociąg z Łodzi do Zakopanego. Sama podróż pociągiem minęła bez większych niespodzianek poza jedną, gdyż okazało się że mój kolega który miał mi towarzyszyć na pierwszym etapie z Zakopanego do Krakowa dosiadając się w Krakowie zaspał ;) i nie zdążył na pociąg.

Trasa którą miałem do przejechania wyglądała mniej więcej tak: Ib2015

Jadąc średnio 15 km/h przez 8 h dziennie całość powinienem pokonać w ~6 dni. Na podstawie moich doświadczeń - rok wcześniej pokonałem 300 km dzielące Poznań od Berlina w mniej niż dobę i codziennego przemieszczania się po mieście rowerem wydawało mi się to całkiem rozsądne. Wg. mapy, całość trasy powinna zamknąć się 718-750 km, noclegi czekały w Krakowie, Częstochowie, Łodzi, na obozach pod Włocławkiem i Brodnicą oraz w harcówce w Gdańsku. Rozpocząłem podróż niespodziewanie samemu (spotkaliśmy się z drugim Adamem w połowie dystansu dzielącego Kraków od Zakopanego). Po drodze mieliśmy kilka niespodziewanych objazdów (których oczywiście nie było na mapie).

Ib2015

Mimo że plan zakładał że trasę z Krakowa do Łodzi pokonam samemu, to Adam który postanowił mnie odprowadzić drugiego dnia do Ojcowa powiedział że bierze wolne na cały tydzień i przejedzie ze mną całą całość :). Ib2015

Gdzieś za Łodzią okazało się że droga która na mapie była opisana jako asfalt, i faktycznie tak się zaczęła, Ib2015

okazała się piaskownicą która była jednym z bardziej męczących elementów. Ib2015

I na koniec 6 dnia, zamoczyliśmy stopy w Bałtyku. Wskazanie licznika na końcu wyprawy trochę się nam rozjechało z początkowym założeniem: Ib2015

843 km (140 km dziennie przez 6 dni a nie 120 km jak zakładaliśmy).

Rozjazd względem planu

Rozjazd względem planu na poziomie 16-17% przy jednej zmiennej (szacowanie długości trasy przy użyciu bardzo dokładnej mapy), braku “klienta z zewnątrz” (robiliśmy to dla siebie i aktualizowaliśmy plan pod siebie).

Pomyślmy, jak by to wyglądało gdybym zabrał się za planowanie czegoś większego, np. wyprawę dookoła świata? Albo chciał oszacować czas i kosz czegoś co może być Wam trochę bliższe czyli remont mieszkania / budowa domu? Podobnie sprawy się mają przy projektach IT, a szczególne tych startupowych.

Badania

Szukając w sieci danych zebranych przez badaczy, natrafiliśmy na raport Standish Group w którym wzięło udział 365 respondentów i 8.380 aplikacji. Wskazuje on że tylko 16% projektów jest realizowanych na czas, przekroczenie kosztów znajduje się średnio na poziomie 189% a czas przekraczany jest o 222%. Jeśli zaś chodzi o zestaw funkcji, to zespoły dowożą średnio ok 61% tego co założono w specyfikacji.

Przyczyn opóźnień

Obserwując różne projekty zauważyłem że często przewijają się te same problemy wpływające na opóźnienie projektu:

  • Nieścisłości w dokumentacji - np. coś co wydawało się autorowi że działa w jeden sposób u partnera z którym się chciał zintegrować działa zupełnie inaczej. Albo, co gorsza serwis partnera zwraca teraz coś, co wymaga zmiany architektury wcześniej wdrożonych funkcji.
  • Niespodziewane, nieprzewidywalne trudności - żeby nie szukać daleko - choroba kogoś z zespołu
  • Konieczność czekania na cokolwiek. Komuś implementacja danej funkcji zajmuje chwilę dłużej lub musimy poczekać na jakieś dane ze strony klienta
  • Niedoszacowanie czasu koniecznego na realizację zadania

6 elementów wpływających na estymację

  • Naturalne problemy z planowaniem - współczynnik rozjazdu
  • Doświadczenie i zgranie zespołu
  • Znajomość warsztatu pracy
  • Nieznana dziedzina
  • Komunikacja z klientem
  • Dostępny czas na szacowanie

A co wpływa na nasze szacowanie? To że jesteśmy ludźmi ;). Zakładając jakiś harmonogram mamy tendencję do ignorowania czynników, które nie mają związku z samym projektem. Często nie bierzemy pod uwagę możliwości wystąpienia wielu zdarzeń mogących zagrozić projektowi, gdy każde z nich z osobna ma małe prawdopodobieństwo wystąpienia.

Współczynnik “rozjazdu”

Plan na dziś: dzień wypchany na maksa zadaniami: Ib2015a Ib2015b

Wzór na “współczynnik rozjazdu”:

10 godzin faktycznego czasu / 8 godzin planowania = 1,25 (czli 25%)

Małe ćwiczenie. Przygotujcie dla siebie listę zadań na cały następny dzień a następnie, oszacujcie ile poszczególne zadanie może zająć czasu. Kolejnego dnia, przy użyciu stopera zmierzcie czas trwania każdego zadania i zapiszcie czas realizacji. Porównajcie czas szacowany z faktycznym, po podzieleniu drugiego przez pierwsze i otrzymamy nasz własny współczynnik rozjazdu. Jeśli coś miało zająć w sumie 8 h a zajęło 10 h to nasz współczynnik wynosi 1.25 czyli rozjeżdżamy się o 25%.

Proszę pamiętać, że cały czas rozmawiamy o rzeczach które wykonujemy po raz kolejny, bądź są modyfikacją czegoś co już wcześniej robiliśmy. Wyceniamy też cały czas w bardzo małych porcjach (dni i konkretne zadania).

TIP: “Planuj tylko tyle ile pomnożone przez współczynnik da cały dzień roboczy”

Jeśli ktoś chciałby zaplanować kolejny dzień, powinien na podstawie dnia poprzedniego wybrać tylko tyle zadań ile czasu koniecznego na ich wykonanie pomnożone przez współczynnik rozjazdu da cały dzień roboczy. Czyli, bazując na poprzednim współczynniku powinno być to ok. 6,4 h

Doświadczenie i zgranie zespołu

To chyba najważniejszy element układanki. Będziemy mieli dużo większą dokładność jeśli będziemy szacować coś co już wcześniej robiliśmy. Weźmy na warsztat coś z naszego, webowego podwórka czyli “Logowanie użytkownika”. Jeśli ktoś pracował przy jednym dwóch projektach z logowaniem może od razu rzucić jakąś liczbę, jednak osoba która przeżyła kilka różnych projektów powinna zapytać się:

  • Czy to ma być tylko mailem, czy może przez FB/G+?
  • Jeśli przez FB to co z rejestracją apki? Kto to robi?
  • Czy ma być potwierdzenie mailem?
  • Czy formularz ma walidować maila jak nie ma potwierdzenia mailem?
  • Czy mamy blokować konto po n-błędnych próbach logowania?
  • Czy ma się generować token dla apki mobilnej?
  • Czy system ma wylogowywać po określonym czasie?
  • Czy i jak można odzyskać hasło?
  • Czy admin ma akceptować usera?
  • Czy konta można zawieszać?
  • Jak ma wyglądać mail potwierdzający?
  • Jakie mają być parametry hasła?
  • Jakie inne dane mają się znaleźć w formularzu?
  • Czy ma być weryfikacja 2-etapowa?
  • etc.

Odpowiedzi na te pytania wpływają na czas realizacji zadania - o to są pytania które można zadać dopiero po n-projektach w których były elementy logowania. Sytuacja staje się duuużo bardziej skomplikowana w przypadku funkcji startupu która jest realizowana po raz pierwszy.

Bardzo ważnym jest żeby zespół rozumiał się prawie bez słów oraz posiadał dużo wspólnych doświadczeń. Dzięki temu, podczas sesji wyceniania zadań można operować wieloma skrótami myślowymi odnoszącymi się do przeszłych doświadczeń.

Znajomość warsztatu pracy

To chyba dość oczywista sprawa, ciężko wymagać od backendowca wyceniania czasu kodowania wodotrysków we frontendzie.

Znajomość dziedziny

Znajomość dziedziny lub inaczej tematu w którym się poruszamy. Tutaj moim ulubionym przykładem jest słowo którego nauczyliśmy się podczas pracy nad sklepami z modnymi ubraniami czyli “Baskinka”. Zakładam że większość facetów bez użycia google nie była by w stanie opisać co to takiego ;). Dzięki wiedzy o specyficznym słownictwie branży klienta - bez względu czy to ubrania czy fizyka kwantowa, można dużo dokładniej szacować złożoność zadań.

Komunikacja z klientem

Bez stałej komunikacji z zamawiającym nie ma możliwości podejścia do estymatów. I to na poziomie wyceny wstępnej jak i szczegółowej. Prawie każdy (nawet najprostszy), opis zadania może zostać zrozumiany na n-sposobów (tak jak przykład z logowaniem).

Czas szacowania

Problemem może być też dostępny czas i inne zasoby które możemy poświęcić na szacowanie. Im więcej czasu i im więcej szczegółowych opisów tym zapewne nasza wycena będzie bliższa faktycznemu czasowi. Jednak to może zadziałać tylko wtedy kiedy po drodze nic się nie zmieni w trakcie realizacji projektu - co jak pokazuje życie jest raczej niemożliwe.

Rodzaje projektów

W tym momencie chciałbym wyraźnie zaakcentować różnice między trzema głównymi rodzajami projektów które można spotkać w webie.:

  • "WordPress": Jest to mały, w miarę prosty i powtarzalny serwis. Może być to np. strona firmowa/landingpage z trzema zakładkami. Estymacja ogranicza się do wybrania wtyczek i implementacji otrzymanego layoutu.
  • Sklep/CRM: Jest to już bardziej złożony projekt, ma jednak ograniczone menu możliwości. Składamy go z dostępnych modułów i dodatków. Większość pracy to zabawa w konfigurowanie.
  • StartUp: Złożony lub bardzo złożony projekt. Tak jak w startupie, cały czas tworzymy nowe funkcje nowego produktu poruszając się w warunkach skrajnej niepewności. Estymacja na początku współpracy będzie skrajnie niepewna. Jednak, wypadało by podać jakieś widełki.. :).

Tylko jak się za to zabrać?

Trzy modele estymowania

O ile dość łatwo wycenić złożoność czasową w projektach klasy WordPress i Sklep/CRM bo jest to głównie funkcja doświadczenia i wyboru odpowiednich klocków przez konsultanta, to w przypadku StartUp'u sprawa może być znacznie bardziej skomplikowana.

Pierwszym i chyba najszybszym jest metoda zwana u nas roboczo “z biodra”, jest to zazwyczaj coś w rodzaju: “2-3 miesiące 2-3 ludzi” i o dziwo, kilka razy się to nam sprawdziło (zapewne dzięki dużemu rozstrzałowi). Dzięki tej metodzie jesteśmy w stanie bardzo szybko ocenić czy robimy prostą apkę na facebooka czy mamy do czynienia z drugim google. Niestety nie nadaje się do zapisania w umowie.

Drugą, kosztowniejszą metodą jest “estymowanie z zapasem”. W naszym przypadku jest to dość dokładne przegadanie poszczególnych funkcji przez dwóch doświadczonych developerów a następnie przemnożenie wszystkiego przez współczynnik rozjazdu oraz dodanie czasu który przewidujemy na spotkania zespołu. Jest on dość zasobożerny i przy pozostawieniu sobie furtki do aneksowania umowy może zostać zapisany w projekcie.

Ostatnim jest “szacowanie na bieżąco” stosowany np. w Scrum'ie. Polega on z grubsza na wycenianiu bardzo małych zadań ale tylko na najbliższy okres pracy. Dzięki temu możemy poświęcić tylko tyle czasu ile jest konieczne do przygotowania się do następnego cyklu przy okazji wyjaśniając z klientem wszystkie niejasności. Jest on moim zdaniem najlepszy do projektów klasy “StartUp” gdyż dba o efektywne wykorzystanie czasu jaki jest nam dany. Planowanie trwa krócej gdyż nie zajmujemy się sprawami które i tak ulegną zmianie. Oszczędzamy też klientowi wyceny mnożone przez różne współczynniki rozjazdu.

Wracając do przykładu przejazdu rowerowego, mieliśmy dość łatwo gdyż nikt do mnie nie przyszedł i powiedział: “Adam, ta trasa jest do przejechania w 3 dni”.

“No super, ale ile to będzie kosztować?”

Dość często słyszę pytanie od founderów startupów: “A ile czasu potrzebujecie żeby zbudować nam ten serwis?” lub “Ta aplikacja powinna być gotowa za 3 miesiące, zdążycie?”. Niestety, nie ma na to prostej odpowiedzi. Zależy to od 1.000 czynników o których wiemy i o których dowiemy się dopiero w trakcie współpracy. Jeśli miałbym udzielić jakiejś rady, to polecałbym rozpoczęcie współpracy w modelu time&material (z zastrzeżeniem możliwości szybkiego rozwiązania umowy) i wspólne przeżycie kilku iteracji produktu. Po 2-3 sprintach obydwie strony powinny mieć jakieś wyczucie do ro tempa rozwoju i możliwego zakończenia prac nad MVP.

Możliwe reakcje

Jednym ze skuteczniejszych sposobów jest zaproponowanie modelu mieszanego, czyli “z zapasem” wplecionego w “zwinny”. Polega to mniej więcej na wycenianiu “fix” funkcji których implementacja wyniesie łącznie nie więcej niż jeden cykl przez kilka cykli. A następnie zaproponowanie przejścia na klasyczny sposób rozliczania na bieżąco, który pozwoli obydwóm stronom zaoszczędzić nadmiarowych sesji planowania i narzutu wynikającego z współczynnika rozjazdu.

Dlaczego jest to dobre dla klienta?

Traktujemy klientów nie jak przeciwników w negocjacjach, nie stajemy po dwóch stronach barykady tak jak w przypadku ceny fix (kiedy software house chce zrobić jak najmniej aby zarobić jak najwięcej a klientowi marzy się dodawanie nowych funkcji w nieskończoność), ale jako współuczestników procesu, towarzyszy wspólnej podróży. Dzięki rozliczeniu godzinowym możliwe jest ciągłe aktualizowanie backlogu przyszłych funkcji. Bez problemu możemy je dodawać i odejmować tak jak podpowiada nam rynek.

Bez pełnej transparencji ze strony agencji/software house ten model nie ma szans powodzenia. Potencjalnie stwarza on miejsce do prostych nadużyć takich jak puste przebiegi godzinowe. Z naszej perspektywy, problem ten występuje częściej w relacjach z klientami rodzimymi niż zagranicznymi. Wynikać to może z jednej strony że tam jest to raczej standardem (lub tylko tacy szukają zdalnych zespołów) lub po prostu my tu w PL mamy niższe koszta życia i oni ryzykują mniejsze kwoty.

Zasady współpracy

  • Określić dostępny miesięczny budżet czasu na development
  • Ułożyć listę funkcji projektu wg priorytetów, aktualizować ją na bieżąco
  • Dbać o komunikację w zespole, synchronizować pracę poszczególnych osób
  • Określić przybliżoną datę oddawania etapów koniecznych do budowy MVP
  • Tak manipulować zakresem w trakcie realizacji projektu aby końcowy efekt danego etapu miał konkretną wartość biznesową
  • Starać się wypracować możliwie szczegółowe specyfikacje zadań (ale tylko na najbliższy czas)
  • Pracować w krótkich cyklach, szybko zbierać feedback

Podsumowanie

Nie upieram się że szacowanie czasu jest bez sensu, chcę jednak zaznaczyć, że jest to wyjątkowo trudna sprawa. Można ją zrobić dobrze, ale koniecznym do tego jest wyjątkowo zgrany zespół pracujący nad doskonale znaną mu dziedziną z dużym doświadczeniem w wykorzystywanych technologiach. Niestety nawet wtedy mogą zdarzyć się niespodziewane awarie, choroby lub urlopy które wpłyną na czas całości projektu.


Dodaj komentarz!

Czytaj dalej: