Szacowanie pracochłonności – część pierwsza

Prowadząc warsztaty lub doradzając zespołom wytwarzającym oprogramowanie często spotykam się z błędnymi przekonaniami na temat szacowania pracochłonności.

Na początku chciałbym tutaj rozdzielić dwie, jakże różne, sytuacje:

1. Szacowanie pracochłonności całego projektu przed jego rozpoczęciem, najczęściej w celu oszacowania budżetu i czasu potrzebnego na jego realizację (go – no-go, kwestie formalne, kontrakty, przetargi, itp.).
2. Szacowanie pracochłonności bieżącej pracy na potrzeby zaplanowania pracy na kolejne sprinty / tygodnie.

Temat pierwszy zasługuje na oddzielny wpis, natomiast dzisiaj chciałbym się przyjrzeć sytuacji numer dwa.

Pułapki szacowania w czasie

Niestety, szacując pracochłonność „w czasie” jesteśmy wystawieni na wiele pułapek. Jeśli sytuacja projektowa wymaga od nas takiego szacowania, dobrze mieć świadomość z jakimi ryzykami się to wiąże i w jakie pułapki możemy wpaść.

Pułapka 1: „czy mi się to opłaca”

Wyobraźmy sobie sytuację, w której mam oszacować pracochłonność konkretnego zadania – zadania X. Załóżmy, że oszacowałem, że realizacja zadania X zajmie mi 4 dni. Zadanie zrealizowałem w przeciągu dwóch dni. I teraz dylemat – czy opłaca mi się zgłosić, że zrealizowałem zadanie szybciej?

Jak zwykle to zależy, ale weźmy pod uwagę następujące niuanse:
Jeśli tym razem zrobiłem szybciej, to następnym razem, gdy oszacuje pracochłonność na 4 dni – druga osoba może założyć, że zrealizuje zadanie szybciej. Skoro już wcześniej moje szacunki były wyższe od faktycznego czasu realizacji, całkiem prawdopodobne, że sytuacja może się powtórzyć. Najgorsze, gdy ktoś po drugiej stronie nie tylko założy, że mam tendencję do „przeszacowywania”, ale na dodatek będzie oczekiwał, że zamiast 4 dni, spędzę na realizacji tylko 2 lub 3 dni.

W teorii zatem, nie mam żadnego zysku w tym, żeby wyjść przed szereg i pochwalić się, że zrealizowałem zadanie szybciej, gdyż mogę przeczuwać, że w przyszłości tego typu sytuacja może (choć nie musi) obrócić się na moją niekorzyść. Dużo tutaj zależy od dojrzałości poszczególnych osób w zespole i relacji, jakie sobie wypracowaliśmy.

Pułapka 2: syndrom studenta

Znany syndrom odkładania wszystkiego na ostatni moment. Teoretycznie mam odpowiednią ilość czasu na realizację zadania, tak aby wykonać je w odpowiedniej jakości. Mając jednak świadomość tego, że na jego realizację mam określoną ilość czasu, istnieje szansa, że zabiorę się za nie „na porządnie” dopiero tuż przed „deadlinem”. Syndrom studenta bardzo łatwo zaobserwować w zespołach pracujących w dłuższych sprintach (3-4 tygodnie), gdzie tzw. poczucie pilności (ang. „sense of urgency”) umyka w środku sprintu.

Pułapka 3: prawo Parkinsona

W 1955 roku w brytyjskim tygodniu „The Economist” Cyril Northcote Parkinson przedstawił następujące prawo:

„Praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie”

Im więcej czasu zaplanujesz na realizację danego zadania, tym więcej czasu na niego poświęcisz.

Pułapka 4: pułapka oceniania

Gdy pracochłonność jest wyceniania w czasie, bardzo łatwo porównać realizację z oszacowaniem. Co za tym idzie, bardzo łatwo jest ocenić: „za wolno”, „zgodnie z planem”, itd. (ocena zero-jeden). Im dalej jesteśmy od zespołu i nie widzimy z jakimi wyzwaniami na co dzień mierzy się zespół – tym łatwiej nam o tego typu oceny, zwłaszcza, gdy występuje niedoszacowanie pracochłonności. „Za wolno”, „to już dawno powinno być zrealizowane”, itp. W obliczu braku pełnej informacji łatwiej nam złapać coś namacalnego, czyli coś co można zmierzyć i na tej podstawie dopowiedzieć sobie dalszą część historii.

Pułapka 5: szacujący vs. realizujący

Zdarza się tak, że opieramy się na szacunkach osoby A, podczas gdy faktycznie zadanie jest realizowane przez osobę B. Biorąc pod uwagę różnice w wiedzy, doświadczeniu, znajomości projektu lub znajomości danego fragmentu projektu – bardzo łatwo o sytuację, gdy osoba B poświęci znacznie więcej czasu, niż gdyby dane zadanie było realizowane przez osobę A.

Pułapka 6: jak oszacować pracę kreatywną

Wytwarzanie programowania to, jakby nie patrzeć, praca kreatywna. I nawet przez jedną osobę to samo zadanie może być zrealizowane w przeciągu kilku godzin jak i kilku dni. Czasem jest tak, że jak się człowiek zatnie na czymś, siedzi cały dzień i ciągle coś nie działa. Po czym, gdy wstajemy rano, bierzemy prysznic i nagle przychodzi nam do głowy gotowe rozwiązanie. Siadamy do komputera, 10 minut i zrealizowane. I jak tu wiarygodnie oszacować realizację danego zadania co do minuty?

Pułapka 7: presja czasu

Biorąc pod uwagę fakt, że praca programisty to praca kreatywna, w sytuacji, gdy gonimy przekroczone terminy lub dbamy o to, żeby zespół był przeładowany, sami narażamy się na to, że praca programistyczna nie zostanie wykonana efektywnie. Niestety tak to już jest, że wysoki poziom stresu nie idzie w parze z pracą kreatywną (będzie o tym osobny wpis). Do tego dochodzą sytuacje rozpraszające uwagę, tj. zbyt duża ilość spotkań lub niepotrzebne spotkania, open-space’y czyli kwestia braku możliwości skupienia się wystarczająco. I znowu, biorąc pod uwagę powyższe: jak tu wiarygodnie oszacować realizację danego zadania co do minuty? (A pułapka nr 4 wisi w powietrzu)

Pułapka 8: diabeł tkwi w szczegółach

Programista siada do realizacji zadania, wydawało się, że wszystko zostało omówione, realizuje „happy flow” i kolejne sytuacje brzegowe i nagle wewnętrzny głos w głowie zaczyna zadawać pytania: czy to ma być zrealizowane tak, czy tak? A może jeszcze inaczej? Ale w sumie to nie było dokładnie opisane, to zrobię to tak. A potem się okazuje, że trzeba przerabiać albo praca została wykonana niepotrzebnie.
Inną kwestią jest to, że czasem Product Owner czy klient, dopiero gdy zobaczy finalny efekt, jest w stanie dać realny feedback co do szczegółów wykończenia danego zadania. Czasem po prostu tak jest, że zobaczenie namacalnych efektów uświadamia nam detale, o których nie pomyśleliśmy wcześniej. A każdy taki detal to dodatkowy czas potrzebny na jego realizację – czasem to będzie 15 minut, czasem kilka godzin, ale zawsze to będzie coś dodatkowego do zrobienia.

Pułapka 9: błędy

Typowa sytuacja w projekcie software’owym: realizujemy funkcjonalność i prędzej czy później pojawiają się błędy – czasem bardzo szybko w efekcie wykonanych testów, czasem po kilku tygodniach, a nawet miesiącach, gdy dana funkcjonalność jest używana przez użytkowników. I teraz czas potrzebny na poprawienie błędu zakwalifikować do czasu realizacji danej funkcjonalności czy jakoś inaczej? Bardzo łatwo tutaj o zbędną biurokrację.
Co więcej, poprawiając błędy, narażamy się na dodatkowe ryzyko, jakim jest czynnik ludzki. Każda zmiana w kodzie, niezależnie czy to nowa funkcjonalność, czy poprawka istniejącego kodu, naraża nas na błędy regresji, na które znowu trzeba będzie poświęcić dodatkowy czas. I znowu: jak ten czas potem przyporządkować? I jak to się ma wszystko do początkowych estymacji?

Pułapka 10: deadline’y

Jeśli jestem pod presją czasu, na przykład mam coś do dostarczenia na jutro do godziny 12:00 i dodatkowo pod żadnym pozorem nie mogę tego terminu przekroczyć – prawdopodobnie dostarczę to „jakoś”. W sytuacji, gdy pojawia się presja czasu, pierwsze co jest „poświęcane” to jakość. Dodatkowo wszystkie sytuacje typu: „znane błędy, zanim klient je zauważy to mamy jeszcze trochę czasu”, powodują, że nie do końca miarodajny jest pomiar: realizacja vs. szacowanie. Straty na jakości to proszenie się o problemy w przyszłości: dłuższa realizacja, więcej błędów – czyli wszystko to, czego chcielibyśmy uniknąć.

Czasem powinno nam zależeć, żeby było wolniej

Kwestia jakości to jedno, czyli pod żadnym pozorem nie chcielibyśmy schodzić poniżej pewnego poziomu (patrz pułapka nr 10). Inna sprawa to kwestia wymienności ról w zespole i dylemat „tu i teraz” czy „patrzymy na zespół i efektywność w dłuższej perspektywie”. Tu i teraz opłaca nam się bardziej, żeby daną rzeczą zajął się „ekspert” w tej dziedzinie. tylko co, jeśli ekspert zachoruje, pójdzie na urlop, czy odejdzie do innej firmy? Wymienność ról w zespole to dość ważny temat, że powinniśmy brać pod uwagę fakt, że coś potrwa dłużej, ale za to wymiana wiedzy i doświadczenia w zespole zaowocuje szybszą realizacją przyszłych funkcjonalności.

Jeśli nie jednostki czasu, to co?

Zastanówmy się po co tak naprawdę nam to szacowanie. Do czego jest nam ono potrzebne i co chcielibyśmy uzyskać:

Z perspektywy biznesu / Product Ownera – ważne są kwestie związane z przewidywalnością tego, co może zostać zrealizowane, bo na tej podstawie można zweryfikować roadmapę lub zaplanować kolejne działania.

Do tego w zupełności wystarczy nam szacowanie względne, np. tzw. story pointy, opisane jakiś czas temu przez Igora Springera w artykule „Plusy i minusy estymacji zadań”
Jest znacznie szybsze, a przy okazji pozbywamy się tych wszystkich pułapek, które towarzyszą nam szacowaniu w czasie.

Czy warto szacować?

Zdecydowanie tak. Kiedy mam oszacować pracochłonność, muszę zastanowić się:
– czy wiem wszystko o tym, co należy zrobić,
– czy pomyślałem o tym, w jaki sposób chciałbym to zrealizować,
– czy pomyślałem o ryzykach i niespodziankach, które mogą wystąpić podczas realizacji.

Traktowałbym proces szacowania jako elementem konwersacji pomiędzy Product Ownerem, a zespołem, aby jak najlepiej zrozumieć wymagania i siebie nawzajem – z jednej strony intencje biznesowe, a z drugiej strony ograniczenia techniczne.

Chcielibyśmy uniknąć sytuacji, gdy programista zapoznaje się z wymaganiami dopiero na spotkaniu planistycznym albo dopiero, gdy siada do ich realizacji. Niestety tak jest, że czasem po otrzymaniu wstępnych wymagań trzeba się z tym przespać i dopiero po kilku dniach przychodzą nam do głowy pytania i wątpliwości, które trzeba zweryfikować.

Przygotowanie estymacji zmusza do przemyślenia tematu na różnych płaszczyznach, dzięki czemu pewne pytania i niejasności zostają zaadresowane odpowiednio wcześniej, gdy Product Owner jest w jednym pomieszczeniu z zespołem i ma dla niego przeznaczony czas.

Jak żyć? (co może się przydać z perspektywy pracy Product Ownera):

• szacowanie względne – w zupełności wystarczające do tego, aby zaplanować prace na najbliższy sprint
• szacowanie już podczas „Backlog refinementów” pod warunkiem, że cały zespół jest obecny na tym spotkaniu, (a nie tylko tech-leader). Pamiętajmy: chodzi tutaj o przekazywanie informacji o wymaganiach, wspólnym wypracowaniu rozwiązania, doprecyzowywaniu, a nie tylko wypracowanie suchej liczby oznaczającej „koszt” – patrz: pułapka nr 8
• bycie blisko zespołu, aby mieć świadomość, z jakimi technicznymi wyzwaniami mierzy się zespół – patrz: pułapka nr 4
• dzielenie wymagań (np. historyjek użytkownika) na jak najmniejsze biznesowe elementy („Hamburger method”, „Elephant Carpaccio”) – patrz pułapka 2 i 3
• skracanie ścieżki informacji zwrotnej, aby jak najszybciej zareagować, gdy coś idzie w nie tym kierunku co trzeba – patrz: pułapka nr 8

W pracy Product Ownera warto mieć świadomość w jakie pułapki możemy wpaść kurczowo porównując estymację vs. realizację oraz to, jak ważny jest sposób w jaki podchodzimy do tego tematu w kontekście zespołu (akcja-reakcja).

O takich niuansach (i nie tylko), będziemy mówili już niedługo na pierwszym w Polsce 5-dniowym bootcampie z zarządzania produktami – Product Management Academy