Szacowanie w projektach IT – część 2

Szacowanie w projektach IT – część 2

Ten wpis jest kontynuacją tematu o szacowaniu w projektach IT i odnosi się do pojęć wyjaśnionych w części 1.

Wyliczanie czasochłonności na podstawie pracochłonności

Sposobem, który jest często stosowany do wyliczania czasochłonności jest: Czasochłonność = Pracochłonność / Ilość zasobów.

Niestety w takich wyliczeniach ukryte są pewne optymistyczne założenia, które często nie są spełnione. Poniżej lista kilku takich założeń wraz z propozycjami jak podejść dla nich do tematu oszacowania czasochłonności.

Założenie 1: Przydzielanie kolejnych osób do zadania skraca czas jego realizacji proporcjonalnie do liczby osób

Problem

Powyższe wyliczenie zakłada, że czasochłonność maleje liniowo przy przydzielaniu kolejnych osób do zadania, co rzadko występuje w rzeczywistości. W trakcie kopania studni może w niej kopać tylko jedna osoba jednocześnie, tak samo wiele zadań w projektach IT wymaga minimalnego czasu poświęconego przez jedną osobę i dodawanie kolejnych osób znacząco go nie skraca. O zbyt optymistycznym szacowaniu czasu w projektach pisano już lata temu chociażby w klasykach typu Mityczny osobomiesiąc (Brooks Frederick), czy Marsz ku klęsce (Edward Yourdon).

Sugerowane podejście

Aby oszacować czasochłonność złożonego zadania, do którego przydzielamy wiele osób trzeba je szczegółowo zaplanować, czyli rozbić zadanie na podzadania i je oszacować, określić które z nich mogą być równolegle wykonywane, określić zależności między nimi a następnie zsumować czasy w najdłuższej sekwencji tych podzadań.

Założenie 2: Oszacowana pracochłonność zawiera wystarczający bufor bezpieczeństwa

Problem

Pracochłonność może być oszacowana z małym buforem bezpieczeństwa, z kolei czasochłonność często jest rozumiana jako oszacowanie z dużym prawdopodobieństwem dotrzymania terminu. Pesymistyczny sposób traktowania oszacowania czasu sugerują też używane tu pojęcia jak commitment czy deadline.

Sugerowane podejście

Prosząc zespół o przygotowanie estymat trzeba precyzyjnie określić jakiego rodzaju oszacowania potrzebujemy. Skuteczna jest praktyka osobnego optymistycznego szacowania zadania i osobnego szacowania ryzyk dla niego, daje to informację o precyzji oszacowania oraz pozwala zrozumieć i zaadresować część ryzyk. Optymistyczne oszacowania pracochłonności zadań nie powinny być komunikowane do klienta, który może pochopnie zrozumieć te estymacje i przyjąć, że pracochłonność w kontrakcie jest przeszacowana i przepłacił za projekt.

Założenie  3: Osoby przydzielone do zadania będą w 100% skoncentrowane na tym zadaniu

Problem

Osoby przydzielone do zadania często mają też inne zadania, które muszą równolegle wykonywać, czyli nie dysponujemy 100% ich czasu i uwagi. Jeśli osoba ma przypisane wiele zadań i musi się często przełączać między nimi, to traci ona sporo czasu na przełączaniu się pomiędzy zadaniami. Ukryte koszty wielozadaniowości są rzadko mierzone i bywają pomijane przy planowaniu obciążenia danej osoby.

Sugerowane podejście

Idealną sytuacją jest, gdy osoba zaangażowana jest w jeden projekt i wykonuje jedno zadanie na raz i choć nie zawsze da się to zapewnić, to warto do tego dążyć. Zadania rozpraszające prace to zadania typu świadczenie usług utrzymania systemów i wsparcia klienta, odpowiadanie na maile czy spotkania pozaprojektowe. Dla zadań utrzymaniowych i wsparcia klienta często stosowane jest zdefiniowanie w zespole osobnej roli, która zajmuje się takimi zadaniami. Rola ta może rotacyjnie być przekazywana pomiędzy członkami zespołu. W ten sposób reszta zespołu może w pełni skoncentrować się na zaplanowanych w projekcie zadaniach. Aby dobrze oszacować ile czasu zajmują wszystkie te zadania rozpraszające, trzeba po prostu przez jakiś czas mierzyć czas wymagany na ich realizację i przy szacowaniu czasochłonności uwzględnić odpowiedni procent dostępności zespołu.

Założenie 4: Wszystkie zależności zewnętrzne do zadania będą dostępne na czas

Problem

Niektóre z zadań w projektach mają zależności zewnętrzne od innych zespołów. Przykładowe problemy występujące przy zależnościach zewnętrznych to niedostarczenie ich na czas, dostarczenie rozwiązania niekompletnego lub nie wystarczającej jakości, problemy komunikacyjne, zmiany założeń, pojawianie się nowych niezaplanowanych zależności. Zakładanie, że wszystkie zależności zewnętrzne będą dostępne na czas bez aktywnego zarządzania nimi, jest zbyt optymistyczne. Z kolei, gdy zostawi się na barkach programisty zarządzanie zależnościami zewnętrznymi, to zamiast programować, musi on poświęcać czas na robienie tego, w czym nie koniecznie się specjalizuje i co niekoniecznie lubi robić.

Sugerowane podejście

Wszystkie zależności zewnętrzne powinny być z góry zidentyfikowane, daty ich dostarczenia zaplanowane na linii czasu, a następnie powinny być aktywnie zarządzane. Odpowiedzialność za zarządzanie tymi zależnościami i komunikację powinna być po stronie menedżera projektu lub innej osoby koordynującej projekt. Oszacowanie czasochłonności zadań z zależnościami zewnętrznymi powinno uwzględniać potencjalne ryzyka opóźnień dostarczenia tych zależności. Jeśli zależności zewnętrzne pochodzą od klienta, to w harmonogramie w kontrakcie dobrze jest je uwzględnić jako kamienie milowe.

Co kiedy nie da się oszacować z wystarczającą precyzją?

Nie ma jednoznacznej odpowiedzi jaka jest definicja niewystarczającej precyzji oszacowania, dobrze jest najpierw zrozumieć co osoba odbierająca estymację zamierza z nią zrobić. Jeśli ma być ona podstawą do zrobienia wiążącej oferty handlowej, będzie to inny próg niż w przypadku, gdy biznes pyta zespół developerski o zgrubną pracochłonność projektu na potrzeby wstępnej priorytetyzacji. Oczekiwania biznesu są często takie, że estymacja, którą podaje zespół developerski nie zostanie przekroczona o więcej niż 30%, ale najbezpieczniej zapytać biznes jak to jest w tym konkretnym przypadku. Jeśli chodzi o oferty handlowe minimalnie akceptowalna precyzja zależy od wielu czynników jak apetyt na ryzyko, chęć zdobycia klienta, marginesy w stawkach za programistów, itp.

Dla zadań skomplikowanych technicznie lub algorytmicznie, posiadających niejasne zależności zewnętrzne lub inne potencjalne ryzyka, przed podaniem czasochłonności warto wykonać najpierw wstępną analizę techniczną lub prototyp zwany też proof of concept. W metodykach Agile zadania, które służą do wstępnej analizy, by móc dopiero w kolejnym kroku dokonać estymacji, nazywane są Spike. W ich przypadku planuje się z góry pracochłonność, którą poświęci się na analizę zadania w najbliższej iteracji.

Podobne problemy z brakiem możliwości oszacowania występują dla zadań, które są zbyt ogólnie zdefiniowane i zakres prac może być całkowicie różny w zależności od interpretacji wymagań. W tych wypadkach sprawdzają się metodyki Agile i przyrostowe odkrywanie oczekiwań klienta. Można też podzielić dane zadanie na podzadania, w których część jest dobrze zdefiniowana i gotowa do oszacowania, a część musi być uszczegółowiona przed podaniem estymacji.

Czasami jest duża presja na podanie oszacowania pomimo tego, że jest to komunikowane, że zadanie wymaga dalszej analizy. W takich sytuacjach rolą menedżera jest próba wynegocjowania czasu na zrobienie analizy lub jak się nie uda, to podanie jako oszacowania nie jednej liczby, ale zakresu liczb. Dolna część zakresu jest w tym wypadku oszacowaniem oczekiwanym, a górna część zakresu jest oszacowaniem bardzo bezpiecznym. Duża różnica między dolną i górną granicą oszacowania, to prosty przekaz do klienta, że zadania wymagają doszczegółowienia, by podać je z lepszą precyzją. Podając zakres estymacji zespół nie bierze też na siebie ryzyka, że estymacja zostanie zakomunikowana komuś jako precyzyjne oszacowanie, z którego trzeba się potem wywiązać.

Oszacowania w projektach fixed-price dla zewnętrznego klienta

Wycena projektu do oferty lub kontraktu FP

Jako kontrakt fixed-price rozumiem tu kontrakt z określonym z góry zakresem, czasem i budżetem projektu. Wycena do oferty lub kontraktu FP wymaga podania wartości pieniężnej, którą się wylicza na podstawie szacowanej pracochłonności projektu oraz odpowiednich stawek osób wykonujących projekt.

W wycenach kontraktów stosuje się oczekiwaną pracochłonność wraz z buforami bezpieczeństwa dla ryzyk. Bufory bezpieczeństwa mogą być różne w zależności od branży, potencjalnej konkurencji, pozycji rynkowej, chęci zdobycia kontraktu, itp. Aby oferta była konkurencyjna wobec innych oferentów nie można dodać zbyt dużych buforów.

Ryzyka szacuje się albo jako wartość procentową, o którą zwiększa się oszacowanie bazowe danego zadania albo jako wartość bezwzględną w dniach roboczych, którą dodaje się do oszacowania bazowego. Można szacować ryzyka osobno dla poszczególnych zadań lub zbiorczo dla części lub całości projektu.

Harmonogram do oferty lub kontraktu FP

Harmonogram w ofercie lub kontrakcie fixed-price z reguły zawiera najważniejsze kamienie milowe związane z datami odbiorów etapów i nie zawiera szczegółowego planu dla wszystkich zadań w projekcie. Harmonogram taki zakłada pesymistyczną czasochłonność, czyli uwzględnia różne ryzyka opóźnień, daty odbioru całości projektu oraz w harmonogramie często powiązane są z karami umownymi za opóźnienia, stąd muszą tam być odpowiednie marginesy.

Oszacowania czasochłonności w takim harmonogrami nie mogą być jednak zbyt pesymistyczne, bo oferta nie będzie konkurencyjna na rynku oraz harmonogram może nie zostać zaakceptowany przez klienta. Dodatkowo firma musi myśleć o rentowności nie tylko pojedynczego projektu, ale też całego działu czy zespołu projektowego. Jeśli rozciągniemy harmonogram zbyt mocno, a w tym samym czasie zespół nie będzie miał zaplanowanych zadań z innego projektu, to rentowność tego działu/zespołu w mierzonej jednostce czasu jak kwartał czy rok może spaść poniżej akceptowalnego poziomu.

Harmonogram operacyjny

Harmonogram operacyjny to harmonogram używany przez kierownika projektu po stronie dostawcy do codziennego zarządzania projektem, jest on bardziej szczegółowy w porównaniu do harmonogramu z kontraktu czy harmonogramu do planowania strategicznego/taktycznego.

Jeśli do przygotowania planu projektu została zastosowana metody ścieżki krytycznej, to oszacowania zadań są to oszacowania oczekiwane lub bezpieczne. W przypadku użycia metody łańcucha krytycznego, oszacowania zadań są optymistyczne, a ryzyka opóźnień z poszczególnych zadań uwzględnione są na końcu projektu w buforze bezpieczeństwa. Metoda łańcucha krytycznego będzie opisana szerzej w jednym z przyszłych wpisów.

 

Następna część >>

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *