Was vor der ersten Zeile Code feststehen muss

Software-Projekte scheitern selten daran, dass jemand nicht programmieren konnte. Sie scheitern daran, dass in Woche neun eine Frage auftaucht, die in Woche eins zwanzig Minuten gekostet hätte.

Das hier ist die Liste, die wir vor jedem Angebot durchgehen. Nicht als Formalie: jeder offene Punkt darauf ist ein Betrag, den am Ende irgendwer zahlt.

1. Das Datenmodell

Was sind die Objekte, um die sich alles dreht — Auftrag, Kunde, Termin, Dokument? Wie hängen sie zusammen, und was passiert, wenn eines gelöscht wird? Ein Datenmodell lässt sich in Woche eins auf zwei Seiten aufschreiben. In Woche neun ist es eine Migration mit Produktivdaten.

2. Rollen und Rechte

Wer darf was sehen, wer darf was ändern, wer darf freigeben? Fast jede Anwendung im Unternehmen hat mindestens drei Rollen, und fast jede Spezifikation erwähnt genau eine. Rechte nachträglich einzuziehen bedeutet, jede Ansicht und jeden Endpunkt noch einmal anzufassen.

3. Die Schnittstellen

Welche Systeme müssen mitspielen — ERP, Warenwirtschaft, Buchhaltung, Kalender, Zahlungsdienstleister? Und die Frage dahinter, die häufiger übersehen wird: gibt es dort überhaupt eine dokumentierte Schnittstelle, und wer im Unternehmen hat Zugang dazu?

Der teuerste Satz in einem Softwareprojekt lautet: der Hersteller muss das erst freischalten.

4. Wo es läuft

Cloud, eigenes Rechenzentrum, hybrid? Welche Daten dürfen das Haus verlassen, welche nicht? Muss ein Auftragsverarbeitungsvertrag geschlossen werden, gibt es Vorgaben aus einer Konzernrichtlinie? Betrieb ist keine Frage für den Schluss — er bestimmt die Architektur mit.

5. Woran Erfolg gemessen wird

Nicht als Marketingzahl, sondern als Abnahmekriterium: Was muss die Software können, damit sie als fertig gilt? Wenn diese Frage offen bleibt, verschiebt sich die Antwort mit jedem Meeting — und niemand kann sagen, ob das Projekt fertig ist.

6. Die Übergabe

Wem gehört das Repository, wo liegen die Zugänge, wer kann in sechs Monaten einen Fehler beheben? Das gehört in den Vertrag, nicht in eine spätere Unterhaltung. Bei uns ist die Antwort immer dieselbe: Repository und Infrastruktur laufen auf die Organisation des Kunden.

Warum das ein eigener Auftrag sein darf

Diese sechs Punkte zu klären ist Arbeit — Gespräche mit Fachbereich und IT, ein Blick in die Altsysteme, ein geschriebenes Dokument mit Datenmodell, Schnittstellenliste und Rollenmatrix. Deshalb bieten wir Architektur und Spezifikation als eigene Leistung an, unabhängig davon, wer danach baut.

Ein Angebot, das vor dieser Arbeit entsteht, ist eine Schätzung. Ein Angebot danach ist eine Zusage.

Wenn ein Dienstleister diese Punkte überspringt und sofort einen Betrag nennt, ist das kein Zeichen von Erfahrung. Es ist ein Zeichen dafür, dass die Differenz später jemand trägt — und das sind in der Regel nicht Sie beim Lesen des Angebots, sondern Sie im laufenden Projekt.