Rejestr Założeń ubezpieczeniem terminu

Niedawno robiłam przegląd znanych mi narzędzi oraz pojęć z zakresu zarządzania projektami, które w jakiś sposób systematyzują wiedzę, którą już posiadam. Było ich 123 wrzuconych w tabelkę. Przy okazji odkurzyłam pewien rejestr, który przypomniał mi jedną z sytuacji, w jakiej go zastosowałam, a którym dzisiaj się z Wami podzielę.

Estymowanie jednak takie straszne…

Jeden z zespołów poproszony o przedstawienie estymacji dla zakresu, który był do zrealizowania, ocenił te prace na 14 tygodni. Estymacja była dla klienta nie do zaakceptowania, co więcej – spowodowała falę niezadowolenia i eskalację. Temat trafił do mnie. Postanowiłam przyjrzeć się więc nie tyle zakresowi, co podejściu zespołu do procesu szacowania czasochłonności prac.

Zawsze staję po stronie estymacji zespołu, jeśli zespół umie ją obronić. Czasem brak akceptacji ze strony klienta nie jest uzasadniony, dlatego uważam, że nie zawsze należy uginać się pod presją. Trzeba uzasadnić liczby i założenia, jakie za nimi stoją. Skąd więc 14 tygodni i dlaczego dla wspomnianego zakresu było to za dużo?

Najlepszą obroną jest bufor (?!)

Zespół nauczony negatywnymi doświadczeniami z przeszłości takimi jak:

• rozpoczynający się sprint pomimo niespełnionych założeń wynikających z DoR, np. brak architektury rozwiązania, danych testowych, makiet,
• nagle pojawiające się zmiany i niezmieniający się i nieprzekraczalny termin dostarczenia,
• zależności od innych zespołów i również “sztywny” termin,

postanowił się zabezpieczyć, dodając do estymacji… bufory na wszystkie powyższe okoliczności.

Pokazuje to jak nieprawidłowości procesu uczą złych praktyk, zachęcają do kombinowania, powodują pewien strach czy obawy przed rzetelnością, która i tak będzie musiała ulec pod naporem oczekiwań biznesu i presji czasu, na którą nie ma miejsca, z którą nikt nie chce się liczyć, kiedy czas płynie, a termin jest zagrożony. Krótko mówiąc, zespoły często działają w środowiskach projektowych opartych na jednostronnych oczekiwaniach biznesu, pozbawione praw do tego, aby pracować zgodnie ze sztuką lub chociażby procesem, który w danej organizacji został wdrożony i nie jest przestrzegany.  

Tak więc i mój zespół zaczął się podświadomie bronić przed nierealnością oczekiwań, a to że bronił się niewłaściwie jest właśnie przedmiotem tego artykułu.

Dlaczego dodawanie buforów nie jest dobrą strategią obrony?

Przede wszystkim dlatego, że bufory są niemierzalne, podobnie jak wszystkie nieszczęścia, przed którymi mają nas zabezpieczyć.

Kiedy estymujemy, nie wiemy ile zmian się pojawi, ile zależności będzie nas blokować jak długo czy kiedy dostaniemy w końcu brakującą architekturę, dane itd. Pojawia się więc pytanie dlaczego 14 tygodni, a nie na przykład 13 czy 15.

Co z buforem, kiedy wspomniane nieszczęścia się nie zmaterializują lub zmaterializuje się tylko część z nich? Co, jeśli bufor okaże się niedoszacowany? Czy bufor zawiera skończoną listę możliwych negatywnych scenariuszy? No właśnie.

O buforze pisałam już w artykule “Bufor – koło ratunkowe czy demotywator?”. Tu chcę podkreślić, że nie jest on i nie może być wiarygodnym zabezpieczeniem dla zespołu. Jak powiedział Peter Drucker, guru zarządzania, uważany za jednego z najwybitniejszych myślicieli i teoretyków zarządzania XX wieku: “Jeśli nie możesz tego zmierzyć, nie możesz tym zarządzać” (ang. If you can’t measure it, you can’t manage it).

Rejestr Założeń, czyli jak rozmawiać z biznesem

Co zatem może nam pomóc? Rejestr Założeń – narzędzie o wielkiej mocy i znaczeniu, proste w swojej formie, choć nie znaczy to, że łatwo taki rejestr stworzyć.

Założenia to czynniki, które dla celów planowania uznaje się za prawdziwe, rzeczywiste lub pewne bez konieczności dowodzenia lub demonstrowania. Określa się również potencjalne skutki wywołane przez te czynniki, jeśli założenia okażą się nieprawdziwe. /PMBOK, 5th edition/

Cała trudność polega na zdefiniowaniu założeń. Ja stosuję technikę: “zrobię to w x dni / tygodni, przy założeniu, że…” i tu muszę wykazać się umiejętnością przewidywania tak, aby założenia były możliwie jak najbardziej wyczerpujące. To swego rodzaju “nakładka” na zakres, która “dodefiniowuje” to, co wprost z zakresu nie wynika, może odnosić się do sposobu wykonania, wykorzystanych technologii czy posiadanych zasobów.

Znów posłużę się przykładem z życia – sprzątaniem. Mogę powiedzieć: posprzątanie całego domu zajmie mi 8 godzin przy założeniu, że:

• na kanapie nie będzie sierści kota
• okna są czyste i nie wymagają mycia
• podłogę odkurzy robot sprzątający
• nic w międzyczasie się nie rozleje / nie wysypie
• mam w domu wszystkie niezbędne środki chemiczne
• w sprzątaniu pomoże mi mąż

Oczywiście, jeśli któreś z założeń okaże się nieprawdziwe, moich 8 godzin może ulec zmianie.

Wracając do przykładu i nieszczęsnych 14 tygodni mojego zespołu – tak oto udało nam się sprowadzić pierwotną estymację (dla przypomnienia 14 tygodni) do – uwaga – 5 tygodni. Pozostałych 9 tygodni przekuliśmy w założenia:

1. Wszystkich 5 zidentyfikowanych zależności zostanie rozwiązanych do dnia …
2. Przygotowane schematy wymiany danych są ostateczne i nie ulegną zmianie.
3. Capacity zespołu nie ulegnie zmianie.
4. Wymagania biznesowe nie ulegną zmianie.
5. Konfiguracja Kafki nie ulegnie zmianie.
6. Rejestr schematów nie zostanie wyczyszczony.
7. Nie wystąpi przestój w działaniu Kafki / REST API Kafki.
8. Środowiska będą działać poprawnie.
9. Informacje, które mamy dzisiaj, są ostateczne i nie zostaną wprowadzone żadne nowe dane.

W przypadku wystąpienia zmian / działań, które będą miały wpływ na powyższe założenia, zespół dokona re-estymacji. Klient zaakceptował 5 tygodni i załączony do estymacji Rejestr Założeń.

Podsumowanie

Rejestr Założeń i praca z nim to nie tylko obrona estymacji i jej uzasadnienie, ale też edukacja biznesu. Pokazuje jaki wpływ na pierwotne szacunki mają zmiany, najczęściej nie pochodzące od zespołu. Biznes powinien mieć świadomość, że estymacja nie może pozostać stała, jeśli założenia, które jej dotyczą się zmieniają.

Zaakceptowanie zmieniających się czasochłonności i terminów dostarczenia prac w okolicznościach zmieniających się założeń to zasada fair play, którą biznes jest winien zespołom deweloperskim.