Ein gutes Projekt-Briefing erklärt, wer Unterstützung braucht, was diese Menschen erledigen müssen und woran man einen Erfolg erkennt. Ein paar klare Absätze, eine grobe Skizze und ein konkretes Beispiel reichen uns als Ausgangspunkt.
Mit diesem Kontext stelle ich Rückfragen und grenze die Arbeit gemeinsam mit Ihnen ab, bevor ich Umfang und Zeitplan vorschlage. Dieser Leitfaden zeigt, was hineingehört, am Beispiel eines erfundenen Buchungsprodukts. Dieselben Fragen gelten für eine neue App, einen Bot oder eine Funktion in einem bestehenden Produkt.
Beginnen Sie mit dem Problem und den Menschen
Beschreiben Sie, wer das Produkt nutzen wird, was diese Personen erreichen wollen und wie sie es heute tun. Für unser Buchungsbeispiel: „Kunden schreiben unserem Team, um einen Termin anzufragen. Mitarbeitende prüfen einen gemeinsamen Kalender, schicken einen Zahlungslink und bestätigen jede Buchung von Hand.“ Daraus geht hervor, welche Arbeit die Software unterstützen muss.
Nennen Sie das Ergebnis, das Sie sehen möchten. Das können weniger Handgriffe sein, ein funktionierender Buchungsablauf oder eine Möglichkeit für Kunden, ihre Bestellung zu verfolgen. Wenn Sie heute schon etwas messen, teilen Sie die Zahl. Wenn nicht, beschreiben Sie, wie ein gutes Ergebnis aussehen würde.
Spielen Sie eine wichtige Aufgabe durch
Wählen Sie eine Aufgabe, auf die es ankommt, und beschreiben Sie sie von Anfang bis Ende. Zum Beispiel: Ein Kunde wählt eine Leistung, sucht sich einen freien Termin aus, bezahlt und erhält eine Bestätigung. Danach kann eine Administratorin die Buchung einsehen oder stornieren.
Nennen Sie auch die Ausnahmen. Was passiert, wenn die Zahlung fehlschlägt, der Kunde es sich anders überlegt oder zwei Personen denselben Termin wählen? Sie müssen nicht jeden Fall selbst lösen. Wenn Sie die Frage aufwerfen, finden wir die Arbeit, bevor wir uns auf einen Zeitplan festlegen.
Legen Sie fest, was die erste Version braucht
Trennen Sie, was für eine erste brauchbare Version nötig ist, von dem, was später folgen kann. Ein Buchungsprodukt braucht zum Start vielleicht einen Zahlungsanbieter, während Abos und Empfehlungsprämien warten können. Ihre Prioritäten helfen mir, eine Version vorzuschlagen, die schon für sich genommen nützlich ist.
Hinter einem Funktionsnamen können mehrere Entscheidungen stecken. Bei „Kundenkonten“ sagen Sie mir, wer sich registrieren kann, was die Person sehen darf, ob Mitarbeitende andere Rechte haben und was passiert, wenn jemand den Zugang verliert. Diese Punkte dürfen auch als offene Fragen stehen bleiben, die wir gemeinsam klären.
Schreiben Sie auf, woran Sie erkennen, dass eine Funktion fertig ist. „Buchungs-E-Mails versenden“ lässt Raum für unterschiedliche Erwartungen. Klarer ist: „Nach einer erfolgreichen Zahlung erhält der Kunde eine E-Mail mit Buchungsnummer, Datum und Hinweisen zur Stornierung.“
Solche Prüfpunkte nennt man oft Akzeptanzkriterien. DerLeitfaden von GOV.UK zu User Stories beschreibt dieselbe Idee: Formulieren Sie das Bedürfnis der Nutzer und listen Sie dann die Ergebnisse auf, an denen man erkennt, dass es erfüllt ist.
Teilen Sie, was es schon gibt
Ihre aktuelle Website oder App und ob sie bereits genutzt wird.
Designs, Markenmaterial, Inhalte und Beispiele für Oberflächen, die Ihnen gefallen. Erklären Sie, was Ihnen an jedem Beispiel gefällt.
Dienste, die an das Produkt angebunden werden müssen, etwa Zahlungen, E-Mail, ein CRM oder ein Telegram-Bot.
Vorhandene Daten, die übernommen werden müssen, und wem die betreffenden Konten gehören.
Rahmenbedingungen wie benötigte Sprachen, Geräte, Anforderungen an Barrierefreiheit oder eine bereits getroffene Technologieentscheidung.
Wenn Sie ein bestehendes Produkt verbessern möchten, sagen Sie das gleich zu Beginn. Eine Funktion kann Änderungen an vorhandenen Daten, Berechtigungen und Abläufen nach sich ziehen. Das bestehende System anzusehen gehört dazu, wenn man den Umfang verstehen will.
Erklären Sie Termin und Entscheidungswege
Wenn es einen Starttermin gibt, sagen Sie mir, warum er wichtig ist und was bis dahin fertig sein muss. Ein Termin, der an ein Ereignis gebunden ist, führt zu anderen Entscheidungen als ein Wunschdatum. Auch ein Budgetrahmen, falls vorhanden, hilft uns, Prioritäten zu besprechen, bevor ich ein Angebot erstelle.
Nennen Sie die Person, die Prioritäten bestätigen und die Arbeit freigeben kann. Erzählen Sie mir auch von Abhängigkeiten: ausstehende Inhalte, Zugänge vom bisherigen Entwickler oder ein anderes Team, das für eine Integration zuständig ist. Solche Punkte können die Planung genauso beeinflussen wie der Code.
So sieht ein brauchbares erstes Briefing aus
Wir bieten Leistungen mit Terminvereinbarung an. Kunden buchen derzeit per Nachricht, und unser Team prüft die Verfügbarkeit von Hand.
In der ersten Version sollen Kunden eine Leistung und einen freien Termin wählen, über unseren bestehenden Anbieter bezahlen und eine Buchungsbestätigung erhalten. Unser Team muss Buchungen einsehen und Stornierungen bearbeiten können.
Website, Markenauftritt und ein Zahlungskonto haben wir bereits. Abopakete und Empfehlungsprämien können später kommen.
Wir brauchen Hilfe bei der Entscheidung, wie Stornierungen und fehlgeschlagene Zahlungen ablaufen sollen. Wir haben einen Wunschtermin für den Start, möchten aber erst festlegen, was realistisch ist, wenn diese Fragen geklärt sind.
Auch dieses Beispiel lässt noch einiges offen: Regeln für die Verfügbarkeit, Erstattungen, Rechte der Mitarbeitenden und den Inhalt jeder Bestätigung. Das ist normal. Ein erstes Briefing liefert genug Kontext, um diese Entscheidungen zu erkennen.
Ein Briefing zum Kopieren
Wir möchten Folgendes bauen oder verbessern: …
Genutzt wird es von: …
Das Problem mit dem heutigen Ablauf ist: …
Die wichtigste Aufgabe, die Nutzer erledigen sollen, ist: …
Für die erste Version brauchen wir: …
Diese Funktionen können warten: …
Das gibt es schon, einschließlich Designs und Integrationen: …
Unser Termin, unsere Rahmenbedingungen und unser Budgetrahmen, soweit bekannt: …
Als Erfolg sehen wir es, wenn: …
Die Entscheidungen trifft: …
Lassen Sie eine Zeile leer, wenn Sie die Antwort noch nicht kennen. Offene Fragen sollen sichtbar sein. Sobald wir uns auf einen Umfang geeinigt haben, besprechen wir bei jedem neuen Wunsch zuerst, wie er sich auf Arbeit und Zeitplan auswirkt, bevor er dazukommt.
Sie könnenIhr Briefing hier senden. Ich arbeite schriftlich, Sie müssen also weder eine Präsentation noch einen Anruf vorbereiten. Ich antworte mit Fragen und nächsten Schritten, bevor wir die Arbeit vereinbaren.