Individualsoftware-Projekte steuern: ein Leitfaden für Auftraggeber

Das Projekt läuft seit sieben Monaten. In jedem Statustermin heißt es „zu neunzig Prozent fertig“, und niemand kann erklären, warum die letzten zehn Prozent schon drei Monate dauern. Sie haben keine funktionierende Maske, die Sie anklicken könnten, keine Testadresse und keinen Vertrag, der festlegt, was „fertig“ bedeutet. Das liegt selten an einem schlechten Entwicklungsteam. Viel häufiger fehlen dem Auftraggeber schlicht die Werkzeuge, um das Projekt zu steuern.

Dieser Beitrag ist ein Leitfaden für alle, die Individualsoftware beauftragen. Programmieren müssen Sie dafür nicht. Sie müssen wissen, was Sie verlangen, was Sie wann sehen sollten und welche Sätze in den Vertrag gehören. Wir gehen der Reihe nach vor: Konzeptphase, MVP, User Stories, Vertragsmodelle, Sprint- und Demo-Rhythmus, Tests, Quellcode und Übergabe sowie die Zeit nach dem Livegang.

Konzeptphase und Umfang: erst das Problem, dann die Masken

Die meisten Projekte beginnen mit einer Liste von Masken: „Eine Anmeldeseite, eine Bestellmaske und eine Auswertungsseite.“ Eine solche Liste ist eigentlich schon ein Lösungsvorschlag. Entscheidend ist das Problem dahinter. „Unsere Händler bestellen telefonisch, und falsche Artikelnummern führen jede Woche zu Retouren“ hilft mehr als eine Liste mit zehn Masken.

Die Konzeptphase, oft Discovery genannt, ist ein kurzer Abschnitt, in dem Sie mit dem Entwicklungsteam Problem, Nutzer und Rahmenbedingungen klären. Meist gehören einige Workshops dazu, ein Blick auf den heutigen Ablauf vor Ort und eine technische Voranalyse. Am Ende einer guten Konzeptphase haben Sie:

• Eine Beschreibung des Problems und des Erfolgs: Was soll nach dem Projekt anders sein, und woran messen Sie das?
• Nutzerrollen: Händler, Außendienst, Lagerleitung, Buchhaltung, Administration.
• Eine Darstellung des heutigen Ablaufs, inklusive der Schritte, die jemand von Hand erledigt.
• Die anzubindenden Systeme: ERP, Buchhaltung wie DATEV, Zahlungsdienstleister, Versanddienstleister, E-Rechnung im Format XRechnung oder ZUGFeRD.
• Rahmenbedingungen: DSGVO, Branchenvorgaben, interne IT-Sicherheitsrichtlinien, die tatsächlichen Geräte der Nutzer.
• Ein priorisiertes Backlog und einen groben Architekturvorschlag.
• Eine Risikoliste mit den Themen, die am wenigsten verstanden sind und am teuersten werden können.

Die Konzeptphase als eigenen, kleinen Auftrag zu vergeben, ist für beide Seiten gesund. Sie sehen, wie das Team arbeitet, bevor Sie das große Budget binden, und das Team erfährt, was es wirklich bauen soll, bevor es schätzt. Die Ergebnisse sollten Ihnen gehören und auch dann nützen, wenn Sie mit einem anderen Anbieter weitermachen. Wie ein gutes Briefing aussieht, beschreiben wir in einem eigenen Beitrag.

Das MVP richtig zuschneiden

Ein MVP, ein Minimum Viable Product, ist kein halb fertiges Gesamtprodukt. Es ist die kleinste funktionierende Version, mit der Sie Ihre riskanteste Annahme an echten Nutzern prüfen. Das Schlüsselwort lautet „funktionierend“: Ein schmaler Pfad, auf dem Nutzer ihre Aufgabe von Anfang bis Ende erledigen, schlägt ein breites Schaufenster, das alles ein bisschen anreißt.

Nehmen wir einen Ersatzteilgroßhändler mit zweihundert Händlern. Die verlockende Liste für Version eins ist lang: Bestellung, Bestand, Aktionen, Kontoauszüge, Retouren, App, umfangreiche Auswertungen. Ein sauber zugeschnittenes MVP sagt dagegen: Eine Pilotgruppe von zehn Händlern kann Teile nach Artikelnummer oder Fahrzeugmodell suchen, den Bestand sehen und bestellen, und die Bestellung landet automatisch im ERP. Aktionen, Retouren und App kommen in Phase zwei.

Schneiden Sie nach Nutzerablauf, nicht nach technischen Schichten. „Erst die ganze Datenbank, dann alle Masken“ liefert monatelang nichts, was ein Nutzer sehen kann. Eine einfache Einteilung wie MoSCoW hilft: Must, Should, Could und Won't (diesmal nicht). Eine Liste mit leerer Won't-Spalte hat in Wahrheit nichts gestrichen.

Drei Dinge werden in MVPs immer wieder vergessen:

• Die Verwaltung. Wer pflegt Artikel, Nutzer und Rechte, und wo?
• Die Datenübernahme: Wie kommen Kundenkonten und Preislisten aus dem Altsystem ins neue?
• Die Auswertungen, denn die Geschäftsführung fragt in der ersten Woche, wie viele Bestellungen eingegangen sind.

Fehlen diese drei, ist Ihr MVP auf dem Papier klein und in der Praxis unvollständig.

User Stories und Akzeptanzkriterien

Eine praktische Form, Anforderungen festzuhalten, ist die User Story: „Als [Rolle] möchte ich [etwas tun], damit [ich einen Nutzen habe].“ Zum Beispiel: „Als Händler möchte ich Teile nach Fahrzeugmodell suchen, damit ich ohne Artikelnummer das richtige Teil bestellen kann.“ Eine Story sollte kurz sein, ein einziges Bedürfnis beschreiben und in einem Sprint umsetzbar bleiben.

Nützlich wird eine Story erst durch die Akzeptanzkriterien darunter, also die messbare Antwort auf die Frage, wann sie erledigt ist. Ein verbreitetes Muster lautet „Gegeben ist …, wenn …, dann …“:

• Gegeben ist ein Händler mit ausgeschöpftem Kreditlimit: Wenn er eine Bestellung bestätigen will, dann blockiert das System sie und zeigt das verbleibende Limit an.
• Gegeben ist ein Artikel ohne Bestand: Wenn er in den Warenkorb gelegt wird, dann erscheint der voraussichtliche Liefertermin in dieser Zeile.
• Gegeben ist eine bestätigte Bestellung: Dann erscheint sie innerhalb weniger Minuten im ERP, und der Händler erhält eine Bestätigung per E-Mail.

Das Projekt braucht außerdem eine Definition of Done. Der Begriff stammt aus dem Scrum Guide und beschreibt die gemeinsame Qualitätsschwelle für jede Aufgabe: Code geprüft, automatisierte Tests geschrieben, in die Testumgebung ausgerollt, Dokumentation aktualisiert. Ohne diese Definition bedeutet „fertig“ für jeden etwas anderes.

Festpreis oder Aufwand? Vertragsmodelle

Kein Thema wird in der Angebotsphase so heftig diskutiert, und die richtige Antwort hängt davon ab, wie gut das Projekt verstanden ist. Je klarer der Umfang, desto sinnvoller ein Festpreis; je größer die Unsicherheit, desto ehrlicher die Abrechnung nach Aufwand.

Ein Festpreis wirkt auf dem Papier am sichersten, versteckt aber zwei Kosten. Der Anbieter preist Unbekanntes als Risikoaufschlag ein. Und alles, was Sie unterwegs lernen, landet als Änderungsantrag auf dem Tisch, sodass sich die Zusammenarbeit vom Verbessern des Produkts zum Auslegen des Vertrags verschiebt.

Die Abrechnung nach Aufwand braucht Vertrauen und Transparenz. Wöchentliche Stundenberichte, Fortschritt im Backlog und die verbleibende Schätzung sind in diesem Modell keine Extras, sondern das Modell selbst. Ein gesundes Muster, das wir oft sehen: Konzeptphase zum Festpreis, Entwicklung nach Aufwand mit Obergrenze, nach dem Livegang ein monatlicher Wartungsvertrag.

Wie liest man Schätzungen?

Eine Softwareschätzung ist kein Versprechen, sondern eine Prognose auf einem bestimmten Wissensstand. Schätzungen vor der Konzeptphase schwanken naturgemäß stark und werden enger, sobald die Konzeptphase abgeschlossen ist und die ersten Sprints laufen. Bitten Sie deshalb um eine Spanne statt einer einzelnen Zahl und fragen Sie, warum sie so breit ist: welche Schnittstelle, welche Unbekannte? Story Points sind keine Stunden, sondern relative Größen; aussagekräftig ist das durchschnittliche Tempo, das sich nach einigen Sprints zeigt. Die Schätzung nach den ersten beiden Sprints neu zu besprechen, ist so normal, dass man es in den Vertrag schreiben kann.

Sprint- und Demo-Rhythmus: Wie sehen Sie Fortschritt?

Agile Teams teilen die Arbeit in kurze Abschnitte, sogenannte Sprints. Laut Scrum Guide dauert ein Sprint höchstens einen Monat, in der Praxis wählen die meisten Teams ein oder zwei Wochen. Das Sprint Review am Ende ist Ihr wichtigster Termin, denn dort wird die fertige Arbeit lauffähig in der Testumgebung gezeigt.

Der Maßstab ist einfach: laufende Software statt Folien. „Die Entwürfe sind fertig“ oder „das Backend steht zu achtzig Prozent“ ist kein Fortschritt. Lassen Sie sich in der Demo die Maus geben, klicken Sie selbst, geben Sie falsche Daten ein, drücken Sie die Zurück-Taste.

Auf Ihrer Seite braucht es einen Product Owner, der Prioritäten festlegt, Fragen des Teams innerhalb weniger Tage beantwortet und an den Demos teilnimmt. Wandern Entscheidungen durch ein fünfköpfiges Gremium, wartet das Team, und bei Abrechnung nach Aufwand landet das Warten direkt auf der Rechnung. Wer eine Führungskraft ohne freie Stunden in der Woche in diese Rolle setzt, bremst das Projekt vom ersten Tag an.

Auch das Backlog müssen Sie einsehen können. Lassen Sie sich Lesezugriff in Jira, Linear oder GitHub Projects geben. Ein einfaches Burn-up-Diagramm, das zeigt, wie viel Umfang erledigt ist und wie sich die Restschätzung bewegt, ist ehrlicher als jeder Monatsbericht.

Wie bleibt der Umfang im Griff?

Schleichende Umfangserweiterung kommt selten als große Entscheidung. Sie kommt als „kleine Ergänzung“, als „Wenn ihr die Maske schon baut, könnt ihr auch …“ oder als Finanz- oder IT-Sicherheitsabteilung, die mitten im Projekt mit eigenen Wünschen dazustößt. Jeder Wunsch ist für sich vernünftig; zusammen schieben sie den Liefertermin um Monate.

Eine einfache Regel genügt meistens: Kommt etwas hinein, geht etwas hinaus. Der neue Wunsch wird ins Backlog geschrieben und geschätzt, und der Product Owner entscheidet, was dafür nach hinten rückt. Jede dieser Entscheidungen kommt mit Datum und Begründung in ein Entscheidungsprotokoll. Ein halbes Jahr später steht dort die Antwort auf „Wer wollte das eigentlich, und warum?“.

Die Erweiterung kommt nicht nur vom Auftraggeber. Eine Animation, die niemand bestellt hat, oder ein Modul „für alle Fälle“ zählt ebenfalls dazu. Sehen Sie so etwas in einer Demo, fragen Sie, zu welcher Story es gehört.

Tests und Qualität: Staging, automatisierte Tests und Abnahme

Ein professionelles Projekt hat mindestens drei Umgebungen: die Entwicklungsumgebung, eine Testumgebung (Staging), die der Produktion möglichst genau gleicht, und die Produktion. Demos und Ihre eigenen Tests finden auf Staging statt; in der Produktion wird nicht experimentiert.

Echte Kundendaten unverändert ins Staging zu kopieren, ist eine verbreitete und gefährliche Abkürzung. Personenbezogene Daten sollten anonymisiert oder durch realistische Testdaten ersetzt werden. Nach DSGVO verdient eine Testumgebung dieselbe Sorgfalt wie die Produktion.

Qualität entsteht nicht durch Herumklicken allein. Ein gutes Team schreibt automatisierte Tests auf mehreren Ebenen und lässt sie bei jedem Zusammenführen von Code in einer CI-Pipeline wie GitHub Actions oder GitLab CI laufen:

• Unit-Tests prüfen, ob einzelne Funktionen richtig rechnen, etwa Rabatte und Mehrwertsteuer.
• Integrationstests: Sie zeigen, dass Code, der mit Datenbank, ERP oder Zahlungsdienstleister spricht, korrekt funktioniert.
• End-to-End-Tests spielen mit Werkzeugen wie Playwright oder Cypress in einem echten Browser Abläufe durch, etwa „Händler meldet sich an, sucht ein Teil, bestellt“.
• Code-Reviews, bei denen jede Änderung von einer anderen Entwicklerin gelesen wird als der, die sie geschrieben hat.

Dazu kommen Prüfungen für Sicherheit, Performance und Barrierefreiheit. Für die Sicherheit sind OWASP ASVS und die OWASP Top 10 ein guter Ausgangspunkt, für Barrierefreiheit die Kriterien der WCAG 2.2; bei Diensten für Verbraucher kann zudem das BFSG greifen. Bei Systemen mit personenbezogenen Daten oder Zahlungen ist ein unabhängiger Penetrationstest vor dem Livegang gut angelegtes Geld.

Der letzte Schritt ist Ihr Abnahmetest. Sie gehen die Akzeptanzkriterien durch und melden Fehler nach Schwere: System nicht nutzbar, wichtige Funktion defekt oder kosmetischer Mangel. Wer vorab festlegt, mit wie vielen offenen Fehlern welcher Schwere live gegangen werden darf, erspart sich den Streit in der letzten Woche.

Planen Sie auch den Tag des Livegangs. Um welche Uhrzeit wird umgestellt, wie lange läuft das Altsystem parallel, wie wird zurückgerollt, wenn etwas schiefgeht, und wer beobachtet in der ersten Woche die Fehlermeldungen? Ein Livegang am Freitagabend kann zur Krise werden, bei der am Wochenende niemand ans Telefon geht.

Quellcode, Nutzungsrechte und Übergabe

Der Quellcode gehört vom ersten Tag an in ein GitHub- oder GitLab-Konto Ihres Unternehmens. Der Anbieter erhält Zugriff; das Repository liegt nicht in seinem Konto und wartet darauf, am Ende „übergeben“ zu werden. Dasselbe gilt für Cloudkonto, Domains, App-Store-Konten, E-Mail-Dienst und API-Schlüssel von Drittanbietern: Alles läuft auf Ihr Unternehmen, das Team bekommt Berechtigungen.

Beim geistigen Eigentum ist ein Punkt zentral. Computerprogramme sind nach §§ 69a ff. UrhG geschützt, und das Urheberrecht selbst ist in Deutschland nicht übertragbar; übertragen werden Nutzungsrechte. Bei Angestellten stehen die vermögensrechtlichen Befugnisse nach § 69b UrhG grundsätzlich dem Arbeitgeber zu, eine Agentur oder ein Freelancer ist aber nicht Ihr Angestellter.

Hier muss der Vertrag die Nutzungsrechte ausdrücklich einräumen, etwa ausschließlich, zeitlich und räumlich unbeschränkt und inklusive Bearbeitung. Nach der Zweckübertragungslehre (§ 31 Abs. 5 UrhG) gelten im Zweifel nur die Rechte als eingeräumt, die der Vertragszweck erfordert.

Zwei weitere Punkte sind wichtig. Der Anbieter bringt oft eigene Bibliotheken und Werkzeuge mit, die schon vor Ihrem Projekt existierten; daran erhalten Sie eine Lizenz, und deren Umfang gehört in den Vertrag. Außerdem nutzt fast jedes Projekt Open-Source-Komponenten. Freizügige Lizenzen wie MIT machen selten Probleme, Copyleft-Lizenzen wie GPL oder AGPL können dagegen verlangen, dass Sie eigenen Quellcode offenlegen, sobald Sie die Software weitergeben oder über ein Netzwerk anbieten. Verlangen Sie bei der Übergabe ein Lizenzverzeichnis.

Dokumentation und Übergabe

Dokumentation sorgt dafür, dass das System nicht im Kopf einer einzelnen Person steckt. Lassen Sie sich bei der Übergabe mindestens Folgendes aushändigen:

• Eine Installations- und Startanleitung (README): Wie bringt eine neue Entwicklerin das System auf ihrem Rechner zum Laufen?
• Einen Architekturüberblick und die Gründe für wichtige technische Entscheidungen.
• API-Dokumentation, am besten im OpenAPI-Format.
• Das Datenmodell und welche Daten wie oft mit externen Systemen ausgetauscht werden.
• Die Deployment-Schritte, eine Liste der Umgebungsvariablen und wo Geheimnisse gespeichert sind und wer sie verwaltet.
• Backup- und Wiederherstellungsverfahren, mindestens einmal erprobt.
• Eine Liste bekannter Probleme und verschobener Aufgaben.

Der Test einer guten Übergabe ist einfach: Kann ein Entwickler außerhalb des Teams das System allein mit diesen Unterlagen aufsetzen und eine kleine Änderung ausrollen? Das tatsächlich zu prüfen, kann ein Schritt der Abnahme sein. Räumen Sie dabei auch die Zugänge auf: Konten ausscheidender Personen werden geschlossen, geteilte Passwörter und API-Schlüssel erneuert.

Nach dem Livegang: Wartung, SLA und was Projekte scheitern lässt

Wartung und SLA

Software ist am Tag des Livegangs nicht fertig; an diesem Tag beginnt ihr Betrieb. Updates von Betriebssystem, Framework und Bibliotheken, Sicherheitspatches, Fehlermeldungen von Nutzern und kleine Verbesserungen brauchen einen Wartungsvertrag, in dessen Mitte das Service Level Agreement steht.

Ein gutes SLA ordnet Störungen zuerst ein: kritisch, wenn das System steht, hoch, wenn eine wichtige Funktion ausfällt, normal, wenn weitergearbeitet werden kann. Für jede Klasse gibt es zwei getrennte Zeiten, die Reaktionszeit und die Zeit bis zur Lösung oder Umgehung. Verwechseln Sie die beiden nicht; „Rückmeldung in zwei Stunden“ und „Behebung in zwei Stunden“ sind sehr verschiedene Zusagen. Servicezeiten, Überwachung und Alarmierung, Backup-Häufigkeit und die Verantwortung für das Hosting gehören in dasselbe Dokument.

Wartung heißt nicht nur, auf Störungen zu warten. Ein monatliches oder jährliches Stundenkontingent für Sicherheitsupdates der Bibliotheken, Versionssprünge von Framework und Serversoftware, ablaufende Zertifikate und kleine Verbesserungen ist weit weniger mühsam, als das System nach zwei Jahren neu schreiben zu müssen.

Was Projekte am häufigsten scheitern lässt

Codequalität allein bringt selten ein Projekt zu Fall. Die Ursachen, die wir am häufigsten sehen, liegen in der Steuerung:

• Auf Auftraggeberseite gibt es niemanden, der entscheiden darf.
• Echte Nutzer sehen das Produkt zum ersten Mal eine Woche vor dem Livegang.
• Datenübernahme und Schnittstellen werden mit „machen wir später“ kleingeredet.
• Alles geht an einem Tag live, statt mit Pilotgruppe und schrittweiser Umstellung.
• Das günstigste Angebot wird gewählt, ohne den Umfang verstanden zu haben.
• Nur ein einziger Entwickler kennt das System.
• Für die Zeit nach dem Livegang ist kein Budget eingeplant.

Wo fangen Sie an?

1. Schreiben Sie Problem, Nutzer und Erfolgsmaßstab auf eine Seite; die Maskenliste kommt später.
2. Starten Sie mit einer eigenen, kleinen Konzeptphase und lassen Sie festhalten, dass die Ergebnisse Ihnen gehören.
3. Schneiden Sie das MVP auf einen Nutzerablauf zu und nehmen Sie Verwaltung, Datenübernahme und Auswertungen in die Liste auf.
4. Verlangen Sie messbare Akzeptanzkriterien für jede Story und eine Definition of Done für das Projekt.
5. Wählen Sie ein Vertragsmodell, das zur Unsicherheit des Projekts passt, und prüfen Sie den Text mit Ihrer Rechtsberatung.
6. Benennen Sie Ihren Product Owner und geben Sie ihm einen Kalender, in dem die Rolle wirklich Platz hat.
7. Legen Sie Repository, Cloudkonten und Domains vom ersten Tag an auf Ihr Unternehmen an.
8. Unterschreiben Sie Wartungsvertrag und SLA vor dem Livegang, solange Ihre Verhandlungsposition noch stark ist.

Wir bei AYTE Digital führen die Konzeptphase bei Individualsoftware als eigenen Abschnitt durch und legen Quellcode und Konten vom ersten Tag an auf den Namen des Kunden an. Haben Sie ein laufendes oder festgefahrenes Projekt, gehen wir gern Ihr Backlog gemeinsam durch und schauen, welche der Punkte oben fehlen.