Dlaczego twój projekt się opóźnia? – bufory "bezpieczeństwa" w zadaniach
W tym wpisie poruszę temat tego jak bufory „bezpieczeństwa” (cudzysłów nie jest przypadkowy) w taskach wpływają na przedłużenia projektu. Opiszę również jak „kary” za nie wykonywanie zadań w terminie przez developerów przyczyniają się do opóźnień. Zrozumienie istoty problemu jest pierwszym krokiem do ich eliminacji i zwiększenia prawdopodobieństwa realizacji projektów w terminie (lub przed).
Na początku warto powiedzieć, że nie jesteśmy w stanie przewidzieć dokładnego czasu wykonania zadania. Nasza wycena, zawsze więc będzie jedynie szacunkiem. Czas wykonania zadania poznamy dopiero po jego wykonaniu.
Jeśli pytasz developera w ile czasu wykona zadanie, uzyskujesz odpowiedź w stylu: 40m, 2h, 3d etc. Już w tym momencie możesz być przekonany, że kłamie. Nie wykona zadania w tym czasie, jedynie taki czas sobie na nie przeznaczył – to zmienia postać rzeczy. Zadanie wykona w 38m, 1h43m lub 2d 7h – to będzie faktyczny czas realizacji zadania, który de facto poznasz dopiero po jego wykonaniu. Jak już wcześniej wspominałem w artykule o najczęstszych błędach w estymowaniu – okrągłe liczby zawsze kłamią!
Tak więc możemy ułożyć równanie:
czas wykonania zadania = (faktyczny czas wykonania zadania*) + (margines zapasu/bufor bezpieczeństwa)
*- mam tutaj na myśli czas, o którym pisałem powyżej, który poznamy dopiero po wykonaniu zadania.
Doskonale z tym zazębia się prawo Parkinsona, które w skrócie mówi o tym, że praca rozszerza się tak żeby wypełnić przeznaczony na nią czas. Skrót skrótu: wykonamy zadanie w takim czasie jaki sobie na nie przeznaczyliśmy (lub dłuższym). Chcemy być słowni, więc mniej lub bardziej świadomie dążymy do tego by wykonać zadanie dokładnie w takim czasie jak zadeklarowaliśmy. Nawet jeśli prawo Parkinsona nie wypełni naszej estymaty w 100%, to można dołożyć zadania sprawdzające/testujące, które nam pomoże „zmarnować” ten czas( 😉 ). Można więc ogólnie powiedzieć, że margines z naszego równania jest czasem spędzonym bezproduktywnie lub mało produktywnie.
Prawdziwa tragedia dzieje się wtedy, gdy podczas wykonywania zadania wykorzystujemy margines (bufor) na rzeczy dla, których nie jest on przeznaczony.
Np. przez pierwsze 60% zadania wszystko przebiega bezproblemowo. Małymi kroczkami tracimy nasz bufor, wykonując zadanie bez presji czasu, bez pośpiechu, nadmiernie pedantycznie. Pamiętajmy o tym, że nasz bufor/margines powinien być na rzeczy nieprzewidziane, które mogą opóźnić zadania. Mając 80% wykonania zadania możemy mieć już spalony bufor – przez to, że działaliśmy wolniej/mniej efektywnie. W takiej sytuacji mamy dokładnie tyle czasu żeby dokończyć nasze zadanie tym tempem, które sobie narzuciliśmy, które równocześnie wypełni nasz zadeklarowany czas (prawo Parkinsona) oraz, które nie uwzględnia nieprzewidzianych komplikacji. Takie zachowanie powoduje ogromne ryzyko, ponieważ nieprzewidziane rzeczy mają to do siebie, że są nieprzewidziane 😉 i mogą wyskoczyć w takim momencie, gdy bufor jest już spalony lub zbyt mały – ups, mamy opóźnienie.
Właśnie ta sytuacja może wpłynąć na opóźnienie twojego projektu – nadmierne bufory/marginesy w zadaniach. Jak sobie z tym radzić wyjaśnię w kolejnym wpisie (obiecuję 😉 ) – w tym chcę skupić się na przyczynie opóźnień.
Pssst… mam dla Ciebie prezent 🙂
Co wpływa na wielkość buforu?
Głównym czynnikiem są „kary”. Kary mogą być formalne lub nieformalne. Formalną karą może być brak premii, zwolnienie w ekstremalnych przypadkach, natomiast nieformalną karą może być dobitny monolog przełożonego, „przecież mówiłeś, że się wyrobisz!” lub inne psychologicznie nieprzyjemne zdarzenia przez które większość z nas przechodziła.
W zależności od skali kary za niewykonanie zadania w terminie, developer dobiera sobie bufor – by mieć „pewność”, że wykona zadanie w terminie bo chce uniknąć kary. Niestety ten bufor jak już wcześniej opisałem nie jest produktywnie wykorzystywany.
Prosty przykład; maturę prawdopodobnie pisałeś w szkole (budynek, adres), do którego chodziłeś na zajęcia codziennie (miałeś lekcję od poniedziałku do piątku w tym budynku). Zjedzenie śniadania, toaleta poranna, droga do szkoły zajmuje ci więc tyle samo czasu w dniu matury ile w zwykłym dniu. Mimo to, (pewnie większość z nas) nastawiła w dniu matury budzik na duuuużo wcześniej – „by mieć pewność” 😉 Zarezerwowaliśmy sobie nadzwyczajnie duży bufor ponieważ „kara” za niewykonanie zadania w terminie (przybycie do szkoły na czas) była dużo większa. Na lekcji dostawało się „spóźnienie”, natomiast maturę powtarza się w sierpniowym terminie 😉 Jak widzisz skala „kary” wpłynęła na to, że powiększyłeś bufor. Taki margines zapasu prawdopodobnie został wykorzystany bezproduktywnie (byłeś gotowy wcześniej i czekałeś, byłeś 15x w toalecie bez potrzeby 😉 ), zamiast tego – mógłbyś przeznaczyć go np. na naukę przed egzaminem (lub cokolwiek innego) co zwiększyłoby twój wynik na egzaminie. Abstrahując od tego, czy nauka kilka godzin przed samym egzaminem ma sens – to tylko przykład 😉
Mam nadzieję, że jesteś sobie w stanie wyobrazić jak wykorzystywanie buforu w miejscach, w których jego wykorzystanie nie jest niezbędne może opóźnić twoje zadania – co się składa na opóźnienie całego projektu. Teraz wiesz, dlaczego we wstępie ująłem słowo bezpieczeństwo w cudzysłów – zwiększając bufor otrzymujemy w zamian złudne poczucie bezpieczeństwa i zwiększone ryzyko opóźnień. Może ten bufor powinien nosić nazwę „bufor niebezpieczeństwa”? 🙂
Część 2 : łańcuch krytyczny – za szybkie zamykanie zadań
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
