Allgemein

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.

Dieser Beitrag erschien zuerst auf http://skillhero.com/