Der „Living Prototype“: Warum das Lastenheft ausgedient hat
Das strategische Dilemma: Excel vs. Governance
In der Unternehmensrealität existiert ein Spannungsfeld, das in fast jedem Projekt spürbar ist: Der Konflikt zwischen der notwendigen Governance der IT-Abteilung und der operativen Agilität der Fachbereiche.
Es ist absolut nachvollziehbar, warum Infrastruktur-Manager und sicherheitsorientierte Architekten skeptisch auf „Schatten-IT“ blicken. Excel-Tabellen, die per E-Mail zirkulieren, sind ein Albtraum für Datenintegrität, Versionskontrolle und Compliance. Wenn geschäftskritische Prozesse auf einer lokalen .xlsx-Datei basieren, ist das ein signifikantes Betriebsrisiko.
Dennoch müssen wir anerkennen, warum die Fachabteilungen immer wieder zu Excel zurückkehren, selbst nachdem teure ERP-Module eingeführt wurden: Excel funktioniert sofort. Es erfordert keine Tickets, keine Genehmigungsverfahren und passt sich dynamisch an den Prozess an.
Die strategische Lösung: „Excel with Guardrails“
Wenn wir versuchen, Excel durch starre Prozesse zu ersetzen, werden die Nutzer Wege finden, das System zu umgehen. Die Lösung ist daher nicht, die Flexibilität zu verbieten, sondern sie zu professionalisieren. Wir bauen Applikationen, die sich für den Nutzer so schnell und flexibel anfühlen wie eine Tabelle, die aber im Hintergrund auf einer robusten Datenbank (wie PostgreSQL/Supabase) laufen.
Das Ziel ist ein strategischer Kompromiss: Wir geben den Nutzern die Flexibilität, die sie fordern, und der IT die Governance (Backups, Rollenrechte, Audit-Logs), die sie benötigt.
Realität schlägt Theorie: Das Ende der Spezifikation
In traditionellen Umgebungen gilt das Lastenheft als Versicherung. Die Logik ist verständlich: Man möchte genau definieren, was geliefert wird, um Budgetsicherheit zu gewährleisten. Doch diese Herangehensweise birgt einen fundamentalen Denkfehler, den Steve Jobs einst treffend beschrieb:
„People don't know what they want until you show it to them.“
Das ist keine Kritik an der Kompetenz der Fachbereiche, sondern eine psychologische Realität. Was Nutzer in einem Meetingraum sagen, dass sie brauchen (theoretische Anforderung), unterscheidet sich oft drastisch von dem, was sie im täglichen Stress tun (faktisches Verhalten).
Ein 100-seitiges Spezifikationsdokument zementiert Annahmen, die oft falsch sind. Das Risiko ist hierbei nicht technischer Natur, sondern konzeptioneller Art: Wir bauen das falsche Produkt – aber das perfekt.
Der Ansatz: Wir ersetzen die theoretische Planung durch den „Living Prototype“.
Der Living Prototype als Risiko-Management
Anstatt Monate in Papierarbeit zu investieren, starten wir die Entwicklung mit echtem Code ab Tag 1. Ein „Living Prototype“ ist kein Klick-Dummy in Figma, sondern funktionierende Software auf einer Produktionsumgebung.
Validierung durch Nutzung statt durch Meetings
Dieser Ansatz verändert die Dynamik der Zusammenarbeit grundlegend:
- Validierung: Anstatt zu fragen: „Wäre dieses Formular so okay?“, stellen wir den Link bereit: „Versuchen Sie bitte, diesen Vorgang jetzt zu buchen.“
- Verhaltens-Analyse: Wir beobachten, wo Nutzer stolpern, nicht wo sie glauben, dass sie stolpern würden.
- Investitionsschutz: Wir erkennen Sackgassen nach Tagen, nicht nach Monaten.
Natürlich gibt es Szenarien – etwa im Bankenumfeld oder bei sicherheitskritischer Infrastruktur –, in denen umfangreiche Vorab-Planung aufgrund regulatorischer Anforderungen unumgänglich ist. Doch für die meisten internen Business-Tools ist die „Efficiency Gap“ zwischen Planung und Umsetzung das größere Risiko.
Schnelle Iteration ist Sicherheit
Das größte Risiko in der Softwareentwicklung ist nicht der fehlerhafte Code, sondern die fehlerhafte Anforderung.
Indem wir den Feedback-Loop radikal verkürzen, betreiben wir aktives Risiko-Management. Wenn ein Feature im „Living Prototype“ auf Ablehnung stößt, haben wir lediglich wenige Entwicklertage "verbrannt", statt ein komplettes Quartalsbudget.
Wir liefern „Excel with Guardrails“: Eine Software, die so stabil ist, dass die IT ruhig schlafen kann, aber so anpassungsfähig bleibt, dass der Fachbereich nicht heimlich wieder Tabellenkalkulationen öffnet.
Fazit
Die Entscheidung für einen „Living Prototype“ ist ein bewusster Trade-off: Wir tauschen die illusorische Sicherheit eines detaillierten Plans gegen die empirische Sicherheit einer validierten Lösung.
In einer komplexen Marktumgebung gewinnt nicht das Unternehmen mit dem besten Plan, sondern das Unternehmen mit der schnellsten Anpassungsfähigkeit. Bauen Sie Systeme, die die operative Realität abbilden, nicht die theoretischen Wünsche.