Warum technische Schulden im Unternehmen mit einem schlechten Briefing beginnen

Im Laufe meiner Geschäftsjahre – zuerst bei „Alkar“ in den 90ern, dann bei „Dom i Sad“ und jetzt bei formspace.design – habe ich immer wieder festgestellt: Die Wurzel der meisten Probleme bei Entwicklung, Automatisierung und selbst einfachen Aufgaben liegt in einem schlechten Briefing. Technische Schulden, also die angesammelten Probleme im Code oder System, die die Entwicklung verlangsamen, beginnen nicht mit „ungeschickten Händen“ des Programmierers, sondern mit einer unklar formulierten Anfrage. Das ist meine tiefe Überzeugung, basierend auf Jahrzehnten der Praxis, der Aufgabenstellung und der anschließenden Überarbeitungen.

Warum ein schlechtes Briefing das Fundament technischer Schulden ist

Stellen Sie sich vor: Sie bauen ein Haus. Aber anstatt eines klaren Entwurfs und Plans sagen Sie den Bauherren: „Machen Sie etwas Schönes, Geräumiges und Gemütliches.“ Was werden sie bauen? Etwas, das ihren Vorstellungen von Schönheit, Geräumigkeit und Gemütlichkeit entspricht, aber nicht unbedingt Ihren. In IT-Projekten zeigt sich dies noch deutlicher. Ein Programmierer ist ein Ausführender, der mit Logik und Algorithmen arbeitet. Wenn er eine vage technische Spezifikation (Lastenheft) erhält, muss er Details selbst ergänzen und Entscheidungen für den Kunden treffen. Diese „Ergänzungen“ sind die ersten Bausteine der technischen Schulden.

Ich erinnere mich, wie ich Anfang der 90er Jahre, als wir bei „Alkar“ gerade erst anfingen, Software für die Verwaltungsbuchhaltung einzuführen, diesen Fehler selbst gemacht habe. Mir schien, dass die Programmierer meine Bedürfnisse „verstehen sollten“. Infolgedessen verbrachten wir Wochen, manchmal sogar Monate mit der Entwicklung von Funktionen, die dann überarbeitet werden mussten, weil sie nicht ganz den tatsächlichen Geschäftsprozessen entsprachen. Jede solche Überarbeitung ist nicht nur verlorene Zeit, sondern auch entgangener Gewinn, Demotivation des Teams und letztendlich echtes Geld. Meinen Beobachtungen zufolge kann eine 30%ige Änderung des Lastenhefts zur Hälfte des Projekts die Fristen und das Budget verdoppeln. Das sind enorme Verluste, die vermieden werden könnten.

Anzeichen eines schlechten Briefings: Wie man sie frühzeitig erkennt

Ein qualitativ schlechtes Briefing frühzeitig zu erkennen, ist bereits die halbe Miete. Hier sind einige Warnsignale, auf die ich immer achte:

1. Mangel an Spezifität. Formulierungen wie „benutzerfreundlich gestalten“, „modern gestalten“, „Effizienz verbessern“ ohne numerische Kennzahlen oder klare Bewertungskriterien. Was bedeutet „benutzerfreundlich“? Für wen? Auf welche Weise?
2. Widersprüchliche Anforderungen. Wenn in einem Punkt des Lastenhefts das eine steht und in einem anderen das genaue Gegenteil. Oder wenn verschiedene Stakeholder unterschiedliche Vorgaben machen und diese nicht abgestimmt sind.
3. Unklares Zielverständnis. Wenn der Kunde nicht klar formulieren kann, welche Geschäftsaufgabe das Produkt oder die Funktion lösen soll, welches Ergebnis er am Ende erwartet.
4. Häufige Änderungen während des Prozesses. Natürlich ändert sich das Geschäftsumfeld, aber wenn die Anforderungen jede Woche grundlegend überarbeitet werden, ist dies ein sicherer Weg zu Chaos und endlosen Überarbeitungen. Dies ist ein klassisches Beispiel für „zuerst X gemacht – dann überarbeitet“, das ich hunderte Male gesehen habe.
5. Fehlende Prioritäten. Wenn alle Funktionen gleichermaßen wichtig sind und kein Verständnis dafür besteht, was zuerst für ein Minimum Viable Product (MVP) getan werden muss.

Wie ich lernte, Aufgaben für Programmierer zu formulieren

Mein Weg vom „Direktor, der 'irgendetwas' will“ zum Gründer von formspace.design, der selbst Aufgaben stellt (manchmal auch sich selbst, mithilfe von KI), war lang und steinig. Bei „Alkar“ verstand ich, dass man sich in Details vertiefen muss. Bei „Dom i Sad“, wo ich Projekte im Bau- und Landschaftsdesign leitete, lernte ich, große Aufgaben in kleinere, messbare Schritte zu zerlegen. Damals begann ich, Prinzipien anzuwenden, die später die Grundlage meines Ansatzes zur Automatisierung und IT bildeten.

Ich begann, von mir selbst und meinen Managern zu fordern:

• Eine klare Beschreibung des gewünschten Ergebnisses: Was soll passieren, wenn der Benutzer eine Aktion ausführt? Welche Daten sollen sich ändern? Wie sieht das aus?
• Screenshots, Prototypen, Diagramme: Visualisierung sagt oft mehr als tausend Worte. Selbst eine handgezeichnete Skizze hilft, Zweideutigkeiten zu vermeiden.
• Beispieldaten: Wie sollen die Eingabe- und Ausgabedaten aussehen? Dies ist entscheidend für die korrekte Funktion des Systems.
• Verständnis des Geschäftsprozesses: Wenn der Programmierer versteht, wofür eine bestimmte Funktion benötigt wird, kann er eine optimalere Lösung vorschlagen oder logische Fehler im Lastenheft bemerken.

Das bedeutet nicht, dass ich Programmierer geworden bin. Vielmehr habe ich gelernt, in einer Sprache zu sprechen, die es dem Entwickler ermöglicht, meine Gedanken genau zu verstehen. Meine Erfahrung mit KI, über die ich im Artikel Wie KI mir hilft, formspace.design ohne großes Team zu führen berichtet habe, bestätigt diese These nur: Je präziser und detaillierter mein Prompt, desto besser das Ergebnis.

Checkliste für die Erstellung eines effektiven Briefings

Um den Schmerz und die technischen Schulden zu vermeiden, mit denen ich konfrontiert war, empfehle ich die Verwendung der folgenden Checkliste bei der Vorbereitung eines Briefings:

1. Definieren Sie das Ziel: Welches Problem löst das Projekt? Welches Ergebnis wird erwartet? (Zum Beispiel: „Die Zeit für die Kostenschätzung von 3 Stunden auf 15 Minuten reduzieren“).
2. Beschreiben Sie die Zielgruppe: Wer wird das Produkt nutzen? Welche Bedürfnisse und Einschränkungen haben sie?
3. Erstellen Sie eine Liste der Funktionen (funktionale Anforderungen): Was genau soll das System tun? Jede Benutzeraktion, jede Systemreaktion. (Zum Beispiel: „Der Benutzer kann ein Foto des Grundstücks hochladen“, „Das System generiert 3 Varianten des Landschaftsdesigns“).
4. Geben Sie nicht-funktionale Anforderungen an: Leistung, Sicherheit, Benutzerfreundlichkeit, Skalierbarkeit. (Zum Beispiel: „Die Seite sollte nicht länger als 2 Sekunden laden“, „Das System sollte bis zu 1000 Anfragen pro Stunde verarbeiten“).
5. Zeichnen Sie Prototypen oder Diagramme: Wie sieht die Benutzeroberfläche aus? Wie bewegt sich der Benutzer durch das System? Dies kann eine Skizze auf Papier oder ein vollständiges Mockup in Figma sein.
6. Geben Sie verwendete Technologien und Integrationen an (falls vorhanden): Mit welchen anderen Systemen soll das Produkt interagieren?
7. Definieren Sie Fristen und Budget: Realistische Rahmenbedingungen für das Projekt.
8. Benennen Sie Verantwortliche: Wer auf Kundenseite wird die Arbeit abnehmen, Fragen beantworten, Feedback geben?
9. Führen Sie ein Briefing-Review durch: Lassen Sie mehrere Personen auf Kunden- und Auftragnehmerseite das Dokument lesen und besprechen, um Unklarheiten und Widersprüche vor Arbeitsbeginn zu identifizieren.

Folgen eines mangelhaften Briefings für das Unternehmen

Der Preis eines schlechten Briefings ist hoch und misst sich nicht nur in Geld, sondern auch in Zeit, Reputation und sogar der Moral des Teams. Ich habe gesehen, wie Projekte sich um ein bis zwei Jahre verzögerten oder sogar ganz scheiterten, nur wegen anfänglicher Unklarheit. Nach meinen Schätzungen führt jeder Euro, der in der Briefing-Phase „gespart“ wird, zu zehn Euro an Nacharbeiten und Überarbeitungen.

• Finanzielle Verluste: Zusätzliche Arbeitsstunden von Programmierern, Kosten für Überarbeitungen, entgangener Gewinn durch verspätete Produkteinführung.
• Zeitverlust: Projekte überschreiten die Fristen, was zu einem Verlust des Wettbewerbsvorteils führen kann.
• Geringe Produktqualität: Wenn die Anforderungen unklar waren, löst das Endprodukt möglicherweise nicht die tatsächlichen Probleme der Benutzer oder ist unpraktisch in der Anwendung.
• Demotivation des Teams: Ständige Überarbeitungen und fehlende klare Ziele ermüden sowohl den Kunden als auch den Ausführenden und verringern die Produktivität und die Motivation, am Projekt zu arbeiten.
• Reputationsrisiken: Misslungene Projekte können dem Ruf des Auftraggebers und des Auftragnehmers schaden. Schließlich ist dies, wie ich im Artikel Typische Geschichte: Eins bestellt, anderes erhalten, zweimal bezahlt schrieb, ein häufiges Problem, mit dem viele konfrontiert sind.

formspace.design und Lehren aus der Vergangenheit: Wie wir technische Schulden vermeiden

Als ich formspace.design gründete, verstand ich, wie wichtig es ist, Fehler der Vergangenheit zu vermeiden. Ich bin kein professioneller Programmierer, aber meine langjährige Erfahrung im Geschäfts- und Landschaftsdesign hat mich den Wert einer klaren Planung gelehrt. Ich entwickle formspace.design selbst, nutze KI als leistungsstarkes Werkzeug, und dies wurde nur möglich, weil ich gelernt habe, meine Ideen maximal konkret zu formulieren. Die Module von formspace.design werden unter Berücksichtigung dieses Prinzips erstellt.

Wenn ich beispielsweise eine neue Funktion plane, sei es in den Planungsmodulen (1.x Plan/Zonen/Objekte) oder im KI-Konzeptblock (2.1 AI concept), erarbeite ich zuerst selbst das Nutzungsszenario bis ins kleinste Detail. Ich stelle mir vor, was der Benutzer tun wird, welche Daten er eingeben wird, welches Ergebnis er erwarten wird. Für das Modul 3.1 „Design nach Foto“ bedeutet dies die genaue Definition von Bildverarbeitungsparametern, möglichen Stilen, Elementen, die die KI erkennen und ändern soll. Ich halte diese Schritte fest, zeichne Prototypen und erst danach beginne ich mit dem Schreiben des Codes (oder der Prompts für die KI). Dies ermöglicht es mir, „Selbst-Ergänzungen“ in der Implementierungsphase zu vermeiden und technische Schulden zu minimieren, selbst wenn ich ohne ein Team von Programmierern arbeite, wie ich in Wie ein Tag aussieht, an dem ich programmiere, ohne Programmierer zu sein teilte.

Häufige Fragen

Kann man technische Schulden vollständig vermeiden?

Technische Schulden vollständig zu vermeiden, ist wohl unmöglich, da sie aus verschiedenen Gründen entstehen können, einschließlich sich ändernder Technologien oder Geschäftsanforderungen. Sie können jedoch durch ein qualitativ hochwertiges Briefing, regelmäßiges Refactoring und strategische Planung minimiert und effektiv verwaltet werden. Das Wichtigste ist, jede Aufgabe bewusst anzugehen und bekannte Probleme nicht „auf später“ zu verschieben.

Was tun, wenn der Kunde kein klares Briefing geben kann?

In einer solchen Situation ist es die Aufgabe des Managers oder Analytikers, dem Kunden bei der Formulierung der Anforderungen zu helfen. Dies kann die Durchführung von Workshops, Interviews, die Analyse von Geschäftsprozessen und die Erstellung von Prototypen umfassen. Es ist wichtig, suggestive Fragen zu stellen, Optionen anzubieten und Konkretheit zu erreichen, bevor die Aufgabe zur Entwicklung übergeben wird. Dies ist eine Zeitinvestition, die sich vielfach auszahlen wird.

Bedeutet ein detailliertes Briefing immer ein erfolgreiches Projekt?

Ein detailliertes Briefing erhöht die Erfolgschancen erheblich, garantiert ihn aber nicht zu 100 %. Wichtig sind auch die Qualifikation der Ausführenden, ein effektives Projektmanagement, eine adäquate Risikobewertung und die Bereitschaft zur Kommunikation. Das Fehlen eines detaillierten Briefings führt jedoch fast immer zu Problemen, während seine Existenz ein starkes Fundament bildet.

Wie unterscheidet man technische Schulden von der normalen Notwendigkeit von Nacharbeiten?

Technische Schulden sind unbezahlte „Kredite“, die zugunsten der Geschwindigkeit aufgenommen werden, aber später eine Rückzahlung erfordern. Sie äußern sich in suboptimalem Code, temporären Lösungen, fehlender Dokumentation, was die weitere Entwicklung erschwert. Normale Nacharbeiten sind eine geplante Produktentwicklung, das Hinzufügen neuer Funktionen oder die Verbesserung bestehender, die nicht durch Fehler oder minderwertige Entscheidungen in der Vergangenheit verursacht wurden.

Muss ich als Führungskraft technische Details verstehen, um ein Briefing zu erstellen?

Es ist nicht notwendig, Programmierer zu sein, aber ein Verständnis der grundlegenden Funktionsprinzipien des Systems und wie Ihre Entscheidungen die technische Umsetzung beeinflussen, ist sehr nützlich. Mein Weg zu formspace.design hat gezeigt, dass tiefgreifende Fachexpertise in Kombination mit der Fähigkeit, Aufgaben klar zu formulieren, wichtiger ist als die Kenntnis von Programmiersprachen. Das Wichtigste ist die Fähigkeit, geschäftliche Bedürfnisse in für Entwickler verständliche Anforderungen zu übersetzen.

Wie oft sollte ein Briefing überprüft und aktualisiert werden?

Ein Briefing ist ein lebendiges Dokument, das sich an sich ändernde Bedingungen anpassen kann und sollte. Radikale Änderungen sollten jedoch minimiert und bewusst durchgeführt werden, unter Berücksichtigung der Konsequenzen. Für langfristige Projekte wird empfohlen, das Briefing regelmäßig (z. B. vierteljährlich) zu überprüfen und alle Änderungen zu dokumentieren, damit das Team immer mit aktuellen Informationen arbeitet.

Können Agile-Methodologien für ein flexibles Briefing verwendet werden?

Agile-Methodologien eignen sich hervorragend für einen flexiblen Entwicklungsansatz und können helfen, ein starres, veraltetes Briefing zu vermeiden. Doch auch in Agile sind klare User Stories und Akzeptanzkriterien für jede Iteration notwendig. Ohne diese kann man selbst bei einem flexiblen Ansatz leicht in Unklarheiten und die Anhäufung technischer Schulden geraten.

Fazit

Meine Erfahrung hat mich überzeugt: Ein qualitativ hochwertiges Briefing ist nicht nur eine Formalität, sondern ein entscheidend wichtiger Schritt, der den Erfolg des gesamten Projekts bestimmt. Letztendlich ist es Ihr Investitionsplan in die Geschäftsentwicklung. Sparen Sie keine Zeit und Mühe bei seiner Erstellung, und Sie werden in Zukunft viel mehr sparen. Klarheit und Konkretheit am Anfang sind der Schlüssel zu stabiler Entwicklung und Risikominimierung. Dies ist eine Lektion, die ich über Jahrzehnte gelernt habe und die ich jetzt bei der Entwicklung von formspace.design anwende.