Prototyp vor der Entwicklung statt Lastenheft: Warum eine hundertseitige Spezifikation kein Projekt rettet

Ein Unternehmen arbeitet mehrere Monate an seinem Lastenheft. Das Dokument umfasst über hundert Seiten und wurde von Vertrieb, Operations, Finanzen und IT kommentiert. Nach der Vertragsunterzeichnung mit dem Dienstleister folgen Monate der Entwicklung, und bei der ersten Vorführung heißt es: „So haben wir das nicht gemeint.“

Das Szenario ist fiktiv, das Problem dahinter ist jedoch real. In der internationalen NaPiRE-Umfrage, die 228 Organisationen aus 10 Ländern vollständig ausgefüllt haben, wählten die Befragten die kritischsten Probleme im Requirements Engineering aus. Am häufigsten nannten sie unvollständige oder verborgene Anforderungen (48 % der Befragten). Mängel in der Kommunikation zwischen Team und Kunde nannten 41 %, und unter den zehn wichtigsten Problemen stuften die Befragten sie am häufigsten als schwerwiegende Ursache für das Scheitern eines Projekts ein.

Ein umfangreiches Lastenheft vermittelt ein Gefühl von Sicherheit, doch das Entscheidende lässt sich daran nicht testen: ob Menschen die Lösung verstehen und ihre Arbeit damit bewältigen. Wer nach dem Prinzip „Prototyp statt Lastenheft“ vorgeht, sieht das innerhalb weniger Tage bis Wochen, solange Korrekturen noch günstig sind, und nicht erst nach Monaten der Entwicklung.

Warum die Unterschrift unter dem Lastenheft nicht vor Missverständnissen schützt

Eine Unterschrift bestätigt die Zustimmung zum Text, nicht aber, dass sich beide Seiten darunter dasselbe vorstellen. Frederick P. Brooks Jr. schrieb 1987 in seinem Essay No Silver Bullet, der schwierigste Teil der Softwareentwicklung bestehe darin, genau zu entscheiden, was gebaut werden soll, und kein anderer Teil sei später schwerer zu korrigieren. Ihm zufolge ist es für den Kunden tatsächlich unmöglich, die Anforderungen an moderne Software vollständig, präzise und korrekt zu spezifizieren, bevor er einige Versionen davon ausprobiert hat.

Ein dickes Dokument verdeckt dieses Problem aus unserer Sicht eher. Mit jeder Seite wächst das Gefühl der Vollständigkeit, doch jede Abteilung liest vor allem ihr eigenes Kapitel, und Selbstverständlichkeiten schreibt niemand auf. Das erste Feedback zu etwas Greifbarem erhält das Unternehmen erst, wenn auf dem Missverständnis bereits Code steht. Brooks bezeichnete es im selben Essay als grundlegend falsche Annahme der damaligen Softwarebeschaffung, dass sich ein System vorab zufriedenstellend spezifizieren, ausschreiben, bauen und installieren lasse.

Derselbe Satz, verschiedene Screens

Einen Text kann man nicht benutzen, deshalb können Sie daran nicht überprüfen, ob ihn alle gleich verstehen. Nehmen Sie als Beispiel die Anforderung „Bestellungen über dem Limit gibt der Vorgesetzte frei“. Die Finanzchefin stellt sich eine morgendliche Übersicht zur Sammelfreigabe vor, der Lagerleiter eine Benachrichtigung auf dem Smartphone, der Entwickler ein Statusfeld in einer Tabelle. Alle Vorstellungen stimmen mit dem Satz überein, und jede führt zu anderem Aufwand und anderen Kosten.

Ausnahmen zeigen sich erst, wenn die Aufgabe tatsächlich ausgeführt wird. Wer gibt frei, wenn der Vorgesetzte im Urlaub ist? Gilt die Freigabe auch nach einer Mengenänderung?

Ein Viertel der NaPiRE-Befragten zählte zudem zu den kritischsten Problemen, dass Stakeholder Anforderungen nur schwer von Lösungen trennen können, die sie bereits kennen. Das GOV.UK Service Manual, der Leitfaden der britischen Regierung, rät, eine vorab festgelegte Lösung in der Discovery-Phase, also bei der Untersuchung des Problems noch vor dem Bau, als Problem neu zu formulieren: nicht „eine interaktive Karte der Servicezentren bauen“, sondern „wie wir Menschen die Suche nach dem nächstgelegenen Servicezentrum erleichtern“.

Was ein Prototyp ist und was nicht

Ein Prototyp ist eine vereinfachte Form des künftigen Produkts, an der sich eine Lösung ausprobieren lässt, bevor sie programmiert wird. Kara Pernice von der Nielsen Norman Group beschreibt ihn als Hypothese, also als Lösungskandidaten, den Sie am direktesten überprüfen, indem Sie Menschen bei der Arbeit damit beobachten. Er ist kein Minimum Viable Product (MVP), das Eric Ries als die Version eines neuen Produkts definiert, mit der ein Team bei geringstem Aufwand ein Maximum an validierten Erkenntnissen über seine Kunden gewinnt. Der Prototyp ist ein engeres Werkzeug: Er prüft die entworfene Lösung noch vor ihrem Bau.

Die Detailtreue (Fidelity) eines Prototyps ist laut Pernice das Maß, in dem er dem fertigen System ähnelt, und zwar in Interaktivität, visueller Gestaltung sowie Inhalt und Befehlen. Für die Entscheidung vor der Entwicklung unterscheiden wir in der Praxis drei Stufen:

• Skizze oder Papierprototyp. Statt des Systems reagiert ein Mensch, der den Entwurf kennt, und reicht dem Nutzer die nächsten gezeichneten Screens. Bei der verwandten Wizard-of-Oz-Methode steuert eine Person den Bildschirm aus einem anderen Raum, sodass sich auch Verhalten testen lässt, das noch niemand programmiert hat. Jakob Nielsen zählt Paper Prototyping zu den schnellsten und günstigsten Techniken. Diese Stufe eignet sich, um den grundlegenden Ansatz und den Ablauf zu prüfen.
• Klickbarer Prototyp (Klickdummy). Verknüpfte Screens, die wie eine Anwendung reagieren, obwohl dahinter nichts läuft. Damit prüfen Sie, ob Menschen die zentralen Aufgaben ohne Hilfe bewältigen.
• Funktionsfähiger Prototyp mit echten Daten. Ein begrenztes Stück echten Codes, angebunden an eine Datenstichprobe oder eine riskante Integration. Sinnvoll ist er, wenn die Unsicherheit nicht in der Benutzeroberfläche liegt, sondern in den Daten oder der Technologie.

Unsere Auswahlregel: die niedrigste Detailtreue, die die aktuelle Frage noch beantwortet. Laut Nielsen hat ein früher Test gegenüber einem späten einen so großen Vorsprung, dass dieser sogar den Unterschied in der Qualität des Prototyps überwiegt. Das Design Kit von IDEO.org rechnet beim Rapid Prototyping mit einigen Tagen bis Wochen, je nachdem, was getestet wird.

Was ein App-Prototyp belegen muss

Ein Prototyp ist ein Test, keine Präsentation. Laut dem GOV.UK-Leitfaden müssen Sie nicht die gesamte User Journey als Prototyp abbilden; oft genügt es, sich auf die anspruchsvollsten Teile zu konzentrieren und die riskantesten Annahmen zu testen. Vor der Entwicklung sollte ein Prototyp diese Fragen beantworten:

1. Verstehen die Menschen den Ablauf? Bewältigt auch jemand, der nicht am Entwurf mitgearbeitet hat, die Aufgabe von Anfang bis Ende? Jedes Zögern im Test kann im Echtbetrieb ein Anruf beim Support oder ein Fehler in einer Bestellung sein.
2. Sind die zentralen Entscheidungen gefallen? Ein Text erlaubt es, einen Streitpunkt zu vertagen, ein Screen nicht. Was jetzt entschieden wird, bleibt nicht als Unsicherheit im Angebot stehen.
3. Hält der Entwurf echten Daten stand? Echte Bezeichnungen sind oft länger als in der Demo, Felder sind leer und Datensätze doppelt.
4. Funktioniert die riskanteste Integration? Eine Integration ist die Anbindung an ein anderes System, etwa an die Buchhaltung. Der britische Dienst Register to vote würde ohne API nicht funktionieren, also ohne eine Schnittstelle für den Datenaustausch, die an die Registrierungssysteme von mehr als 400 Kommunalverwaltungen angebunden ist. Das Team konzentrierte sich deshalb bereits in der Alpha-Phase, die für Prototypen vorgesehen ist, auf diese Schnittstelle.
5. Nehmen die Nutzer die Lösung an? Ein Prototyp garantiert keine Akzeptanz, liefert aber Hinweise darauf, ob Menschen das neue Vorgehen ihren heutigen Workarounds vorziehen würden. Warum das wichtig ist, erläutert der Artikel Das teuerste System ist das, das Ihre Mitarbeiter nicht nutzen.

Testen mit Nutzern: beobachten statt fragen

Beim Usability-Test löst eine Person aus der Zielgruppe am Prototyp eine reale Aufgabe, etwa die Beispielaufgabe „Stellen Sie zu dieser Rechnung eine Gutschrift aus“, und Sie beobachten, wo sie zögert und was sie anders versteht. Ein Fragebogen erfasst, was Menschen nach eigener Einschätzung tun würden. Die Beobachtung zeigt, was sie tatsächlich tun.

Jakob Nielsen stützt sich auf ein Modell, nach dem eine erste Studie mit fünf Teilnehmern etwa 85 % der Usability-Probleme aufdeckt, also der Stellen, an denen Menschen hängen bleiben oder Fehler machen. Statt einer Studie mit 15 Personen empfiehlt er drei Runden mit je fünf, weil jede weitere Runde die Korrekturen überprüft und tiefer liegende Probleme sichtbar macht. Das gilt für vergleichbare Nutzer: Bei zwei deutlich unterschiedlichen Gruppen empfiehlt er drei bis vier Personen pro Gruppe.

Wann späte Änderungen wirklich teuer sind

Änderungskosten sind das, was die Korrektur einer Entscheidung in einer bestimmten Projektphase kostet. Barry Boehm und Victor Basili schrieben 2001 in einem Artikel, dass es oft 100-mal teurer ist, ein Softwareproblem nach der Auslieferung zu finden und zu beheben, als in der Phase der Anforderungen und des Entwurfs. Das Wort „oft“ fügten sie bewusst hinzu: Bei kleinen, unkritischen Systemen liegt das Verhältnis ihnen zufolge eher bei 5:1. Außerdem gaben sie an, dass die damaligen Projekte etwa 40 bis 50 % ihres Aufwands in vermeidbare Nacharbeit steckten, und zählten übereilt spezifizierte Anforderungen zu ihren beiden Hauptquellen.

Dass die Kosten mit der Zeit steigen, gilt jedoch nicht universell. Tim Menzies und seine Koautoren fanden in 171 Projekten keinen Beleg dafür, dass die Behebung von Problemen in einer späteren Phase durchgängig oder wesentlich mehr Aufwand kostet als kurz nach ihrem Entstehen. Dabei handelte es sich überwiegend um kleine bis mittlere Projekte nach der Methodik Team Software Process, ohne Daten aus der Zeit nach der Auslieferung. Die Autoren weisen selbst darauf hin, dass der Effekt möglicherweise nur bei bestimmten Projekttypen auftritt.

Aus unserer Sicht verteuert nicht der Kalender eine späte Änderung, sondern das, was inzwischen auf der Fehlentscheidung gewachsen ist: Code, Integrationen, Dokumentation, Schulungen und das Datenmodell. Kara Pernice erinnert daran, dass es sehr teuer ist, Code wegzuwerfen, einen Prototyp dagegen nicht. Ein nicht behobenes Missverständnis bezahlt das Unternehmen nach dem Go-live zudem jeden Tag als Reibungsverlust im Arbeitsalltag; wie sich dieser berechnen lässt, zeigt der Artikel Gutes Design ist keine Dekoration.

Ein Prototyp lohnt sich deshalb vor allem dort, wo auf einer Fehlentscheidung das meiste aufgebaut würde: bei vielen Nutzern, mehreren Integrationen und langer Entwicklungszeit. Umfang und Kosten des Prototyps lassen sich vorab begrenzen, die Kosten eines Irrtums nicht.

Der Prototyp als Grundlage für Angebot und Aufwandsschätzung

Wenn Dienstleister einen hundertseitigen Text kalkulieren, kalkuliert jeder seine eigene Auslegung und seinen eigenen Puffer für Unsicherheiten. Wer vorsichtig ist, setzt den Preis zu hoch an, wer weniger vorsichtig ist, zu niedrig, und die Differenz zeigt sich später in Change Requests, also in Leistungen außerhalb der ursprünglichen Vereinbarung, die gesondert abgerechnet werden.

Ein Klickdummy mit Akzeptanzkriterien verändert die Ausgangslage. Akzeptanzkriterien sind laut dem GOV.UK-Leitfaden eine Aufstellung von Ergebnissen, die als Checkliste dient, um zu bestätigen, dass ein Dienst seine Aufgabe erfüllt und den Bedarf der Nutzer gedeckt hat. Sie werden oft in der Form „fertig, wenn …“ formuliert, beim Dienst Register to vote etwa: Der Nutzer weiß, wie er sich online registriert. Der Prototyp zeigt, wie es funktionieren soll, die Kriterien legen fest, wann etwas fertig ist, und so kalkulieren die Dienstleister dasselbe.

Der Leitfaden rät außerdem zu überdenken, warum Sie eine Funktion brauchen, wenn sich ihr Ziel nicht formulieren lässt. Eine Funktion, die nicht gebaut wird, kostet weder in der Entwicklung noch in der Wartung etwas.

Risiken eines Prototyps

• Verwechslung mit dem fertigen Produkt. Ein Klickdummy sieht fertig aus, doch ihm fehlen Sicherheitsmechanismen, Datenverarbeitung und Fehlerbehandlung. Pernice weist darauf hin, dass die Führungsebene bei ausgefeiltem Design leicht der Versuchung erliegt, den Prototyp direkt live zu schalten.
• Zu viel Feinschliff an der Optik. Bei niedriger Detailtreue äußern Nutzer laut Pernice eher negative Reaktionen, Designer hängen weniger an ihrem Entwurf, und Stakeholder sehen, dass die Arbeit noch nicht abgeschlossen ist. Feinschliff dämpft ehrliches Feedback also eher.
• Unklare Zukunft des Prototyps. GOV.UK empfiehlt, in der Alpha-Phase nur das zu bauen, was zum Testen von Ideen nötig ist, keinen Code in Produktionsqualität, und damit zu rechnen, den Code am Ende der Phase zu verwerfen. Ob der Prototyp verworfen oder weiterentwickelt wird, muss vor seinem Bau entschieden werden. Sonst kann er aus Trägheit zur Grundlage des Produkts werden, mitsamt technischen Schulden, also Abkürzungen, die jede weitere Änderung verteuern.

Wann Sie keinen Prototyp brauchen

Ein Prototyp verringert Unsicherheit. Wo keine besteht oder sie sich günstiger verringern lässt, ist er ein unnötiger Kostenfaktor.

• Sie kaufen Standardsoftware ohne Anpassungen. Die Rolle des Prototyps übernimmt dann eine Testversion oder Demo, in der Menschen ihre realen Aufgaben durchspielen.
• Das System ist klein und unkritisch. Boehm und Basili schreiben, dass sich solche Systeme in einem weniger formalen Modus mit fortlaufendem Prototyping effizienter entwickeln lassen. Den separaten Prototyp ersetzt hier das Produkt selbst, das in kurzen Schritten entsteht.
• Die Frage lautet nicht wie, sondern ob überhaupt jemand das will. Dann kann ein Smoke-Test genügen, also eine Prüfung der Nachfrage, bevor es die Lösung gibt. Eric Ries beschreibt, wie sein Team zwei Wochen mit dem Bau einer Funktion verbrachte, die niemand wollte, obwohl das seiner Ansicht nach bereits ein einfacher Smoke-Test mit einer AdWords-Anzeige gezeigt hätte.
• Das Problem liegt nicht in der Software. Enthält der Prozess einen überflüssigen Schritt, bringt ein App-Prototyp ihn lediglich auf den Bildschirm. Diesen Schritt gilt es zuerst zu streichen. Ob sich ein eigenes System überhaupt lohnt, erläutert der Artikel Ein gutes internes System kann sich schneller bezahlt machen als ein neuer Mitarbeiter.

Laut GOV.UK ist es kein Scheitern, ein Projekt am Ende der Discovery-Phase zu stoppen, wenn die Untersuchung zeigt, dass dies die beste Entscheidung ist: Das spart Zeit und Geld. Entscheiden Sie über einen Prototyp deshalb danach, wo im Projekt die größte Unsicherheit liegt und was ein Irrtum kosten würde.

Was Sie mitnehmen

• Prüfen Sie vor der Unterschrift unter ein umfangreiches Lastenheft den riskantesten Teil mit einem Prototyp: den häufigsten Ablauf, eine strittige Ausnahme oder eine ungeprüfte Integration.
• Geben Sie jedem Prototyp vorab eine Frage und ein Erfolgskriterium mit, sonst bleibt vom Test nur eine Präsentation.
• Testen Sie mit fünf vergleichbaren Personen an realen Aufgaben und führen Sie nach den Korrekturen eine weitere Runde durch.
• Stützen Sie Lastenheft und Dienstleisterauswahl auf einen getesteten Prototyp und Akzeptanzkriterien, damit alle dasselbe kalkulieren.
• Benennen Sie zuerst die Unsicherheit, die Sie ausräumen wollen. Manchmal beseitigt sie eine Testversion von Standardsoftware, ein Smoke-Test oder eine Prozessanpassung günstiger.