Ich wurde gebeten, die Produktentwicklung in einem Team zu leiten. Das ist für mich eine etwas neue Reise, da ich mich normalerweise eher als Webdesigner bezeichne als als Produktmanager oder Stratege.
Der schwierigste Teil dieses Jobs war für mich, meine Gedanken zu ordnen. Ich habe eine Zusammenfassung für das Produkt geschrieben, das wir entwickeln, einige Wettbewerbsrecherchen durchgeführt und sogar meine begrenzten MBA-Kenntnisse für eine SWOT-Analyse aufgefrischt. Oh ja, jetzt sieht es so aus, als wüsste ich, was ich tue!
Viele von uns, die CSS-Tricks regelmäßig lesen, müssen wahrscheinlich strategisch denken, um ihre Arbeit zu erledigen, sei es im Design, in der Entwicklung oder beidem. Was ich jedoch festgestellt habe, ist, dass strategisches *Denken* etwas ganz anderes ist als strategisches *Handeln*. Während strategisches Denken ein interner Prozess ist, der im Kopf bleibt, erfordert strategisches Handeln sorgfältige Orchestrierung und die Fähigkeit, interne Gedanken so zu dokumentieren, dass sie im Team geteilt und verstanden werden können.
Der Unterschied zwischen strategischem Denken und Handeln war mir nie so bewusst wie damals, als ich mich zusammensetzte, um Feature-Anforderungen für dieses Projekt zu schreiben. Ich dachte, ich würde teilen, was ich in meinen ersten Versuchen, Anforderungen zu schreiben, gelernt habe.
Bevor ich beginne, möchte ich sagen, dass es unzählige Möglichkeiten gibt, Feature-Anforderungen anzugehen. Was ich jetzt teilen werde, entstammt größtenteils Bruchstücken, die ich beim Stöbern im Web nach Antworten auf meine eigenen Fragen gefunden und so zusammengesetzt habe, dass es für mich funktioniert.
Erkenne deine Voreingenommenheit
Das Erste, was ich lernen musste zu akzeptieren, ist, dass ich bei der Herangehensweise an Anforderungen voreingenommen bin. Ich bin von Beruf Webdesigner und dementsprechend neigen meine Gedanken eher zur visuellen Seite der Dinge. Ich kann den ganzen Tag Wireframes skizzieren und Mockups erstellen, aber nicht alle Leute im Team sehen oder denken so.
Es ist nichts Falsches an einer Neigung zum visuellen Denken, aber es lohnt sich, diese zu erkennen und sich daran zu erinnern, dass Ihre Dokumentation für andere verständlich sein muss. In meinem Fall hatte ich Spaß daran, Layouts zu skizzieren und viele Quadrate zu zeichnen, die darstellen, wie Benutzer durch das Produkt navigieren. Das hat mir geholfen, meine Gedanken aus dem Kopf zu bekommen, damit ich mit dem Dokumentationsprozess beginnen kann. Ihr Prozess können Stichpunktlisten oder Diagramme sein. Nutzen Sie, was für Sie Sinn macht, und wissen Sie, dass Sie diese Arbeit für andere übersetzen müssen.
Erzähle eine Geschichte
Ich habe auch gelernt, dass es sehr hilft, Features als Geschichten zu betrachten.
Denken Sie darüber nach: Eine Geschichte hat einen Protagonisten (den Benutzer), der sich in einer Situation (dem Benutzerfluss) befindet, bevor er zu einem auslösenden Ereignis (der zu erledigenden Aufgabe) kommt, um eine Auflösung (das erwartete Ergebnis) zu finden. Wer hätte gedacht, dass Stephen King die ganze Zeit ein Meister im Verfassen von Feature-Anforderungen war?
Mein bisheriger Prozess war, eine Liste aller wichtigen Produktfeatures zu erstellen und dann aus der Perspektive des Endbenutzers eine Geschichte darüber zu erzählen, wie er jedes Feature nutzt. Unser Team nennt diese User Stories, und jedes Feature kann so wenige wie eine einzige Story und so viele wie ein Dutzend haben, je nach den Anwendungsfällen.
User Stories sind großartig, weil sie Sie zwingen, aus der Perspektive eines Benutzers zu denken und sich auf erwartete Ergebnisse zu konzentrieren. Nehmen wir an, wir schreiben die Anforderungen für die Kontoerstellung. So rahmen wir jede User Story ein:
| Als… | Ich erwarte, dass… | Damit… |
|---|---|---|
| [Identifiziere den Benutzer] | [Beschreibe die Aufgabe] | [Erkläre das erwartete Ergebnis] |
Nehmen wir an, wir schreiben die Anforderungen für die Kontoerstellung. So könnte eine User Story dafür aussehen:
| Als… | Ich erwarte, dass… | Damit… |
|---|---|---|
| Jeder Neukunde | Ich kann mein bestehendes Google- oder Facebook-Konto zum Registrieren verwenden | Ich kann mich schneller anmelden und weniger Konten verwalten |
Ich werde hier kurz einfügen, dass diese Übung erfordert, dass Sie Ihre Benutzer sehr gut kennen. Sicher, das obige Beispiel ist eher generisch, da es sich an „jeden Neukunden“ richtet, aber das Nachdenken darüber, wer Ihre Benutzer sind, das Dokumentieren ihrer Persönlichkeiten und sogar das Geben ihnen Namen wird es Ihnen ermöglichen, spezifischer und kontextbezogener zu schreiben, wenn Sie User Stories verfassen. MailChimp hat einen wunderbaren Bericht über ihren Prozess zur Erstellung von User Personas, der mir sehr geholfen hat.
Dokumentiere Benutzerflüsse
Wenn eine User Story hilft, Erwartungen für eine Feature-Anforderung zu setzen, dann bietet ein Benutzerfluss Kontext dazu, wie der Benutzer dorthin gelangt ist und wo er nach Abschluss der Aufgabe landet.
Zurück zu meiner persönlichen Neigung zum visuellen Denken: Für mich macht es am meisten Sinn, dies in einem Diagramm darzustellen. Ich weiß jedoch, dass nicht jeder wie ich denkt, daher habe ich die erforderlichen Schritte, die ein Benutzer zur Bewältigung der Aufgabe unternimmt, umrissen und ein Diagramm verwendet, um komplexere Flüsse zu veranschaulichen.
Hier ist, wie ich einen Fluss für die User Story, die wir zuvor für die soziale Anmeldung in einem Kontoerstellungsfeature verwendet haben, aufschreiben würde:
| Benutzerfluss-ID | Beschreibung |
|---|---|
| UF-1 | Kunde reagiert auf einen Call-to-Action auf der Marketingseite, um ein Konto zu erstellen |
| UF-2 | Kunde wählt auf dem Bildschirm zur Kontoanmeldung, ein neues Konto mit einem Google- oder Facebook-Konto zu registrieren |
| UF-3 | Kunde wählt entweder Facebook oder Google aus |
| UF-4 | Kunde wird aufgefordert, die Verwendung seines ausgewählten Kontos zur Registrierung eines Kontos zu autorisieren, indem seine Identität verifiziert wird |
| UF-5 | Kunde entweder
|
Beachten Sie, wie jedem Schritt eine ID zugewiesen wird und jede ID in Unteraufgaben verzweigen kann. Die IDs sind nützlich, um bei der Besprechung mit anderen im Team auf spezifische Punkte in der Dokumentation verweisen zu können. Dies kann sicherlich unübersichtlich werden, weshalb ein schönes Diagramm hilfreich sein kann.
Dokumentiere Anforderungen
Das Verrückte daran, zu lernen, wie man Anforderungen schreibt, ist, wie viel Vorabdenken erforderlich ist, bevor man wirklich in die Anforderungen einsteigt.
Sobald das Feature identifiziert, eine User Story geschrieben und der Fluss umrissen ist, gehe ich zu den eigentlichen Anforderungen über und verwende das gleiche Format wie für Benutzerflüsse.
Nochmal, zurück zu unserem Beispiel für soziale Anmeldung, einige einfache Anforderungen könnten sein:
| Anforderungs-ID | Beschreibung |
|---|---|
| RQ-1 | Ein Google Analytics Trichter zur Messung von Konversionen und Abbrüchen |
| RQ-2 | OAuth-Integration |
| RQ-3 | Optionen für Facebook und Google |
Sie können so detailliert sein, wie Sie möchten. Ich versuche, eher konservativ zu sein und so viele wie möglich zu schreiben, während ich versuche, nicht zu starr definiert zu sein, um die kreative Freiheit während des Designs und der Entwicklung nicht zu ersticken.
Sei transparent mit Annahmen
Ich habe gelernt, dass jede Entscheidung, die ich treffe, von Annahmen durchdrungen ist. Es ist schwer, sich allem bewusst zu sein, aber die Anerkennung dessen, was man für selbstverständlich halten mag, ist wichtig, da sie einen Einblick in den Entscheidungsprozess gibt. Das Dokumentieren von Annahmen ermöglicht es anderen, Ihre Logik zu verstehen und bietet eine Gelegenheit, weitere Diskussionen anzuregen.
Lassen Sie uns ein paar Annahmen in unserem laufenden Beispiel dokumentieren:
| Annahme-ID | Beschreibung |
|---|---|
| AS-1 | Soziale Logins sind lohnenswert. MailChimp schrieb ein überzeugendes Argument gegen ihre Verwendung, aber das stammt aus dem Jahr 2012, und sie haben später anerkannt, dass es nützlich sein kann, abhängig von der Website. |
| AS-2 | Dieser Bericht von TechCrunch aus dem Jahr 2015 ist immer noch gültig, dass Google und Facebook die am häufigsten genutzten sozialen Logins sind und andere zu marginal sind, als dass wir sie für den ersten Start berücksichtigen könnten. |
| AS-3 | Wir werden diese Informationen speichern und einen Benutzer angemeldet halten, solange er im von ihm ausgewählten sozialen Konto angemeldet ist |
| AS-4 | Wir werden diese Option gegenüber der E-Mail-Option bevorzugen wollen, da sie Zeit sparen kann. |
Glauben Sie mir, ich hätte nicht gedacht, dass eine scheinbar einfache Aufgabe so viele Annahmen mit sich bringt! Das kann so hilfreich sein.
Mögliche Einschränkungen vermerken
Eine Einschränkung ist eine Begrenzung, die außerhalb Ihrer Kontrolle liegen kann. Das frühzeitige Festlegen dieser Einschränkungen hilft anderen im Team bei der Planung. Ich habe es auch hilfreich gefunden, andere zu fragen, ob sie bei der Identifizierung von Einschränkungen helfen können, da man manchmal nicht weiß, was man nicht weiß.
| Einschränkungs-ID | Beschreibung |
|---|---|
| CT-1 | Google OAuth 2.0 Limits |
| CT-2 | Facebook-Richtlinien für Web-Berechtigungen |
Beispieldokument
Ich habe ein Google-Dokument zusammengestellt, das all diese Konzepte zusammenfasst. Sie können es gerne als Ausgangspunkt verwenden, wann immer Sie damit beauftragt werden, Feature-Anforderungen zu schreiben.
Zusammenfassend
Ich hoffe sehr, dass dies für jeden hilfreich ist, der sich mit Feature-Anforderungen auseinandersetzt. Wie bereits erwähnt, ist nichts hier als vorschreibend gedacht. Dies ist nur das, was ich auf meiner frühen Reise in die Produktentwicklung hilfreich fand.
Das gesagt, finden Sie vielleicht einige dieser zusätzlichen Ressourcen hilfreich:
- Practical Design Discovery: Dan Brown schreibt und bietet einen umfassenden Leitfaden auf A List Apart darüber, wie Designanforderungen in problemlösende Prinzipien zerlegt werden können, hinter denen sich ein Team versammeln kann.
- Schreiben Sie ein Skript: Chris schrieb diesen kurzen Beitrag als Antwort auf einen Beitrag von Jeremy Keith und er dient als gute Erinnerung daran, dass Code-Anforderungen Erzählungen sein können, die der Code-Struktur folgen.
- Sketch vs. Figma: Christian Krammer verglich die beiden Apps für Wireframing und überzeugte mich, Figma auszuprobieren.
User Stories fehlt der Kontext. Lang lebe Job Stories!
https://blog.intercom.com/using-job-stories-design-features-ui-ux/
Danke fürs Teilen! Das hatte ich vorher noch nicht gesehen und es ist interessant.
Ich sehe immer noch viel Wert in User Stories. Der Kontext ist da, auch wenn das Fehlen einer Verbindung zwischen dem erwarteten Ergebnis und der daraus resultierenden Emotion vielleicht der Punkt ist, an dem Job Stories die Oberhand haben.
Danke für den Artikel. Ich habe gerade "The Mythical Man Month" erneut gelesen. Richtiges Architektieren und Dokumentieren ist schwer – aber mit Disziplin und Beharrlichkeit machbar.
Zu welchem Zeitpunkt sollte dies in den Prozess einbezogen werden? Mein Unternehmen versucht, einen guten Prozess für die Auftragsentwicklung zu entwickeln, damit wir Kunden genau kalkulieren können, anstatt etwas zu sagen wie „Benutzer können sich mit sozialen Profilen anmelden“ und dann Monate später einen Treffer zu landen, wenn der Kunde entscheidet, dass auch ein obskures soziales Netzwerk aufgenommen werden sollte. Dieses Beispiel ist etwas konstruiert, aber es ist die Art von Dingen, mit der wir uns jetzt befassen.
Zusammenfassend lässt sich sagen: Ist dies etwas, das einbezogen werden könnte/sollte, bevor der Strich unter der Linie unterschrieben ist?
Gute Frage! Ich nehme an, es hängt davon ab, wie etabliert der Umfang des Projekts ist, bevor Sie involviert sind. Ich verlange oft eine Entdeckungsphase, bevor ich mich zu einem neuen Kundenprojekt verpflichte, wenn der Umfang unklar ist oder der Kunde bestätigt hat, dass keiner existiert. Dann wiederum könnte eine solche Übung in anderen Kontexten übertrieben sein.