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:
Zakładamy jedynie pozytywne scenariusze
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
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.
Jesteśmy przekonani o własnej wyjątkowości
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?
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.
Za bardzo wierzymy, że więcej zasobów rozwiąże problem
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
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.
Zbyt przywiązujemy się do jednostki rozliczeniowej
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
Powodów „rozjazdu” między planem w wykonaniem może być jeszcze wiele, my jednak przejdźmy do konkretów.
Jak liczyć, żeby policzyć?
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:
- Metoda koszulkowa – do oszacowania stosuje się rozmiar koszulek: S, M, L, XL, XXL.
- Metoda Sturbuck’s – do oszacowania stosuje się rozmiar kaw w tej popularnej kawiarni: tall, grande, venti, trenta – wiem, że hipsterskie, ale piszę, jak jest.
- Metoda ZOO – do oszacowania stosuje się rozmiar zwierząt – od mrówki do słonia.
- Metoda Story Points – o której więcej za chwilę.
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.
Story Points
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:
- znak ∞ mówi o tym, że zadania nie da się ukończyć;
- znak ½ mówi, że zdanie jest błahe i proste;
- znak ? mówi, że nie da się ustalić wartości;
- dodatkowy znak możne też oznaczać np. prośbę o przerwę.
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:
- Zespół projektowy opracowuje tzw. user stories, a więc w maksymalnie naturalny sposób próbuje opisać co użytkownik będzie robił z owocami projektu, ergo: co powinien dostać, aby móc to robić. Jeśli tworzysz kurs typu MOOC, to wiesz, że nie składa się on jedynie z kilku czy kilkunastu lekcji multimedialnych. Patrząc na to z punktu widzenia produkcji nie dostrzeżesz punktu widzenia użytkownika. User story powinno być zawsze i bezwzględnie ustalone i potwierdzone z klientem. Jeden projekt może mieć dziesiątki różnych „historyjek”. Dla każdej estymacja musi się odbyć niezależnie.
- Zaczyna się estymacja. Każdy z członków zespołu wybiera własną wartość za pomocą karty z talii, ale nie pokazuje jej innym.
- Członkowie pokazują swój wybór odsłaniając karty.
- Jeśli wszyscy są zgodni, to mamy estymację gotową, ale to się rzadko zdarza.
- Jeśli nie – dyskutujemy na temat różnic: skąd się wzięły? Osoby o skrajnych estymatach powinny się wypowiedzieć w szczególności, bo może widzą w zagadnieniu coś, co umknęło innym.
- Następuje kolejna estymacja (pkt. 2) i tak do momentu, aż wszyscy się zgodzą.
- Jeśli to nie następuje można, a nawet należy, podzielić zagadnienie na mniejsze. Również w przypadku zbyt dużych wartości, nawet jeśli wszyscy się zgodzą. Może się okazać, że coś jest zbyt trudne, aby ugryźć to „na raz”. Dlatego jest karta ze znakiem nieskończoności – jeśli czujemy, że tak naprawdę nie jesteśmy w stanie rzetelnie oszacować wyniku.
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:
- Complexity – jak bardzo złożone jest zagadnienie.
- Effort – jak duży wysiłek jest potrzebny do jego realizacji.
- Doubt – jakie są niewiadome.
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.
Czas na czas
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:
m – wariant najbardziej prawdopodobny.
p – wariant pesymistyczny – maksimum czasu potrzebnego na realizację
te – to oczywiście nasz wynik.
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ą.
