Wie sag ich’s meinem ITler?

Kennen Sie das: Sie wollen etwas von Ihrer internen IT oder externen Dienstleister und haben das Gefühl, nicht verstanden zu werden? Oder das Ergebnis ist ein anderes als gewünscht? Oder Ihnen fallen im Prozess des Produktmanagements neue Anforderungen ein?

 

Um im Produktmanagement Abstimmungsprobleme zwischen Business und IT zu minimieren, haben wir für uns das Product Requirement Canvas entwickelt. Es enthält alle wesentlichen Dimensionen, die ein Nicht-ITler realistischer Weise bereit stellen kann, um als Produktmanager bzw. Product Owner seine Anforderungen auszudrücken. Die im Canvas enthaltenen Informationen helfen Software-Entwicklern dabei, ein klareres Bild von den Erwartungen zu bekommen. Und sie sorgen für eine gründliche Auseinandersetzung mit den tatsächlichen Anforderungen.

Das Product Requirement Canvas für Anforderungen im Produktmanagement

Das Product Requirement Canvas kann hier als PDF-Datei herunter geladen werden.

 

Die vier Dimensionen

Das Canvas teilt sich in folgende Dimensionen:

  1. Die User-Stories stehen in der Mitte. Sie beschreiben die konkreten Probleme, die vom neuen Feature oder der Software gelöst werden sollen.
  2. Die Business-Dimension beschreibt das Warum der Anforderung und die Einbettung in den Kontext der Organisation. Sie findet sich in der oberen linken Seite mit den vier Feldern Goal, Examples, Constraints und KPI.
  3. Die Technik-Dimension beschreibt im Detail, welche Ausprägungen und Nebenbedingungen die User Stories haben. Sie findet sich in der oberen rechten Seite mit den vier Feldern Data Fields, User, Test Cases und Scenarios.
  4. Die Organisations-Dimension enthält Informationen über die Art und Weise, mit der die Anforderungen umgesetzt werden sollen. Sie bildet das untere Fundament mit den vier Feldern Open Questions, Dependencies, Stakeholder und Not Doing.

 

## User Stories

Die User Stories beschreiben die Bedürfnisse der Nutzer und ihre Motivation dahinter. Dabei geht es um die Probleme der Nutzer, nicht die Lösung der Probleme. User Stories ermöglichen es den Entwicklern, in die Welt der Nutzer einzutauchen und die Software aus ihrer Brille zu sehen. Oftmals sind mehrere User Stories hilfreich, um eine Anforderung zu erfassen. Das Konzept der User-Stories ist weit verbreitet, weshalb online zahlreiche Tipps zu deren Ausformulierung zu finden sind.  https://www.mountaingoatsoftware.com/agile/user-stories

 

Beispiel: Als Kundenservice-Mitarbeiter möchte ich bei Anfragen die Kundennummer mitgeliefert bekommen, um die Anfrage schneller bearbeiten zu können.

 

## Goals

Mit jeder Umsetzung einer Anforderung soll ein übergeordnetes Ziel erreicht werden. Dies ist kein Ziel des Users sondern des Anbieters der Software. Ziele können qualitativer oder auch quantitativer Natur sein und geben den Beteiligten Sinn und Verknüpfung zu den übergeordneten Ambitionen der Organisation.

 

Beispiel: Wir wollen erstklassigen Kundenservice.

 

## KPI

Um den Nutzen einer umgesetzten Anforderung vorab zu definieren, sollte deren Auswirkung auf vorhandene KPI definiert werden. Wird die Software mit dem neuen Feature häufiger oder länger genutzt? Können Aufgaben schneller abgearbeitet werden? Wird eine Fehlerrate gesenkt? KPI einzubinden hilft dann, wenn im Unternehmen tatsächlich KPI verwendet werden und die Wirkung des neuen Features auch messbar zugeordnet werden kann.

 

Beispiel: Wir können die Bearbeitungszeit von Kundenanfragen per E-Mail um 20% reduzieren, da uns eine frühe Identifikation des Kunden schnell Zugriff auf seine Kundenhistorie ermöglicht.

 

## Constraints

Jede Software Entwicklung geschieht unter wirtschaftlichen Erwägungen. Bei Beauftragung von externen Dienstleister aber auch oft von internen Abteilugnen, braucht es ein Budget für die Entwicklung. Anforderungen an den Fertigstellungs-Termin der Entwicklung sollten benannt werden, sofern sie vorliegen. Der Product Owner ist festzulegen. Dabei handelt es sich um die Person, welche für die Formulierung der Anforderungen verantwortlich ist. Im Zuge dessen sind Auswirkungen auf andere Geschäftsprozesse zu benennen – vorgelagerte Schritte, nachgelagerte Aufgaben oder Datenauswertungsvorgänge.

 

Beispiel: Das Feature sollte vor dem Verkaufsstart von XY umgesetzt sein, da dann wieder mit mehr Service-Anfragen gerechnet wird.

 

## Examples

Umsetzungsbeispiele geben den Beteiligten eine Vorstellung davon, was mit den User Stories gemeint ist. Diese Beispiele können Screenshots von anderer Software, aber auch eigene Skizzen sein. Beispiele sind mit Vorsicht zu genießen und sollten deshalb dosiert eingesetzt werden. Sie helfen bei der Konkretisierung der Anforderung, da sie – im Gegensatz zu den User Stories – das “Wie” schon ausmalen. Gleichzeitig können sie auf das Projektteam einschränkend wirken, da die Kreativität in eine bestimmte Richtung gelenkt wird und sich der Product Owner frühzeitig auf eine Lösung festlegt.

 

Beispiele: Screenshot eines Kontaktformulars von Firma XY

 

## Data fields

Neue Anforderungen betreffen oftmals die Datenstruktur der Software. Neue Datenfelder müssen womöglich geschaffen werden, existierende Datenfelder sind betroffen oder gar nicht mehr nötig. Das Hinzufügen oder Entfernen von Datenfeldern geht oft mit deutlich höheren Aufwand einher, als die ausschließliche Verwendung bereits vorhandener Datenfelder. Hier früh eine Klarheit über die Anforderungen zu schaffen, erleichtert die Prognose des Aufwands.

 

Beispiele:

– im Kontaktformular braucht es ein neues Feld “Kundennummer”

– in diesem Feld dürfen nur Zahlen eingegeben werden

– Eingaben in Feld Kundennummer werden im CRM an “Cusomter-ID” überführt

 

## Test Cases

Testfälle helfen dem Entwicklungsteam die Anforderungen genauer zu verstehen und auch Sonderfälle frühzeitig zu erkennen. Mit Testfällen wird eine Anwendung sehr konkret und erlebbar. Besonders wichtig sind so genannte Edge Cases. Sie beschreiben Fälle von Eingaben, die sehr unwahrscheinlich sind oder eine extreme Ausprägung annehmen, wie z.B. alte Daten oder erwartbare Fehleingaben der Nutzer.

 

Beispiele:

  • Kundennummer-Systematik vor Jahr 1995
  • Kunde gibt keine Kundennummer ein
  • Kundennummer ist zu lang

 

## User

Viele Systeme arbeiten mit Usern in unterschiedlichen Rollen. So haben manche User besondere Administrations-Rechte in einem Bereich, es gibt ggf. Premium-User oder nicht registrierte User. Es sollte beschrieben werden, welche User von den Änderungen betroffen sind und wovon dies abhängt.

 

Beispiele: Kundennummer wird nur bei nicht eingeloggten Seitenbesuchern erfasst; bei eingeloggten Usern wird die Kundennummer bereits automatisch übermittelt

 

## Scenarios

Mithilfe von Szenarien wird der Kontext, in dem die User das Feature nutzen, beleuchtet. Software kann mittlerweile von verschiedenen Geräten (z.B. PC, Tablet, Smartphone, Smartwatch) in verschiedenen Situationen (z.B. am Arbeitsplatz, auf dem Sofa, im Zug) mit unterschiedlichsten Internet-Verbindungen (z.B. im Firmennetz, im Flugzeug) verwendet werden. Das Feature sollte so entwickelt werden, dass es in den Situationen vom User optimal genutzt werden kann.

 

Beispiele: Kunden nutzen das Formular zuhause vom Schreibtisch, Küchentisch oder Couch via Smartphone, Tablet oder Laptop.

 

## Dependencies

Anforderungen sind eingebettet in einen Kontext von wirtschaftlichen, rechtlichen oder technischen Rahmenbedingungen. Womöglich müssen Gelder noch freigegeben oder Aufträge erteilt werden, eventuell sind Schnittstellen zu anderen Systemen nötig oder in Arbeit befindlichen Funktionen Voraussetzung für die Durchführung. Diese Abhängigkeiten gilt es zu benennen. Der Datenschutz ist ebenso zu wahren. Dabei geht es insbesondere um die Fragen: Welche personenbezogenen Daten werden erfasst? Zu welchem Zweck werden diese Daten erfasst? Wer hat darauf Zugriff? Wo sind diese Daten gespeichert?

 

Beispiele: Änderung wird von Dienstleister umgesetzt, interner Beauftragungsprozess nimmt vier Wochen in Anspruch

 

## Stakeholder

Zum richtigen Zeitpunkt die richtigen Menschen einzubeziehen erleichtert eine erfolgreiche Umsetzung. Dies kann rechtliche oder politische Unterstützung wie auch die Freigabe der nötigen Entwickler-Kapazitäten sein. Besonders hilfreich ist Feedback von tatsächlichen Nutzern, um frühzeitig ihre Bedürfnisse zu berücksichtigen.

 

Beispiele: Freigabe bei Datenschutzbeauftragten einholen

 

## Open Questions

Nicht immer kann sofort jede Frage entschieden werden, oftmals weil Auswirkungen nicht überblickt oder Experten noch nicht einbezogen sind. Deshalb sollten diese Fragen notiert und später bearbeitet werden.

 

Beispiele: Sollte das Feld Kundennummer verpflichtend sein?

 

## Not doing

Festzulegen, welche Funktionen nicht entwickelt werden sollen, trägt zur Klarheit und schnelleren Umsetzung bei. Weil User Stories bewusst einen breiten Lösungs-Horizont zulassen, werden mitunter Ideen entwickelt, die nicht gewollt sind. Das führt später zu Diskussionen und ggf. verlorener Arbeitszeit.

 

Beispiele: Vorgangsnummer soll nicht zusätzlich miterfasst werden

 

Wie kann ich mit dem Canvas arbeiten?

Das Canvas hilft Produktmanagern bzw. Product Ownern bei der Klärung der eigenen Anforderungen. Es kann auch in Teambesprechungen zum Einsatz kommen, um gemeinsam die Anforderungen im Rahmen des Produktmanagements zu erarbeiten und zu diskutieren. Gut eingesetzt ist es lebendige Digitalkompetenz.

 

Wir bei Skill Hero haben die Felder des Canvas in eine Online-Vorlage überführt. Als Projektmanagement-Tool nutzen wir JIRA und Confluence, dort können wir Vorlagen für neue Wiki-Seiten definieren. Für neue Features haben wir eine Vorlage eingerichtet, welche die für uns relevanten Felder des Product Requirement Canvas und noch andere Angaben enthält (z.B. welche Systeme mutmaßlich betroffen sind). Auf dieser Seite werden für alle jederzeit einseh- und bearbeitbar sämtliche Informationen zusammengetragen. Die Seite ist dann Ausgangspunkt für Aufwandsschätzungen, auf ihr werden Entscheidungen des Produktmanagements dokumentiert und Anmerkungen vorgenommen. So haben wir unseren Weg gefunden, zwischen Business und IT verständlich zu sprechen.

SHARE THIS