Die 7 W-Fragen im Anforderungsmanagement

Nachdem es nun einige Zeit ruhig war auf meinem Blog, melde ich mich nun wieder mit einem Evergreen für Softwareprojekte zurück.

Hintergründe der Kundenanforderung

Der Kunde hat eine Idee. Er hat einen Bedarf für eine neue Softwarelösung erkannt oder möchte eine bestehende Software ablösen. Z.B. weil die Lizenzen für die aktuelle Version auslaufen oder die Plattform als ganzes abgeschafft werden soll.

Je nachdem woher er kommt fallen beide Szenarien schon einmal unterschiedlich aus. Hat der Kunde nur eine diffuse Vorstellung wie „Ich würde gerne meine Personalplanung und Urlaubsverwaltung automatisieren.“,  dann ist er in der eigentlichen Umsetzung noch nicht festgelegt und muss hier ggf. sogar Stück für Stück an die technologische Plattform mit ihren Möglichkeiten und Grenzen herangeführt werden.

Möglichkeit Zwei ist, dass er diese Software bereits kennt und nutzt. Er würde allerdings gerne eine neue, moderne Umsetzung haben. Entweder, weil die alte Plattform strategisch abgelöst wird, oder weil er selbst von der alten genervt ist. Im Fall einer strategischen Entscheidung ist dies wiederum schwieriger, da er eventuell gar nicht wechseln will und man zusätzlich noch gegen Widerstände ankämpfen muss. Möchte er selbst den Wechsel, fällt auch die Beratung leichter. In beiden Fällen ist die Situation hier, dass der Kunde bereits seine Software kennt und er entsprechende Vorstellungen und Erwarutungshaltungen hat. Er wird davon ausgehen, dass die neue Applikation im Prinzip ein besserer Klon der Altsoftware ist. Besser deshalb, weil er ja jetzt die Möglichkeit hat, neue Funktionalitäten einbauen zu lassen, die er schon immer haben wollte.

Doch selbst bei einem Neusystem wird der Kunde nicht unvoreingenommen an die Sache herangehen. So wird er heutzutage natürlich mit einem Smartphone arbeiten und kennt die schicken – oder auch mal weniger gelungenen – Apps aus dem jeweiligen Store. Vielleicht ist er sogar ein Apple-User und ist es entsprechend gewohnt alles möglichst unkompliziert zu haben. Ein guter Vorsatz. Allerdings ist eine Vereinfachung oft schwerer zu erreichen als alles zu übernehmen. Und das bedeutet entsprechende Mehrkosten.

Was die W-Fragen sind und ihr Mehrwert

Und schon sind wir voll im Thema. Wie bringen wir die Anforderungen des Kunden zu Papier? Wie unterscheiden wir „Must Have“ von „Nice To Have“? Wie bringen wir die Designanforderungen des Kunden und die User Experience im Preis unter? Was ist überhaupt der Preis / Aufwand den wir dafür aufrufen können und sollten? Und ist unser Ansprechpartner denn eigentlich die richtige Ansprechperson für das Thema?

Für genau diese Themen entlehnen wir eine Technik, die bereits vielerorts eingesetzt wird und sich über viele Jahre bewährt hat. Wer bereits einmal die Rettungsdienste angerufen hat, oder von seinen Eltern darüber aufgeklärt wurde, dem werden die W Fragen ein Begriff sein. „Was ist passiert?  Wo ist es passiert? Wie viele Verletzte gibt es? Wer war beteiligt?“ Später wird man dann noch fragen, „Wie ist es passiert? Was war der Auslöser“ etc. Wir sehen, die W-Fragen sind eine effektive Methode schnell an zielgerichtete Informationen zu gelangen. Eine Technik, die übrigens auch im Journalismus oftmals erfolgreich eingesetzt wird. Wenn es also für die Experten der Informationsbeschaffung und Verarbeitung hilfreich ist, wieso dann nicht auch für unsere Anforderungsanalyse?

Diese Technik liegt übrigens auch den User Stories zugrunde, ist dort allerdings weniger detailliert.
„Als <ROLLE> möchte ich <ANFORDERUNG> um zu erreichen, dass <NUTZEN>„.
Dahinter stecken die Fragen Wer, Was und Warum. Diese 3 Fragen bilden auch tatsächlich den Kern unseres Modells. Doch sind sie meist nur ausreichend, wenn es bereits ausreichend Fachwissen gibt und der Projektleiter / Anforderungsmanager / Entwickler weiß, wie er das im Interesse des Kunden umsetzen kann, sodass es sich harmonisch in das Gesamtbild einfügt. Vielleicht kennt der neue Benutzer die Standardfunktionen meiner Plattform oder vielleicht erwartet er eine App. Wie wichtig ist ein stimmiges Design? Ist es für intern oder extern? Diese Fragen werden in einer User Story  nicht oder nur zufällig erfasst und umrissen. Meist benötigt man dennoch ein Rahmenwerk, welches die Umgebungsparameter erfasst und definiert. Genau hier greift das Modell der W-Fragen und erweitert die User Stories und reichert sie mit weiteren Infromationen an.

Die W-Fragen im Detail

Nun aber genug Geplänkel. Welche W-Fragen wollen wir nutzen und was erreichen wir dadurch? Fangen wir mit den Klassikern der User Story an.

Was möchten Sie tun?
Hier geht es darum den konkreten Anwendungsfall zu beschreiben. Der Kunde wird etwas sagen wie „Ich möchte einen Knopf zum Drucken haben.“ Damit ist in diesem einfachen Fall zwar impliziert was er möchte, doch es ist keine Antwort auf die Frage, was er tun möchte. Er hätte auch antworten können „Ich möchte das Gelbe Formular„. Möchte er wirklich das Formular? Oder ist damit nicht etwas anderes impliziert? Hier gilt es nachzufragen. Was genau möchten Sie tun? Oder um zur Zweiten Frage zu kommen:

Wozu möchten Sie das?
Die Frage bezieht sich auf das Was. Wir versuchen damit den Kunden zum Nachdenken anzuregen. Wozu möchten Sie das Gelbe Formular? Wir fragen hier also nach dem Zweck. Im Fall wird herauskommen, dass er eigentlich einen Passierschein A38 benötigt um eine andere Aufgabe zu lösen. Diese Aufgabe hat eine Abhängigkeit zu unserer aktuellen User Story. Aha!

Das Gleiche hätte auch beim Drucken herauskommen können. Wozu genau möchten Sie das Dokument ausdrucken? Vielleicht möchte er es archivieren oder genehmigen lassen? In beiden Fällen könnte man auch eine papierlose Alternative anbieten, welche den Prozess innerhalb der Software hält. Nur, weil er es bisher so gemacht hat, heißt das ja nicht, dass dies auch für die aktuelle Lösung der beste Weg ist. Wir sehen, schon diese beiden Fragen bringen uns wesentlich näher an das eigentliche Geschehen.

Wer tut das?
Die nächste Frage ist wieder ein Klassiker. Wer ist die handelnde Person oder Gruppe? Ist es der Manager? Oder ist es vielleicht ein Mitarbeiter im Außendienst? Vielleicht sogar ein Externer? Die Definition der Person bringt uns auch direkt die besonderen Eigenschaften des Handelnden. Der Manager ist also der Linienvorgesetzt. Sehr gut, damit kann man vielleicht schon etwas automatisieren. Der Außendienstmitarbeiter hat keinen direkten VPN Zugang, sondern muss sich Anmelden. Dann wissen wir, dass wir eine entsprechende offene Schnittstelle nach Außen brauchen. Ggf. sogar mit entsprechenden Sicherheitsmaßnahmen. Die nächste Frage schließt sich daran an.

Wie tut er das?
Was beim Außendienstler vielleicht noch intuitiv erfasst werden kann, gibt durch die Frage nach dem Wie Gewissheit. Der Außendienstler macht das beispielsweise über sein Smartphone. Entsprechend brauchen wir also eine Webseite, die mit der Darstellung auf dem Handy kompatibel ist. Oder er benötigt sogar eine App, damit gewisse Sicherheitsmechanismen auf dem Firmengerät umgesetzt werden können.

Wann passiert das?
Diese Frage gibt Rückschlüsse auf Abhängigkeiten und eventuelle wiederkehrende Ereignisse. Das Drucken der Seite passiert, wenn die Genehmigung über den digitalen Weg fehlgeschlagen ist. Ah! Das ist interessant. Hier kann man direkt die anderen Fragen wieder aufgreifen. Wieso ist es fehlgeschlagen, wie kann man es umgehen, etc. Aber in diesem Fall ergibt sich, dass es sich um einen digitalen Archivierungsprozess handelt und wenn dieser nicht funktioniert, gibt es die Handlungsanweisung das Dokument auf Papier auszudrucken und abzuheften. Eine Lösung könnte sein, dass wir das Wann verändern. Wenn der Archivierungsdienst fehlschlägt, weil er z.B. gerade gewartet wird, dann versuchen wir es nach X Minuten/Stunden erneut.

Wo passiert das?
Die Frage nach dem Ort kann wieder vielschichtig sein. An welcher Stelle soll dieser Druckknopf sein? Gibt es eventuell eine Bedingung dafür? „Wenn das Archivieren fehlgeschlagen ist, dann soll der Knopf oben Rechts erscheinen“ Oder viel plastischer, wo soll denn ausgedruckt werden? Wieder aha! Es gibt also einen Drucker in einem speziell gesicherten Archivierungsraum, in dem diese Dokumente zwischengelagert werden. Und dieser ist nur über eine ganz spezielle Schnittstelle erreichbar. Gut, wieder etwas, dass wir berücksichtigen müssen.

Wieso machen Sie es so?
Und schließlich die Ketzerfrage. Wieso gerade so? Gibt es einen zwingenden Grund dafür? Oder könnten wir es eventuell smarter gestalten? Wieso möchten Sie umbedingt, dass das Dokument per sofort und sicher archiviert ist? Vielleicht kommt heraus, dass alle paar Minuten ein Lösch-Job über fertige Dokumente läuft, da es hierfür eine gewisse rechtliche Anforderung gibt? Wäre es dann aber nicht viel sicherer, wenn der Lösch-Job den Status „Archiviert“ abfragt? Und wenn das archivieren fehlschlägt, könnte er das Dokument in einen geschützten, Bereich verschieben, auf dem es keiner einsehen kann. Dieser ist zwar kein Archiv im rechtlichen Sinne, kann jedoch als Zwischenstation genutzt werden, bis die Archivschnittstelle wieder läuft. Vielleicht ist es ja sogar sinnvoll, eine zweite, unabhängige Archivierungsfunktion zu nutzen, die in dasselbe Archiv geht? Wenn die Anforderung ein PDF-A an Ort X ist, dann könnte das ja auch durch eine andere Software bewerkstelligt werden, sofern die erste in Wartung ist. Oder wie wäre es mit zwei unabhängigen Servern, die den Dienst betreiben und nacheinander gewartet werden?

Zusammenfassung und Fazit

Wir sehen bereits anhand dieses einfachen Beispiels, welche Macht und welcher Nutzen in den W-Fragen steckt, und wie sie die User Story erweitern. In unserem Beispiel war die User Story „Als Außendienstmitarbeiter möchte ich etwas drucken können, um die Daten immer sicher abzulegen.“ Aus dieser Story haben wir durch die 7 Fragen, die natürlich auch mehrfach und mit unterschiedlicher Formulierung genutzt werden, sehr viel mehr herausgeholt. Wir wissen, es geht darum, dass ein Dokument immer verlustsicher vor einem Lösch-Job archiviert werden muss. Dieser Job ist wichtig, damit kein anderer auf dieses Dokument zugreifen kann, da es sich um eine rechtliche Anforderung handelt. Der Außendienstler muss in der Lage sein dieses Dokument auch von außen über sein Smartphone zu archivieren. Entsprechend benötigen wir eine Schnittstelle, die noch dazu abgesichert sein muss, da das Formular ja nicht in fremde Hände geraten darf. Und schließlich haben wir noch das bewährte Vorgehen hinterfragt und eine Alternative zum Ausdrucken angeboten, die nun vom Kunden bewertet wird.

Natürlich ist diese Arbeit sehr aufwendig. Wenn wir sie für jede einzelne User Story durchführen, haben wir alleine in der Anforderungsermittlung sehr viel zu tun. Doch es lohnt sich. Denn je klarer eine Anforderung ist, desto genauer können wir abschätzen, was eigentlich zu tun ist. Was dem Kunden hier wirklich wichtig ist und wo wir vielleicht nur Schleifen am Nachthemd haben. Wenn wir diesen kritischen Pfad einer Anforderung ermitteln, können wir auch leichter die Umsetzungszeit, die Testaufwände (gemessen auch an der Kritikalität) und damit schlussendlich die Kosten ermitteln. Außerdem können wir dem Kunden genau erklären was wir vorhaben und wie die Kosten zustande kommen. Die Glaskugel, mit der wir Aufwände abschätzen wird damit um vieles klarer und das Risiko für beide Seiten kleiner. Die Tiefe der Fragen und die Zeit, die wir dafür aufwenden, hängen dann natürlich wieder davon ab, wie kritisch das jeweilige Thema ist und wie der Rahmen für das Gesamtprojekt ist.

Projekt „Intranet Relaunch“ I

Was erwartet euch in dieser Serie?

Wie bereits erwähnt ist mein Schwerpunkt die Technologiefamilie SharePoint mit all Ihren Facetten. Von OnPrem bis O365 und Apps, von 2007 bis 2016, von InfoPath und Nintex über C# bis zum JavaScript Object Model ist diese Landschaft sehr vielschichtig und bietet für große Unternehmen viele Einsatzmöglichkeiten über – aus der IT gesehen – lange Zeiträume.

Oft ist es nun so, dass ein Kunde, wenn er zu uns kommt, bereits eine Technologie für eine Fragestellung im Einsatz hat. Nehmen wir mal als Beispiel ein Intranet. Es gibt also bereits ein Portal, auf das die Nutzer zugreifen können um sich über Unternehmensinhalte zu informieren. Hier beginnt unsere neue Serie, die sich damit beschäftigt, wie man ein neues Intranet am Beispiel von O365 SharePoint einführen könnte. Mein Fokus soll dabei nicht auf den technischen, sondern den organisatorischen Schwierigkeiten liegen, die ein Kunde damit hat.

Wir werden bei der IT beginnen, welche das Intranet nicht länger Supporten möchte. Davon ausgehend ein Vorprojekt durchführen, eine Ausschreibung starten, die Bewerberauswahl durchführen, das Konzept erstellen und abnehmen, ein Team zusammenstellen, das Projekt mit all seinen Zwischenschritten durchführen, die Meetings abhalten, die Tests abnehmen, die Anwender schulen, das Projekt live schalten und schließlich den Support für das neue Intranet initiieren.

Es handelt sich also um einen vollständigen Zyklus, den ein solches Projekt durchlaufen muss und wird somit auch einen Querschnitt und zahlreiche Verweise auf alle Themen liefern, die ich auch sonst in diesem Blog so behandelte. Ich freue mich über fleißige Leser und Feedback zu meinen Artikeln. Viel Spaß beim Lesen!

Bestandsaufnahme

Für diese Serie nehmen wir ein kleines Beispiel. Ein Unternehmen hat 300 Mitarbeiter und möchte ein ihr bestehendes Intranet ablösen. Das bestehende Intranet beinhaltet aktuell Nachrichten aus dem Konzern, eine Wissensbibliothek, ein Workflow für die Urlaubsfreigabe und eine Anwendung für die Arbeitszeiterfassung. All diese Module existieren bereits seit einigen Jahren und wurden 2011 von einem externen Dienstleister nach dem Stand der Technik mit SharePoint 2010 umgesetzt.

Die IT stellt nun fest, dass es für diese Version in Zukunft keinen Mainstream Support mehr geben wird. Damit widerspricht die Lösung einer internen Richtlinie und muss abgelöst werden. Also informiert sie die zuständige Fachabteilung und veranlasst, dass nach einer neuen Lösung gesucht wird.

Der Fachseite selbst fehlt die entsprechende Expertise um den Wechsel eines Intranets durchzuführen. Also beauftragt sie in einem Vorprojekt zunächst einmal ein Beratungshaus damit den Status Quo zu ermitteln und die notwendigen nächsten Schritte auszuloten. Das Beratungshaus stellt dafür zunächst 3 Consultants bereit. Zum einen Infrastrukturspezialisten, welcher einen Health Check für die SharePoint-Infrastruktur durchführt. Der zweite Consultant ist ein Softwarearchitekt, welcher den Aufbau des Intranets analysiert. Als letztes schickt das Unternehmen noch einen Business Consultant. Er hat in dieser Phase die wahrscheinlich wichtigste Funktion. Denn er wird die Nutzer des alten Intranets ansprechen und über Interviews und Umfragen versuchen einen Blick in den Alltag dieser Kollegen zu erhalten.

Diese 3 Themen werden auch den Einstiegspunkt für uns in das Thema „Relaunch Intranet“ sein und einzeln in jeweils einem Beitrag behandelt werden.

SharePoint Customizations – wann nutze ich welches (DEV)-Modell?

Ein Kollege von mir ist auf einen exzellentes Webcast von „SharePoint Patterns & Practices“ gestoßen, dass ich euch nicht vorenthalten möchte. In dem 48 minütigen Beitrag geht es darum, welche Art der Entwicklung wann Sinn ergibt. Dabei werden folgende Typen betrachtet:

  • SharePoint Farm / Sandbox solutions – WSPs
  • SharePoint add-in model
  • Single page apps / externally hosted apps
  • SharePoint Framework

Die Betrachtung richtet sich dabei nach den Kriterien Wirtschaftlichkeit, Flexibilität, Zukunftssicherheit und O365 Fähigkeit.

Das Video habe ich euch direkt eingebunden. Den kompletten Beitrag findet ihr hier: SharePoint PnP Webcast – SharePoint Customizations – When to use which model?