Jede Projektorganisation braucht einen Überblick über das Geschäftsfeld, in dem die Nutzer mit dem Software-Produkt arbeiten: Das Big Picture. Das langfristig geplante große Ziel ist es, im Rahmen des Projektes das beste Ergebnis für die Nutzer zu erreichen. Nur so werden sich langfristig Fachabteilungen an der Finanzierung des Projektes beteiligen.

06 Dokumente für das Big Picture

Bedarfsgerecht

Das Wissen über die Geschäftsbereiche haben unsere Stakeholder, speziell die Auftraggeber. Dieses Wissen vermitteln sie uns bei der Formulierung eines Bedarfes an einer neuen Funktion im System. Der Bedarf entsteht in den Fachabteilungen. In einer Anforderung wird beispielsweise der abstrakte Wunsch eines Nutzers formuliert. Änderungen allgemeiner rechtlicher Randbedingung (ganz aktuell die DSGVO) oder wirtschaftliche Erfordernisse sind weitere Treiber für Anforderungen.

ktip Eine Anforderung ist noch Teil der Projektdokumentation.

Der Baustein Topic hilft uns, die Entscheidungen des Auftraggebers, eine Anforderung in diesem System umzusetzen, gut zu begründen.

Viele Topics kann ein Product-Owner bereits bei der Projektinitialisierung erfassen. Sie dokumentieren das Verständnis des Auftraggebers über den Rahmen, in dem sich das Projekt bewegen soll. Alle Topics zusammen beschreiben den Projektauftrag. Eine Baseline der Topics kann Teil des Vertrages zwischen Auftraggeber und Projekt sein.

Übersichtlich

Der Baustein Topic wird in der Sprache der Auftraggeber und Fachleute als Überblick (englisch: management summary) geschrieben, vom Product-Owner für Stakeholder.

Die Summe der Topics gibt einen sehr guten Überblick über die “Größe” des Produkts. Stakeholder und Projektmitarbeiter haben gleichermaßen die Möglichkeit als Leser, sich diesen groben Einblick im Wiki zu verschaffen. Unterschiedliche Vorstellungen über den Umfang des Software-Produktes werden dadurch vermieden.

Zielgerichtet

In Zusammenarbeit mit Stakeholdern prüft der Product-Owner den Änderungsbedarf. Er prüft, ob er fachlich in den Kontext des Software-Produktes passt. Das wesentliches Kriterium für die Übernahme des Bedarfes als neue Anforderung an das System ist, ob er eindeutig einem Topic der Produktdokumentation zugeordnet werden kann. Das Topic hat daher einen hohen Wert, weil unklare oder zu große Anforderungen sehr früh erkannt werden.

Kann eine Anforderung nicht eindeutig einem Topic zugeordnet werden, dann hat der Product-Owner die Aufgabe, die Anforderung zu teilen. Die neu entstandenen Anforderungen können dann eindeutig einem Topic zugeordnet werden.

Eine Anforderung kann auch dazu führen, dass ein neues Topic erstellt wird, wenn kein existierendes Topic passt. In diesem Fall hat der Product-Owner die Aufgabe, mit den Stakeholdern zu verhandeln, ob es ein neues Topic im System gibt. Ganz wesentlich ist hier die Diskussion darüber, ob die Anforderung tatsächlich in diesem System umgesetzt wird oder ob nicht vielleicht doch ein anderes System besser geeignet wäre.