Ich habe dieses Feld auf dem Projektplan hunderte Male gesehen. Es hat immer dieselbe Bezeichnung: Anforderungen festlegen. Das Zeitfenster dafür ist stets bemerkenswert klein – nur ein oder zwei Tage (oder manchmal noch weniger!).
Wenn ich Projektmanager frage, was an dieser Stelle passiert, erzählen sie mir notgedrungen, dass sie mit den wichtigsten Stakeholdern sprechen und die Anforderungen, die zur Sprache kommen, einsammeln. Es geht darum, auf die Wiese zu gehen und Beeren für das Projekt zu pflücken.
Wie kommt es, dass diese wichtigen Stakeholder diese Anforderungen kennen? Nun, offenbar ist es einfach so. Sie haben einige Zeit darüber nachgedacht (abgesehen von denen, die es nicht getan haben). Sie haben mit Kunden gesprochen (abgesehen vom Großteil, der noch nie mit Kunden geredet hat). Sie haben mit den Vertrieblern und den Technologen und den Business-Leuten gesprochen, die ihnen genau erklärt haben, was nötig ist, um dieses Produkt erfolgreich zu machen. (Aber woher wissen diese Leute das nun wieder?)
Einmal zusammengetragen, werden die Anforderungen in ein Dokument geätzt (das Product-Requirements-Dokument oder PRD). Sobald das geschehen ist, wird es nie wieder verändert oder aktualisiert. Es ist das Evangelium, das die Grundlage des Projekts bildet. Es ist das, was wir nun konzipieren, designen und programmieren werden.
Entgleisende Zeitplanungen vermeiden
Wir haben nicht immer Anforderungen gesammelt und ein PRD aufgesetzt. In früheren Tagen haben wir das Projekt von einem einfachen Ziel wie "Konvertiere das statische HTML-Intranet, damit es auf MS SharePoint läuft" aus gestartet. Wie schwer kann das am Ende schon sein? Die Seiten haben wir alle schon. Wir kippen sie nur in die neue Plattform und voila, fertig!
Aber das hat nicht funktioniert. Irgendwo mitten im Projekt stoßen wir auf etwas, das wir nicht wussten. Etwas, dass wir hätten wissen sollen. Wie das neue Zielvereinbarungssystem der Personalabteilung, das sie integriert haben wollen. Oder das Strategiehandbuch, das als PDF vorliegt und konvertiert werden muss.
Bald ist das Projekt entgleist. Wir müssen Dinge tun und hinzufügen, von denen wir nicht wussten, dass sie getan oder hinzugefügt werden müssen. Wir versuchen, sie in die bestehende Architektur einzubauen, aber das geht nur ein Stück weit. Und schon bald sind wir dabei, dem ganzen System eine neue Architektur zu verpassen. Alles verspätet sich immer mehr und die Planung entgleitet uns.
Die Sammlung von Anforderungen zu Beginn des Projekts war dazu bestimmt, solche Planungsunfälle zu vermeiden. Wenn wir die Personalabteilung dazu bringen, uns im Voraus von der Zielvereinbarungs-Software und dem Strategiehandbuch zu erzählen, können wir Zeit einplanen, um das zu erledigen.
Das Sammeln von Anforderungen funktioniert nicht
Das Problem besteht darin, dass das Füllen einer Kiste mit Anforderungen am Anfang der Planung das Entgleisen nicht verhindert. Gut, wenn es unser Ziel ist, den Stakeholdern, mit denen wir gesprochen haben, die Schuld in die Schuhe zu schieben ("Ihr habt es uns vorher nicht gesagt, als wir gefragt haben!"), dann können wir wahrscheinlich schnell Vollzug melden. Haben wir allerdings das Ziel, eine großartige Anwendung zu entwickeln, die die User erfreut und mit der sie ihre Ziele erreichen, müssen wir weg von den initialen Anforderungen hin zu etwas, das funktioniert.
Wenn wir Anforderungen sammeln, sagen wir, dass das Team in zwei Arten von Leuten unterteilt ist: jene, die wissen, was wir brauchen, und jene, die das nun zusammentragen müssen. Das ist eine Schieflage in der Teamstruktur, die alle auf dem falschen Fuß erwischt.
Der Prozess erfordert, dass wir in Dinge vertrauen, die wahr sein können oder auch nicht – ohne Checks und Prüfungen, um zu sehen, ob wir richtig liegen. Er erfordert, dass wir alles im Voraus wissen, und blendet den Gedanken aus, dass wir unterwegs womöglich etwas lernen könnten. Und er treibt uns dazu, uns dafür zu schämen, dass wir irgendwo ein Detail ausgelassen haben, obwohl wir damals unmöglich davon wissen konnten.
Damit dieser Prozess funktioniert, müssen die Stakeholder in die Zukunft schauen können und allwissend sein. Ganz offen: Es funktioniert niemals.
Die Erlösung ist Wissenschaft (und mehr)
Wenn wir keine Anforderungen sammeln, wie wollen wir dann lernen, was unsere Kunden und Nutzer brauchen? Wie erfahren wir etwas über die geschäftlichen und technologischen Rahmenbedingungen?
Die Antwort: mit Wissenschaft (und einem kleinen Extra)!
Wir haben festgestellt, dass die besten Teams das Sammeln von Anforderungen durch vier Kernaktivitäten ersetzen, die die Machtverhältnisse dynamisch verändern. Es scheint, als wüsste niemand, was wir bauen müssen, allerdings haben ein paar Leute Ideen. Wenn wir diese Ideen validieren können und sie dann verfeinern, werden wir alle schlauer dahingehend, was unsere Kunden und User erfreut.
Diese vier Aktivitäten sind das Formulieren von Hypothesen, die Durchführung von Nutzerforschung, um diese Hypothesen zu testen, die Dokumentation des Beobachteten in Form von Szenarios und die Nutzung von Kritik, um zu validieren, das die Anwendung das unterstützt, was wir gelernt haben. Witzigerweise ist nichts davon neu. Wir wussten die ganze Zeit, wie wir diese Dinge machen. Die meisten von uns tun’s halt einfach nicht.
Hypothesen formulieren
Den Kern einer jeden Anforderung bildet eine Sammlung von Annahmen. Wenn unsere Anforderung "Die Homepage sollte Links auf die heute am häufigsten besuchten Seiten enthalten" lautet, ist damit ein bunter Strauß von Annahmen verbunden. Wir nehmen an, dass die am häufigsten besuchten Seiten zu den Dingen gehören, auf die die Leute zugreifen wollen. Wir nehmen an, dass sie das über die Homepage tun wollen. Wir nehmen an, dass alle dieselbe Homepage mit denselben Links brauchen.
Woher sollen wir wissen, dass diese Annahmen korrekt sind? Woher sollen wir wissen, ob es da zum Beispiel nicht noch eine andere Seite gibt, auf die niemand zugreift, die aber extrem nützlich ist? Woher sollen wir wissen, dass die User die Homepage statt ihrer Browser-Bookmarks nutzen werden?
Indem wir unsere Annahmen in Form von Hypothesen formulieren, erkennen wir an, dass wir nicht alles wissen können. Viel wichtiger ist, dass wir die Diskussion eröffnen, um zu sehen, was wir wissen und was nicht.
Statt eine Anforderung festzulegen, können wir sagen: "Wir denken, dass Links zu den am häufigsten besuchten Seiten die beste Möglichkeit bilden, dem User zu helfen. Finden wir heraus, ob das stimmt." Eine Hypothese ist etwas, das bewiesen oder widerlegt werden kann, und mittendrin sind wir und lernen jede Menge wichtige Dinge über jeden Schritt auf dem Weg.
Nutzerforschung betreiben, um die Hypothesen zu testen
Hier fängt die Wissenschaft richtig an. Wenn unser Team Experimente aufbaut, um unsere Hypothesen zu testen, können wir beobachten, wie unsere Nutzer heute arbeiten. Wir können sehen, welche Seiten sie besuchen. Noch wichtiger: Wir können sehen, wo sie eine Seite im Verlauf des Tages hätten nutzen können, es aber nicht taten (weil sie vielleicht nichts von ihr wussten oder weil sie zu schwer zu finden war).
Wir betreiben Nutzerforschung, indem wir User besuchen und beobachten, wie sie leben und arbeiten. Wir können die Rahmenbedingungen des Marktes und die technologischen Limitierungen ebenfalls erforschen. Wir können kleine Prototypen programmieren, um zu sehen, ob die Server schnell genug antworten. Wir können verschiedene Preismodelle an künftigen Kunden ausprobieren, um zu sehen, ob sie die Unterschiede beschreiben können.
Jedes Experiment macht uns klüger. Darum ist es wichtig, das gesamte Team inklusive der Stakeholder in diese Experimente einzubeziehen. Wir können ihr Bauchgefühl testen, indem wir sie bitten, die Ergebnisse eines Experiments zu prognostizieren, und das dann mit dem vergleichen, was wir tatsächlich sehen.
Vergegenwärtigung durch Szenarien
All diese Nutzerforschung bringt gewaltige Einsichten darüber, wie die Leute heute arbeiten. Wir bekommen ihre Motivation und die Realität ihrer spezifischen Situationen zu sehen. Wir können anfangen, uns vorzustellen, wie unsere Anwendung ihr Leben besser machen kann.
Diese Einsichten lassen sich mithilfe von Szenarien festhalten. In jedem Szenario beschreiben wir, was unsere künftigen User erreichen möchten, warum sie das wollen und welche Herausforderungen sie überwinden müssen, um das in die Tat umzusetzen.
Nutzerforschungsbasierte Szenarien sind ein praktischer Weg, um Anforderungen abzubilden, denn sie halten den Fokus des Teams darauf gerichtet, was die User tun werden. Sie bringen das Warum auf den Tisch, statt mit einer Liste mit oftmals widersprüchlichen, entmenschlichten Was-Aussagen zu arbeiten. Das Szenario wird zur Form, in die wir unser Design gießen. Es sagt uns, welche Lücken und Ritzen gefüllt werden müssen, um ein großartiges Nutzererlebnis zu erschaffen.
Validierung durch Kritik
Wenn sich Lösungen abzeichnen, ist Kritik essenziell, um die Anforderungen am Leben zu halten. Gute Kritik stellt zwei Fragen: "Was versuchen wir hier zu tun?" und "Erreichen wir das mit dieser Design-Alternative?" Kritik ist der Wegweiser, der dafür sorgt, dass wir in Sachen Anforderungen alle auf einer Seite stehen.
Indem wir etwas Zeit darin investieren, die Anforderungen mithilfe von Kritik zu überdenken, stellen wir sicher, dass sie nach wie vor valide sind, speziell vor dem Hintergrund des ganzen Krams, den wir seit dem Start gelernt haben. Dank der entstehenden Diskussionen sind die Anforderungen stets in den Köpfen präsent, statt in einem Dokument begraben zu sein, in das monatelang niemand reinschaut, wenn überhaupt. Es ist aufregend zu sehen, wie die Kreativität des Teams expandiert, wenn jeder die Möglichkeit hat, verschiedene Lösungen dahingehend auszutesten, ob sie in den Mantel des Szenarios passen.
Zeit sparen, indem wir Zeit investieren
Das Zeitfenster für das Sammeln von Anforderungen ist ziemlich klein. Höchstens ein paar Tage sind dafür eingeplant.
Die alternativen Aktivitäten – Hypothesen aufstellen, Nutzerforschung betreiben, Szenarien ausarbeiten und Kritik üben – erfordern mehr Zeit. Viel mehr Zeit. Wie soll das gehen, ohne das Projekt in die Länge zu ziehen?
Wir müssen diese Aktivitäten mit dem Rest des Projekts in Kontext setzen. Wieviel Zeit sparen wir, wenn wir einer großartigen Lösung schneller nahekommen? Wieviel Zeit gewinnen wir dadurch, dass sich alle darüber einig sind, warum wir machen, was wir tun?
Wir entfalten diese Aktivitäten fast über das gesamte Projekt hinweg, statt Anforderungen am Anfang in eine enge Kiste zu stecken. Sie sorgen dafür, dass praktisch jeder andere Projektabschnitt besser und schneller läuft. In der seltsamen Welt der Projektphysik läuft es darauf hinaus, dass wir Zeit sparen, indem wir Zeit investieren.
Und das Wichtigste ist, dass wir am Ende eine Anwendung haben, die auf wirklichen Anforderungen basiert und so hervorragende Nutzererlebnisse ermöglicht. Dafür hat man uns ja schließlich ins Boot geholt.
Dieser Artikel wurde im Original am 25. Juni 2013 unter dem Titel Replacing "Requirements Gathering" with Something That Works
