Ocena prototypu

Historia, której efektem jest stwierdzenie: „wiemy już, co należy stworzyć”, a nie: „stworzyliśmy to”.

Prototyp ma na celu naukę, a nie praktyczne zastosowanie. Chodzi o to, aby odpowiedzieć na pytanie (czy ta interakcja wydaje się właściwa, czy to podejście da się skalować, czy ten interfejs API sprawdzi się) na tyle szybko, by można było zmienić kierunek działań, zanim zdecyduje się na jego wdrożenie. Zespoły, które szacują nakład pracy nad prototypami w taki sam sposób, jak nad funkcjami, otrzymują wynik, który prowadzi do sfinansowania niewłaściwego zakresu prac.

Drugi rodzaj niepowodzenia jest odwrotny: szacuje się, że prototyp będzie niewielki, dostarcza się coś, co „po prostu działa” w wystarczającym stopniu, a następnie wprowadza się to do produkcji, ponieważ harmonogram posunął się naprzód. Prototyp, który staje się produktem, jest najdroższym kodem w bazie kodu, ponieważ nikt nie zaplanował elementów, których w nim brakuje.

O czym się mówi w tym pomieszczeniu

Inżynier: „Mogę coś szybko przygotować w ciągu kilku dni”.

Wstęp: „Na jakie pytanie staramy się odpowiedzieć?”

PM: „Czy to trafi do klientów, czy ma charakter wyłącznie wewnętrzny?”

Wstęp: „Jeśli odpowiedź brzmi »tak«, to czy wyrzucamy to i budujemy od nowa?”

Inżynier: „Nigdy tego nie wyrzucamy”.

Pytania, które warto zadać przed głosowaniem

• Na jakie pytanie odpowiada prototyp i skąd będziemy wiedzieć, że uzyskaliśmy odpowiedź?
• Wyłącznie do użytku wewnętrznego czy w obecności klientów?
• Czy domyślnym rozwiązaniem jest „Throwaway” i czy zespół jest temu oddany?
• Czym jest przedział czasowy i co się dzieje po jego upływie?
• Jeśli to zadziała, jak wygląda droga od prototypu do kodu produkcyjnego?

Prawdziwym zagrożeniem jest podejście inżyniera oparte na zasadzie „nigdy niczego nie wyrzucamy”: należy zaplanować budżet na prototyp jako część rozwiązania, a skalowanie wersji produkcyjnej potraktować jako odrębny projekt, tak aby rozwiązanie jednorazowe nie stało się domyślnym wyborem.

Proszę opracować prototyp rozwiązania, a nie samego produktu, i zaplanować przebudowę, zanim harmonogram zrobi to za Państwa.

Podobnie jak w przypadku szacowania skokowego wzrostu nakładu pracy związanego z badaniami, efektem końcowym jest wiedza; należy traktować te sytuacje w ten sam sposób. Proszę zapoznać się z typowymi błędami w planowaniu metodą „planning poker” dotyczącymi wkradania się elementów badawczych do opisu zadania oraz z innymi przykładami udanych szacunków.