Estymacja czasu realizacji zadań (w zasadzie każdego typu i w każdej branży) to pięta achillesowa zarządzania zespołami i projektami. Opera w Syndey (ta znana głównie z wyglądu) została zaplanowana na 4 lata budowy przy budżecie 7 milionów dolarów australijskich. Skończyło się na 14 latach i 102 milionach. Także nie mówcie, że akurat wam planowanie czasu wychodzi dobrze. Nikomu nie wychodzi. A kończy się zazwyczaj dużymi stratami i utyskiwaniem, że teraz to już robimy projekt nie po to, żeby zarobić, ale jak najmniej stracić.
Główny problem bierze się z tego, że w projektach opartych o tworzenie multimediów zazwyczaj główną jednostką szacunkową jest czas, jaki zespół projektowy musi spędzić nad realizacją zadania. Często znaczenie ma też zakup dodatkowych usług, koszty technologiczne, koszty licencji czy amortyzacji sprzętu, ale – generalnie – liczy się mityczna i nieuchwytna roboczogodzina. Sęk w tym, że człowiek niezbyt dobrze radzi sobie z estymacją czasu. Jest kilka powodów:
Często pomijamy w planowaniu to, że coś może pójść nie tak. Nie ma znaczenia to, że dajemy sobie pewien bufor bezpieczeństwa, bo zawsze musimy pamiętać o tzw. Prawie Hofstadter’a:
It always takes longer than you expect, even when you take into account Hofstadter’s Law
Douglas Hofstadter's: <em>An Eternal Golden Braid</em> (1979)
Powiązany z tym jest problem myślenia życzeniowego, który każde nam być optymistami. Jest to pomocne, ale jednocześnie niebezpieczne, szczególnie jeśli chodzi o planowanie czasu. Na tę przypadłość często cierpią ludzie, którzy ciągle się spóźniają, choć wcale tego nie chcą i naprawdę starają się coś z tym zrobić. Możesz przestawić budzik, ale nie przestawisz mózgu. Rozwiązaniem są długa praca nad swoimi przyzwyczajeniami, albo lobotomia – obie metody niebezpieczne.
Badania pokazują, że większość osób uważa się, że ponadprzeciętnych w dziedzinie, którą się zajmują. To pozwala nam lepiej funkcjonować, bo wierzymy, że jesteśmy w czymś lepsi, niż reszta świata wyrażona jako średnia statystyczna populacji. Wyrazisty przykład dał amerykański komik, George Carlin:
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?
George Carlin
No właśnie, badania pokazują , że aż 90% kierowców uważa się za lepszych, niż średnia statystyczna, choć z matematycznego punktu widzenia jest to bzdura. Z psychologicznego – wszystko się zgadza.
W tym zakresie dziwactw nie ma na świecie nikogo lepszego, niż Fred Brooks, który w lata 60. prowadził najbardziej złożony projekt w historii IBM. Powiedział kiedyś:
Nine women can’t make a baby in one month
Fred Brooks
Prawo Brooksa mówi, że im więcej osób dołącza do projektu w jego dojrzałej fazie, tym później będzie on ukończony. Jest w tym pewna sprzeczność z naszym próbami estymacji. Powinno być szybciej, dużą ilość roboczogodzin rozłożymy na więcej osób. W praktyce tak nie ma. No i właśnie – dziewięć kobiet nie urodzi dziecka w jeden miesiąc.
No i wraca temat roboczogodzin. Jednostki szacowania czasu pracy są dosyć oderwane od rzeczywistości. Po pierwsze: na czas może wpłynąć wiele zmiennych. Na każdą decyzję składają się takie elementy jak złożoność problemu, potrzebny wysiłek oraz niewiadome – do czego wrócę jeszcze w części narzędziowej tego poradnika.
Unexpected always pushes in a single direction: higher costs and a longer time to completion
Nassim Nicholas Taleb
Powodów „rozjazdu” między planem w wykonaniem może być jeszcze wiele, my jednak przejdźmy do konkretów.
Pierwsza sprawa, to problem z tymi jednostkami czasu. Jesteśmy do nich za bardzo przywiązani i wiedzą to doskonale liderzy projektów programistycznych. W metodykach takich jako SCRUM celowo unika się szacowania za pomocą godzin, aby zespół był w stanie pomyśleć poza ramami kalendarza. Programiści do estymacji czasu wybierają różne metody:
Rozumiecie, o co chodzi? Bardziej skomplikowane zadanie będzie koszulką w rozmiarze XL, a mniej złożone – M. Jeśli nie ma jednostek czasu, to nie ma też problemu jego błędnego oszacowania. Może się wydawać, że to zamiatanie problemu pod dywan, bo przecież nie rozliczymy się z klientem w koszulkogodzinach i prędzej czy później wrócimy do jednostek czasu, ale na tym etapie, gdzie wiele zmiennych zaburza możliwość estymacji, planowanie czasu jest po prostu mało trafne.
Musicie bowiem uświadomić sobie jedną, najistotniejszą rzecz w całym tym wywodzie: problem z estymacją czasu nie bierze sie z tego, że nie potraficie liczyć, albo nie rozumiecie jak działa zegar. Bierze się z tego, że nie macie żadnych dobrych wskaźników, z wyjątkiem własnego doświadczenia, aby rzetelnie estymować. Doświadczenie zaś nie wystarcza, bo świat współczesnych projektów jest bardzo zmienny.
Przykładowa talia kart z ciągiem Fibonacciego.
Metoda ta opiera się o ciąg liczb następujących po sobie. Odpowiednio: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55 itd., jeśli jest potrzeba. Interesujący się matematyką odkryli w tym zapewne ciąg Fibonacciego, gdzie każda kolejna liczba jest sumą dwóch poprzednich. I właśnie na tej metodzie dziś się skupimy.
Taki ciąg jest lepszy od zwykłego ciągu liczb całkowitych, bowiem pozwala skupić się na zadaniu, a nie na szczegółach, których studiowanie może zaburzyć całość oceny. Nie dyskutujemy nad tym, czy zadanie zajmie nam 4 czy 5 godzin, a w związku z tym czy wyrobimy się do południa, jeśli zaczniemy rano, ale czy ma wartość 5 czy 8 i jak to się ma do innych zadań. Czasem do ciągu dodaje się dodatkowe symbole:
Wszystkie znaki są o tyle ważne, że estymacji dokonuje się w grupach, często korzystając ze specjalnych talii kart do gry z ciągiem, stąd często tę metodę nazywa się po prostu planning poker. Największą zaletą tej metody jest to, że zamiast określać ile czasu zajmie dane zadanie, określamy jako ma się ono do innych zadań w projekcie i dlaczego. To zaś pozwala przede wszystkim otwierać się na nieprzewidziane wcześniej aspekty i lepiej planować.
W praktyce może się to odbywać tak:
W projektach multimedialnych często nie ma user stories takich, jak w tworzeniu aplikacji, więc trzeba sobie projekt podzielić trochę inaczej – ważne, aby były to jakieś logiczne i łatwe do zrozumienia etapy czy części.
Przykładowo: gdy tworzę dla klienta nowe webinarium to jednym z zdań może być wykonanie animowanej czołówki. Animator zazwyczaj będzie miał tendencję do niedoszacowania, bo robi takie rzeczy często i wydaje mu się, że – jak zazwyczaj – będzie to „krótka piłka”. Innego zdania będzie kierownik produkcji, który wie jak trudno jest wyciągnąć od klientów konkrety. Będzie więc się bał, że utknie w niekończącym się festiwalu poprawek.
Widzicie teraz, jak to działa?
Warto też zbadać sobie, co się składa na różnice w planowaniu. Są to zasadniczo trzy elementy, o których już wspominałem:
Dyskusja o każdym zagadnieniu właśnie przez ten pryzmat pozwala odkryć wiele nieścisłości i wykonać świadomą estymację. Tyle, że wymaga też poważniejszego pochylenia się nad tematem. Ja z doświadczenia wiem, że to bardzo się opłaca i wcale nie musi być czasochłonne. Listę niewiadomych i tak zawszę robię, bo jest to dla mnie podstawa do dyskusji z klientem. Niejednokrotnie też zdarzało mi się, że dzięki niej uświadamiałem klientowi, czego nie wie i nie przewidział. Dzięki temu potencjalne pożary gasiliśmy w zarodku, a do tego klienci zazwyczaj czują się bezpiecznie z kimś, kto myśli, a nie tylko bezrefleksyjnie przyjmuje kolejne zlecenia.
Mamy nasz projekt w podziale na punkty. To super, ale przecież i tak musimy jakoś oszacować to w czasie. No więc jak przełożyć punkty na czas? Już same punkty bardzo pomogły nam zrozumieć zależności między elementami projektu i wykryć zupełnie nowe ryzyka. Może czytając ten artykuł niełatwo to zauważyć, ale różnica między tym, co osiągnęliśmy dotychczas, a tym co byśmy osiągnęli od razu estymując czas są naprawdę spore. Trzeba też oddać sprawiedliwość tym, którzy zajmują się metodykami agile zawodowo i pewnie teraz przeżywają koszmar czytając, jak swobodnie podchodzę do tematu. Nie jest bowiem wcale powiedziane, że punkty powinny się przełożyć na czas, a już na pewno niekoniecznie metodą, którą zastosuję za chwilę. Potraktujcie więc tę część trochę swobodnie, niezależnie od pierwszej. Nic bowiem nie stoi na przeszkodzie, aby planowanie czasu zacząć od tego momentu, jeśli projekt jest na tyle prosty, że zabawy w story points nie miałyby sensu.
Jedną z metod przełożenia tego, co zebraliśmy w formie abstrakcyjnych punktów na czas jest tzw. PERT. Wzór pozwala oszacować ryzyko między optymistycznym a pesymistycznym wariantem czasowym. Wygląda on następująco:
Przykładowo: dochodzimy do wniosku, że na nagranie godzinnego wykładu potrzebne nam są 2 godziny w studio (biorąc pod uwagę przygotowanie czy powtórki) – to optymalny czas, wynikający z moich doświadczeń. Wiemy też, że są klienci bardzo zwinni, którzy wykorzystają jedynie godzinę. Niemniej jednak często zdarza się też, że takie nagranie ciągnie się przez 5 godzin. Podkładając te wartości pod wzór PERT otrzymujemy:
Innymi słowy – rozsądnie będzie zarezerwować o najmniej 2 i pół godziny, i tak też wycenić zlecenie.
Wartości, które wybrałem do powyższego przykładu mogą pochodzić z moich dotychczasowych doświadczeń z klientem, podstawowej analizy Complexity + Effort + Doubt lub rzetelnie przeprowadzonego planowania opartego o story points. Niemniej jednak na coś trzeba się zdecydować, jakieś liczby do wzoru podstawić, więc lepiej mieć na to metodę, niż dywagować. Zauważcie, że gdybyśmy podeszli do sprawy standardowo, to od razu w naszym projekcie i budżecie założylibyśmy wartość m i pomnożyli ją przez wartość roboczogodziny. Estymacja z prawdziwego zdarzenia pozwoliła nam na lepsze zrozumienie m, a także na zastanowienie się czy nie za bardzo przesuwamy się w stronę o lub p.
Tyle na dziś i życzę owocnego estymowania i żeby wasze projekty zawsze zgadzały się z realizacją.