Kostenvoranschlag für einen Prototyp
Wie man einen Prototyp einschätzt: Es handelt sich um ein Ergebnis, das zum Lernen und nicht zum Einsatz gedacht ist. Wie man verhindert, dass aus dem „Wegwerfprodukt“ der Produktionscode wird, mit dem niemand gerechnet hat.
Die Geschichte, deren Ergebnis lautet: „Wir wissen nun, was wir entwickeln müssen“, und nicht: „Wir haben es entwickelt.“
Ein Prototyp ist auf das Lernen ausgelegt, nicht auf den Einsatz. Es geht darum, eine Frage (Fühlt sich diese Interaktion richtig an? Lässt sich dieser Ansatz skalieren? Wird diese API den Anforderungen standhalten?) so schnell zu beantworten, dass Sie die Richtung ändern können, bevor Sie sich endgültig darauf festlegen. Teams, die Prototypen auf dieselbe Weise einschätzen wie Funktionen, erhalten einen Wert, der die falsche Art von Arbeit finanziert.
Die andere Fehlerquelle ist das Gegenteil: Man plant einen Prototyp in kleinem Umfang, liefert etwas aus, das „gerade so funktioniert“, und überführt dieses Produkt dann in die Produktion, weil der Zeitplan voranschreitet. Der Prototyp, der zum Produkt wird, ist der teuerste Code im Code-Repository, da niemand die Teile einkalkuliert hat, die fehlen.
Was in dem Raum gesagt wird
Ingenieur: „Ich kann in ein paar Tagen etwas auf die Beine stellen.“
Einleitung: „Welche Frage versuchen wir zu beantworten?“
PM: „Ist das für Kunden bestimmt oder nur für den internen Gebrauch?“
Leitgedanke: „Wenn die Antwort ‚Ja‘ lautet, werfen wir es dann weg und fangen von vorne an?“
Ingenieur: „Wir werfen es niemals weg.“
Fragen, die man sich vor der Stimmabgabe stellen sollte
- Welche Frage beantwortet der Prototyp, und woran erkennen wir, dass wir eine Antwort haben?
- Nur intern oder vor Kunden?
- Ist dies standardmäßig als „Wegwerfartikel“ vorgesehen, und steht das Team dazu?
- Wie lang ist die Zeitvorgabe, und was geschieht am Ende dieser Zeitspanne?
- Falls es funktioniert, wie sieht der Weg vom Prototyp zum Produktionscode aus?
Das Motto des Ingenieurs „Wir werfen es niemals weg“ birgt das eigentliche Risiko: Planen Sie den Prototyp als Lösung ein und gestalten Sie die Serienfertigung als eigenständiges Projekt, damit der Wegwerfansatz nicht automatisch zum Standard wird.
Entwerfen Sie einen Prototyp für die Lösung, nicht für das Endprodukt, und planen Sie die Neugestaltung, bevor der Zeitplan dies für Sie vorsieht.
Genau wie bei der Schätzung eines Forschungsschubs ist das Ergebnis Wissen; behandeln Sie beides auf dieselbe Weise. Lesen Sie mehr zu häufigen Fehlern beim Planning Poker, bei denen sich die Recherche in die Story einschleicht, sowie zu den anderen praktischen Schätzbeispielen.