Dlaczego twój projekt się opóźnia? część 3 – bufor centralny

W poprzednich częściach poruszałem kwestię braku zarządzania buforami czasu w zadaniach, marnowaniem marginesów czasowych oraz złej definicji projektu, która również przyczynia się do opóźnień. Przed przeczytaniem tej części polecam ci rzucić okiem na część pierwszą o buforach bezpieczeństwa w łańcuchu krytycznym oraz część drugą, kontynuacje opisu łańcucha krytycznego.

Bufor centralny

Na początku przedstawię prowizoryczny diagram sieci projektu, by pokazać jak rozkładane są bufory czasowe w standardowym podejściu.

Nasz prowizoryczny diagram składa się z czterech zadań. Każde z zadań składa się faktycznego czasu potrzebnego na wykonanie (biała część) oraz z buforu „bezpieczeństwa” (szara część), który jest dodawany przez developera „by mieć pewność”. Oczywistą oczywistością jest fakt, że buforu oficjalnie nie ma, ale wszyscy wiedzą, że istnieje. W tym przykładzie bufory są optymistycznie krótkie 😉

Z poprzednich serii wiemy, że te bufory są bezproduktywnie wykorzystywane lub marnowane – by temu zaprzestać musimy je połączyć w jeden większy bufor, który będzie dostępny dla wszystkich. Dodatkowo skracamy czas na wykonanie każdego z zadań o ~50% (dlaczego akurat tyle, wyjaśnię poniżej). Zobaczmy, jak wygląda diagram naszego projektu po wprowadzeniu bufora centralnego.

Na osi czasu zaznaczyłem początek oraz koniec projektu (deadline). W tym okresie czasowym naniosłem dwa diagramy: górny (standardowe podejście), dolny (z buforem centralnym). Suma czasu buforów jest dostępna jako bufor centralny (szary kolor) dla wszystkich zadań projektowych (nie usuwałem pionowych linii w buforze centralnym, żebyś mógł zobaczyć, że odpowiadają 1:1 tym z górnego wykresu). Gołym okiem widać sporą oszczędność czasową.

agresywne obcięcie estymat o 50%

W pierwszej części opisywałem skutek „kar” za niewykonanie zadań w terminie – zwiększenie bufora „bezpieczeństwa”. Im większa kara, tym większy bufor. W momencie konfrontacji estymaty developera i oczekiwań PM rozpoczynają się negocjacje. Manager wie, że estymata zawiera bufor, więc chce ją skrócić, developer wie, że PM będzie chciał zredukować czas, więc daje większy bufor. Cała ta procedura, mówiąc programistycznie, jest w pętli while, która kończy się w momencie zaakceptowania czasu przez Manager’a. Takie zdarzenia powodują barierę, bo ludzie zamiast współpracować nad wspólnym celem, zaczynają się licytować i próbować przechytrzyć. Opisałem to pokrótce w drugiej części tej serii o łańcuchu krytycznym.

Poniżej znajduje się wykres krzywej gęstości prawdopodobieństwa Beta ukończenia zadania względem czasu. W punkcie oznaczonym minimum jest oznaczone najbardziej optymistyczne zakończenie zadania. Można powiedzieć, że ukończenie zadania wcześniej jest niemożliwe. Następnie krzywa zwiększa swoją wartość prawdopodobieństwa i osiąga najwyższy poziom po upływie około 50% czasu. Miejsce to jest zaznaczone na wykresie „aggressive, but possible”. Według statystyki jest to najbardziej prawdopodobny czas zakończenia zadania. Dalej krzywa traci wartość, ponieważ w estymacie znajduje się bufor czasowy, który jest zbyt duży i kończymy zadanie przed jego wykorzystaniem. Innymi słowy, nie biorąc pod uwagę marnotrawienia buforu, krzywa gęstości prawdopodobieństwa Beta zakłada, że szanse na przedłużenie zadania maleją. To miejsce jest zaznaczone jako wysoce prawdopodobne, że będziemy mieć wykonany task. Wnioskiem jest to, że bufory czasowe przedłużają nam wykonanie zadania (zgrywa się to z prawem Parkinsona).

Według tego założenia, po zredukowaniu czasu na wykonanie zadania o połowę mamy agresywną estymatę, która jest możliwa do wykonania przy założeniu, że nie będziemy marnować buforu bezpieczeństwa, którego nie będzie w zadaniu ponieważ znajduje się w buforze centralnym.

Czy zawsze należy obciąć o 50%? Oczywiście, że nie. Jednemu developerowi należy obciąć o 75% (bo jest bardzo podatny na prawo Parkinsona i dodawanie bufora), drugiemu trzeba obciąć o 20%, a trzeciemu nie należy obcinać, bo nie jest podatny na prawo Parkinsona i nie dodaje buforów – jego estymaty są faktycznym czasem wykonania. 50% jest dobrym punktem wyjściowym, który można przesuwać w górę lub dół w miarę poznawania możliwości developera.

W tym modelu nie mogą występować „kary” za niewykonanie zadania w agresywnej estymacie – to podstawowe założenie. Nie stawiamy sobie ścian w postaci deadline’ów na zadania – obieramy zespołem wspólny cel: zrealizować projekt na czas. To jest naszym jedynym deadline’em.

Jeśli ktoś nie zmieści się w agresywnej estymacie, dobierzemy z buforu centralnego. Dzięki temu uzyskamy najkrótszy czas realizacji zadania. Wykorzystamy tylko tyle z bufora, ile potrzebujemy na ukończenie zadania. W ogólnym rozrachunku kończymy to zadania wcześniej. Minimalizujemy zużycie bufora i czas wykonania zadania, a maksymalizujemy wydajność.

Przykład:
Developer wyestymował zadanie na 4h, agresywna estymata daje mu na wykonanie 2h. Największe prawdopodobieństwo, że zostanie ukończone zadanie (bez wykorzystywania buforów), jest właśnie po 50% – 2h. Statystyki kłamią ;), developer potrzebował 3h na ukończenie zadania. Dzięki temu zrealizowaliśmy zadanie 25% szybciej. Mamy jednocześnie 1h w centralnym buforze dla opóźnień w innych zadaniach.

ambitne cele zamiast kar

Bez wątpienia z większą przyjemnością i motywacją będziemy wykonywać zadanie, za które nie ma kary, a być może będzie nagroda – zostaniemy świetnym, wydajnym developerem. W odwrotnej sytuacji gdy uciekamy przed konsekwencjami – pracujemy w stresie, co na dłuższą metę powoduje tzw „wypalenie zawodowe” (jaskrawy przykład). Podchodzimy do zadań z mniejszym zapałem, a atmosfera robi się gęsta. Czym większy stres, tym mniejsza kreatywność, co często wiąże się z brakiem pomysłu na rozwiązanie zadania, schematycznymi działaniami powodującymi bugi. Nikt na tym nie zyskuje. Zamieniając karę na wyzwania otrzymujemy wynik win : win.

na co powinien być zużywany bufor?

Powinien być zużywany na rzeczy, których nie mogliśmy przewidzieć lub ich skali nie byliśmy w stanie określić. Mowa o problemach obiektywnych. Przykład:

• nie byłem w szkole bo byłem chory
• dziecko nie może wyjść na dwór bo jest zimno
• nie skończyłem zadania bo zepsuł mi się komputer

Z tymi argumentami ciężko dyskutować – tak się stało, musimy to zaakceptować. Takie problemy nie zdarzają się często, ale są obecne. W perfekcyjnej sytuacji bufory centralne wykorzystywane są tylko na takie sytuacje – problemy obiektywne.

Istnieje też cała masa problemów, które byliśmy w stanie przewidzieć jak np. napisanie struktury klas pod funkcjonalność, przygotowanie widoku lub cokolwiek innego. Mimo, że mogliśmy je przewidzieć to nie uwzględniliśmy ich w estymacie naszego zadania. W mniejszym stopniu bufor może być wykorzystywany na takie problemy wynikające z naszego braku szerszego spojrzenia na rozwiązywane zadanie. Jesteśmy w stanie częściej „przewidywać nieprzewidziane” gdy przeanalizujemy historię problemów jakie występowały w innych zadaniach podobnego typu. Dlatego istnieje ogólne przekonanie, że developer z większym doświadczeniem estymuje dokładniej – na podstawie swojego doświadczenia jest w stanie przewidzieć więcej. Czym więcej opóźnił zadań, tym jego historia będzie bogatsza co przyczyni się do lepszych estymat. Pod warunkiem, że uczy się na błędach. Analogicznie jest z niedoświadczonymi programistami lub tymi nie uczącymi się na błędach – zadanie wyestymowane na 1 dzień, może zająć 20m lub tydzień. Czas realizacji jest wtedy wynikowy.

Fatalną sytuacją jest gdy bufory są marnowane, mam tutaj na myśli sytuacje gdy developer dodaje sobie pracę żeby wypełnić planowany czas (wraz z buforem). Szerzej opisałem to w artykule o buforach „bezpieczeństwa” w zadaniach..

Podsumowanie

Możemy maksymalizować wydajność zasobów poprzez wprowadzenie buforu centralnego, który jest jawny i optymalnie wykorzystywany. W przeciwieństwie do ukrytych buforów w każdym z zadań, które często bywają bezproduktywnie wykorzystywane (marnowane). Uzyskujemy sytuację gdy opóźnienie jednego zadania nie opóźnia nam całego projektu dzięki elastycznemu korzystaniu z buforu. Cały zespół ma wspólny cel, do którego dąży: realizacja projektu na czas. Unikamy sytuacji gdy „każdy skrobie swoją rzepkę” nie dążąc do realizacji projektu na czas tylko dążąc do realizacji swojego zadania na czas. Takie podejście maksymalizuje ryzyko opóźnień.
Bufor centralny nie jest panaceum na opóźnienia projektów. Możliwe, że opóźnienia w twoim projekcie wynikają z czegoś innego niż bufory bezpieczeństwa w zadaniach. Właściwie stosując się do metod łańcucha krytycznego realizujemy projekt tak szybko, jak to możliwe.

W kolejnych częściach tej serii będę poruszał kwestię zarządzania centralnym buforem czasu oraz inne korzyści ze stosowania łańcucha krytycznego w prowadzeniu projektów.