TL;DR: Wenn Softwareprojekte sich über Monate ziehen, liegt das selten an fehlender Kapazität. Bei einem Software-Unternehmer mit 10 Mitarbeitern lag ein Projekt ein halbes Jahr still — weil Support und Entwicklung nur über Tickets kommunizierten. Sobald ein Entwickler und ein Supporter gemeinsam am selben Projekt arbeiteten, war es in unter einer Woche fertig. Der Hebel war die Informationslücke zwischen den Abteilungen, die durch cross-funktionale Zusammenarbeit verschwand.
287 offene Tickets und ein Inhaber, der alles koordiniert
Montagmorgen, Ticket-Board: 287 offene Einträge. Ein Software-Unternehmer mit 10 Mitarbeitern scrollt durch die Liste, priorisiert, schiebt um, beantwortet Rückfragen von Entwicklern, die Tickets nicht verstehen — weil der Supporter, der sie angelegt hat, den Kontext längst vergessen hat. Ein konkretes Kundenprojekt steht seit über einem halben Jahr auf der Liste. Kapazität wäre da. Trotzdem bewegt sich nichts.
Wie ein Supporter und ein Entwickler das Projekt in einer Woche abschlossen
Die Struktur im Unternehmen war klassisch: Der Supporter stellte ein Problem fest, schrieb ein Ticket, beschrieb es so genau wie möglich — und hoffte, dass der Entwickler eine Woche später noch verstand, was gemeint war. Der Entwickler öffnete das Ticket, hatte Rückfragen, der Supporter erinnerte sich nicht mehr an die Details. Neues Ticket, neue Wartezeit. Das Projekt drehte sich im Kreis.
Im Rahmen eines Coachings bei anne&thorsten. lernte der Inhaber ein Prinzip kennen, das er sofort umsetzte: Er setzte einen Entwickler und einen Supporter zusammen an dasselbe Projekt. Die beiden gingen gemeinsam zum Kunden, holten die Anforderungen ein, der Entwickler programmierte, der Supporter testete — Seite an Seite, im selben Raum, am selben Tag. Das Projekt, das ein halbes Jahr stillgestanden hatte, war in unter einer Woche fertig. Der Inhaber war an keiner Stelle involviert. Die beiden Mitarbeiter kamen grinsend zu ihm, weil sie selbst merkten, dass da gerade etwas passiert war.
Warum das Ticket-System der eigentliche Engpass war
Der Reflex bei einem Projekt, das sich über Monate zieht: mehr Leute draufsetzen, höher priorisieren, den Druck erhöhen. Keiner dieser Hebel hätte hier etwas geändert. Das Problem war die Informationslücke zwischen zwei Abteilungen.
Supporter und Entwickler arbeiteten zeitlich versetzt am selben Gegenstand. Der Supporter hatte den Kontext — er kannte den Kunden, das Problem, die Dringlichkeit. Der Entwickler hatte die Fähigkeit, es zu lösen. Aber zwischen den beiden lag ein Ticket-System, das als Kommunikationskanal funktionieren sollte und in Wahrheit eine Mauer war. Jedes Ticket war eine Übersetzung: Der Supporter übersetzte sein Verständnis in Text, der Entwickler übersetzte den Text zurück in ein technisches Problem. Bei jeder Übersetzung ging Information verloren. Und jede Rückfrage kostete Tage, weil sie asynchron lief.
Sobald die beiden im selben Raum saßen, verschwand die Übersetzungsschicht. Eine Rückfrage war eine Frage über den Tisch, keine Woche Wartezeit. Das Projekt wurde in unter einer Woche abgeschlossen — bei geschätztem Aufwand von zwei bis drei Wochen. Die Beschleunigung kam aus dem Wegfall der Informationslücke. Kein neues Tool, kein zusätzlicher Mitarbeiter, keine Überstunden.
Dieses Muster sitzt in Software-Unternehmen, die ihre Teams funktional aufteilen: QA hier, Entwicklung dort, Support drüben. Jede Abteilung für sich funktioniert. Aber die Übergaben zwischen den Abteilungen fressen mehr Zeit als die eigentliche Arbeit. Wer ein Softwareprojekt schneller liefern will, muss an den Übergaben ansetzen — da, wo Information verloren geht.
Wo liegt Dein Übergabe-Engpass?
Nimm Dir ein Projekt, das sich gerade zieht, und zähle die Übergaben: Wie oft wechselt eine Information von einer Person zur nächsten, bevor etwas umgesetzt wird? Wenn Du bei drei oder mehr Übergaben landest, hast Du Deinen Hebel. Setz die Leute zusammen, die das Wissen haben und die das Problem lösen können — an denselben Tisch, am selben Tag. Die Geschwindigkeit kommt aus der Nähe.
Weiterlesen
- Entwicklungseffizienz verdoppeln: Wie ein 30-Minuten-Daily 20 Meeting-Stunden ersetzt — 20 Stunden Meetings pro Woche, kein Sprint-Commitment, Features seit einem Jahr offen.
Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.
Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.
Häufige Fragen
Funktioniert das auch bei Teams, die remote arbeiten?
Ja — der Mechanismus ist derselbe. Wichtig ist, dass Entwickler und Supporter synchron am selben Projekt arbeiten, ob im selben Raum oder in einem gemeinsamen Video-Call. Die Informationslücke entsteht durch asynchrone Übergaben, nicht durch räumliche Trennung allein.
Brauche ich dafür agile Frameworks wie Scrum oder Kanban?
Kein Framework ist Voraussetzung. Der Kern ist, dass die Leute mit dem Wissen und die Leute mit der Umsetzungsfähigkeit gleichzeitig am selben Gegenstand arbeiten. Ob Du das Sprint nennst oder Projektteam, spielt keine Rolle.
Was mache ich, wenn mein Team zu klein ist für feste cross-funktionale Gruppen?
Feste Gruppen sind kein Muss. Es reicht, pro Projekt eine temporäre Paarung zu bilden — ein Entwickler, ein Supporter, ein gemeinsamer Kundentermin. Bei 10 Mitarbeitern ist das realistisch, ohne die restliche Arbeit lahmzulegen.
Wie messe ich, ob die Übergaben wirklich das Problem sind?
Nimm Dein längstes offenes Projekt und zeichne den Weg einer einzelnen Anforderung nach: Vom Kunden über den Supporter ins Ticket, vom Ticket zum Entwickler, vom Entwickler zurück zum Supporter, vom Supporter zum Kunden. Zähle die Tage, die zwischen den Übergaben vergehen. Wenn die Wartezeit zwischen den Schritten länger ist als die Arbeitszeit in den Schritten, hast Du Deine Antwort.