Wer die Software baut, sollte die Anforderung aus erster Hand hören

Dienstag, 11:40 Uhr. Im neuen Bestellportal landen 40 Kanister Lack im Warenkorb, und das Portal zeigt: „Versand heute“. Am Nachmittag ruft der Einkäufer an und will die Sendungsnummer wissen. Es gibt keine. Der Lack ist Gefahrgut, und Gefahrgut holt der Spediteur bei euch gesondert ab, frühestens am nächsten Werktag. Im Lager weiß das jeder. Das Portal weiß es nicht.

Trotzdem ist der Code nicht fehlerhaft. Er macht genau das, was im Ticket stand. Das Beispiel ist ausgedacht, das Muster dahinter nicht: Softwareprojekte scheitern oft nicht an schlechtem Code, sondern an Kommunikationsfehlern und unklaren Anforderungen. Hier liest du, wo diese Fehler entstehen, was sie kosten und wie du sie abfängst, bevor sie beim Kunden landen.

Wie die Regel auf dem Weg zum Entwickler schrumpft

Bei vielen Dienstleistern läuft eine Anforderung über mehrere Stationen, bis sie beim Entwickler ankommt. Für die Versandregel kann das so aussehen:

Keine dieser Stationen hat schlecht gearbeitet. Jede hat behalten, was aus ihrer Sicht wichtig war. Menschen filtern Informationen immer durch die Brille ihres eigenen Berufs, und das lässt sich nicht abstellen.

Unterwegs sind so zwei Dinge verloren gegangen: das Wort „Werktag“ und der Satz über Gefahrgut. Bestellt jemand am Samstag um zehn, verspricht das Portal ebenfalls einen Versand, den es nicht gibt.

Dazu kommt die Sprachbarriere zwischen Fachbereich und Technik. Wer das Geschäft verantwortet, beschreibt Ziele: Kunden sollen wissen, wann ihre Ware kommt. Wer baut, braucht Regeln und Ausnahmen. Diese Lücke muss jemand schließen. Am besten machen das die beiden Seiten, die es betrifft, direkt miteinander.

Jede Station zwischen Fachbereich und Entwickler macht aus einer Regel eine Zusammenfassung.

Was ein spät entdecktes Missverständnis kostet

Teuer werden solche Fehler, weil sie spät auffallen. Im Beispiel merkt es nicht einmal die Abnahme, sondern erst ein Kunde. Danach kommen Entschuldigung, Nacharbeit und ein neuer Test, und das alles muss jemand bezahlen.

Eine Auswertung zu ausgelagerten Entwicklungsprojekten nennt deutliche Zahlen:

• Kommunikationsprobleme führen dazu, dass 62 % der ausgelagerten IT-Projekte das Budget überschreiten.
• Fehlkommunikation kann Zeitpläne um 70 % verlängern.
• Über Scope Creep kann sie zusätzlich 10 bis 20 % Mehrkosten verursachen.
• Kommunikationsfehler führen dazu, dass 50 % der ausgelagerten Projekte die Erwartungen der Kunden nicht erfüllen.

Dabei hätte im Beispiel eine einzige Rückfrage gereicht: „Gilt das für alle Artikel?“ Gestellt hat sie niemand. Der Entwickler hat die Versandleitung nie gesprochen, und die Versandleitung hat das Ticket nie gesehen.

Mehr Text in den Tickets hilft nur begrenzt

Viele reagieren auf Missverständnisse, indem sie mehr aufschreiben: längere Spezifikationen, ausführlichere User Stories, mehr Abstimmungsmails. Das hilft nur begrenzt. Laut einer Auswertung zu Kommunikationsschulden berichten Teams, die rein textbasierte Anforderungen nutzen, von 30 bis 50 % höheren Nacharbeitsraten. Der Einsatz visueller Modelle kann Missverständnisse demnach um bis zu 60 % reduzieren.

Der Grund ist einfach: Ein Dokument beantwortet keine Rückfragen. Gute Dokumentation ist deshalb kein Archiv, sondern ein Werkzeug, mit dem man Unklarheiten aufdeckt. Effektive Teams prüfen aktiv, ob die Absicht hinter einer Anforderung die Übersetzung überstanden hat.

Ein visuelles Modell muss nichts Aufwendiges sein. Für das Bestellportal reicht ein Ablauf, den Versandleitung und Entwickler zusammen aufzeichnen:

flowchart TD
    A["Bestellung im Portal"] --> B{"Gefahrgut im Warenkorb?"}
    B -- ja --> N["Lieferstatus: Versand nächster Werktag"]
    B -- nein --> C{"Bestellt an einem Werktag?"}
    C -- nein --> N
    C -- ja --> D{"Vor 14 Uhr?"}
    D -- nein --> N
    D -- ja --> H["Lieferstatus: Versand heute"]

Im Ticket stand nur die unterste Frage. Die beiden darüber kommen auf den Tisch, sobald beide Seiten den Ablauf gemeinsam aufzeichnen. Spätestens beim Kasten „Versand heute“ fragt jemand aus dem Lager: „Und der Lack?“ Am Whiteboard kostet diese Frage ein paar Minuten. Nach dem Start kostet sie einen verärgerten Kunden und einen Nachtrag.

Das klappt aber nur, wenn der Entwickler selbst mit am Tisch sitzt. Liest er die Anforderung zwei Wochen später im Ticketsystem, ist es zu spät.

So sieht der direkte Draht bei uns aus

Bei Mavaris gibt es kein Account-Team und keine Junior-Besetzung, die im Hintergrund baut. Du sprichst mit dem Entwickler, der deine Software schreibt und der die Standards aus Projekten für Bahn, Porsche und Schufa mitbringt. Die Konzernprozesse lässt er dort.

Erst der Prozess, dann der Code. Bevor wir programmieren, erarbeiten wir den Ablauf zusammen mit deinem Fachbereich. Wir zeichnen ihn auf, gehen Ausnahmen durch und klären Begriffe wie „Werktag“.

Rückfragen gehen den kurzen Weg. Ist beim Bauen etwas unklar, fragen wir direkt bei den Leuten nach, die es wissen. Niemand muss raten, nur weil der Weg zur Antwort zu lang ist.

Ehrliche Antworten kommen früh. Wer selbst baut, merkt im Gespräch, wenn eine Anforderung teuer wird oder wenig bringt, und kann das gleich sagen. Das gilt auch, wenn wir für ein Vorhaben nicht die Richtigen sind.

Die kleinen Wörter zuerst

Egal, mit wem du dein nächstes Projekt umsetzt: Schreib vorher die drei Regeln auf, die für deinen Ablauf am wichtigsten sind. Dann markierst du darin jede Ausnahme. Achte auf Wörter wie „außer“, „nur wenn“ oder „auch am Wochenende“.

Im ersten Gespräch lässt du dir diese Regeln von der Person zurückerklären, die später den Code schreibt. Fehlt dabei eine Ausnahme, hast du ein Missverständnis gefunden, das noch nichts gekostet hat.

Und wenn die Person, die den Code schreibt, gar nicht mit am Tisch sitzt, ist das auch eine Antwort.