Das Konzeptdokument war ein Notbehelf

10 Min. Lesezeit

Bauen statt beschreiben

Warum es Konzeptdokumente gab

Niemand schreibt gerne Konzeptdokumente. Man schreibt eins, weil es früher katastrophal teuer war, das Falsche zu bauen.

Ich habe Spikes mit Teams von 25 Leuten durchgeführt. Ein Spike ist ein zeitlich begrenztes Experiment, typischerweise auf einen Arbeitstag beschränkt, bei dem das gesamte Team eine Frage angreift: Können wir das? Ist das machbar? Was bricht, wenn wir es versuchen? Ein Tag, 25 Leute, Antwort bis Feierabend.

In Organisationen, die Konzeptpapiere über Fantasieszenarien satt hatten, liebte das Management Spikes. Es war befreiend. Statt eines weiteren Konzeptdokuments, an das niemand glaubte, bekam man in acht Stunden eine echte Antwort. Das Team baute etwas, stieß an die Wände, fand die Grenzen und kam mit Evidenz statt Meinungen zurück. Das fühlte sich ehrlich an.

Aber Spikes kosten echtes Geld. Fünfundzwanzig Leute für einen Tag sind nicht billig. Und ein Prototyp über mehrere Wochen, der dann weggeworfen wird? Das konnten viele Organisationen nicht akzeptieren. Also blieb der Standard: die Sache auf Papier beschreiben, über die Beschreibung streiten, die Beschreibung absegnen lassen, dann bauen.

Das Dokument war ein Stellvertreter für die Sache selbst. Eine hübsche künstlerische Darstellung eines Hauses statt eines echten Hauses. Dieser Stellvertreter war wirtschaftlich sinnvoll, als jede Zeile Code von Hand geschrieben, manuell getestet und über ein Ritual mit drei Freigaben, einem Change Advisory Board und einem Wartungsfenster um 2 Uhr nachts am Samstag ausgeliefert wurde. Die Kosten des Bauens waren hoch. Die Kosten des Schreibens niedrig. Erst das Günstige machen. Niemand fragte, ob das Günstige auch das Richtige war.

Die Blaupausen-Illusion

Konzeptdokumente haben ein tieferes Problem, und es hat nichts mit Kosten zu tun. Es ist ein Denkmodell, das aus dem falschen Beruf stammt.

Konzeptdokumente fühlen sich an wie Baupläne. Ein Architekt denkt, entwirft, spezifiziert. Dann bauen Arbeiter nach der Spezifikation. Das Denken kommt zuerst. Das Bauen ist mechanische Ausführung. Wissensarbeiter entwerfen. Handwerker konstruieren.

Auf Software angewandt war das schon immer ein Missverständnis. Software-Entwicklung ist kein Ingenieurwesen im klassischen Sinn. Ein Ingenieur wendet bekannte Normen auf bekannte Probleme an. Eine Brücke wird, einmal entworfen, exakt nach Plan gebaut. Der Bauplan funktioniert, weil das Problem verstanden ist, die Materialien vorhersagbar sind und die Physik sich nicht mittendrin ändert. Bauvorschriften und technische Normen haben Gesetzeskraft. Wer sie ignoriert, begeht einen Rechtsverstoß. Ein Ingenieur, der von der Spezifikation abweicht, haftet persönlich, statt in einer Retrospektive darüber zu reden.

Software ist grundlegend anders. Anforderungen ändern sich. Nutzer überraschen. Systeme interagieren auf Weisen, die niemand vorhergesehen hat. Der Akt des Bauens enthüllt das Problem erst. Man versteht nicht, was man baut, bis man es baut. Der Entwickler ist kein Bauarbeiter, der anderer Leute Gedanken ausführt. Der Entwickler ist der Denker. Der Code ist das Denken in konkreter Form.

Wenn Organisationen Konzeptdokumente als Baupläne behandeln, trennen sie Denken vom Bauen und geben beides verschiedenen Leuten. „Wissensarbeiter” produzieren die Spezifikation. „Programmierer” führen aus. Diese Trennung garantiert Scheitern, denn bei Software passiert das wichtigste Denken während der Konstruktion, nicht davor. Jede interessante Erkenntnis, jede kritische Entwurfsentscheidung, jedes „Moment, das funktioniert nicht, weil…” passiert, wenn jemand die Sache tatsächlich baut.

Das Konzeptdokument hat nicht nur Zeit gekostet. Es hat eine falsche Trennung zwischen Leuten, die denken, und Leuten, die Code tippen, institutionalisiert. Kluge Leute schreiben auf, was gebaut werden soll, dann codieren die Programmierer es. Dieses mentale Modell ist nie ganz verschwunden. Das Konzeptdokument ist sein letztes überlebendes Artefakt.

Die Ökonomie hat sich umgekehrt

Was sich geändert hat: Ich kann einem KI-Assistenten ein System beschreiben und habe innerhalb von Stunden funktionierenden Code. Keinen Pseudocode. Kein Mockup. Funktionierender, testbarer, auslieferbarer Code. Der Spike, der früher 25 Leute und einen vollen Arbeitstag erforderte? Ein einzelner Entwickler mit einem KI-Assistenten kommt an einem Nachmittag zum selben Ergebnis. Der Prototyp, der früher einen Sprint verschlang, entsteht in ein oder zwei Tagen.

Das ist keine Theorie. Das ist mein Dienstag.

Wenn ein Entwickler einen funktionierenden Prototyp schneller fertigstellt, als ein Product Manager ein Konzeptdokument schreibt, kehrt sich die Ökonomie vollständig um. Das Dokument ist jetzt die teure Option. Nicht weil Papier Geld kostet, sondern weil das Dokument länger braucht, weniger Informationen liefert und eine falsche Sicherheit erzeugt, die der eigentliche Bau unweigerlich zerstört.

Ein Konzeptdokument sagt, was jemand denkt, das passieren wird. Ein Prototyp sagt, was tatsächlich passiert. Das eine ist Meinung. Das andere ist Evidenz.

Feature Flags haben alles verändert

Der eigentliche Wendepunkt ist nicht nur, dass Bauen schneller wurde. Es ist, dass Feature Toggles produktionsreifen Code ausliefern lassen, während er unsichtbar bleibt.

Was das bedeutet: Ein Entwickler baut ein Feature. Echter Code, echte Tests, echte Auslieferung. Es geht in Produktion. Es sitzt hinter einem Flag, unsichtbar für Nutzer. Ein Product Owner, ein Stakeholder, ein Kundenbeirat, wer auch immer freigeben muss, schaltet es in einer Staging-Umgebung ein, sieht es funktionieren, prüft es an der Realität und entscheidet.

Kein Dokument nötig. Kein Konzeptprüfungstermin, bei dem zwölf Leute hypothetische Grenzfälle diskutieren, die vielleicht nie eintreten. Keine Freigabe auf eine Beschreibung von etwas, das niemand gesehen hat. Die Sache existiert. Einschalten. Ansehen. Entscheiden.

Der alte Einwand war immer: „Aber was, wenn wir das Falsche bauen?” Berechtigtes Anliegen. Schlechte Lösung. Ein Konzeptdokument verhindert nicht, das Falsche zu bauen. Es verhindert, überhaupt irgendetwas zu bauen, bis genug Leute sich auf eine gemeinsame Vorstellung einigen, was das Richtige sein könnte. Dann baut man und stellt fest, dass die Vorstellung falsch war. Wie jedes Mal.

Code hinter Feature Flags kann etwas, das Konzeptdokumente nie konnten: günstig in Produktion scheitern. Drei Ansätze bauen. Alle drei mit Flags versehen. Jeden mit echten Nutzern testen. Messen. Die Verlierer abschalten. Den Gewinner ausliefern. Versuch das mal mit einem Konzeptdokument.

Was Konzeptdokumente tatsächlich produzieren

Ein Konzeptdokument produziert drei Dinge zuverlässig: Verzögerung, falsches Vertrauen und Termine.

Verzögerung, weil das Schreiben, Prüfen, Überarbeiten und Freigeben des Dokuments Wochen dauert. In diesen Wochen lernt niemand etwas von echter Software. Der Markt bewegt sich. Wettbewerber liefern aus. Nutzer entwickeln Workarounds.

Falsches Vertrauen, weil ein gut geschriebenes Dokument sich nach Fortschritt anfühlt. Alle haben genickt. Alle waren einverstanden. Das Dokument hat Abschnitte und Diagramme und eine Risikobewertung. Sicher ist der schwere Teil geschafft. Ist er nie. Der schwere Teil beginnt, wenn Code auf Realität trifft: unerwartetes API-Verhalten, Daten, die nicht zu den Annahmen passen, Nutzer, die das System auf Weisen verwenden, die sich niemand vorstellen konnte, während er auf ein Word-Dokument starrte.

Termine, weil jedes Dokument einen Prüfungszyklus erzeugt. Mehr Leute im Raum bedeuten mehr Meinungen, mehr Überarbeitungen, mehr Termine. Keiner dieser Termine produziert funktionierende Software. Sie produzieren überarbeitete Dokumente, die auch falsch sein werden, nur auf andere Art falsch.

Die eigentliche Kompetenz war immer dieselbe

Nichts davon bedeutet „hör auf zu denken und fang an zu tippen.” Die Kompetenz ist nicht Tippen. Das Ende des Programmierens als Fleißarbeit beendet nicht den Bedarf an Urteilsvermögen. Man muss das Problem nach wie vor verstehen. Man muss mit Nutzern sprechen. Man muss die Fachlichkeit gut genug durchdringen, um etwas Brauchbares zu bauen.

Der Unterschied liegt im Wie. Früher schrieb man. Jetzt baut man. Früher beschrieb man sein Verständnis. Jetzt demonstriert man es. KI als Denkpartner ersetzt nicht das Denken. Sie macht den Abstand zwischen Denken und greifbarem Ergebnis so klein, dass das Zwischendokument überflüssig wird.

Gute Entwickler wussten das schon immer. 2010 habe ich darüber geschrieben, wie man mit Cucumber die Entwicklung direkt aus einem Gespräch mit dem Kunden startet, Anforderungen als ausführbare Spezifikationen in natürlicher Sprache erfasst und test-first gebaut, ohne Konzeptdokument weit und breit. Die Feature-Datei war das gemeinsame Verständnis. Der bestehende Test war der Beweis. KI hat Bauen-als-Denken nicht erfunden. KI hat es so schnell gemacht, dass selbst dokumentensüchtige Organisationen die Alternative nicht mehr ignorieren können.

Die Leute, die gute Konzeptdokumente geschrieben haben, konnten meistens gut denken. Ihre Fähigkeit war nie das Dokument. Es war die Klarheit des Denkens dahinter. Diese Klarheit drückt sich jetzt in funktionierender Software aus statt in formatierten PDFs. Besser für alle.

Fachexperten denken in Oberflächen, nicht in Systemen

Aber bitte keine Romantisierung. Die meisten Fachexperten denken nicht in Systemen. Sie denken in Bildschirmen. Frag einen Stakeholder, was er braucht, und er beschreibt ein Formular mit Feldern, einen Button, der etwas tut, einen Bericht, der Zahlen zeigt. Software ist für sie das, worauf sie klicken können. Alles hinter dieser Oberfläche, das Datenmodell, die Integrationspunkte, die Fehlerfälle, existiert nicht in ihrer Vorstellung. Nicht weil sie dumm sind. Weil es ihnen niemand je gezeigt hat.

Genau deshalb haben Konzeptdokumente so lange überlebt. Der Fachexperte beschrieb Bildschirme. Wireframes. Button-Beschriftungen. Das Konzeptdokument erfasste, was sichtbar war, und ignorierte, was strukturell war. Es fühlte sich vollständig an, weil es jeden Pixel abdeckte. Es war hohl, weil es nichts über Datenkonsistenz, Fehlerbehandlung oder das Verhalten bei gleichzeitiger Nutzung durch zwei Personen aussagte.

Ein funktionierender Prototyp verändert dieses Gespräch. Wenn Fachexperten Bildschirme reagieren sehen, klicken sie, tippen, werden verwirrt und stellen Fragen, die kein Konzeptdokument je provoziert hat. „Moment, was passiert, wenn ich hier nichts eingebe?” Diese Verwirrung ist Gold wert. Ihre Frustration wird zum Anforderungsdokument. Ihr „das meinte ich nicht” wird zum Testfall. All das entsteht durch Berühren der Software, nicht durch Lesen darüber.

Wann Dokumente noch Sinn ergeben

Regulatorische Anforderungen, bei denen ein Prüfer eine schriftliche Spezifikation vor der Umsetzung verlangt. Sicherheitskritische Systeme, bei denen Menschenleben von nachgewiesener Korrektheit vor der Auslieferung abhängen. Vertragliche Verpflichtungen, bei denen ein Kunde ein definiertes Ergebnis bezahlt.

Das sind berechtigte Fälle. Weniger als man denkt.

Ich habe an einem Achszähler-System für einen deutschen Bahnzulieferer gearbeitet. Sicherheitskritischer geht es kaum. Züge, Gleise, Menschenleben. Die regulatorischen Anforderungen waren umfangreich: SIL-Zertifizierung (Safety Integrity Level), Rückverfolgbarkeit von der Anforderung über den Test bis zur Auslieferung. Die Art von Fachgebiet, in dem man Konzeptdokumente für unverzichtbar halten würde.

Wir haben festgestellt, dass TDD jede Compliance-Anforderung erfüllte. Jeder Test war einer Anforderung zugeordnet. Jede Anforderung einem Test. Die Nachweiskette war besser als alles, was ein Konzeptdokument liefern konnte, weil sie ausführbar war. Man konnte den Beweis laufen lassen.

Aber das Unternehmen hat es nicht übernommen. Das Compliance-Rahmenwerk diente nicht wirklich dem Nachweis von Korrektheit. Es diente der Verteilung von Schuld. Konzeptdokumente existierten, damit bei einem Fehler alle auf die Freigabekette zeigen konnten. „Ich habe das Konzept freigegeben. Die Entwickler sind vom Konzept abgewichen. Nicht mein Problem.” Wenn die Testsuite selbst die Spezifikation ist und die Tests bestehen, ist die Verantwortung klar. Kein Raum für die bequeme Fiktion, dass zwölf Unterschriften auf einem Dokument bedeuten, dass zwölf Leute die Korrektheit geprüft haben. Sie haben nichts geprüft. Sie waren in einem Termin und haben nicht laut genug widersprochen.

Selbst in regulierten Branchen überlebt das Konzeptdokument oft nicht, weil die Regulierung es verlangt, sondern weil Organisationen geteilte Verantwortung klarer Zurechenbarkeit vorziehen. Das Dokument ist ein Schutzschild, keine Spezifikation.

Die anderen 90% der täglich gebauten Software haben keine solche Ausrede. Sie brauchen einen Entwickler, der das Problem versteht, eine KI, die den Bau beschleunigt, ein Feature Flag, das die Sichtbarkeit steuert, und einen Verantwortlichen, der Ja oder Nein sagen kann, wenn er die echte Sache sieht.

Schluss mit Konzeptdebatten. Anfangen, Evidenz zu liefern.

Die Person, die mit Mockups in den Raum kommt und „Bau das” sagt, hat Konkurrenz bekommen: der Entwickler, der mit der funktionierenden Sache in den Raum kommt und „Probier das” sagt. Der eine brachte eine Beschreibung mit. Der andere brachte Evidenz.

Das Konzeptdokument war ein Notbehelf für teures Bauen. Bauen wurde günstig. Der Notbehelf wird nicht mehr gebraucht. Bauen. Flag setzen. Zeigen. Entscheiden. Weitermachen.