Ocena prototypu

Historia, której rezultatem 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 podejmie się ostateczną decyzję. Zespoły, które szacują nakład pracy nad prototypami w taki sam sposób, jak szacują nakład pracy nad funkcjami, otrzymują wynik, który prowadzi do sfinansowania niewłaściwego rodzaju prac.

Drugi rodzaj niepowodzenia jest odwrotny: szacuje się prototyp jako niewielki, wprowadza się na rynek rozwiązanie, które „po prostu działa” w wystarczającym stopniu, a następnie przenosi się je do środowiska produkcyjnego, ponieważ harmonogram poszedł 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 oddaniem głosu

• 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 jednorazowe wykorzystanie, 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 produkcji potraktować jako odrębny projekt, tak aby rozwiązanie jednorazowe nie stało się domyślnym wyborem.

Opracujcie prototyp rozwiązania, a nie samego produktu, i zaplanujcie przebudowę, zanim harmonogram zrobi to za Państwa.

Podobnie jak w przypadku szacowania skoku nakładu pracy związanego z badaniami, efektem końcowym jest wiedza; należy traktować je w ten sam sposób. Proszę zapoznać się z typowymi błędami w planowaniu metodą „planning poker”, wynikającymi z wplątania elementów badawczych w opisy zadań, a także z innymi sprawdzonymi przykładami szacowania.