„Wir brauchen eine Software, die unseren Prozess abbildet“ — so beginnen viele Erstgespräche. Zwischen diesem Satz und einem Produkt, das im Alltag zuverlässig läuft, liegen Entscheidungen, die über Jahre nachwirken. Dieser Beitrag zeigt den Fahrplan, mit dem wir Individualentwicklungen umsetzen — inklusive der Stellen, an denen Projekte typischerweise entgleisen.
Anforderungen: aus Wünschen testbare Kriterien machen
Der häufigste Projektfehler passiert vor der ersten Zeile Code: unklare Anforderungen. „Das System soll Angebote verwalten“ ist ein Wunsch, kein Kriterium. Wir übersetzen Wünsche in überprüfbare Aussagen: „Ein Sachbearbeiter erstellt aus einer Kundenanfrage in unter fünf Minuten ein freigabefähiges Angebot; Preisregeln kommen aus dem ERP; jede Freigabe wird revisionssicher protokolliert.“ Solche Sätze kann man testen — und genau daran wird später abgenommen. Für ein mittelgroßes Projekt entstehen so typischerweise 40 bis 80 Akzeptanzkriterien, priorisiert in Muss und Kann.
Discovery und Prototyp: Risiken früh entschärfen
Bevor wir ein Team auf Monate verplanen, klären wir die zwei bis drei größten technischen Risiken in einer kurzen Discovery-Phase — meist zwei bis vier Wochen. Gibt es eine belastbare Schnittstelle zum Altsystem? Reicht die Datenqualität für die geplante Automatisierung? Ein klickbarer Prototyp der Kernmaske gehört ebenfalls dazu: Er kostet wenige Tage und verhindert die teuerste Fehlentwicklung überhaupt — eine Software, die formal korrekt ist, aber am Arbeitsalltag der Nutzer vorbeigeht.
Architektur: Entscheidungen für die nächsten fünf Jahre
Architektur heißt nicht, das neueste Framework zu wählen, sondern die Struktur, die zum Problem und zur Organisation passt. Unsere Leitfragen: Wer betreibt das System in fünf Jahren? Welche Lastspitzen sind realistisch? Welche Teile ändern sich häufig, welche nie? Daraus folgen bewusst konservative Entscheidungen — etablierte Sprachen, dokumentierte Schnittstellen, klare Modultrennung. Jede wesentliche Entscheidung halten wir in einem kurzen Architecture Decision Record fest: eine halbe Seite, die in drei Jahren erklärt, warum etwas so gebaut wurde.
Entwicklung: kurze Iterationen, Reviews, automatisierte Tests
Die Umsetzung läuft in Iterationen von zwei Wochen, jede endet mit einem lauffähigen Zwischenstand, den der Kunde selbst bedienen kann. Drei Qualitätsregeln gelten dabei ohne Ausnahme: Jede Änderung durchläuft ein Code-Review durch eine zweite Person. Kernlogik ist durch automatisierte Tests abgedeckt, die bei jedem Stand automatisch laufen. Und Fehler aus dem Testbetrieb werden vor neuen Features behoben — sonst baut man auf Sand. Ein Kundenportal mit Anbindung an Warenwirtschaft und Dokumentenablage entsteht in diesem Modus typischerweise in 12 bis 16 Wochen bis zum ersten produktiven Release. Einen Überblick über unser Leistungsspektrum von der Konzeption bis zur Entwicklung finden Sie unter Dienstleistungen.
Go-live ist kein Endpunkt: Betrieb und Weiterentwicklung
Software, die produktiv geht, beginnt erst zu leben. Deshalb gehören zu jedem Projekt ein Betriebskonzept (Monitoring, Backups, Update-Zyklen), eine Einweisung der Anwender und ein definierter Kanal für Fehlermeldungen und Änderungswünsche. Realistisch sollten Sie pro Jahr 15 bis 20 Prozent der ursprünglichen Entwicklungskosten für Pflege und Weiterentwicklung einplanen — das ist kein Mangel, sondern der Normalzustand nützlicher Software: Sie wächst mit den Anforderungen.
Woran Sie einen belastbaren Fahrplan erkennen
Ein seriöses Angebot für Individualsoftware nennt testbare Abnahmekriterien, weist Discovery und Risiken explizit aus, liefert in kurzen Etappen sichtbare Ergebnisse und beziffert die Folgekosten des Betriebs. Fehlt einer dieser Punkte, fragen Sie nach. Wenn Sie ein konkretes Vorhaben durchdenken möchten — vom ersten Anforderungsworkshop bis zur Umsetzung — sprechen Sie mit uns: zum Erstgespräch.
