Nur eine Empfehlung... wie wir unseren Informationsbedarf organisieren

Informationen werden von Geschäftsanwendern in der gesamten Branche benötigt. Im Rahmen unserer Beratungsaufträge stoßen wir jedoch auch auf eine unzureichende Beschreibung dessen, was der Geschäftsanwender eigentlich Bedürfnisse. 

Daher möchten wir in diesem Artikel die Art und Weise vorstellen, wie wir unseren Informationsbedarf intern bei Scalefree strukturieren und wie wir dies für viele unserer Kunden tun.

Was ist mit User Stories?

Wir alle kennen User Stories aus Scrum und vielen Business Intelligence-Projekten.
Ihre Struktur sieht in der Regel folgendermaßen aus:

Als will ich , damit .

Das folgende Beispiel stellt eine typische User Story dar, die wir in einem Projekt erhalten:

Als möchte ich haben, damit .

Was sollen wir nun mit dieser User Story machen?
Es fehlen viele Details, und ja, wir alle kennen die Verfeinerung des Product Backlogs. Das Problem ist, dass die User Story im Rahmen von Business Intelligence-Bemühungen einfach nicht ausreicht und eine gewisse Struktur hilfreich sein könnte.

Anforderungen an Informationen

Entwickler in den Bereichen Enterprise data warehousing und Business Intelligence benötigen viel mehr Details als nur die User Story. Andererseits ist die Benutzergeschichte ein guter Ausgangspunkt für den Informationsbedarf. Sie kann also als typische Einführung betrachtet werden. Die Gesamtstruktur sieht wie folgt aus:

1. Benutzergeschichte (Einleitung)
2. Grafisches Mockup
3. Ausführliche Erklärung
4. Liste der KPIs
5. Liste der Datenquellen
6. Testfälle

Auf diese Abschnitte wird im Folgenden näher eingegangen.

Einführung

Wie bereits erwähnt, ist dies die Benutzergeschichte und ein guter Ausgangspunkt, um die Informationsanforderungen des Geschäftsanwenders vorzustellen. Aus Gründen der Effizienz ist darauf zu achten, dass der Geschäftswert angegeben wird, damit er für das Entwicklungsteam klar ist.

Grafisches Mockup

Grafische Konzepte unterstützen die Klarheit des Informationsbedarfs. Sie sind daher ein hilfreiches Instrument, um dieselbe Anforderung aus einem anderen Blickwinkel zu betrachten. Das grafische Mockup könnte alles Mögliche sein, z. B: 

• ein Bildschirmfoto oder ein Ausdruck des alten Berichts, der neu erstellt werden muss
• ein Tabellenkalkulationsmodell, das wie der endgültige Bericht oder das Dashboard aussieht
• Eine Zeichnung in einem Tool wie Microsoft Visio, Lucidchart und dergleichen
• Eine Kritzelei auf Papier

Allen Optionen ist gemeinsam, dass sie dem endgültigen Endprodukt so nahe wie möglich kommen und so viele Details wie möglich enthalten sollten, einschließlich grafischer Aspekte, Diagrammoptionen, Beispielwerte, Hervorhebungen usw.

Ausführliche Erläuterung

Der nächste Abschnitt erklärt im Wesentlichen das Mockup aus dem vorherigen Abschnitt in allen relevanten Details. Beziehen Sie sich auf das Diagramm und erklären Sie alles, was im Endergebnis enthalten sein sollte, das der Entwickler benötigt, um den Bedarf, die zu erledigende Arbeit und die Geschäftserwartung zu verstehen. Bitte beachten Sie, dass das Hinzufügen von Referenzen zum Mockup-Diagramm hilfreich sein kann, um Details im Diagramm besser zu referenzieren.

Liste der KPIs

Maßnahmen und andere Berechnungen sollten hier näher erläutert werden. Intern verwenden wir einen Datenspeicher, in dem wir die Strukturen der KPIs, ihren Bezug zueinander und alle erforderlichen Details zur Berechnung der Maßnahmen sowie alle Details zu deren Verständnis aufbewahren: Was ist z. B. ein guter Trend (aufwärts, abwärts, gleichmäßig)? Gibt es definierte Schwellenwerte? Wer ist der Eigentümer der Maßnahme usw.

In einfachen Fällen ist eine Wiki-Seite pro KPI ausreichend. In anderen Fällen können Sie sie zu MDM oder einem anderen KPI-System hinzufügen.
Kennen Sie eine andere Methode? Hinterlassen Sie einen Kommentar, wenn Sie uns auf kommerzielle und Open-Source-Systeme zur Definition von KPIs hinweisen möchten.

Liste der Datenquellen

Sobald die Details feststehen, ist die wichtige Frage: Woher kommen die Daten? Zu diesem Zweck sollten Sie sie in diesem Abschnitt auflisten. Intern haben wir einen Namensraum in unserem Wiki, in dem wir unsere Datenquellen in allen relevanten Details beschreiben und definieren.
Wenn Sie an dieser Struktur interessiert sind, hinterlassen Sie einfach einen Kommentar!

Wenn Interesse besteht, könnte das ein weiterer guter Blog-Artikel sein. Wir freuen uns aber auch, von Ihnen zu lernen, also schicken Sie uns Links zu interessanten Beispielen.

Testfälle

Ein weiterer wichtiger Abschnitt sind die manuellen Testfälle für den Benutzerakzeptanztest (UAT). Sie sollten nicht versteckt werden, es sei denn, Sie wollen Ihre Zeit im Sprint Review Meeting verschwenden. Machen Sie sie transparent, damit jedes Teammitglied sie selbst testen kann.

Maximierung des Wertes von Informationsanforderungen

Damit ist die Struktur der Informationsanforderung fertiggestellt, aber wie lässt sich nun der Wert dieser Anforderung maximieren? Sie eignet sich bereits hervorragend für die Dokumentation der Anforderungen des Geschäftsanwenders, aber normalerweise gehen wir noch weiter. Sobald die Anforderungen erfüllt sind und das Dashboard oder der Bericht in Produktion gegangen ist, benötigen wir auch eine Benutzerdokumentation. In der Regel wandeln wir die Informationsanforderungen in eine Benutzerdokumentation um, indem wir das grafische Mockup durch einen tatsächlichen Screenshot des produzierten Artefakts ersetzen und den Text aufpolieren.

Das maximiert den Wert des Aufwands, reduziert die Gesamtkosten und hält das Dokument langfristig auf dem neuesten Stand. Bei Änderungsanfragen erstellen wir in der Regel ein Ticket und aktualisieren sowohl das Dashboard oder den Bericht als auch die Dokumentation als Teil der "Definition of done".

Wir hoffen, dass dies ein wenig zur Klärung der Art und Weise beiträgt, wie wir die Informationsanforderungen dokumentieren möchten. Geben Sie dieses Dokument gerne an Ihre Geschäftskunden weiter und hinterlassen Sie bitte einen Kommentar mit Ihrem Feedback!