Estymowanie budżetu w zwinnych projektach

Jacek Wieczorek, autor książki “Labirynty Scruma”, w jednym ze swoich postów na LinkedIn napisał, że ograniczeniem zwinności software house’u jest poziom zwinności jego klientów. Stwierdzenie to doskonale odzwierciedla mój własny pogląd na temat zwinności i jej ograniczeń. Poszłabym nawet o krok dalej i zaryzykowała stwierdzeniem, że brak lub niski poziom zwinności klientów jest ograniczeniem biznesów prowadzonych agile’owo (nie tylko software house’ów). Czy zatem bez zwinności klienta możemy być w pełni zwinni? Myślę, że nie. Myślę, że możemy być zwinni razem albo wcale.

Jest wiele czynników, które tworzą (lub ograniczają) zwinność – zarówno po stronie zamawiającego, jak i wykonawcy. Myślę, że to temat na całkiem pokaźny cykl artykułów, jednak dziś chciałabym się skupić na jednym z tych czynników, jakim jest estymowanie budżetów w projektach zwinnych. To również pytanie, z którym spotykam się bardzo często.

Jak estymować budżet zwinnego projektu?

Wiele firm pracuje agile’owo w modelu rozliczeniowym “time & material” (rozliczenie według czasu pracy i zużytych materiałów), ale ich klienci nadal chcieliby znać koszt projektu przed jego rozpoczęciem. Stajemy zadem w obliczu odpowiedzi na pytania:

1. Jak zmaksymalizować dokładność szacunków?
2. Co zrobić, aby klienci nie traktowali tej estymacji jako sztywnego i niezmiennego budżetu?

Podzielę się z Tobą moimi praktykami, które pomagają mi maksymalizować dokładność estymacji, niemniej jednak doczytaj ten artykuł do końca, bo odpowiedź na to pytanie paradokslanie nie jest tym, czego potrzebujesz :)

Aby zmaksymalizować dokładność estymacji:

1. Zidentyfikuj wymagania w oparciu o to, co naprawdę “musi być”, co “powinno”, a co “może być” (korzystając np. z techniki MoSCoW),
2. Zacznij od maksymalnie uproszczonej wersji produktu (ang. Minimum Viable Product, MVP)
3. Podziel pracę na mniejsze części (WBS lub Backlog Produktu) – zrób dekompozycję
4. Korzystaj z technik estymowania, zarówno tych ze świata waterfall, jak Agile. Wybieraj te techniki, w których biorą udział osoby, które będą wykonywać pracę, np. szacowanie przez ekspertów (ang. Expert Judgemet), metoda wstępująca (ang. Bottom-up Estimating), jak również Poker Planning, grupowanie podobieństw (ang. Affinity Grouping) lub Bucket System, aby estymowanie było bliższe rzeczywistości. Pamiętaj, że techniki agile’owe w odróżnieniu od waterfall’owych szacują złożoność zadań, a nie czas trwania.
5. Słuchaj, co mówią członkowie zespołu – nie ignoruj ich obaw, gdy mówią, że coś jest niedoszacowane.
6. Stwórz rejestr założeń – uwzględnij założenia, jakie przyjmujesz do estymacji.
7. Zadbaj o zrozumienie tego, co należy zrobić, a czego nie należy robić w ramach konkretnego wymagania – zdefiniuj wykluczenia.
8. Wyciągaj wnioski z minionych doświadczeń i poprzednich projektów. Zwróć uwagę na estymacje (były w punkt / przeszacowane / niedoszacowane?)
9. Edukuj członków zespołu projektowego i klienta, czym są ryzyko i zmiana w projekcie, aby pomóc im je identyfikować i umiejętnie zarządzać.
10. Nieustannie monitoruj koszty i w razie potrzeby podejmuj działania korygujące. Postaw na ciągłe doskonalenie.

Precyzyjne planowanie za zwinność

W rezultacie powyższych działań otrzymasz zakres kosztów (minimum i maksimum), który przede wszystkim często jest tak szeroki, że nie mówi o dokładnych kosztach poszczególnych funkcji, a tym samym o koszcie całego projektu. Nawet jeśli klient wybierze wariant minimum, maksimum bądź po prostu optimum, będzie miał ustalony budżet za ustalony zakres, czyli “fixed price” za “fixed scope”. Brzmi waterfall’owo? Bo jest waterfall’owe. I tu dochodzimy do sedna sprawy.

• Im więcej wiemy, tym lepiej możemy oszacować.
• Aby dowiedzieć się więcej, musimy poświęcić więcej czasu na planowanie.
• Im więcej czasu poświęcamy na odgórne planowanie całości, tym mniej jesteśmy Agile (tracimy tę elastyczność, reagowania na zmiany i podążania za wartością biznesową).
• Nawet jeśli jesteśmy z tym OK, że nie jesteśmy tak bardzo zwinni, estymacje mają ograniczoną żywotność, co oznacza, że ​​musisz je aktualizować przez cały czas. W przeciwnym razie rzeczywistość okaże się rozczarowująca w porównaniu do planu. Czy naprawdę chcesz być rozczarowany?

Zarządzanie budżetem ponad estymowanie

Krótko mówiąc, im dokładnej estymujemy, tym mniej zwinni jesteśmy. Klient powienien mieć tego świadomość, że zyskując wymierne liczby, traci na zwinności, a tym samym w rezultacie otrzyma mniejszą wartość biznesową. Dlatego…

… bardziej niż estymacji potrzebujemy budżetu. Estymowanie pomaga klientowi w podjęciu krótkoterminowej, szczegółowej decyzji (i możemy to robić iteracyjnie). Dla strategicznych i długoterminowych decyzji zarządzanie budżetem jest znacznie lepszą techniką.

Zamiast dążyć do idealnego szacowania, wolę uświadomić klientowi ewentualną różnicę między początkową a ostateczną estymacją (w granicach tolerancji) i pomóc mu zrozumieć, jak zarządzać swoim budżetem w najbardziej efektywny sposób poprzez:

• Budowanie świadomości na temat tego czym jest Agile w ogóle (zwinne wartości i pryncypia);
• Budowanie świadomości na temat zwinnego procesu wytwarzania oprogramowania – np. Scrum, Kanban, Scrumban, każdy inny proces Agile – jak pracujemy i czego klient może oczekiwać (proces + dobre praktyki);
• Budowanie świadomości na temat samej natury oprogramowania – złożoności, nieprzewidywalności, jakości, skalowalności itp. – zaproszenie do naszego świata;
• Wyjaśnienie, które czynniki wpływają na koszty i powodują, że mogą one ulec zmianie – innymi słowy wyjaśnienie skąd pochodzi koszt, aby klient czuł, że jest decydentem w tej kwestii – transparentność jest tu kluczowa;
• I wreszcie skupienie się na potrzebach biznesowych i zarządzaniu budżetem (np. zwinna mind mapa budżetowa) – koncentracja na dostarczaniu wartości.

Świadomy klient to zaangażowany klient

Moim zdaniem edukacja klienta przy długoterminowej współpracy jest koniecznością, a co wiecej – jest inwestycją, która się zwróci. Im bardziej świadomy jest klient, tym bardziej efektywna i partnerska jest współpraca. Gdy klient rozumie pewne komplikacje lub odchylenia, które mogą się zdarzyć po drodze (co więcej – na pewno się zdarzą), nie reaguje na nie negatywnie. Oczywiście, jako wykonawca musimy pamiętać, że budżet ma swój limit i naszym zadaniem jest pomóc klientowi rozsądnie go wydać, angażując go jednocześnie w proces decyzyjny.

I na koniec mój “Manifest Estymowania Agile” :)

1. Zarządzanie budżetem ponad spędzanie wielu tygodni na szacowaniu. Estymacja nie pomoże klientowi w podjęciu decyzji strategicznej, którą jest niewątpliwie decyzja o rozpoczęciu projektu.
2. Edukowanie klienta ponad dobrze wyglądające ceny. Klient świadomie zarządza swoim budżetem i decyduje, za co płaci (nie tylko w kontekście wymagań funkcjonalnych, ale również jakości, skalowalności itp.)
3. Estymowanie zespołowe ponad prognozy jednoosobowe. Planowanie oparte jest na wzajemnym zobowiązaniu się członków zespołu (ang. Commitment Driven Sprint Planning) oraz wypełnienie luk w rozumieniu “co” i “jak” powinny być dostarczane
4. Zapewnienie wartości biznesowej ponad dostarczanie funkcji w oprogramowaniu. Jako wykonawca dbamy o zrozumienie czego biznes naprawdę potrzebuje i pomagamy klientowi w efektywnym wydaniu budżetu na oprogramowanie.