Produktmanager dokumentieren Arbeit

Zur Dokumentation der Entwicklung digitaler Produkte setzen Produktmanager Werkzeuge ein. In diesem Beitrag stelle ich 5 Werkzeuge vor und beschreibe ihren Einsatz in der täglichen Praxis.

Als Produktmanager organisiere ich die Entwicklung digitaler Produkte. Zur Organisation gehört die Dokumentation. Ich stelle im Folgenden eine Reihe von Werkzeugen vor, die ich zur Dokumentation der Produktentwicklung verwende.

Das Entwicklungslog

Im Entwicklungslog wird der aktuelle Stand der Arbeit festgehalten. In Abhängigkeit von der „Schlagzahl“, also der Intensität der Arbeit, erfolgen Einträge in das Entwicklungslog für gewöhnlich täglich oder manchmal sogar mehrfach täglich. Ist die Schlagzahl geringer, zum Beispiel in Wartungsphasen, werden nur dann Einträge erstellt, wenn an dem Produkt gearbeitet wird.

Meist führe ich zwei Entwicklungslogs parallel. Das interne Entwicklungslog dokumentiert die Arbeit des Teams und kann das Protokoll des Daily Standup Meetings sein. Das externe Entwicklungslog richtet sich an Auftraggeber und Stakeholder. Durch zwei Logs werde ich dem Umstand gerecht, dass Zielgruppen unterschiedliche Sprachen sprechen.

In beiden Fällen dokumentiert das Entwicklungslog den aktuellen Stand der Arbeit (siehe Abb. 1). Das interne Log setze ich beim Review und bei der Retrospektive ein. Auf diese Weise kann der Sprint detailliert nachvollzogen werden, nichts fällt unter den Tisch. Das externe Log dient der Transparenz. Auftraggeber und Stakeholder wissen zu jedem Zeitpunkt, wie der Stand der Entwicklung ist. Diskussionen und Entscheidungen können auch rückwirkend nachvollzogen werden.

Abb. 1: Vergleich von Einträgen intern/extern für den gleichen Tag

Die Roadmap

Während das Entwicklungslog die Vergangenheit dokumentiert, ist die Roadmap ein Werkzeug, um die Zukunft zu planen. Ich verwende ein Board mit vier Spalten: Backlog, Next, Now und Done. In diesem Board werden Karten einsortiert (siehe Abb. 2). Die Karten enthalten im besten Fall Outcomes, falls dies nicht möglich ist Features. Dabei versuche ich Arbeitsschritte zusammen zu fassen und verzichte weitgehend auf Details. Der Titel einer Karte kann zum Beispiel „Onboarding“ heißen.

Abb.2: Roadmap mit den Karten Onboarding und Checkout

Die Roadmap ist ein Werkzeug um die Zukunft der Produktentwicklung zu planen und zu diskutieren. Ich setze die Roadmap bei fast jedem Treffen mit dem Entwicklungsteam und

Auftraggebern ein. Die Kommunikation kann dann folgendermaßen beginnen:

„Wir arbeiten aktuell am Checkout. Als nächstes würden wir uns das Onboarding vornehmen. Sind alle damit einverstanden? Gibt es Gründe, Änderungen an der Roadmap vorzunehmen?“

Der Wissensspeicher

Im Verlauf jeder Produktentwicklung wird Wissen erzeugt. Neues Wissen entsteht, bestehendes Wissen kann bestätigt oder widerlegt werden. Damit dieses Wissen nicht verloren geht, muss es festgehalten werden.

Beispiele für Sektionen im Wissensspeicher:

  • Ergebnisse von Discovery und Nutzertests
  • Analytische Daten und deren Auswertung
  • Design Entscheidungen
  • Technische Erkenntnisse und Entscheidungen
  • Anforderungen und Entscheidungen von Stakeholdern

Im Fall von Auftragsarbeiten ist es im Interesse des Auftraggebers, diesen Wissensspeicher zu betreiben und zu verwalten. Er kann mir als Produktmanager Zugang gewähren, um Erkenntnisse festzuhalten.

Oft existiert leider kein Wissensspeicher. Dann lege ich einen an und gewähre dem Auftraggeber Zugang. So kann er sich relevante Informationen für die eigene Dokumentation aus dem Speicher heraus ziehen.

Der externe Issue-tracker

Stakeholder haben Wünsche. Je mehr Stakeholder, desto mehr Wünsche. Nicht alle diese Wünsche werden erfüllt. Oft ist es sogar so, dass ein Großteil aller Ideen niemals umgesetzt wird.

Aber Stakeholder sind Menschen und Menschen haben das Bedürfnis, dass ihre Wünsche gehört und nicht ignoriert werden. Dafür richte ich einen externen Issue Tracker ein.

Stakeholder bekommen Zugriff und können ihre Anforderungen hier dokumentieren. Als Produktmanager sichte ich die Issues und entscheide gemeinsam mit dem Team und dem Auftraggeber, welche Wünsche einen Mehrwert für das Produkt darstellen, und welche zusätzlichen Arbeiten (z.B. Nutzerinterviews) im Rahmen der neuen Anforderung durchgeführt werden müssen. Nur dann kann die Aufgabe vom externen Issue Tracker in das Product Backlog überführt werden kann.

Das Journal

Ich mache jeden Tag Eintragungen in mein persönliches Journal. Hier sammle ich meine Gedanken zur aktuellen Arbeit. Das Journal ist ein Werkzeug zur Selbstreflexion und zur Selbstevaluation. Am Ende jeder Woche, jeden Monats und jeden Jahres sichte ich meine Einträge in einer persönlichen Retrospektive. Ich arbeite heraus, was gut gelaufen ist und vor allem, wo es Optimierungspotenzial gibt. Ich bewerte den Erfolg meiner eigenen Vorsätze und lege Outcomes für die nächsten Zeiträume fest.

Mit dem Journal versuche ich, meine eigenen Fähigkeiten gezielt in bestimmte Richtungen zu erweitern und meine Leistungen iterativ zu verbessern. Mein Leben ist wie meine Produkte: fortlaufende Prozesse, deren Entwicklung nie abgeschlossen ist und deren Qualität von guter Planung und fortlaufender Pflege abhängt.

Die Arbeit mit Werkzeugen

Die besten Werkzeuge helfen nichts, wenn sie nicht verwendet werden. Alle oben beschriebenen Methoden müssen kontinuierlich verwendet werden. Die Personengruppen, an die sie sich wenden, werden laufend von mir auf die Existenz der Dokumentation hingewiesen und aufgefordert, diese auch zu verwenden. Dazu ist es auch notwendig, den Mehrwert der Werkzeuge zu verdeutlichen. Dies habe ich mit diesem Beitrag getan.

MW Studio | App & Web Entwicklung aus Greifswald