Estymowanie zadań wciąż dla wielu PMów jest czymś trudnym do zrozumienia. Często estymaty są utożsamiane z czasem, jaki zostanie poświęcony na dane zadanie i często próbuje się dociekać dlaczego coś zajęło 3h, a nie 1h jak wcześniej zespół wyestymował. Niestety, błąd pojawia się już na samym początku tego rozumowania. Estymujemy ilość pracy, a nie czas jaki zajmie jej wykonanie. To jest fundamentalna różnica, trudna do zrozumienia w świecie ManDayów i DevDayów oraz traktowania deweloperów jak zasoby. Deweloper deweloperowi nie jest równy. Dwóch Seniorów też zwykle nie. Przewidywalność w projekcie jest zagadnieniem wielowymiarowym. Aby te zagadnienia zwizualizować posłużę się pewną historią.

Gdzieś w świecie żył sobie człowiek imieniem Robert. Stwierdził, że otworzy firmę która zajmować się będzie pracami ziemnymi, a w szczególności przemieszczaniem hałd piasku. Zebrał czterech kolegów, którzy akurat szukali pracy i poszli na pierwsze zlecenie. Na samym początku pojawiał się problem – ile to może kosztować, na ile powinni się cenić? Początkowo chcieli liczyć na godziny. Stefan, pasjonat ćwiczeń na siłowni i najlepiej zbudowany w całej ekipie powiedział, że sam da radę przenieść tonę w 2 godziny. A cała hałda to około 5 ton, więc jak jest ich w sumie pięciu, to akurat 2 godziny powinny wystarczyć. Niestety, nikt poza nim nie był zbudowany jak Arnold Schwarzenegger albo Mariusz Pudzianowski. Pozostali członkowie zespołu zaprotestowali, że nie dadzą rady przesypać tego w takim tempie. Stwierdzili po długich naradach, że lepiej będzie liczyć sobie robociznę od tony piachu, bo w godzinę pracy ilość przeniesionego piasku przez poszczególnych pracowników była bardzo różna. Na początek ustalili, żę będą brać 200 PLN od tony. Klient jednak chciał mieć cenę ostateczną, dlatego skoro oszacowali ilość piasku na 5 ton, to umówili się z nim na 1000 PLN. Odległość na jaką mieli przenieść piach początkowo nie wydała im się duża, więc postanowili nosić piach w wiadrach. Napracowali się, zadanie wypełnili, ale ostatecznie byli bardzo zmęczeni. Po skończonej robocie poszli razem coś zjeść, uzupełnić płyny i zastanowić się co dalej. Podumali więc co nieco i doszli do wniosku, że warto byłoby policzyć ile naprawdę tych wiaderek piachu przerzucili. Na ile dobrze oszacowali ilość pracy i czy mogli zaproponować wyższą cenę ostateczną. Druga myśl jaka im się pojawiła to sprawdzenie, czy można by przenosić piach szybciej. Postanowili spróbować z taczkami. Zainwestowali w sprzęt i ruszyli do kolejnego zlecenia.

Przy drugim zleceniu szło im już znacznie lepiej, ale piasku było znacznie więcej. Wstępnie oszacowali ilość piachu na 25 ton, więc liczyli na okrągłą sumkę po paru dniach pracy. Liczyli też taczki, żeby sprawdzać ile faktycznie tego piasku udało się przewieźć i móc prognozować, kiedy skończą zlecenie. Pod koniec pierwszego dnia doszli do wniosku, że coś jest nie tak. Wizualnie oceniając hałdę wyszło im, że jest większa od tej z poprzedniego zlecenia około pięciokrotnie. Ale pod koniec dnia, udało im się przewieźć 5 ton (licząc po liczbie taczek) a hałda nie zmalała o 20%, tylko o znacznie mniej. Zaczęli się zastanawiać gdzie leży problem. Po chwili przyszło olśnienie. Piasek był przywieziony świeżo z kopalni. Był jeszcze bardzo mokry. Piasek z ostatniego zlecenia leżał tam już od kilku tygodni, a lato było w pełni. Słońce pozwoliło mu dobrze przeschnąć. Gdy kończyli to zlecenie, dostali wiadomość, że jest kolejny chętny na ich usługi.

Trzecie już zlecenie wyglądało podobnie do pierwszego. Piachu było tylko około 2 razy więcej i był raczej suchy. Nauczeni ostatnimi doświadczeniami sprawdzili, czy piasek jest mokry pod górną warstwą. Okazało się, że nie, dlatego ochoczo zabrali się za pracę. Początkowo praca postępowała zgodnie z planem. Podzielili się na ładowaczy i tragarzy, żeby optymalnie wykorzystać posiadane taczki i łopaty, ale po paru godzinach pojawił się problem. W niższych warstwach zaczął pojawiać się żwir, stopniowo coraz grubszy aż do całkiem sporych kamyków. Łopaty coraz gorzej się sprawdzały. Wg umowy hałda miałą zniknąć, niezależnie od tego co się znajduje na jej dnie. Skończyli wcześniej, bo łopatami nie byli zbyt wiele zdziałać, a szef ekipy pojechał do sklepu budowlanego po kilofy. Następnego dnia ekipa mogła ruszyć do pracy z nowym sprzętem i zaczęli nadrabiać zaległości. Ostatecznie ekipie udało się tylko niezbyt znacznie przekroczyć prognozowany termin ukończenia. Stało się jednak jasne, że nie brali do tej pory pod uwagę ryzyka, że coś pójdzie nie tak. Postanowili, że przed następnym zleceniem zrobią próbny wykop i dopiero wtedy podadzą cenę za tonę. Ucieszyli się też, że taka „niespodzianka” pojawiła się przy małym zleceniu, a nie takim jak np. zlecenie nr 2.

Tutaj możemy zakończyć tę historyjkę i przejść do rzeczy…

Jakie wnioski można wysnuć na podstawie tej tendencyjnej opowiastki?

  1. Szacowanie jest trudne, zamiast wróżyć z fusów lepiej opierać się na dotychczasowych doświadczeń. W software dewelopmencie znany jest problem: jak przeliczać godziny senior developera na junior developera? Najlepsza odpowiedź wg mnie? Nie przeliczać. Prędkość jest cechą całego zespołu, nie pojedynczych jego członków.
  2. Metryki – Po pierwszej robocie nasi bohaterowie postanowili zacząć stosować miary dla swojej pracy. Jeśli nie możesz czegoś zmierzyć, to jak sprawdzisz czy jest lepiej?
  3. Warto eksperymentować i szukać usprawnień. Nasi bohaterowie nie daliby rady zrealizować ostatniego zlecenia używając tylko łopat. Pracowali nad swoim warsztatem, stosowali innowacje, mimo że czasem oznaczało to, że jeden z pracowników nie będzie pracował tylko pojechał po kilofy (szukał innowacji). Innowacje długofalowo są opłacalne. Warto jednak pamiętać o ryzyku i eksperymentować na wczesnych etapach projektu.
  4. Nie wszystko da się przewidzieć. Mokry piach był do przewidzenia, ale gruby żwir – już mniej. Odpowiednie narzędzia (kilofy) pozwalają szybciej rozwiązywać napotkane problemy. Trzeba jednak zmotywowanego teamu, przestrzeni na innowacje i uczenia się na małych potknięciach.
  5. Estymata jest z definicji nieprecyzyjna. Dlatego należy obserwować rzeczywiste wyniki i na ich podstawie planować przyszłość. Estymaty zespołu są niedoszacowane o 100%, 200% a może 1000%? Tutaj warto zadać sobie pytanie, czy deweloperzy mieli szansę zapoznać się z tematem? Poszukać podobieństw do wcześniejszych prac (historie referencyjne)? Zrobić próbny wykop jak w historii powyżej (spike). Znane z XP spike’i nie powinny być tylko powierzchniowe, sprawdzające czy piach jest suchy, ale dość głębokie, by sprawdzić czy na dnie nie znajdą kamieni.

Nawigacja