Bevor Sie bauen

Was ist eine Software-Discovery-Phase und warum kommt sie vor dem Code?

Eine Discovery-Phase ist die Arbeit, die Sie vor jedem Code leisten, um aus einer groben Idee einen baubaren Plan zu machen. Sie gehen mit klaren Anforderungen, einer vorgeschlagenen Architektur, einer scoped Roadmap und einem Test Ihrer riskantesten Annahme hinaus. Es ist die günstigste Stelle, um herauszufinden, dass Sie gerade das Falsche bauen wollen. Sie zu überspringen ist die teuerste Abkürzung in Software, denn jede falsche Annahme wird in Code gegossen und später bezahlt.

Dreißig-Minuten-Call buchen

Kurze Antwort

Eine Discovery-Phase verwandelt eine Idee in einen klaren Scope, eine Architektur und eine Roadmap und testet Ihre riskanteste Annahme, bevor eine Zeile Produktionscode geschrieben wird.

Passt für

  • Gründer mit einer Idee, aber noch keiner festen Spezifikation
  • Teams, die kurz davor sind, ein echtes Budget für einen Build zuzusagen
  • Produkte mit einer Annahme, die das Ganze versenken könnte
  • Alle, die einen Festpreis wollen, dem sie vertrauen können
  • Stakeholder, die einen Plan brauchen, auf den sie sich einigen

Passt nicht für

  • Eine winzige Änderung an einem bestehenden, gut verstandenen System
  • Arbeit, deren Scope bereits vollständig definiert und validiert ist
  • Käufer, die ungeachtet des Risikos an Tag eins Code wollen
  • Wegwerf-Experimente ohne Weg in die Produktion
// 01

Die Optionen im Vergleich

Was sich ändert, wenn Sie zuerst Discovery durchführen.

Dimension Mit Discovery Ohne Discovery
Scope

Vor dem Bauen definiert und vereinbart.

Mitten im Build entdeckt, wenn Änderungen teuer sind.

Bepreisung

Ein Festpreis kann mit Zuversicht kalkuliert werden.

Schätzungen sind Vermutungen, die nach oben abdriften.

Riskanteste Annahme

Früh getestet, solange es günstig ist, falschzuliegen.

In der Produktion getestet, wo Falschliegen teuer ist.

Architektur

Bewusst für die echten Anforderungen gewählt.

An Tag eins gewählt, dann später dagegen angekämpft.

Stakeholder-Ausrichtung

Alle nehmen denselben Plan ab.

Meinungsverschiedenheiten tauchen auf, nachdem Code existiert.

Typisches Ergebnis

Ein Build, der zum Bedarf passt.

Nacharbeit, Scope Creep und überraschende Kosten.

// 02

Wo Wavect hier steht

Die meiste Software wird nicht durch schlechten Code getötet. Sie wird dadurch getötet, dass das Falsche gut gebaut wird.

Discovery ist, wo wir das herausfinden, bevor es teuer wird. Wir nageln Anforderungen fest, schlagen eine Architektur vor, scopen eine Roadmap und testen die eine Annahme, die das Projekt versenken würde, wenn sie falsch ist. Ein paar Wochen hier sparen routinemäßig Monate später.

Es macht auch den Rest des Engagements ehrlich. Mit einem klaren Scope auf dem Tisch können wir einen Festpreis als Werkvertrag kalkulieren und dahinterstehen. Ohne Discovery ist jede feste Zahl eine Vermutung. Discovery startet ab EUR 3,500, und es ist die günstigste Versicherung, die Sie für das ganze Projekt kaufen.

// 03

Kosten, Risiko und Zeitrahmen

Kosten Ab EUR 3,500Ein Bruchteil eines vollen Builds, und der Input, der einen Festpreis möglich macht.
Risiko Mit Absicht vorgezogenSie finden die falschen Annahmen, solange sie noch günstig zu beheben sind.
Zeitrahmen Wochen, nicht MonateKurz und fokussiert. Es verkürzt den darauf folgenden Build.
// 04

Wo das meistens schiefgeht

  • Discovery überspringen, um ein paar Wochen zu sparen, und dann Monate an Nacharbeit verlieren.
  • Discovery als Dokument-Übung behandeln, statt die riskanteste Annahme zu testen.
  • Architektur an Tag eins wählen und für den Rest des Builds dagegen ankämpfen.
  • Stakeholder uneinig bleiben lassen, bis bereits Code existiert.
  • Einen Festpreis auf einen unentdeckten Scope kalkulieren und dann zusehen, wie er abdriftet.
  • Features bauen, die niemand validiert hat, weil die Idee nie unter Druck getestet wurde.
// 05

Die Checkliste

Eine Discovery-Phase sollte Sie mit all dem hinterlassen.

  • Klare, schriftliche Anforderungen, auf die Sie und das Team sich einigen.
  • Eine vorgeschlagene Architektur, für Ihre echten Bedürfnisse gewählt, nicht nach Standardwerten.
  • Eine scoped Roadmap mit Reihenfolge und grobem Aufwand.
  • Ein Test Ihrer riskantesten Annahme, früh durchgeführt.
  • Ein Scope, klar genug, um einen Festpreis dagegen zu kalkulieren.
  • Dokumentierte Stakeholder-Ausrichtung darüber, was gebaut wird.
  • Eine ehrliche Einschätzung, was unsicher ist und was nicht.
// 06

Wie das in unserer Arbeit aussieht

Wo ein klarer Plan vorab einen schnellen Build möglich machte.

// 07

Wann das passt, und wann nicht

// 01

Wann Wavect die richtige Wahl ist

  • Sie haben eine Idee, aber noch keine Spezifikation, auf die Sie ein Budget wetten würden.
  • Sie wollen einen Festpreis, dem Sie danach tatsächlich vertrauen können.
  • Sie haben eine riskante Annahme, die vor dem Code getestet werden sollte.
  • Sie wollen Gründer, die den Plan hinterfragen, nicht nur den Auftrag annehmen.
// 02

Wann wir nicht die richtige Wahl sind

  • Ihr Scope ist bereits vollständig definiert und validiert.
  • Sie machen eine kleine Änderung an einem System, das Sie gut verstehen.
  • Sie wollen an Tag eins Code und akzeptieren das damit verbundene Risiko.
  • Sie sehen Planung als Overhead statt als Versicherung.

Ein paar Wochen Discovery sind der günstigste Weg herauszufinden, dass Sie das Richtige bauen.

// 08
// 09

Häufige Fragen

Nein. Anforderungen sind Teil davon, aber der Punkt ist, Ihre riskanteste Annahme zu testen und eine Architektur vorzuschlagen, nicht nur Dinge aufzuschreiben. Ein Dokument, das niemand unter Druck getestet hat, ist keine Discovery.
Wochen, nicht Monate. Sie ist mit Absicht kurz und fokussiert. Das Ergebnis ist ein Plan, klar genug, um danach zu bauen und zu bepreisen.
Discovery startet ab EUR 3,500. Es ist ein Bruchteil eines vollen Builds, und es ist das, was einen vertrauenswürdigen Festpreis möglich macht.
Sie können, aber es ist meist die teuerste verfügbare Abkürzung. Falsche Annahmen werden in Code gegossen und in Nacharbeit bezahlt. Discovery verkürzt die Gesamtzeit normalerweise, statt sie zu verlängern.
Die Anforderungen, die vorgeschlagene Architektur, die Roadmap und die Erkenntnisse aus dem Test Ihrer riskantesten Annahme. Es gehört Ihnen, um damit weiterzumachen, mit uns oder nicht.
Zuletzt geprüft: vonKevin Riedl wiki ↗
Dreißig-Minuten-Call buchen