Wie Uber, nur für... So schreibst du ein Software-Briefing
Ein-Satz-Briefing, 80-Seiten-Lastenheft, Screenshot vom Mitbewerber: ein Feldführer - und wie dein Software-Briefing zu einer echten Schätzung führt.
Jedes Softwareprojekt beginnt mit einem Briefing. Manche beginnen mit einem Satz, den jemand für ein Briefing gehalten hat. In unserer Branche ist der häufigste davon kurz, selbstbewusst und enthält einen Fahrdienst.
„Wir brauchen sowas wie Uber, nur für Hundefriseure.“
Wir haben nichts gegen Hundefriseure. Wir haben nichts gegen Uber. Wir haben nur Fragen - ungefähr vierzig - und die erste ist immer dieselbe: Welcher Teil von Uber? Die Karte? Das Bezahlen? Die Preise, die bei Regen steigen? Der Marktplatz dahinter, der eigentlich zwei Apps, eine Disposition und ein Zahlungssystem sind, die so tun, als wären sie eins? Oder doch nur das kleine Auto, das über den Bildschirm fährt, weil es so nett aussieht?
Das hier ist ein Feldführer durch die Briefings, die uns in freier Wildbahn begegnen: warum jedes davon eine seriöse Schätzung unmöglich macht - und was du stattdessen schreiben kannst. Am Ende gibt’s eine Vorlage zum Kopieren. Wir verraten’s niemandem.
Art 1: Das Ein-Satz-Briefing
Lebensraum: Kontaktformular, LinkedIn-Nachricht, Sprachnachricht beim Einparken.
„Brauche App fürs Geschäft, was kostet das?“
Das ist ungefähr so, als würdest du beim Baumeister anrufen und fragen, was ein Haus kostet. Die ehrliche Antwort liegt irgendwo zwischen Gartenhütte und Landeskrankenhaus. Wer auf einen einzigen Satz mit einer einzigen Zahl antwortet, ist entweder Hellseher oder holt sich die Differenz später - per Change Request, mit Zinsen.
Falsch ist das Ein-Satz-Briefing trotzdem nicht. Es ist nur der erste Satz. Wir freuen uns ehrlich darüber, die meisten guten Projekte fangen genau so an. Man muss nur wissen: Es eröffnet ein Gespräch, kein Angebot.
Art 2: Das 80-Seiten-Lastenheft vom Komitee
Lebensraum: ein Netzlaufwerk, Dateiname Lastenheft_FINAL_v7_wirklich_final_Aenderungen-MK.docx.
Verfasst von sechs Abteilungen über neun Monate. Enthält zwölf Seiten Firmengeschichte, ein Glossar, eine RACI-Matrix, drei widersprüchliche Definitionen von „Kunde“ - und auf Seite 61, eingeklemmt zwischen Compliance-Anhang und einem Stockfoto mit Handschlag, die eine Anforderung, auf die es wirklich ankommt.
Jede Abteilung hat ihr Feature untergebracht. Keine durfte sagen, welches davon verzichtbar ist. Also ist alles Priorität eins - und damit nichts.
Die Länge ist nicht das Problem. Das Problem ist, dass ein Briefing, das alle glücklich machen soll, einen politischen Kompromiss beschreibt, kein Produkt. Wir lesen alle 80 Seiten, versprochen. Und dann fragen wir, welche drei Dinge das System am ersten Tag können muss. Die Stille danach ist meistens der aufschlussreichste Moment des ganzen Projekts.
Art 3: Der Screenshot vom Mitbewerber
Lebensraum: eine E-Mail ohne Text, ein Anhang, IMG_4471.png.
„So wie das, nur besser.“
Ein Screenshot zeigt, wie ein Produkt aussieht. Er sagt nichts über das Admin-Backend dahinter, den Zahlungsanbieter, die fünf Schnittstellen, das Support-Team oder die Jahre an Feinschliff, die es so einfach wirken lassen. Wer die Fassade abfotografiert, hat noch keine Installationen.
Schick trotzdem Screenshots - mit je einer Zeile, was dir daran gefällt. „Der Checkout passt auf einen Bildschirm“ ist eine Anforderung. „So wie das“ ist ein Moodboard.
Art 4: „Das Budget ist flexibel“
Lebensraum: das erste Gespräch, vorgetragen mit selbstbewusstem Lächeln.
Übersetzung: Es gibt ein Budget, es ist nicht flexibel, und wir finden die genaue Zahl heraus, indem wir etwas darüber vorschlagen.
Wir verstehen, warum man das Budget versteckt. Die Sorge: Die Agentur schätzt dann einfach genau bis zu der Zahl, die sie gehört hat. Aber ohne Rahmen planen wir im Dunkeln. Ein Buchungssystem für zwanzigtausend kann ein solides, fokussiertes Werkzeug sein. Eines für zweihunderttausend ist etwas ganz anderes. Beides sind gute Antworten - nur auf unterschiedliche Fragen. Mit einem Rahmen können wir das Beste vorschlagen, das hineinpasst, statt eines wunderschönen Plans, den du dann höflich ablehnst.
Was in ein gutes Software-Briefing gehört
Jetzt der Teil unter den Witzen. Ein Briefing, das zu einer realistischen Schätzung führt, hat meistens ein bis zwei Seiten und beantwortet sieben Fragen.
1. Das Problem, nicht die Lösung. „Unsere Disponenten telefonieren täglich zwei Stunden den Fahrern hinterher, um Abholungen zu bestätigen“ ist besser als „Wir brauchen eine App mit Push-Benachrichtigungen“. Das Erste lässt uns die günstigste Lösung finden - vielleicht eine App, vielleicht eine SMS, vielleicht eine Tabelle mit besserer Formel. Das Zweite legt dich auf eine App fest, bevor jemand gefragt hat, ob eine App überhaupt die Antwort ist.
2. Wer die Nutzer sind. Büro am Desktop? Leute auf der Baustelle, mit Handschuhen und schlechtem Netz? Kunden, die es einmal im Jahr öffnen? Zehn Nutzer und zehntausend Nutzer sind verschiedene Systeme mit verschiedenen Preisen, auch wenn die Screens gleich aussehen.
3. Die drei Dinge, die es am ersten Tag können muss. Nicht zwanzig. Drei. Alles andere kommt auf die „Später“-Liste - und die ist kein Friedhof, sondern Phase zwei. Keine andere Frage hilft einer Schätzung so sehr wie diese.
4. Bestehende Systeme, mit denen es reden muss. Buchhaltung, das alte ERP, Zahlungsanbieter, CRM, die Excel-Liste, von der insgeheim alle abhängen. An Schnittstellen sterben Schätzungen leise, also nenn sie früh, auch wenn du nicht sicher bist, ob sie wichtig sind. „Wir haben so ein Rechnungsprogramm, der Gerhard weiß das“ ist für den Anfang eine völlig legitime Antwort.
5. Die Deadline - und warum. „Vor der Messe am 14. März“ ist eine Deadline. „Asap“ ist ein Gefühl. Wenn wir den Grund kennen, können wir sagen, was bis dahin live gehen kann und was einen Monat später nachkommt, ohne dass es jemand merkt.
6. Ein Budgetrahmen. Siehe Art 4. Ein Rahmen reicht. „Zwischen 15 und 30 Tausend“ genügt, damit wir sagen können, was reinpasst, was nicht und wo die Kompromisse liegen.
7. Woran du Erfolg erkennst. Weniger Anrufe. Bestellungen in Minuten statt in Stunden. Ein Launch, der keine Pressemitteilung braucht, nur einen ruhigen Montag. Wenn du beschreiben kannst, woran du merkst, dass es funktioniert, können wir darauf hinbauen - und du hast einen Schiedsrichter, wann immer zwei Features um dieselbe Woche streiten.
Das war’s. Was fehlt: Tech-Stack, Datenbank, Wireframes und das Wort „Blockchain“. Wenn du dazu Meinungen hast, gern rein damit. Aber das ist unser Job, und die meisten Briefings sind ohne diese Dinge besser.
Warum du so eine bessere Schätzung bekommst
Software-Schätzungen gehen vor allem aus einem Grund schief: Das, was geschätzt wurde, war nicht das, was gebaut wurde. Irgendwo zwischen Briefing und Launch ist aus dem „einfachen Buchungsformular“ ein Kalender mit Erinnerungen, Stornos, Rückerstattungen und Dienstplan geworden. Für irgendwen war jedes davon selbstverständlich. Aufgeschrieben hat es niemand.
Ein Briefing mit Problem, Nutzern, Must-haves und Schnittstellen hält den Umfang nicht auf. Aber alle sehen, wenn er sich bewegt - und können bewusst entscheiden.
Ob Webanwendung, App oder der Ersatz für das ERP, das von einer heldenhaften Excel-Datei zusammengehalten wird - die Fragen bleiben dieselben.
Die Briefing-Vorlage zum Kopieren
Füll aus, was du weißt, lass leer, was du nicht weißt. Leer ist auch eine Information.
SOFTWARE-BRIEFING
Das Problem: Was heute weh tut, in ein, zwei Sätzen.
Nutzer: Wer, wie viele, auf welchen Geräten.
Muss am 1. Tag: 1.
2.
3.
Später, vielleicht: Die Nice-to-haves. Sei ehrlich.
Redet mit: Bestehende Systeme, Tools, Excel-Listen.
Deadline: Datum, und warum genau dieses.
Budgetrahmen: Von ... bis ...
Erfolg heißt: Woran wir merken, dass es funktioniert.
Nicht "wie Uber": Außer es ist wirklich wie Uber. Kurz gesagt
Ein gutes Briefing ist weder lang noch hübsch. Es ist ehrlich beim Problem, konkret bei den ersten drei Dingen und offen bei Zeit und Geld. Schreib das, und wer es bekommt, kann dir eine echte Zahl nennen statt einer Spanne, in der man einen Reisebus parken könnte.
Und wenn du gerade nur den einen Satz hast - auch gut. Schick uns den Satz. Wir bringen die vierzig Fragen mit. Nach Uber fragen wir nur ein einziges Mal.