Dlaczego twój projekt się opóźnia? część 2 – za szybkie zamykanie zadań
Ten wpis jest drugą częścią poprzedniego artykułu – dlaczego twój projekt się opóźnia? – bufory „bezpieczeństwa” w zadaniach. Poprzednio poruszałem kwestię tego jak „kary” za nieukończenie zadań w terminie powodują zwiększanie buforów w estymatach oraz jaki negatywny ma to wpływ na realizację projektu w terminie. Dziś opiszę jak błędna definicja projektu wynikająca z utartych schematów „standardowych” metodyk prowadzenia powoduje, że stawiamy przed sobą ograniczenia i sami przyczyniamy się do opóźnień.
Na początku warto wyjaśnić co oznacza zakończenie projektu (w terminie). Mając na uwadze to, że zadania posiadają dodatkowy margines, który jest marnowany można powiedzieć, że projekt kończy się w terminie, jeśli zrealizujemy wszystkie zadania w zaplanowanym czasie. Model zadań z buforami ma to do siebie, że zazwyczaj opóźnienie jednego z zadań powoduje opóźnienie całego projektu – bardzo ogólne stwierdzenie, zakładające, że wiele zadań ma kolejność sekwencyjną.
domykanie zadań kolanem
Gołym okiem widać, że dopełnienie tej definicji w praktyce jest trudne – musimy pilnować tylu terminów, ile mamy zadań. Takie podejście zwiększa ryzyko opóźnienia, ponieważ każdy termin jest obarczony ryzykiem (prawdopodobieństwem, że zadanie zostanie opóźnione). Ukończenie projektu zawiera więc wszystkie prawdopodobieństwa opóźnień ze wszystkich zadań. Istnieje mała szansa, że wszystko zostanie zrealizowane w terminie, tym samym, że projekt zostanie ukończony na czas. Model zadań z buforami wymusza na nas definicję ukończenia projektu, którą przedstawiłem powyżej, a to z kolei utrudnia realizację projektu w zaplanowanym czasie. Błędne koło obarczone dużym ryzykiem opóźnień.
Wkładamy nadmierne pokłady energii i pracy, żeby dopilnować każdego z terminów, który w ogólnym rozrachunku jest mniej istotny. Najważniejsze jest dotrzymanie terminu realizacji projektu, a to co się dzieje po drodze jest na drugim planie. Jeśli chodzi o warstwę biznesową to nie są istotne statystyki na temat ilości zrealizowanych zadań w terminie i tych opóźnionych – liczy się efekt końcowy, czyli data ukończenia projektu. Często nakład pracy zespołu w to, żeby dotrzymywać cząstkowych terminów (realizacja poszczególnych zadań) jest zbyt duża i przyczynia się do opóźnień. Często bywa tak, że żeby dopiąć konkretne zadania w terminie nadmiernie się na nim skupiamy zaniedbując całokształt – resztę zadań. Zdarza się, że do zadania, w którym zbliża się deadline przypisujemy dodatkowe zasoby (by wyrobić się na czas z konkretnym taskiem), opóźniając zadania, które wcześniej szły terminowo. Skutki takiego ruchu odczujemy w przyszłości, ale przecież tym co będzie później, będziemy się martwić później, prawda? 😉 Zdarza się też, że zaciągamy dług technologiczny bo boimy się przekroczyć terminu realizacji zadań, robiąc tym samym „fuszerkę”, która poprzez złe wzorce architektoniczne opóźnia każde z zadań bo na wszystko będzie trzeba robić hacki. Dopchnięcie zadania kolanem by zrealizować je w terminie (bardziej świadomie lub mniej) przyczyniamy się do opóźnienia projektu jako całokształt. Sami przed sobą postawiliśmy ściany w postaci dotrzymywania terminów zadań, które w praktyce są nieistotne (względem realizacji projektu na czas). Naturalnym tokiem byłoby wydłużenie tego jednego tasku, który miał za krótką estymate – możliwe, że projekt opóźniłby się mniej, niż z podejściem gdy dopychamy terminy kolanem poszczególnych zadań. Zadania powinny zajmować tyle czasu ile zajmuje ich realizacja optymalnym sposobem, nie mniej i nie więcej. Jednak życie nie jest tak kolorowe i w poprzednim wpisie o buforach „bezpieczeństwa” w zadaniach wyjaśniałem dlaczego nie możemy poznać faktycznego czasu realizacji bez… realizacji zadania i poznania czasu empirycznie. Nasza estymata zawsze będzie tylko szacunkiem, przybliżoną wartością 🙂
brak zaangażowania zespołu
Wadą takiego podejścia jest sytuacja, którą ogólnie nazywamy „brak zaangażowania zespołu w projekt”. Abstrahując od tego, że zespół może naprawdę nie być zaangażowany w projekt, ale opiszę sytuację gdy brak zaangażowania wynika z wyżej przedstawionego przeze mnie podejścia do realizacji projektu. Ludzie chcą realizować swoją robotę jak najlepiej – w przypadku gdy nie widzą wspólnego celu z zespołem – finalizacja projektu, zaczynają skupiać się na realizacji swoich zadań, nie biorąc pod uwagę, że to tylko pośredni cel. Ich głównym celem staje się realizacja swojego zadania w terminie – co ma skutek taki jak opisałem wcześniej gdy dopychamy zadania kolanem by je zamknąć w terminie. Developer nie zauważa, że będzie pracował nad tym kodem jeszcze przez kilka kolejnych tasków – będzie się tym martwił później 😉 Dopchnięcie jednego zadania kolanem może nam wydłużyć czas realizacji kolejnych tasków bazujących na tym rozwiązaniu co skutkuje kolejnymi „hackami” żeby tylko zakończyć zadanie w terminie. Działa to jak kula śniegowa opóźnień, która się powiększa wraz z czasem. W efekcie słyszymy narzekania: „bo ktoś zrobił ten kod źle, powinien wyglądać [tak] i [tak].” Odbiór PM takich powtarzających się narzekań jest taki, że zespół zaciągnął niepotrzebnie dług technologiczny, który utrudnia dalsze prace lub wręcz je uniemożliwia. Ogólne wrażenie jest takie, że zespół się nie angażuje w projekt bo gdyby się angażował to nie robił by takich kwiatków i myślałby przyszłościowo. Natomiast problemem jest to, że za bardzo angażują się… w swoje zadania zamiast w projekt (jako całokształt). Finał tego jest taki, że PM myśli jak zwiększyć zaangażowanie, robi restrukturyzację zadań, musi zadbać o atmosferę w zespole oraz poinformować biznes, że projekt prawdopodobnie może się opóźnić – robimy wszystko, tylko nie kończymy projektu. Rozwiązujemy problemy, które sami stworzyliśmy tym samym nie skupiając się na progresie w projekcie. Takie problemy nie są tylko winą podejścia do realizacji projektu, bardzo często też wynikają z tego, że w twoim zespole są nieodpowiedni ludzie. Zobacz jak charakteryzuję dobrego developera.
Pssst… mam dla Ciebie prezent 🙂
Podsumowanie
W pierwszym wpisie z serii „dlaczego twój projekt się opóźnia?” opisałem problem jaki powstaje gdy zadania mają nadmierny bufor „bezpieczeństwa”. W drugim artykule również skupiłem się na zdiagnozowaniu przyczyny opóźnień – dotrzymywaniu terminów zadań, zamiast dotrzymywania terminu projektu. Opisałem również skutki takiego podejścia podczas realizacji projektów, które nazywamy „standardowym” (niestety). W kolejnej części opiszę sposoby rozwiązywania problemów buforu zadań w taskach oraz pilnowaniu jednego terminu przez cały zespół. Będą diagramy, wykresy oraz szerszy opis łańcucha krytycznego 🙂
Tymczasem Morpheus ma dla was, krótki spoiler trzeciej części:
Dokładnie tak, jak mówi Morpheus – a co jeśli pilnowalibyśmy tylko jednego terminu? Byłby to termin finalizacji projektu.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
