Zrobiłem ostatnio pewien eksperyment. Poprosiłem zespół o podzielenie feature'a na zadania maksymalnie czterogodzinne. Gdy to zrobili, ponownie poprosiłem, aby te czterogodzinne zadanie posortowali wg skali koszulkowej: S(mało pracy), M, L, XL(dużo pracy).

Ciekawostką, a zarazem przyczyną do powstania tego artykułu było, że zadania otrzymały rożne wartości na skali koszulkowej. Można by się spodziewać, że skoro startujemy z czterogodzinnymi zadaniami, to następnie zespół oszacuje na tę samą ilość pracy np. S albo M. Jednak nie - szacowania koszulkowe były zróżnicowane.

Happy paths

Po wnikliwszej odpytce okazało się, że gdy developorzy i developerki wyodrębniali zadania 4h, to każde z nich przyjmowało pomyślne założenia co do kontekstu zadań. Niektórym osobom brakowało wiedzy, niektóre zadania były obarczone jakąś niepewnością, bo coś musiało się stać, żeby zrobić to a tamto, jeszcze inne zależały od sukcesu kogoś innego. W każdym z przypadków przyszli wykonawcy założyli, że wszystko dookoła pójdzie jak pomaśle, i wtedy zadanie można będzie ogarnąć w 4h.

Jawne założenia

Kontekst: Jeśli musisz ofertować fixed-price, to poniższy tip może uratować ci skórę. Bywa, że na wycenę masz niewiele czasu, brakuje niektórych informacji potrzebnych wycenie, a klientowi musisz podać kwotę.

Wtedy: Dla każdej funkcjonalności jawnie podaj założenia, przy których wycena jest dla ciebie wiążąca. Rekomenduję robić to zespołowo, lub chociaż w 2-3 osoby.

Jawnie wyspecyfikuj założenia, na podstawie których przygotowujesz wycenę.

Konsekwencje Prawie na pewno w trakcie prac, klient będzie chciał wykreślać kolejne założenia. Jednak ponieważ będziesz mieć je jawnie spisane, bez większych przepychanek będzie można je wycenić.

Warianty Jeśli masz nieco więcej czasu, możesz przygotować kilka wersji wyceny przy coraz luźniejszych założeniach. Klienci lubią mieć pewien wybór (byle nie za duży).

Napisz, czego nie będzie

Kontekst Właściwie każdy klient, gdy kontraktujesz z nim funkcjonalności, coś sobie a ich temat wyobraża. Masz ograniczony wpływ na te wyobrażenia.

Wtedy Napisz co klient dostanie w funkcjonalności oraz to, czego nie dostanie - in scope, out of scope.

Jawnie wyspecyfikuj, co jest poza zakresem wycenionej funkcjonalności.

Konsekwencje Na samym początku odkryjesz i rozwiążesz te nieporozumienia, które są najtrudniejsze do obsługi, czyli związane z pieniędzmi.

.