Produktspezifikationen – sieben große Fehler
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.
Dokumentation mit kleinen bunten Zetteln – das reicht ja wohl …
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.
… nur eine Erfahrung am Rande: wenn man nicht in extensive Dokumentation investieren mag, was ich persönlich gut nachvollziehen kann weil sie eigentlich im Moment der Entstehung die Tendenz hat veraltet zu sein, dann sollte man vielleicht etwas mehr Aufwand in Bilder stecken.
Solche Übersichten haben die Eigenart
a. erstaunlich präzise zu sein
b. einen Teil in uns anzusprechen, der einen deutlich höheren Erinnerungswert hat (übrigens auch einen deutlich höheren Wiederverwendungswert)
c. einen sehr gut verwendbaren Abstraktionsgrad zu implementieren (wenn es unübersichtlich wird, ist es implizit “drüber” und das kann auch jeder gleich erkennen)
Ich habe jedenfalls in meinem Berufsleben vieler meiner Grafiken hinter den Wänden der Kollegen gesehen, die schlicht dazu sagten “Damit ist alles erklärt …”
Daneben verlange ich auf meinen Projekten immer “5 things to achive” und “5 things to NOT achieve”, was am Ende sprachlich die gleiche Abstraktionsebene hat wie Bilder.
Für den Rest der Doku ergibt sich im Grunde, was für viele Dinge in unserem Leben gilt: wir habe sie gebraucht um es gedanklich einmal richtig durchzukauen ;-)
Bin auch kein Freund extensiver Dokumentation. Ich lese den Blogartikel aber auch gar nicht so, dass er das fordert. Im letzten Absatz ist das ja eher so’n “so viel wie nötig”…
Bilder finde ich schön und gut, aber wie würdest Du denn bspw. einen bestimmten Rechenalgorithmus in Bildern beschreiben? Da tu ich mich immer schwer mit. Ich hab bspw. mal Software programmiert, die feststellen musste, welchen Restwert bestimmte Anlagegüter haben. Dazu gibt es halt Formeln. Und nein, die stehen auch nicht zum Abschreiben bereit in irgendwelchen Finanzmathematik-Büchern. Ich hätte die gerne in Bildern gehabt, aber ich hab keine Ahnung, wie das gehen soll.
Ein anderes Mal ging es darum, dass was historisiert werden sollte – aus Aufwandsgründen aber eben nicht alles, sondern nur manches. Also bspw. die Historie des Kundenaccounts und die wesentlichen Daten seiner Transaktionen – bis auf die Blobs, die da leider drin vorkamen. Das wäre einfach zu viel geworden. Auch hier: wie stellt man das in Bildern dar – und bitte wenn’s recht ist, eine Bildersprache, die man nach 2 Jahren auch noch eindeutig lesen kann – weil dann ein CEO hektisch reingeschneit kommt, der gerade von einem wichtigen Kunden gefragt worden ist, ob das ein Bug ist, dass die Rohdaten nicht gespeichert werden und ob man die nicht vielleicht doch noch rückwirkend zur Verfügung stellen kann – er hätte da unabsichtlich was gelöscht bei sich. Und dann sitzen da 8 Leute und gucken sparsam, weil 6 von ihnen vor 2 Jahren noch gar nicht an Bord waren.
Ich finde es immer schwierig aus der eigenen Situation heraus zu verallgemeinern, dass Spezifikationen zu viel Arbeit machen und zu wenig bringen, wenn das vielleicht wirklich nur für das eigene Umfeld stimmt. Es gibt noch andere, in denen es vielleicht eben nicht so einfach passt.
Ich wollte auch garnicht diskutieren ob mehr oder weniger Doku, das ist in der Tat sehr kontextabhängig. Aber ich diskutiere gerne, ob es uns nicht gelingt eine Abstraktionsebene zu finden, die den Gesamtaufwand sowohl verringert, als auch die Eindeutigkeit verbessert.
Zu einem Deiner Beispiele: wenn in einer Übersicht über den Historisierungsprozess es ein Icon gegeben hätte für BLOBs aus der Quelldomäne, das rot durchgestrichen war … hätte sich die Diskussion mit dem Chef ziemlich schnell erledigt ;-)
Bin ich immer dabei. Ich hab schon gesehen, dass Leute Windows-Fensterchen nachdokumentiert haben (“und dann muss oben recht noch ein X sein und zwar auf hellgrau und so”), weil sie Angst hatten, dass die nicht genau so aussehen wie sie sich das gewünscht haben. Völlig Banane.
Netter Ansatz mit dem BLOB-Icon… wenn ich mir aber überlege, dass ich auch für die Nachwelt dokumentiere… Nehmen wir mal an, Du kommst neu in ein Team, kriegst eine Story zum Umsetzen, merkst, dass die nicht komplett auf der grünen Wiese basteln darfst und musst dann erst mal verstehen, was es genau schon gibt und wie es funktioniert und zwar nur anhand von Bildern. Puh… tough call.