Ein Vierwochenprojekt, das zehn Wochen dauert, hat selten sechs Wochen an schlechtem Code verloren. Es hat sie ans Warten verloren — auf eine Entscheidung, auf eine Freigabe, auf jemanden mit den richtigen Zugangsdaten, sie zu schicken, auf eine Antwort auf eine Frage, die vier Tage im Posteingang lag. Entwicklungszeit und Kalenderzeit sind zwei verschiedene Uhren, und bei den meisten verspäteten Projekten ist die Lücke zwischen ihnen fast vollständig Zeit, in der niemand tatsächlich programmiert hat.
Entscheidungen sind der häufigste Engpass
Eine Entwicklerin, die an eine Weggabelung kommt — zwei vernünftige Wege, eine Funktion zu bauen, jeder mit anderen Konsequenzen —, muss innehalten und fragen, weil falsches Raten mehr Zeit kostet als das Fragen selbst. Bleibt diese Frage eine Woche unbeantwortet, weil sie die Freigabe von jemandem braucht, der gerade reist, steht das gesamte Projekt dahinter still, obwohl sich die tatsächlich verbleibende Arbeit nicht geändert hat. Eine Person mit der Befugnis zu benennen, diese Fragen zu beantworten, plus eine vereinbarte maximale Antwortzeit, beseitigt diesen Engpass, bevor er auftritt.
Zugangsverzögerungen kosten mehr, als es scheint
Ein Projekt, das Zugangsdaten für einen Zahlungsdienstleister, eine Domain-Registrierungsstelle oder ein bestehendes System braucht, kommt oft ab einem bestimmten Punkt ohne sie nicht weiter — und diese Zugangsdaten liegen häufig bei einem Dritten, einer ehemaligen Mitarbeiterin oder jemandem, der zweimal erinnert werden muss. Eine Woche, die mit dem Warten auf ein Passwort-Reset verloren geht, ist funktional identisch mit einer Woche, die durch ein Codeproblem verloren geht — nur war sie vollständig vermeidbar, wenn die Zugänge vor Projektbeginn eingesammelt worden wären, statt sie erst bei jedem auftretenden Bedarf anzufordern.
Feedback-Latenz summiert sich über das ganze Projekt
Eine Feedbackrunde, die drei Tage statt einen dauert, kostet nicht nur einmal zwei Tage — sie kostet zwei Tage an jedem einzelnen Review-Punkt im Projekt, und die meisten Projekte haben mehrere davon. Ein Team, das sich von Anfang an auf eine konkrete Feedback-Antwortzeit festlegt und sie wie eine Zahlungsfrist behandelt, beseitigt eine Verzögerungsquelle, die sonst bei jedem Meilenstein erneut auftaucht statt nur beim ersten.
Was tatsächlich in der Verantwortung der Entwicklerin liegt
Nichts davon entschuldigt echte Entwicklungsverzögerungen — unterschätzte Komplexität, entdeckte technische Schulden oder eine Entwicklerin, die schlicht im Rückstand ist, sind real und liegen in der Verantwortung der Lieferseite, sie ehrlich zu managen und zu kommunizieren. Aber eine Verzögerung durch eine unbeantwortete Frage mit einer Verzögerung durch schwierigen Code zu verwechseln führt dazu, die falsche Lösung anzuwenden — zusätzliche Entwicklerstunden beschleunigen ein Projekt nicht, das tatsächlich auf eine Entscheidung der Kundenseite wartet, egal wie viele davon hinzukommen.
Die beiden zu unterscheiden ist entscheidend
Zu benennen, in welche Kategorie eine Verzögerung fällt — in dem Moment, in dem sie passiert, nicht erst bei der Nachbesprechung —, ist das, was ein Projekt tatsächlich wieder in den Zeitplan bringt, statt dass alle stillschweigend uneinig darüber bleiben, wessen Woche es war.
Das gehört zum selben Gespräch kaufen, bauen oder konfigurieren — ein gut geführtes Projekt bleibt nur im Zeitplan, wenn beide Seiten die Uhr steuern, die tatsächlich läuft, nicht nur die, die den Code misst.
Unser Software-Team legt Erwartungen an Antwortzeiten und Zugangsanforderungen vor Projektbeginn fest, damit die Wochen, die sonst ans Warten verloren gingen, gar nicht erst entstehen.
