Eine bezahlte Discovery-Phase sollte mit Entscheidungen enden, nicht nur mit Dokumenten: was zuerst gebaut wird und was wegfällt, die wichtigsten Risiken und wie sie getestet wurden, eine Schätzung als Spanne mit ihren Annahmen und ein erster Meilenstein, der starten kann. Beurteilen Sie sie mit einem einzigen Test: Könnten Sie die Ergebnisse einem anderen Team geben und mit dem Bau beginnen, ohne von vorn anzufangen?
Discovery dient dazu, große Entscheidungen zu treffen, solange sie günstig sind
Discovery, auch Scoping oder Inception genannt, ist eine kurze, bezahlte Phase vor der Entwicklung einer Software. Ihre Aufgabe ist es, die Unsicherheit zu beseitigen, die Schätzungen unzuverlässig macht, und die großen Entscheidungen zu treffen, solange sie sich noch günstig ändern lassen. Eine Entscheidung auf dem Papier zu ändern kostet ein Gespräch; sie zu ändern, wenn der Code geschrieben ist, kostet Nacharbeit.
Frühe Softwareschätzungen haben eine große Spannweite und werden erst enger, wenn Entscheidungen Unsicherheit beseitigen, ein Effekt, der oft als Cone of Uncertainty (Trichter der Unsicherheit) bezeichnet wird. Besprechungen allein machen sie nicht enger. Discovery lohnt sich, wenn sie diese Entscheidungen erzwingt: was das Produkt zuerst können muss, welche Rahmenbedingungen feststehen und welche technischen Risiken real sind.
Vereinbaren Sie vor dem Start, was Sie erhalten
Kaufen Sie Discovery wie jede andere Leistung ein: feste Dauer, fester Preis, benannte Personen und eine schriftliche Liste der Ergebnisse. Kann ein Partner nicht sagen, was Sie am Ende in der Hand halten, kann die Phase in endlose Workshops abdriften. Ein vollständiger Satz von Ergebnissen umfasst in der Regel Folgendes.
- Eine Problembeschreibung: wer die Nutzer sind, was sie brauchen und wie Erfolg gemessen wird
- Den Umfang des ersten Release: was dazugehört, was nicht und was verschoben wird
- Die wichtigsten Nutzerwege, skizziert oder als Prototyp, wo sie unklar sind
- Einen Architekturentwurf: Hauptkomponenten, Integrationen, Daten und Hosting, mit den geprüften Optionen
- Ein Risikoregister, das ordnet, was das Projekt scheitern lassen könnte, und wie mit jedem Risiko umgegangen wird
- Eine Schätzung als Spanne mit ihren Annahmen und einen ersten Meilenstein mit Abnahmekriterien
- Ein Entscheidungsprotokoll, das festhält, was entschieden wurde, von wem und warum
Achten Sie auf Entscheidungen, nicht auf einen Stapel Dokumente
Ein Discovery-Bericht kann lang sein und trotzdem nichts entscheiden. Lesen Sie ihn auf Festlegungen hin: welche Funktionen im ersten Release sind und welche nicht, welche Technologie- und Hosting-Entscheidungen getroffen sind, welche Integrationen nötig sind und welche Fragen offenbleiben, jede mit einem Verantwortlichen und einem Termin.
Ein nützliches Signal ist, wovon der Partner abgeraten hat. Ist der Umfang am Ende größer als am Anfang und wurde nichts gestrichen, hat die Discovery vermutlich Ihre Wunschliste protokolliert, statt sie zu prüfen. Manchmal lautet die richtige Schlussfolgerung, ein bestehendes Produkt zu kaufen, weniger zu bauen oder gar nicht zu bauen, und eine gute Discovery-Phase sagt das.
Die riskantesten Annahmen sollten getestet, nicht nur aufgelistet werden
Jedes Projekt beruht auf einigen Annahmen, die alles ändern würden, wenn sie falsch wären: eine externe API, die die benötigte Operation nicht unterstützt, Daten, die unordentlicher sind als erwartet, ein Performance-Ziel, das das gewählte Design nicht erreichen kann, oder Nutzer, die ihre Arbeitsweise nicht ändern werden.
Bitten Sie den Partner, diese Annahmen früh zu benennen und die gefährlichsten während der Discovery zu testen, mit einem technischen Spike, einem klickbaren Prototyp oder einer Arbeitssitzung mit den Menschen, die das betreffende System betreiben. Ein getestetes Risiko ist eine Information. Ein nur aufgeschriebenes Risiko bleibt eine Vermutung.
Eine ehrliche Schätzung ist eine Spanne mit den zugehörigen Annahmen
Eine einzelne Zahl am Ende der Discovery verbirgt die verbleibende Unsicherheit. Verlangen Sie eine Spanne für das erste Release, aufgeschlüsselt nach Hauptkomponenten, mit den Annahmen, die sie nach oben oder unten verschieben würden. Zum Beispiel: Die Schätzung setzt voraus, dass die API des Zahlungsanbieters bereits Teilerstattungen unterstützt; falls nicht, kommt die separat aufgeführte Integrationsarbeit hinzu.
Fragen Sie, welche Teile der Schätzung fest sind und welche noch unsicher, und wie das Abrechnungsmodell mit jedem Teil umgeht. Feste Teile lassen sich zum Festpreis anbieten; unsichere brauchen ein Budget und einen Punkt, an dem Sie neu entscheiden. Der erste Meilenstein sollte so genau spezifiziert sein, dass er zum Festpreis geliefert werden könnte.
Halten Sie sich bei jedem Schritt einen Ausstieg offen
Discovery ist auch der günstigste Moment, um auszusteigen. Stellen Sie sicher, dass Ihnen alles gehört, was dabei entsteht, von Dokumenten und Diagrammen bis zu Prototypen und Code, und dass die Ergebnisse für jedes kompetente Team geschrieben sind, nicht nur für den Partner, der sie verfasst hat. Sie sollten frei sein, mit diesem Partner zu bauen, die Ergebnisse einem anderen Team zu übergeben, intern zu entwickeln oder aufzuhören.
Übertragen Sie denselben Gedanken auf den folgenden Plan: ein erster Meilenstein mit Abnahmekriterien, dann ein Entscheidungspunkt, an dem Sie weitermachen, den Kurs ändern oder die Zusammenarbeit beenden können. So starten wir Projekte bei SDK Enterprises: ein schriftlicher Umfang, ein fester erster Meilenstein und die namentlich benannten Entwickler, damit Sie den Plan sehen, bevor Sie sich auf ein größeres Budget festlegen. Wenn Sie nur Rat brauchen, erhalten Sie eine schriftliche Antwort, mit der Ihr eigenes Team arbeiten kann, ob Sie mit uns bauen oder nicht.
Sechs Fragen, die zeigen, ob sich die Discovery gelohnt hat
Prüfen Sie die Ergebnisse am Ende der Phase anhand dieser Fragen. Lautet die Antwort meist Ja, hat das Geld Klarheit gekauft. Lautet sie meist Nein, haben Sie für Workshops bezahlt.
- Könnte ein anderes Team auf Basis dieser Ergebnisse mit dem Bau beginnen, ohne die Discovery zu wiederholen?
- Hat der Partner mit Nutzern und mit den Menschen gesprochen, die die beteiligten Systeme betreiben, nicht nur mit dem Auftraggeber?
- Wurden die riskantesten Annahmen getestet und die Ergebnisse schriftlich festgehalten?
- Ist die Schätzung eine Spanne mit klaren Annahmen statt einer einzelnen Zahl?
- Wurde etwas gestrichen, verschoben oder infrage gestellt?
- Ist der erste Meilenstein genau genug spezifiziert, um ihn abnehmen oder ablehnen zu können?
Das Wichtigste in Kürze
- Kaufen Sie Discovery mit fester Dauer, festem Preis, benannten Personen und einer schriftlichen Liste der Ergebnisse ein.
- Beurteilen Sie die Ergebnisse nach den Entscheidungen, die sie enthalten, einschließlich dessen, was gestrichen wurde oder wovon abgeraten wurde.
- Die riskantesten Annahmen sollten während der Discovery getestet werden, nicht nur in einem Risikoregister stehen.
- Erwarten Sie die Schätzung als Spanne mit Annahmen und einen ersten Meilenstein, der genau genug spezifiziert ist, um ihn zu bepreisen.
- Sorgen Sie dafür, dass Ihnen jedes Ergebnis gehört, damit Sie mit diesem Partner, mit einem anderen Team oder gar nicht bauen können.
FAQ
Sollte Discovery bezahlt werden, oder kann ein Partner sie kostenlos machen?
Kostenloses Scoping ist Teil des Verkaufs und endet daher bei dem, was in ein Angebot passt. Eine bezahlte Discovery kauft Zeit, um Ihren Code zu lesen, mit Ihren Nutzern zu sprechen und Risiken zu testen, und Ergebnisse, die Ihnen gehören. Halten Sie die Phase kurz und zum Festpreis, damit die Verpflichtung klein bleibt.
Wie lange sollte eine Discovery-Phase dauern?
So lange, bis die Fragen beantwortet sind, die einer verlässlichen Schätzung im Weg stehen, und nicht länger. Vereinbaren Sie die Dauer vorab anhand der Größe des Produkts und der Zahl der beteiligten Systeme, und schließen Sie mit einer Entscheidung über den ersten Meilenstein ab, nicht mit einer Verlängerung der Discovery.
Was, wenn die Discovery zeigt, dass sich das Projekt nicht lohnt?
Dann hat sie ihre Aufgabe zu den geringstmöglichen Kosten erfüllt. Eine gute Discovery-Phase kann zu dem Schluss kommen, dass Sie besser ein bestehendes Produkt kaufen, eine kleinere erste Version bauen oder aufhören, und die Erkenntnisse behalten Sie in jedem Fall.