Wenn Sie Produkte entwickeln, stellt sich spätestens kurz nach der ersten Phase der Rapid-Prototyping-Euphorie heraus, dass Sie und ihr Team sich nicht mehr alles merken können, was Sie so unterwegs entschieden haben. Solange Funktionsumfang und Team noch klein sind, ist das kein Problem. Im Zweifelsfall wiederholen Sie Entscheidungs-Meetings einfach und hoffen, dass nochmal dasselbe rauskommt und Sie nicht zu viel Zeit dabei verballern. Wird Ihr Team aber größer, wird der Funktionsumfang des Produkts größer, wird das Produkt langlebiger oder werden Teile auch mal an Externe ausgelagert, dann spätestens vermittelt eine Beschreibung der Produktmerkmale ein gutes Gefühl. Haben Sie bis dahin die Kurve noch nicht gekriegt und unterlassen Sie nach wie vor die Beschreibung Ihres Produkts, dann geht es so richtig bergab. Aber eigentlich muss man nichts aufschreiben – wie die folgenden sieben Geschichten zeigen.
Agil bringt’s, weil man nichts aufschreiben muss
Wir entwickeln ja alles agil und dass funktionierende Software Vorrang vor extensiver Dokumentation hat, steht schon so im agilen Manifest. Das ist zwar nicht direkt eine Empfehlung zur Unterlassung aller Produktdokumentation, aber unter Ausnutzung des sicherlich gegebenen Interpretationsspielraums ist es bestimmt so gemeint gewesen. Und dann muss es ja stimmen. Ja gut, Herr Sutherland hat später in einem Interview zwar gesagt, dass er sich im Nachhinein gewünscht hätte, diesen Satz etwas weniger missverständlich formuliert zu haben und man ihn derzeit leider gerne hernimmt, um damit leichtfertig das Unterlassen jeglicher Produktdokumentation zu begründen, aber da war er ja auch schon älter und hat das vielleicht gar nicht mehr so recht verstanden, was er da gesagt hat.
Entscheidungen sind immer für die Ewigkeit
Entscheidungen für oder gegen Produktmerkmale sind grundsätzlich für die Ewigkeit. Einmal implementiert haben sie Bestand. Dass man sich später mal anschauen muss, was man früher genau festgelegt hat (weil man sich Gedanken drüber macht, es ändern zu wollen), ist eine immer wieder gern und völlig zu Unrecht aufgebrachte Mär, die vielleicht für schlechte Produktmanager und Product Owner gilt ‑ aber nicht für uns. Zudem ist es ja auch schwierig, eine einmal getroffene Entscheidung bezüglich eines Produktmerkmals zu revidieren. Das zeigt schließlich, dass man früher falsche Entscheidungen getroffen hat. Und wenn alle Stricke reißen gilt immer noch: Der Sourcecode ist seine eigene Dokumentation. Ein Produktmerkmal aus 10.000 Zeilen Python zu rekonstruieren, ist schnell erledigt.
Abnahmetests nach Gefühl sind eh besser als nach Feature
Abnahmetests, die sklavisch die Liste der vereinbarten Produktmerkmale durchgehen, sind ein Zeichen von Misstrauen. Wenn wir bei Misstrauen angelangt sind, ist das Verhältnis zum Auftraggeber sowieso schon nachhaltig gestört. Soweit lassen wir es ja schon vorab nicht kommen. Es wird auch nie passieren, dass ein Auftraggeber auf die Idee kommt, den Preis drücken zu wollen oder einfach den schwarzen Peter für nicht erfolgreiche Produktfeatures bei jemand anderen abladen zu wollen. Das war früher mal so, inzwischen ist dieses Problem in modernen Organisationen (und es gibt ja mittlerweile keine anderen mehr) aber Gott sei Dank flächendeckend geheilt.
Dokumentation heilt sowieso nicht alle Probleme
Eine – durchaus zutreffende – Erkenntnis ist, dass jede noch so sorgfältige Dokumentation von Produktmerkmalen nicht in der Lage ist, ein gemeinsames Verständnis zu erzeugen. Und bedeutet das nicht im Grunde, dass die Abwesenheit derselben notwendiges und hinreichendes Kriterium ist? Doch sicherlich, oder? Ganz klar ein weiterer Punkt, der zeigt, dass Spezifikationsarbeit nicht viel Wert ist!
Warum sich festlegen, wenn man sich doch alles offen halten kann
Dokumentierte Produktmerkmale sorgen viel zu früh dafür, dass man sich festlegen muss. Durch dieses erzwungene Festlegen-Müssen wird Kreativität im Team unterdrückt – was ein Zeichen struktureller Gewalt ist – sowie eine Kultur der Furcht etabliert und Flexibilität hinsichtlich der Frage, welches Problem das Produkt eigentlich lösen muss, rigoros unterbindet.
Leistungsbeschreibungen sind nervig – moderne externe Entwicklung geht ohne
Früher oder später kommt sie: die Notwendigkeit, Teile des Produkts anderswo entwickeln zu lassen. Weil die das besser können. Oder weil man gerade keine Ressourcen frei hat. Nur wollen die dummerweise so nervig genau wissen, was sie eigentlich machen sollen. Und ohne eine Leistungsbeschreibung wollen die einfach kein Festpreisangebot machen. Verwöhnte Branche. Na gut, dann halt Abrechnung nach Tagen. Ist zwar teurer, aber was soll’s.
Bunte Zettel sind eh mehr wert
Gott sei Dank gibt es moderne Methoden, mit denen man um diese Fleißarbeit der Spezifikation herumkommt. Design Thinking zum Beispiel. Die genaue Vorstellung vom Produkt kann man nämlich auch ganz ohne Kenntnisse der grundlegenden Kulturtechnik des Schreibens festhalten. Man benötigt dazu nur möglichst viele, unterschiedlich farbige Post-Its, Stifte und viele Menschen, die Lust haben, die Zettel mit kleinen Bildchen voll zu malen und an die Wand zu kleben. Genauer geht’s eigentlich nicht.
Fazit
Scherz beiseite – es gibt wohl doch einige gute Gründe, Produktmerkmale in einer Spezifikation aufzuschreiben. Die wesentlichen sind die folgenden:
- Produkte sind komplex. Komplexer als dass man sie sich in allen Details einfach so merken könnte.
- Die genauen Beschaffenheiten der einzelnen Produktmerkmale müssen meist verschiedensten Stakeholdern (Entwicklern, Testern, …) zur Verfügung stehen – auch dann, wenn die Produkt-“Erfinder” mal gerade nicht zu sprechen sind.
- Produkte sind langlebig – und niemand kann sich an komplexe Konzepte erinnern, die er zusammen mit ein paar anderen Leuten vor Jahren mal ausgeknobelt hat.
Aber wieviel Aufwand sollte man in eine Produktspezifikation stecken? Es sollte ja nicht in Richtung “l’art pour l’art” gehen. Dazu gibt es eine Faustregel, mit der man sich zumindest in die richtige Richtung bewegen kann: Je mehr Risiko man bereit ist, in Kauf zu nehmen (im Sinne von Unterschied zwischen Wunsch und geliefertem Produkt), desto weniger Spezifikation. Und umgekehrt: je wichtiger es einem ist, dass auch genau das rauskommt, das man haben will, desto mehr Mühe muss in die Spezifikation fließen.