Vorlage für Produktspezifikationen: was hineingehört, mit Beispiel
Private Beta. Der Zugang läuft über die Warteliste, und die kostenpflichtigen Tarife starten, wenn die Beta endet. Tragen Sie sich auf die Warteliste ein.
Eine Produktspezifikation ist nützlich, wenn man darin schnell findet, was man braucht. Eine Vorlage macht das verlässlich. Unten stehen die Abschnitte, die die meisten Teams brauchen, und was in jeden gehört, gefolgt von einem vollständigen Beispiel für eine fiktive Funktion.
Kopfbereich
Produkt, Verantwortliche, Status und Version. Verantwortlich ist eine Rolle oder ein Team, etwa "Produktmanagement Abrechnung", damit die Spezifikation auch nach einem Stellenwechsel noch auf eine Anlaufstelle verweist. Der Status ist Entwurf, In Prüfung oder Freigegeben.
Zusammenfassung
Zwei oder drei Sätze: was Sie bauen und was sich für die Nutzer ändert. Wer nur diesen Abschnitt liest, sollte trotzdem wissen, worum es in der Spezifikation geht und ob sie ihn betrifft.
Problem
Was heute schiefläuft und für wen. Beschreiben Sie die Situation, in der sich der Nutzer befindet, mit Details wie dem Bildschirm, den er verwendet, und dem Schritt, an dem es scheitert. Lassen Sie die Lösung in diesem Abschnitt weg.
Ziele und Nicht-Ziele
Ziele beschreiben, wie Erfolg aussieht, in Begriffen, die Nutzer wiedererkennen. Nicht-Ziele nennen, was Sie in dieser Spezifikation bewusst nicht tun. Wer Nicht-Ziele früh festhält, verhindert später die meisten Diskussionen über den Umfang.
Anforderungen
Eine Tabelle mit ID, einer Anforderung pro Zeile und einer Priorität. Üblich ist die Skala Muss, Soll und Kann. Muss bedeutet, dass die Veröffentlichung ohne diese Anforderung nicht ausgeliefert wird. Soll bedeutet, dass sie enthalten ist, sofern kein klarer Grund dagegen spricht. Kann bedeutet, dass sie enthalten ist, wenn die Arbeit es zulässt. Jede Zeile sollte etwas sein, das eine Testperson als bestanden oder nicht bestanden markieren kann.
Erfolgskennzahlen
Messbar und zeitlich begrenzt. Eine gute Kennzahl hat ein Ziel, einen Zeitraum ab der Veröffentlichung und eine benannte Datenquelle. Wenn Sie sie nicht messen können, schreiben Sie, wie Sie es herausfinden. "Die Nutzer mögen es" ist keine Kennzahl.
Offene Fragen
Dinge, zu denen Sie vor oder während der Umsetzung eine Antwort brauchen, jeweils mit einer verantwortlichen Person. Eine sichtbare Liste ist besser als verborgene Zweifel.
Veröffentlichungsplan
Wie die Funktion die Nutzer erreicht: interner Einsatz, eine begrenzte Beta, allgemeine Verfügbarkeit. Jede Stufe braucht eine Bedingung für den Übergang zur nächsten, so formuliert, dass Sie sie prüfen können.
Ein vollständiges Beispiel: gespeicherte Suchen
Das folgende Beispiel füllt die Vorlage für eine fiktive Funktion aus. Tallybird, die Rechnungs-App, ist erfunden, ebenso die Zahlen, Ziele und Rollen.
- Produkt: Tallybird-Rechnungs-App (fiktiv)
- Funktion: Gespeicherte Suchen
- Verantwortlich: Produktmanagement, Team Abrechnung
- Status: In Prüfung
- Version: 0.3
Zusammenfassung. Gespeicherte Suchen erlauben es, eine Reihe von Filtern der Rechnungsliste unter einem Namen abzulegen, etwa "Überfällig, Kunde Nord", und sie mit einem Klick aus der Seitenleiste wieder zu öffnen. Die Ergebnisse werden bei jedem Öffnen einer gespeicherten Suche neu geladen, sodass auch Rechnungen erscheinen, die nach dem Speichern angelegt wurden. Jeder Nutzer kann bis zu 20 gespeicherte Suchen behalten.
Problem. Nutzer, die jede Woche überfällige Rechnungen prüfen, stellen jedes Mal dieselben drei Filter neu ein (Status, Kunde und Datumsbereich). Die Rechnungsliste merkt sich davon nichts. Wer einen Filter auslässt, sieht eine andere Liste, ohne es zu bemerken.
Ziele.
- Ein Nutzer kann die aktuellen Filter der Rechnungsliste speichern und sie später über die Seitenleiste wieder öffnen.
- Eine gespeicherte Suche zeigt immer aktuelle Rechnungen und keine Momentaufnahme vom Tag des Speicherns.
Nicht-Ziele.
- Das Teilen einer gespeicherten Suche mit anderen Nutzern. Diese Spezifikation betrifft nur persönliche Suchen.
- Gespeicherte Suchen für Berichte, Kunden oder Zahlungen.
- Zeitgesteuerte E-Mail-Zusammenfassungen einer gespeicherten Suche.
- Jede Änderung an der Funktionsweise der Rechnungsfilter selbst.
Anforderungen. Jede Zeile ist eine Entscheidung.
| ID | Anforderung | Priorität |
|---|---|---|
| SRCH-1 | Ein Nutzer kann die aktuellen Filter der Rechnungsliste unter einem Namen mit 1 bis 40 Zeichen speichern. | Muss |
| SRCH-2 | Ein Nutzer kann jede gespeicherte Suche mit einem Klick aus der Seitenleiste öffnen, und die Rechnungsliste zeigt die gespeicherten Filter angewendet an. | Muss |
| SRCH-3 | Die Ergebnisse einer gespeicherten Suche werden beim Öffnen geladen, sodass eine nach dem Speichern angelegte Rechnung in den Ergebnissen erscheint. | Muss |
| SRCH-4 | Ein Nutzer kann seine eigenen gespeicherten Suchen umbenennen oder löschen. Vor dem Löschen erscheint ein Dialog mit einer Schaltfläche Löschen zur Bestätigung. | Muss |
| SRCH-5 | Ein Nutzer kann bis zu 20 gespeicherte Suchen behalten. Beim Speichern einer 21. Suche erscheint die Meldung "Sie haben 20 gespeicherte Suchen. Löschen Sie eine, um eine neue zu speichern." und es wird nichts gespeichert. | Muss |
| SRCH-6 | Eine gespeicherte Suche ist nur für den Nutzer sichtbar, der sie angelegt hat. Eine Anfrage nach der gespeicherten Suche eines anderen Nutzers liefert eine 404-Antwort. | Muss |
| SRCH-7 | Ein Nutzer kann bis zu 3 gespeicherte Suchen anheften, sodass sie in der Seitenleiste über den anderen erscheinen. Ein vierter Pin zeigt eine Meldung und wird nicht angeheftet. | Soll |
| SRCH-8 | Filtert eine gespeicherte Suche nach einem Kunden, der archiviert wurde, lässt sich die Suche trotzdem öffnen, zeigt einen Hinweis mit dem Namen des archivierten Kunden und wendet ihre übrigen Filter an. | Kann |
Erfolgskennzahlen.
- Innerhalb von 8 Wochen nach der allgemeinen Verfügbarkeit öffnen mindestens 30 % der Nutzer, die in einer Woche die Rechnungsliste ansehen, in derselben Woche auch eine gespeicherte Suche. Quelle: die wöchentliche Anzahl des Analytics-Ereignisses saved_search_opened, geteilt durch die wöchentlichen Nutzer, die die Rechnungsliste ansehen.
- Innerhalb von 12 Wochen nach der allgemeinen Verfügbarkeit erscheint das Helpdesk-Tag "repeat filter" auf höchstens 10 Tickets pro Monat, nach 40 im Monat vor der Veröffentlichung. Quelle: der monatliche Export aus dem Helpdesk.
- Weniger als 0,5 % der Aufrufe gespeicherter Suchen liefern in den 4 Wochen nach der allgemeinen Verfügbarkeit einen Serverfehler. Quelle: das Serverfehler-Log, gefiltert auf den Endpunkt für gespeicherte Suchen.
Offene Fragen.
- Sollen archivierte Rechnungen standardmäßig in den Ergebnissen gespeicherter Suchen erscheinen? Verantwortlich: Leitung Abrechnung.
- Ist 20 das richtige Limit für gespeicherte Suchen, oder brauchen große Konten mehr? Verantwortlich: Produktmanagement, nach Prüfung der Support-Tickets aus der Beta.
- Braucht die Seitenleiste ein Suchfeld, sobald ein Nutzer mehr als 10 gespeicherte Suchen hat? Verantwortlich: Design-Leitung.
- Soll das Ereignis saved_search_opened auch festhalten, wie viele Filter angewendet wurden? Verantwortlich: Data Engineering.
Veröffentlichungsplan.
- Interner Einsatz. Das Team nutzt gespeicherte Suchen zwei Wochen lang auf dem eigenen Testkonto. Der Übergang erfolgt, wenn kein offener Fehler als kritisch eingestuft ist und jede Muss-Anforderung das Testskript besteht.
- Begrenzte Beta. Bis zu 15 Kundenkonten schalten die Funktion über ein Feature-Flag ein. Der Übergang erfolgt nach 4 Wochen ohne Meldungen fehlender Rechnungen in den Ergebnissen und mit einer Fehlerquote unter 0,5 %.
- Allgemeine Verfügbarkeit. Jedes Konto kann gespeicherte Suchen nutzen. Der Hilfeartikel ist vor der Umschaltung fertig.
Vage gegenüber prüfbar
Eine Anforderung ist prüfbar, wenn eine Testperson eine Prüfung durchführen und ein klares Bestanden oder Nicht bestanden erhalten kann.
| Vage Anforderung | Prüfbare Umformulierung |
|---|---|
| Gespeicherte Suchen sollten schnell laden. | Die ersten 50 Ergebnisse erscheinen im 95. Perzentil innerhalb von 2 Sekunden bei einem Konto mit 10.000 Rechnungen, gemessen über 20 Durchläufe auf dem Staging-Testkonto. |
| Nutzer sollten ihre Suchen verwalten können. | Ein Nutzer kann jede eigene gespeicherte Suche über ihr Menü in der Seitenleiste mit höchstens 2 Klicks umbenennen oder löschen, und eine gelöschte Suche ist nach einem Neuladen der Seite verschwunden. |
| Die Filterbezeichnungen sollten leicht verständlich sein. | Jeder angewendete Filter erscheint als Bezeichnung in der Form "Feld: Wert", etwa "Status: Überfällig". Eine Testperson kann jede Bezeichnung einem Feldnamen aus der Filterliste der Spezifikation zuordnen. |
| Daten anderer Nutzer sollten privat bleiben. | Eine Anfrage nach einer gespeicherten Suche, die einem anderen Nutzer gehört, liefert eine 404-Antwort. Das prüft ein automatisierter Test an jedem Endpunkt für gespeicherte Suchen. |
Wie viel Vorlage nötig ist
Passen Sie die Vorlage an den Umfang der Änderung an.
- Kleine Änderung, etwa eine Bezeichnung, ein Standardwert oder eine Textkorrektur: ein Kopfbereich, eine Zusammenfassung und eine Anforderungszeile. Lassen Sie die Kennzahlen, die offenen Fragen und den Veröffentlichungsplan weg.
- Mittlere Änderung, etwa eine neue Option auf einem bestehenden Bildschirm: jeder Abschnitt, kurz gehalten.
- Große Funktion, etwa ein neuer Bereich des Produkts oder eine Änderung gespeicherter Daten: jeder Abschnitt vollständig, mit einer Datenquelle für die Kennzahlen und einer Bedingung für jede Veröffentlichungsstufe.
Einige Teile werden unabhängig von der Größe nie weggelassen: Verantwortliche und Version im Kopfbereich, die Nicht-Ziele, eine Priorität auf jeder Anforderung und eine verantwortliche Person bei jeder offenen Frage. Danach fragen Prüfende zuerst.
Das Beispielblatt für eine SaaS-Produktspezifikation auf der Startseite folgt diesem Aufbau mit einer fiktiven Funktion "Zurückstellen und Erinnerungen". In Wordspecs sind dieselben Abschnitte eine Vorlage, sodass jede Spezifikation Ihres Teams sie in derselben Reihenfolge hat.
Dazu passend: eigene Vorlagen für Spezifikationsblätter speichern.