Die Kosten unsichtbarer Arbeit

Unsichtbare Arbeit ist jeder Aufwand, den das Team betreibt, der nicht in einem gemeinsamen System erfasst wird. Sie ist häufiger, als die meisten Teams zugeben, und nimmt vorhersehbare Formen an:

• Slack-Thread-Entscheidungen. Ein 40-Nachrichten-Thread zwischen zwei Entwicklern klärt eine Design-Frage, aber die Entscheidung schafft es nie ins Ticket oder in die PR-Beschreibung. Sechs Monate später macht jemand die Entscheidung rückgängig, weil er nicht wusste, dass sie getroffen wurde.
• „Ich mach das einfach"-Aufgaben. Ein Entwickler bemerkt einen instabilen Test, verbringt zwei Stunden damit, ihn zu beheben, und erstellt nie ein Ticket. Die Arbeit ist passiert, die Zeit wurde aufgewendet, aber der Kapazitätsplan des Teams spiegelt das nicht wider — und niemand lernt aus der Behebung.
• Nebenprojekte und Spikes. Explorative Arbeit, die auf einem lokalen Branch lebt, nie reviewt wird und entweder still stirbt oder drei Wochen später als Überraschungs-PR auftaucht.
• Undokumentierte Hotfixes. Ein Produktionsproblem wird um 23 Uhr mit einem direkten Commit auf main gepatcht. Kein Ticket, keine Post-Mortem-Analyse, keine Aufzeichnung, dass der Fix existiert oder warum er notwendig war. Der nächste Entwickler, der diesen Code anfasst, hat keine Ahnung, wogegen die drei mysteriösen Zeilen schützen.

Nichts davon ist böswillig. Entwickler leisten unsichtbare Arbeit, weil die Reibung, sie zu erfassen, höher erscheint als die Kosten, sie einfach zu erledigen. Und für jeden einzelnen Fall haben sie recht — ein Ticket für eine 20-Minuten-Behebung zu erstellen, fühlt sich wie Overhead an.

Das Problem ist nicht ein einzelner Fall. Das Problem ist das Muster.

Unsichtbare Arbeit bleibt nicht günstig. Sie schaukelt sich auf drei Arten auf, die mit der Zeit teurer werden.

Die Onboarding-Kosten steigen. Jede Entscheidung, die im Kopf von jemandem lebt statt in einem Ticket oder Dokument, ist eine Entscheidung, die ein neues Teammitglied nicht finden kann. Ein Team mit sechs Monaten unsichtbarer Arbeit benötigt einen mehrwöchigen mündlichen Download, um jemanden einzuarbeiten — und dieser Download ist unvollständig, weil die Leute, die ihn geben, die Hälfte dessen vergessen haben, was sie getan haben. Teams mit hoher unsichtbarer Arbeitslast berichten routinemäßig von Onboarding-Zeiten von 4–8 Wochen für Arbeit, die 2 Wochen dauern sollte.

Arbeit wird dupliziert. Wenn Entwickler A nicht weiß, dass Entwickler B letzten Monat bereits dasselbe Problem gelöst hat, löst Entwickler A es erneut. In einem 10-Personen-Team passiert das öfter, als irgendjemand merkt — besonders bei Infrastrukturarbeit, Hilfsfunktionen und Konfigurationsänderungen, die außerhalb der Haupt-Produktcode-Basis leben.

Kontext verflüchtigt sich. Code ohne Ticket-Spur ist Code ohne ein „Warum". Der nächste Entwickler, der ihn liest, sieht was getan wurde, aber nicht warum es getan wurde, was bedeutet, dass er ihn nicht sicher ändern kann. Er lässt ihn entweder in Ruhe (technische Schulden häufen sich an) oder ändert ihn und bricht die Annahme, die der ursprüngliche Autor schützen wollte (erzeugt einen Bug). Beide Ergebnisse sind teuer, und beide sind vermeidbar mit einer einzeiligen Ticket-Beschreibung, die zum Zeitpunkt der Arbeit geschrieben wurde.

Die Aufschaukelung ist es, was unsichtbare Arbeit gefährlich macht. Ein einzelner undokumentierter Hotfix kostet fünf Minuten Kontextverlust. Ein Jahr undokumentierter Hotfixes kostet Wochen an Archäologie jedes Mal, wenn jemand diesen Teil des Systems anfasst.