Ein festgefahrenes Software-Projekt retten

Woran du erkennst, dass dein Projekt wirklich feststeckt

Ein festgefahrenes Software-Projekt sieht von aussen oft noch gesund aus. Es wird gearbeitet, es gibt Tickets, es gibt Meetings. Was fehlt, ist Bewegung in Richtung Ziel. Du merkst es an ein paar nüchternen Signalen: Die Abstände zwischen zwei brauchbaren Releases werden grösser. Jede Änderung zieht zwei neue Fehler nach sich. Niemand im Team kann dir mehr sagen, wann ein bestimmtes Feature fertig ist, ohne lange Luft zu holen.

Dahinter steckt selten ein einzelner Schuldiger. Meistens hat sich über Monate eine Mischung angesammelt: Anforderungen, die unterwegs dreimal gedreht wurden, technische Abkürzungen, die nie zurückgezahlt wurden, und ein Vertrauensverlust zwischen Auftraggeber und Team. Wenn du das Projekt retten willst, fängst du nicht mit Code an. Du fängst mit einer klaren Lagebeurteilung an.

Die Bestandsaufnahme: Wo steht das Projekt heute wirklich

Bevor du irgendetwas reparierst, brauchst du ein belastbares Bild. Eine Bestandsaufnahme ist kein Schuldgespräch, sondern eine Inventur. Drei Dinge schaust du dir an.

Erstens den Stand der Software. Läuft das, was schon gebaut wurde, überhaupt? Gibt es eine Umgebung, in der du es ausprobieren kannst, ohne dass jemand vorher zwei Stunden konfiguriert? Wenn niemand das Projekt auf einem frischen Rechner zum Laufen bringt, weisst du schon viel über den Zustand.

Zweitens den Stand des Wissens. Wo liegt das Verständnis darüber, wie das System funktioniert? Wenn die Antwort eine einzelne Person ist, die gerade kündigen will, ist das ein Risiko, das du sofort adressieren musst. Lass dir die zentralen Abläufe erklären und mitschreiben. Was nirgends dokumentiert ist, existiert betrieblich nicht.

Drittens den Stand der Erwartungen. Oft reden Auftraggeber und Team über zwei verschiedene Projekte. Der eine erwartet ein fertiges Produkt, das andere baut noch an den Grundlagen. Setz beide Seiten an einen Tisch und schreib auf, was bis wann da sein soll. Diese Liste ist oft schon die halbe Diagnose.

Am Ende der Bestandsaufnahme hast du eine kurze, klare Lagekarte: was funktioniert, was wackelt, was fehlt, und wo das grösste Risiko sitzt. Genau diese Reihenfolge entscheidet über die nächsten Schritte. Viele der tieferen Ursachen sind dieselben, an denen Vorhaben generell kippen, und es lohnt sich, sie zu kennen, bevor du weitermachst, warum SaaS-Projekte scheitern.

Stabilisieren kommt vor Ausbauen

Der häufigste Fehler beim Retten: Man will sofort die fehlenden Features nachliefern, weil die ja im Rückstand sind. Das ist verständlich und falsch. Auf einem schwankenden Fundament weiterzubauen, vergrössert nur den Krater.

Stabilisieren heisst, das System wieder in einen Zustand zu bringen, in dem Änderungen berechenbar werden. Konkret bedeutet das: Es gibt einen reproduzierbaren Weg, die Software zu starten und auszuliefern. Es gibt ein Minimum an automatischen Prüfungen, damit eine Korrektur nicht heimlich drei andere Stellen zerstört. Und es gibt Sichtbarkeit darüber, ob das laufende System gerade gesund ist oder nicht.

Dieser letzte Punkt wird unterschätzt. Ein Projekt, das niemand beobachtet, fällt nicht plötzlich aus, es war schon vorher krank, nur hat es keiner gesehen. Ein schlankes Grundgerüst aus Überwachung, Backups und Alarmierung ist kein Luxus, sondern die Voraussetzung dafür, dass du überhaupt ruhig arbeiten kannst. Wir behandeln das ausführlich unter Monitoring, Backups und Alerting als Minimum.

Wir merken den Unterschied bei den eigenen Produkten. Wortfreunde und Reazon laufen jeden Tag für echte Nutzer. Wenn dort etwas wackelt, trifft es uns selbst, nicht nur einen Kunden. Diese Betreiberperspektive verändert, wie man baut: Du legst zuerst die Sicherungen, dann das schöne Stockwerk. Ein Team, das ein Produkt nie selbst betrieben hat, neigt dazu, diese Reihenfolge umzudrehen.

Stabilisieren fühlt sich nach Stillstand an, weil keine neuen Funktionen entstehen. Tatsächlich ist es der Moment, in dem die Geschwindigkeit zurückkommt. Sobald Änderungen wieder sicher sind, geht der Rest schneller, als alle erwarten.

Den Scope retten, statt ihn zu verteidigen

Wenn ein Projekt feststeckt, ist der Umfang fast immer zu gross. Er ist über die Zeit gewachsen, Feature für Feature, jedes für sich sinnvoll, in Summe erdrückend. Den Scope retten heisst, ihn auf das zurückzuschneiden, was den Kern tatsächlich trägt.

Die nützlichste Frage in dieser Phase: Welcher Teil der Software löst das eigentliche Problem, und welcher Teil ist nur drumherum gewachsen? Oft stellt sich heraus, dass dreissig Prozent der Funktionen neunzig Prozent des Werts liefern. Der Rest ist Ballast, der das Projekt langsam und teuer macht. Wenn du Mühe hast, diesen Kern zu benennen, hilft dir die Logik aus erste Funktion und Produktkern finden.

Scope retten ist eine politische Übung, nicht nur eine technische. Jede gestrichene Funktion hat jemanden, der sie wollte. Deshalb triffst du diese Entscheidungen offen und nachvollziehbar: Wir schieben X, weil Y das Produkt zuerst tragfähig macht. Geschoben ist nicht gestrichen. Du nimmst Dinge bewusst aus der ersten Runde, ohne sie für immer zu begraben. Das nimmt der Diskussion die Schärfe und gibt dem Team eine erreichbare Linie.

Ein gut geschnittener Scope macht aus einem hängenden Projekt wieder ein lieferbares. Du brauchst ein nächstes, sichtbares Ergebnis, das in Wochen erreichbar ist, nicht in einem unbestimmten Irgendwann. Dieses erste echte Erfolgserlebnis stellt das Vertrauen wieder her, das unterwegs verloren ging.

Team- oder Partnerwechsel sauber gestalten

Manchmal ist nicht der Scope das Problem, sondern die Zusammenarbeit. Der bisherige Dienstleister liefert nicht mehr, die Kommunikation ist zerrüttet, oder das Wissen droht mit einer Person aus der Tür zu gehen. Ein Wechsel ist dann legitim. Er ist nur gefährlich, wenn er schlecht gemacht wird.

Der kritische Punkt bei jedem Wechsel ist die Übergabe. Software gehört nicht dem, der sie geschrieben hat, sondern dem, der dafür bezahlt hat, vorausgesetzt, das wurde sauber geregelt. Bevor du einen Partner wechselst, klärst du drei Dinge: Hast du Zugang zu allem Code und allen Zugängen? Liegt das Wissen in übergebbarer Form vor oder nur in Köpfen? Und gibt es eine Übergangsphase, in der alt und neu sich überlappen?

Gerade der letzte Punkt entscheidet, ob der Wechsel glatt läuft. Eine harte Kante, an der das alte Team am Freitag geht und das neue am Montag bei null anfängt, produziert genau den Wissensverlust, den du vermeiden willst. Besser ist eine begleitete Übergabe, in der Fragen noch beantwortet werden. Die rechtlichen und praktischen Details dazu findest du unter wem gehört der Code bei der Übergabe.

Wenn du einen neuen Partner suchst, achtest du weniger auf Versprechen als auf Arbeitsweise. Kann er dir zeigen, wie er ein bestehendes, fremdes System übernimmt? Redet er über Betrieb und nicht nur über Entwicklung? Worauf du sonst noch schaust, steht in einen guten Umsetzungspartner erkennen.

Retten oder neu bauen: die nüchterne Abwägung

Nicht jedes Projekt ist es wert, gerettet zu werden. Das ist die unbequeme Wahrheit, die man dir als Auftraggeber oft erspart. Es gibt einen Punkt, an dem Reparieren teurer und langsamer wird als ein gezielter Neubau des Kerns.

Die Abwägung läuft über ein paar Treiber, nicht über ein Bauchgefühl. Frag dich: Wie viel vom bestehenden Code würdest du behalten, wenn du heute neu anfangen müsstest? Wenn die Antwort unter der Hälfte liegt, wird das Festhalten zur Bürde. Wie tief sitzen die Probleme? Ein paar schlampige Stellen lassen sich reparieren. Eine grundlegend falsche Architektur lässt sich nicht wegrefactorn, sie diktiert deine Geschwindigkeit für immer. Und wie gut verstehst du das, was schon da ist? Code, den niemand mehr durchdringt, ist betrieblich oft wertloser als gar kein Code.

Ein Neubau ist trotzdem keine harmlose Entscheidung. Du wirfst nicht nur Code weg, sondern auch das eingebaute Wissen über alle Sonderfälle, die in den Monaten davor entdeckt wurden. Wer komplett neu anfängt, läuft Gefahr, dieselben Fehler ein zweites Mal zu machen, nur mit besserem Gewissen. Deshalb ist der häufigste vernünftige Weg ein dritter: Du behältst die Teile, die funktionieren und verstanden sind, und baust gezielt die kaputten Kernstücke neu. Selten ist alles Müll, selten ist alles Gold.

Wann lohnt sich das Retten also nicht? Wenn das Produkt selbst keinen Markt hat, rettet auch die sauberste Stabilisierung nichts. Dann ist die richtige Antwort nicht besserer Code, sondern eine andere Frage: Brauchen die Nutzer das überhaupt? Software-Probleme zu lösen, die eigentlich Produktprobleme sind, ist verbranntes Geld. In dem Fall gehst du einen Schritt zurück und denkst über den Kern des Produkts neu nach, bevor du wieder in die Umsetzung investierst, Produktentwicklung von SaaS.

Was den Unterschied macht zwischen Retten und Weiterleiden

Ein festgefahrenes Projekt zu retten ist Handwerk, kein Wunder. Die Reihenfolge trägt: zuerst nüchtern hinschauen, dann das Fundament festigen, dann den Umfang auf das Tragende zurückschneiden, und einen Wechsel, falls nötig, mit sauberer Übergabe gestalten. Was du dabei gewinnst, ist nicht nur lauffähige Software, sondern wieder Berechenbarkeit. Du weisst, was als Nächstes kommt und wann.

Die schwierigste Entscheidung bleibt die zwischen Reparieren und Neubauen, und sie verträgt keine Schönfärberei. Triff sie über Treiber, nicht über Hoffnung: wie viel ist verwertbar, wie tief sitzt der Schaden, wie gut wird das System verstanden. Ein Projekt, das niemand mehr betreiben kann, ist kein Projekt mehr, sondern eine offene Rechnung. Der Weg zurück führt über kleine, sichtbare Lieferungen, die das Vertrauen Stück für Stück wieder aufbauen. Genau dort beginnt die Rettung.