Ocena prototypu

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

Prototyp ma na celu naukę, a nie praktyczne zastosowanie. Chodzi o to, by odpowiedzieć na pytania — czy ta interakcja wydaje się właściwa, czy to podejście da się skalować, czy ten interfejs API się sprawdzi — na tyle szybko, by można było zmienić kierunek działań, zanim się na to zdecyduje. 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, dostarcza się coś, co „po prostu działa” w wystarczającym stopniu, a następnie wprowadza się to do produkcji, ponieważ harmonogram poszedł dalej. 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 jest przeznaczone wyłącznie do użytku wewnętrznego?”

Wstęp: „Jeśli odpowiedź brzmi »tak«, to czy wyrzucamy to i zaczynamy 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?
• Domyślnie jest to rozwiązanie jednorazowe — czy zespół jest zdecydowany to realizować?
• 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.

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

Podobnie jak w przypadku szacowania skoku badawczego, efektem końcowym jest wiedza; należy traktować te sytuacje w ten sam sposób. Proszę zapoznać się z typowymi błędami w planowaniu pokerowym, dotyczącymi wkradania się elementów badawczych do opisu zadania, oraz z innymi sprawdzonymi przykładami szacowania.