- vielen Tickets, aber wenig Orientierung
- vielen Beteiligten, aber unklarer Verantwortung
- vielen Meetings, aber kaum Entscheidungen
Ein Projekt, das niemand bewusst so gebaut hat – das aber genau so gewachsen ist.
Ich habe Copilot gefragt, wie er mit einem solchen Anti-Pattern-Projekt umgehen würde. Die folgende Antwort habe ich nicht als technische Anleitung gelesen, sondern als strukturierte Verdichtung von Erfahrung.
Wie man ein chaotisches Projekt rettet – ohne sich selbst zu verlieren
<Copilot-Anfang>
Ein Feldbericht aus der Realität, in der Best Practices nur auf Folien existieren
Es gibt Projekte, die riechen schon beim Betreten nach verbranntem Gummi.
Zu viele Tickets, zu wenig Klarheit.
Zu viele Meinungen, zu wenig Entscheidungen.
Zu viele Meetings, zu wenig Verantwortung.
Und dann wirst du hineingeschoben.
Mit dem freundlichen Satz:
„Kannst du das bitte retten?“
Willkommen im echten Leben.
1. Erst überleben, dann verbessern
Die wichtigste Erkenntnis:
Du rettest ein Projekt nicht, indem du sofort alles richtig machst.
Du rettest es, indem du Schaden begrenzt.
In chaotischen Projekten ist der erste Schritt immer derselbe:
Stabilisieren, nicht optimieren.
Das bedeutet:
- keine neuen Features
- keine neuen Tools
- keine neuen Prozesse
Sondern eine einzige Frage:
Was brennt gerade wirklich?
Chaos ist laut.
Wahrheit ist leise.
2. Erwartungen sichtbar machen – brutal, ehrlich, sofort
In Projekten voller Anti-Pattern fehlt fast immer dasselbe:
eine gemeinsame Realität.
Alle glauben, sie reden über dasselbe.
Tun sie aber nicht.
Deshalb stelle ich eine Frage, die alles verändert:
„Woran würden wir erkennen, dass wir erfolgreich waren?“
Nicht: Was steht im Ticket.
Nicht: Was jemand „immer so macht“.
Nicht: Was „doch klar ist“.
Sondern: Was ist das erwartete Ergebnis?
Wenn niemand es sagen kann, ist das Problem nicht der Code.
Es ist die Führung.
3. Die kleinste funktionierende Wahrheit bauen
In chaotischen Projekten ist Komplexität der Feind.
Deshalb suche ich nach der kleinsten überprüfbaren Wahrheit.
Das ist kein MVP.
Das ist kein Prototyp.
Das ist ein Realitätsanker.
Ein Beispiel:
- Nicht: „Checkout optimieren“
- Sondern: „Unter Bedingung X soll Y passieren – und wir messen Z.“
Diese Mini-Wahrheit ist der erste Stein, auf dem man wieder stehen kann.
4. Tests als Diagnosewerkzeug, nicht als Ritual
In einem Anti-Pattern-Projekt kannst du nicht mit TDD anfangen.
Das wäre wie Yoga in einem brennenden Haus.
Aber du kannst Tests nutzen, um die Wahrheit sichtbar zu machen.
Ein Test ist eine Frage:
„Was genau soll passieren?“
Wenn niemand die Frage beantworten kann, ist das der eigentliche Bug.
Ich schreibe in solchen Projekten zuerst Charakterisierungstests:
- Was tut das System jetzt?
- Was sollte es tun?
- Wo klaffen die Lücken?
Tests werden hier nicht zur Qualitätssicherung genutzt.
Sondern zur Realitätssicherung.
5. Verantwortung neu verteilen – aber richtig
In chaotischen Projekten ist Verantwortung oft ein Wanderpokal.
Jeder hält ihn kurz, bis er heiß wird, und wirft ihn weiter.
Ich drehe das um:
„Wer entscheidet das?“
„Wer trägt die Konsequenz?“
„Wer definiert ‚fertig‘?“
Nicht als Angriff.
Sondern als Struktur.
Verantwortung ist kein Schuldspiel.
Verantwortung ist ein Klärungswerkzeug.
6. Kommunikation entgiften
Chaotische Projekte haben toxische Kommunikationsmuster:
- „Das war doch klar.“
- „Das stand im Ticket.“
- „Das haben wir immer so gemacht.“
- „Das muss jetzt einfach schnell gehen.“
Ich ersetze das durch:
- Explizite Erwartungen
- Explizite Entscheidungen
- Explizite Risiken
Nicht laut.
Nicht belehrend.
Sondern ruhig, präzise, unmissverständlich.
Chaos verliert gegen Klarheit.
Immer.
7. Kleine Siege sichtbar machen
Ein chaotisches Projekt wird nicht durch einen großen Wurf gerettet.
Sondern durch eine Serie kleiner, konsequenter Verbesserungen.
Ich mache diese sichtbar:
- Was war vorher unklar?
- Was ist jetzt klar?
- Was wurde entschieden?
- Was wurde verhindert?
- Was wurde stabilisiert?
Das Team merkt plötzlich:
„Wir bewegen uns wieder.“
Und Bewegung ist der Anfang von Vertrauen.
8. Der stille Trick: Du rettest nicht das Projekt – du rettest die Entscheidungsfähigkeit
Am Ende ist die Wahrheit brutal einfach:
Projekte scheitern nicht an Code.
Sie scheitern an fehlenden Entscheidungen.
Wenn du es schaffst, dass Erwartungen klar werden,
Entscheidungen früher fallen,
und Realität wieder sichtbar wird,
dann rettest du nicht nur das Projekt.
Du rettest die Menschen darin.
Schlussgedanke
Wer in ein chaotisches Projekt geworfen wird,
braucht keine Heldentaten.
Er braucht Klarheit.
Mut zur Wahrheit.
Und die Fähigkeit, Erwartungen in überprüfbare Realität zu übersetzen.
Das ist keine Best Practice.
Das ist Überleben.
Und manchmal ist Überleben der erste Schritt zu Qualität.
</Copilot-Ende>
Fazit: Warum das alles richtig klingt – und in der Realität oft anders ist
Das alles klingt schlüssig.
Fast beruhigend.
Klarheit.
Entscheidungen.
Realitätsanker.
Verantwortung.
Als würde Chaos nur darauf warten, endlich richtig angesprochen zu werden.
Und ja – in der Theorie funktioniert das.
In vielen Situationen sogar erstaunlich gut.
Aber die Realität chaotischer Projekte ist komplizierter.
Nicht, weil die beschriebenen Ansätze falsch wären.
Sondern weil Projekte selten nur technische oder organisatorische Probleme sind.
Sie sind soziale Systeme.
Und soziale Systeme reagieren nicht linear auf Klarheit.
Chaos ist oft kein Zustand, sondern ein Schutzmechanismus
Viele chaotische Projekte sind nicht zufällig chaotisch.
Sie sind es geworden, weil Chaos lange Zeit funktioniert hat.
- Unklare Tickets vermeiden Entscheidungen.
- Viele Meetings verteilen Verantwortung.
- Vage Ziele schützen vor Messbarkeit.
Chaos hält Dinge offen.
Und Offenheit fühlt sich sicher an, wenn niemand verlieren will.
Wer Klarheit schafft, greift in diese Schutzmechanismen ein.
Und das erzeugt Widerstand – nicht aus Bosheit, sondern aus Selbstschutz.
Entscheidungen sind selten technisch – sondern politisch
Die Idee, Entscheidungen „einfach sichtbar zu machen“, unterschätzt einen zentralen Punkt:
Entscheidungen haben Konsequenzen.
Und Konsequenzen haben immer eine Adresse.
In der Realität bedeutet Klarheit oft:
- jemand liegt falsch
- jemand verliert Einfluss
- jemand wird sichtbar verantwortlich
Nicht jedes Projekt scheitert an fehlender Kompetenz.
Viele scheitern daran, dass niemand die Kosten einer Entscheidung tragen will.
Methoden können das nicht auflösen.
Nur Machtverhältnisse können das.
Nicht jedes Projekt will gerettet werden
Das ist unbequem, aber realistisch:
Nicht jedes Projekt will gerettet werden.
Manche Projekte existieren, weil:
- Budgets gebunden werden müssen
- Organisationen beschäftigt bleiben sollen
- politische oder strategische Versprechen erfüllt werden müssen
In solchen Kontexten ist „Projekt retten“ nicht das Ziel.
Stabilität des Systems ist es.
Wer hier echte Klarheit schafft, wird schnell als Störfaktor wahrgenommen –
nicht als Retter.
Klarheit hat einen emotionalen Preis
Was in vielen Leitfäden fehlt, ist der Preis:
- Klarheit kostet Energie.
- Wahrheit kostet Beziehungskapital.
- Entscheidungen kosten Schlaf.
Nicht jede Person kann oder will diesen Preis zahlen –
vor allem nicht dauerhaft.
Viele Anti-Pattern sind deshalb keine Dummheit.
Sondern Erschöpfung, die sich in Struktur verwandelt hat.
Schlussgedanke 2
Der Text beschreibt einen idealen Umgang mit Chaos.
Einen reifen, reflektierten, verantwortungsvollen.
Aber in der Realität braucht es dafür mehr als gute Methoden:
- Rückendeckung
- ein klares Mandat
- psychologische Sicherheit
- und manchmal schlicht Glück
Ohne das bleibt Klarheit ein Risiko.
Die eigentliche Frage ist deshalb nicht:
„Wie rette ich ein chaotisches Projekt?“
Sondern:
„In welchem System ist Rettung überhaupt erwünscht –
und was kostet sie mich persönlich?“
Manchmal ist der klügste Schritt nicht, Ordnung zu schaffen.
Sondern zu erkennen, wo Ordnung strukturell nicht vorgesehen ist.
Und auch das ist Erfahrung.