Entwicklungsbrief - 15 Fragen an den Auftraggeber

Ein guter Entwicklungsbrief spart Wochen an Abstimmung und schützt das Budget vor „und das noch dazu“. Ohne Antworten auf Grundfragen rät das Team Anforderungen und der Auftraggeber wundert sich über Zeit und Preis. Unten - 15 Fragen, die vor Angebot und Kick-off gestellt werden sollten. Die Antworten machen aus einer Idee einen klaren Scope, keine Wunschliste.

• Wozu der Brief - Ziel, Grenzen und Erfolgskriterien festhalten
• Wann fragen - vor dem Angebot und vor dem Kick-off
• Wer antwortet - Entscheider und Product Owner, nicht „jeder ein bisschen“
• Was Sie bekommen - klarer Scope, realistischer Zeitplan, transparentes Budget
• Regel - keine Antwort = Risiko für Nacharbeit und versteckte Kosten

Warum den Brief vor dem Start sammeln

Website, Service oder Integration scheitern fast immer an Unklarheit, nicht am Code. Ist das Ziel unscharf, wechseln Prioritäten wöchentlich und „must-have“ kommt erst am Ende - steigen Zeit und Kosten.

Der Brief ist keine Bürokratie. Er ist ein kurzer Vertrag über den Sinn des Projekts: was wir bauen, für wen, mit welchem Ergebnis, unter welchen Grenzen. Je früher diese Fragen geklärt sind, desto genauer die Schätzung und desto ruhiger beide Seiten.

15 Fragen an den Auftraggeber

1. Welches Geschäftsproblem lösen wir?

Nicht „wir brauchen eine Website“, sondern was jetzt wehtut: wenige Leads, Chaos bei Anfragen, manuelle Prozesse, veralteter Katalog. Das Problem bestimmt Architektur und Feature-Prioritäten.

2. Wer ist die Zielgruppe und was ist ihr Hauptszenario?

Wer ist der Nutzer: B2B-Einkäufer, Retail-Kunde, Mitarbeiter, Partner. Ein Hauptszenario zählt mehr als zehn Nebenszenarien.

3. Woran erkennen wir den Projekterfolg?

Messbare Kriterien braucht es: Lead-Zahl, Conversion, Bearbeitungszeit von Aufträgen, weniger Fehler, schnellere Content-Publikation. Ohne KPI bleibt „fertig“ subjektiv.

4. Welcher Zeitrahmen gilt - und gibt es eine harte Deadline?

Ein Launch zur Messe, Saison oder Produktfreigabe ändert den Plan: MVP jetzt oder voller Scope später. Deadline ohne Prioritäten bedeutet meist Nacharbeit.

5. Welcher Budgetkorridor ist realistisch?

Ein Budgetkorridor hilft, unrealistischen Scope früh zu schneiden. Eine ehrliche Spanne schlägt „ungefähr günstig“ ohne Zahlen.

6. Was existiert schon: Website, CRM, ERP, APIs, Content?

Inventar spart Geld. Integration eines lebenden CRM und Katalog-Migration sind eigene Volumen, nicht „eine Kleinigkeit am Ende“.

7. Welche Integrationen sind zum Start Pflicht?

Zahlungen, Lager, 1C/ERP, E-Mail, Analytics, Messenger. Die Integrationsliste beeinflusst den Zeitplan stärker als die Framework-Wahl.

8. Gibt es Vorgaben zu Stack, Hosting und Sicherheit?

Firmenstandards, On-Premise, Security-Anforderungen, Cloud-Verbote - alles gehört vor der Schätzung in den Brief, nicht nach der Vendor-Wahl.

9. Wer entscheidet und wer freigibt Etappen?

Ein Entscheider beschleunigt das Projekt. Läuft Freigabe durch fünf Abteilungen ohne Owner - planen Sie Puffer für Warten und Meinungswechsel.

10. Was ist Must-have in v1, und was kann warten?

Trennen Sie „nötig für den Launch“ von „später nice“. Ein MVP mit klarem Kern liefert schneller Wert und kostet weniger als „alles auf einmal“.

11. Gibt es Referenzen „so soll es sein“ und Anti-Beispiele „so nicht“?

Links zu Sites und Produkten sparen Stunden UX- und Ton-Diskussionen. Anti-Beispiele helfen auch: sie markieren Geschmacks- und Erwartungsgrenzen.

12. Wer liefert Content, Texte, Fotos und Zugänge?

Content wird oft zum Engpass. Kommen Texte und Zugänge spät - stehen Design und Entwicklung still.

13. Welche Nutzerrollen und Zugriffslevel braucht es?

Gast, Kunde, Manager, Admin, Partner - unterschiedliche Panels und Rechte. Das Rollenmodell vor dem Screen-Design beschreiben.

14. Gibt es rechtliche, Datenschutz- oder Branchenanforderungen?

DSGVO / lokale Privacy-Gesetze, Gesundheit, Finanzen, öffentlicher Sektor - ändern Speicherarchitektur, Einwilligungen, Logs und Verträge. Das lässt sich nicht „später ergänzen“.

15. Wer betreut das Produkt nach dem Launch?

Updates, Monitoring, Content-Änderungen, Incident-Reaktion. Fehlt Support im Plan - altert ein laufendes Produkt schnell.

So nutzen Sie die Antworten in der Praxis

Antworten auf eine Seite verdichten:

Aus dieser Tabelle lassen sich Angebot und Roadmap leicht bauen. Ist eine Zelle leer - das ist kein „Detail für später“, sondern ein offenes Risiko.

Typische Fehler im Brief

• Einen Wunsch („soll schön werden“) mit einem Ergebnis („Leads um 30% steigern“) verwechseln.
• Integrationen als „einen Button“ behandeln, nicht als eigenen Arbeitsstrom.
• Keinen Product Owner auf Kundenseite benennen.
• Must-have aus dem gesamten Backlog ohne Priorisierung bauen.
• Support ignorieren: Launch ohne Support-Owner = Schuld ab Tag eins.

Fazit

Ein Entwicklungsbrief sind 15 kurze, aber klare Fragen zu Ziel, Zielgruppe, KPIs, Zeit, Budget, Integrationen, Grenzen, Rollen und Support. Je vollständiger die Antworten vor dem Start, desto genauer die Schätzung und desto weniger Überraschungen unterwegs.

Wenn Sie Hilfe beim Brief, bei der MVP-Priorisierung oder bei der Schätzung anhand Ihrer Antworten brauchen - melden Sie sich.

Häufig gestellte Fragen

Wie lange dauert das Ausfüllen des Briefs?

Meist 1-2 Werktage, wenn es einen Entscheider und Zugang zu Basisdaten gibt. Schwerer wird es, wenn Entscheidungen über Abteilungen verteilt sind: dann schlägt ein kurzer Workshop von 1-2 Stunden Wochen E-Mail.

Kann man ohne Brief schätzen?

Eine Spanne von-bis ja, keine präzise Summe. Ohne Ziel, Integrationen und Erfolgskriterien schwankt die Schätzung fast immer. Der Brief reduziert Unsicherheit und schützt beide Seiten vor falschen Erwartungen.

Ersetzt der Brief die technische Spezifikation?

Nein - der Brief ist der Einstieg in die Spezifikation. Er fixiert Sinn und Grenzen. Die Spezifikation beschreibt dann Screens, Daten, APIs, Rollen und Abnahmekriterien. Ohne Brief bläht sich die Spec oft auf und ändert sich unterwegs.

Was tun, wenn der Kunde das Budget nicht kennt?

Einen Korridor und Scope-Optionen anbieten: MVP / Standard / erweitert. So lässt sich realistischer Scope leichter wählen. „Budget unbegrenzt“ heißt in der Praxis fast immer: Prioritäten sind noch nicht abgestimmt.

Muss der Brief während der Entwicklung aktualisiert werden?

Ja, wenn sich Ziel, Deadline oder Must-have ändern. Der Brief ist ein lebendiges Grenzdokument. Jede Scope-Erweiterung muss Zeit oder Budget explizit ändern - sonst arbeitet das Team auf Kredit.