Die Psychologie stressiger Projekte: wenn ein Experte ein ganzes Team schlägt

Ginge das mit weniger Leuten schneller?

Über jedem komplexen Projekt hängt eine Frage. Meistens bleibt sie unausgesprochen, weil sie in Zeiten von Agile, Zusammenarbeit und täglichen Standups fast ketzerisch klingt: Ginge das eigentlich mit weniger Leuten schneller?

Öfter, als irgendwer zugeben mag, lautet die Antwort Ja. Nicht immer und nicht für alles. Aber bei einer bestimmten Art von Arbeit, der mit hohem Druck und eng verzahnten Teilen, schlägt ein erfahrener Entwickler, der das ganze Problem im Kopf halten kann, oft ein Team guter Entwickler, die die Hälfte ihrer Zeit damit verbringen, einander Dinge zu erklären.

Das ist kein Plädoyer gegen Teamarbeit. Es ist ein Plädoyer dafür, zu wissen, wann Teamarbeit hilft und wann sie das ist, was dich bremst. Jedes Unternehmen und jede Zahl in den Rechenbeispielen unten ist erfunden.

Jede weitere Person bringt mehr als ein Gespräch mit

Jede Person, die du einem Projekt hinzufügst, bringt Abstimmungsaufwand mit, und zwar nicht linear. Zwei Leute brauchen einen Kanal. Drei Leute brauchen drei. Vier brauchen sechs. Fünf brauchen zehn. Bei einem Team von acht gibt es 28 mögliche Paare, die vielleicht miteinander reden müssen, und alle auf demselben Stand zu halten, wird zu einer eigenen Aufgabe.

Fred Brooks hat das 1975 in The Mythical Man Month beschrieben, aus seiner Zeit als Leiter des Projekts IBM System/360. Muss jeder Teil einer Aufgabe mit jedem anderen abgestimmt werden, schrieb er, wächst der Aufwand mit der Zahl der Paare, und wer einem verspäteten Softwareprojekt Leute hinzufügt, verspätet es weiter. Dieser zweite Satz wurde als Brooks' Gesetz bekannt.¹

Die Zahl der Paare ist eine kleine Formel:

$$C(n) = \frac{n(n-1)}{2}$$

Dabei ist $C(n)$ die Zahl der Kommunikationswege in einer Gruppe, $n$ die Zahl der Personen, $n-1$ die Zahl der anderen, mit denen jede Person reden könnte, und die Division durch $2$ zählt jeden Weg einmal, denn der Weg von Anna zu Ben ist derselbe wie der von Ben zu Anna. Die nächste Person bringt $C(n) - C(n-1) = n - 1$ neue Wege mit, also kostet jede Ergänzung mehr als die davor. Das ist der Abstand zwischen Grenzwert und Durchschnitt, erklärt in Grundlagen: Grenzwert und Durchschnitt.

Rechenbeispiel: ein Checkout Team in Hamburg wächst von drei auf acht

Ein Hamburger Studio, speicherstadtdigital.example, baut mit drei Entwicklern einen Checkout neu. Der Kunde will ihn früher haben, also holt das Studio fünf weitere dazu.

Schritt 1, die Wege. Mit drei Leuten ist $C(3) = \frac{3 \times 2}{2} = 3$. Mit acht ist $C(8) = \frac{8 \times 7}{2} = 28$. Das Team ist $8 / 3 \approx 2{,}7$ mal so groß, die Zahl der Wege $28 / 3 \approx 9{,}3$ mal so groß.

Schritt 2, eine Annahme für das Beispiel: Jedes Paar, das im Gleichschritt bleiben muss, braucht dafür 10 Minuten am Tag. Das kostet 20 Personenminuten, weil zwei Leute im Gespräch sind.

Schritt 3, die täglichen Kosten. Drei Leute: $3 \times 20 = 60$ Personenminuten. Acht Leute: $28 \times 20 = 560$ Personenminuten, etwas mehr als neun Stunden.

Schritt 4, der Anteil an der Kapazität. Bei siebeneinhalb Stunden am Tag haben drei Leute $3 \times 450 = 1.350$ Minuten, die Abstimmung nimmt also $60 / 1.350 \approx 4{,}4\ \%$. Acht Leute haben $8 \times 450 = 3.600$ Minuten, die Abstimmung nimmt also $560 / 3.600 \approx 15{,}6\ \%$.

Das Studio hat die Kopfzahl mehr als verdoppelt und den Anteil jedes Tages, der fürs Abstimmen draufgeht, mehr als verdreifacht.

Die waagrechte Achse ist die Zahl der Personen im Team, die senkrechte die möglichen Kommunikationswege zwischen ihnen. Die Balken biegen sich nach oben: Von neun auf zehn Personen kommen neun Wege dazu, von zwei auf drei nur zwei. Ein Team aus einer Person hat keinen.

Deshalb stellen Unternehmen Projektmanager ein: Jemand muss die Abstimmung abstimmen. Projektmanagement ist wertvoll, und ich rede es nicht klein. Aber es ist Mehraufwand, Arbeit über die Arbeit.

Jetzt nimm die Abstimmung weg. Eine Person, eine Codebasis, ein Problem: keine Abstimmungsmeetings, keine Übergabedokumente. Die Wege innerhalb der Arbeit fallen auf null. Der eine, der bleibt, zwischen dieser Person und dem Kunden, zählt umso mehr.

Meetings sind der sichtbare Teil der Steuer

In Meetings lassen sich die Kosten der Abstimmung leicht zählen, also zähle ich sie.

Rechenbeispiel: ein Sprint für ein Team aus fünf in Köln

Ein Kölner Softwarehaus, suedstadtcode.example, gibt fünf Entwicklern eine neue Funktion und einen Sprint von zwei Wochen, also 10 Arbeitstage.

Schritt 1, der Kickoff: eine Stunde, fünf Leute, also 5 Personenstunden.

Schritt 2, die Sitzung zum technischen Design: zwei Stunden, fünf Leute plus eine Architektin, die aus der Ferne dazukommt, also $2 \times 6 = 12$ Personenstunden.

Schritt 3, die täglichen Standups: 15 Minuten, fünf Leute, jeden Arbeitstag. Das sind $0{,}25 \times 5 \times 5 = 6{,}25$ Personenstunden pro Woche und $12{,}5$ über den Sprint.

Schritt 4, die Summe: $5 + 12 + 12{,}5 = 29{,}5$ Personenstunden geplanter Meetings über den Sprint.

Schritt 5, der Anteil: Fünf Leute über 10 Tage zu je siebeneinhalb Stunden ergeben $5 \times 10 \times 7{,}5 = 375$ Personenstunden, die Meetings nehmen also $29{,}5 / 375 \approx 7{,}9\ \%$ des Sprints.

Die Alternative: ein Entwickler mit Erfahrung im Fachgebiet bekommt dieselbe Funktion. Ein Gespräch über die Anforderungen, rund 90 Minuten, dann eine Woche bauen. Der geplante Mehraufwand liegt bei 1,5 Stunden.

Und das ist ein gut geführtes Team. Ich habe Schlimmeres gesehen. Ich habe Projekte gesehen, in denen die Last an Meetings so hoch war, dass Entwickler zwei Stunden ununterbrochene Zeit zum Programmieren am Tag hatten und die meiste davon damit verbrachten, sich von Kontextwechseln zu erholen.

Die Kosten, die du im Kalender nicht siehst

Die 7,9 % sind die ehrliche Zahl für die Meetings selbst, und sie ist nicht dramatisch. Die größeren Kosten verstecken sich dazwischen. Gloria Mark und Kollegen haben 24 Wissensarbeiter genau beobachtet und ihre Arbeit als stark zersplittert beschrieben: Die Leute verbrachten etwa 11 Minuten mit einem Stück Arbeit, bevor sie wechselten, 57 % dieser Arbeitsstücke wurden unterbrochen, und obwohl die meisten unterbrochenen Arbeiten noch am selben Tag wieder aufgenommen wurden, lagen meist mehr als zwei andere Tätigkeiten dazwischen.²

In einem späteren Experiment erledigten unterbrochene Menschen ihre Aufgaben sogar schneller, ohne Verlust an Qualität, zahlten dafür aber mit mehr Stress, Frust, Zeitdruck und Anstrengung.³ Eine Unterbrechung kostet also selten eine ordentliche, feste Zahl an Minuten. Sie kostet Zersplitterung und Belastung, und in einem schweren Projekt ist es die Belastung, die die Qualität bricht. Wie du Konzentration unter einer Deadline schützt, beschreibe ich in Time to Market und der kritische Pfad.

Die Rechnung spricht immer dann für eine Person, wenn die Kosten der Abstimmung größer sind als der Nutzen paralleler Arbeit. Bei eng verzahnter Arbeit, bei der jedes Teil von jedem anderen abhängt, ist das oft der Fall.

Erfahrung ist Mustererkennung

Erfahrung ist nicht nur eine Zahl im Lebenslauf. Sie ist Mustererkennung.

Die Forschung zur Expertise sagt dasselbe. William Chase und Herbert Simon zeigten Schachmeistern für ein paar Sekunden Stellungen aus echten Partien und ließen sie das Brett nachbauen. Die Meister erinnerten sich an weit mehr als schwächere Spieler, aber der Vorsprung verschwand weitgehend, wenn die Figuren zufällig aufgestellt waren. Was die Meister hatten, war kein besseres Gedächtnis. Es war ein großer Vorrat vertrauter Muster, mit dem sie eine Stellung als wenige sinnvolle Blöcke sahen statt als viele einzelne Figuren.⁴

Wenn ich mir ein neues Problem ansehe, denke ich nicht von den ersten Prinzipien aus. Ich gleiche es mit Tausenden ähnlicher Probleme ab, die ich schon gesehen habe. Dieses Datenbankschema sieht aus wie das, das 2019 bei einem eCommerce Unternehmen Performanceprobleme verursacht hat. Dieses API Design fühlt sich an wie das, das 2021 bei einem Fintech Startup zerbrach, als das Team Webhooks ergänzen wollte. Diese Caching Strategie ist identisch mit der, die 2017 bei einem Marktplatz Daten beschädigt hat.

Ich muss nicht jedes mögliche Versagen durchdenken, weil ich viele davon schon erlebt habe. Die Fehlschläge sind nicht hypothetisch. Sie sind Erinnerungen. Ich sehe den Fehler, bevor er existiert, weil ich genau diesen Fehler schon behoben habe, oder einen, der ihm so ähnlich war, dass die Form unverkennbar ist.

Das meinen Leute, wenn sie sagen, erfahrene Entwickler seien schneller. Nicht, dass sie schneller tippen. Sondern dass sie einen Großteil des Ausprobierens überspringen. Sie wissen schon, welche Ansätze meistens scheitern, also beginnen sie mit einem, der meistens funktioniert.

Rechenbeispiel: zwei Entwickler und ein Problem mit dem Bestand

Ein Münchner Laden für Fahrradteile, kettenblatt.example, verkauft immer wieder Artikel, die nicht mehr auf Lager sind. Beide Entwickler, die er fragt, bekommen dasselbe Briefing.

Der erste, noch neu im eCommerce, probiert nacheinander drei Lösungen: einen nächtlichen Abgleich des Bestands (verkauft tagsüber trotzdem zu viel), eine Prüfung des Bestands beim Ansehen des Warenkorbs (verkauft trotzdem zu viel, wenn zwei Leute gleichzeitig bezahlen) und schließlich eine Sperre in der Datenbank beim Anlegen der Bestellung. Jeder Versuch dauert etwa drei Tage, die Lösung kommt also nach neun.

Der zweite erkennt das Muster schon im Briefing, zwei Kunden kaufen im selben Moment den letzten Artikel, und reserviert den Bestand direkt in derselben Datenbanktransaktion wie die Bestellung. Ein Versuch, drei Tage.

Gleiche Intelligenz, gleiche Werkzeuge. Der Unterschied sind sechs Tage Ausprobieren, die der zweite Entwickler schon vor Jahren hinter sich gebracht hat.

15 Schritte vorausdenken ist Narbengewebe

Es gibt eine Fähigkeit, die über Jahre des Systembaus wächst: die Folgen im Kopf durchzuspielen, bevor sie eintreten.

Du lernst, Fragen zu stellen, die dir am Anfang einer Laufbahn nicht einfallen. Wenn die Daten so strukturiert sind, was passiert, wenn ein neuer Typ dazukommt? Wenn dieser Dienst hinter jenem Cache sitzt, was passiert, wenn der Cache kalt ist? Wenn Nutzer das tun können, was passiert, wenn jemand es 10.000 Mal hintereinander tut? Wenn diese Änderung live geht, was passiert mit den Anfragen, die gerade unterwegs sind?

Diese Fragen sind keine Klugheit. Sie sind Narbengewebe. Jede steht für einen Vorfall im Betrieb oder eine Nacht beim Debuggen, die jemand hätte vermeiden können. Nach genug Narben kommen die Fragen von selbst.

Deshalb bauen erfahrene Entwickler Dinge oft gleich beim ersten Mal richtig. Nicht, weil sie klüger sind. Weil sie misstrauischer sind, und die Wirklichkeit hat dieses Misstrauen geeicht.

Rechenbeispiel: der kalte Cache bei einem Teeladen in Dresden

Ein Dresdner Teeladen, loschwitztee.example, bedient in Spitzenzeiten 2.000 Anfragen pro Minute auf Produktseiten. Ein Cache beantwortet 95 % davon, die Datenbank sieht also $2.000 \times 0{,}05 = 100$ Abfragen pro Minute. Die Datenbank schafft bequem 300.

Jetzt stell die Frage: Was passiert, wenn der Cache kalt ist, etwa direkt nachdem ein Deployment ihn geleert hat? Jede Anfrage geht an die Datenbank: 2.000 pro Minute, also $2.000 / 300 \approx 6{,}7$ mal so viel, wie sie verkraftet. Der Shop fällt genau in dem Moment aus, in dem das Deployment ihn verbessern sollte.

Die Lösung ist nicht schwer: den Cache vorwärmen, bevor der Verkehr umgeschaltet wird, oder nur eine Anfrage jede zwischengespeicherte Seite neu bauen lassen, während die anderen warten. Schwer ist, die Frage vor dem Ausfall zu stellen, nicht danach.

Die Anforderung verstehen, bevor gebaut wird

Hier zeigt der Ansatz mit einer Person seine eigentliche Stärke.

Teams fangen oft an zu bauen, bevor sie ganz verstanden haben, was sie bauen. Es gibt Druck, Fortschritt zu zeigen, und die Illusion, dass Code tippen Fortschritt ist. Also wird die Arbeit auf Grundlage eines unvollständigen Verständnisses aufgeteilt, und das Team merkt bei der Integration, dass die Teile gegen verschiedene Annahmen entworfen wurden.

Ich fange nicht an zu bauen, bevor ich das Problem vollständig verstanden habe. Und ich meine vollständig. Nicht nur den Idealweg, nicht nur die Spezifikation der Funktion. Den ganzen Zusammenhang.

Was sind die rechtlichen Anforderungen? Im deutschen eCommerce kann das den Datenschutz nach der DSGVO bedeuten,⁵ den Sicherheitsstandard der Kartenbranche, PCI DSS, für alles, was Zahlungen berührt,⁶ die Regeln für Fernabsatzverträge ab § 312c BGB⁷ und die Anforderungen an Barrierefreiheit aus dem Barrierefreiheitsstärkungsgesetz (BFSG), das ausdrücklich auch für Dienstleistungen im elektronischen Geschäftsverkehr gilt.⁸ Was sind die echten Anforderungen an die Performance, nicht die ehrgeizigen aus dem Briefing, sondern die, die sich aus dem Verkehr und dem Budget fürs Hosting ergeben? Muss das System in 12 Monaten die zehnfache Last tragen, und wenn ja, welcher Teil bricht zuerst? Welche anderen Systeme berührt es, und welche Verträge gibt es mit ihnen, geschrieben oder ungeschrieben?

Das kostet Zeit. In einem Team kann es aussehen, als käme ich langsam in die Gänge. Aber die Fragen beseitigen Nacharbeit, bevor sie entsteht, und wenn ich baue, baue ich schnell, weil ich keine Anforderungen beim Programmieren entdecke und nicht auf das Teil eines anderen warte, um zu sehen, ob meins passt.

Rechenbeispiel: das Geschenkabo in Leipzig

Ein Leipziger Anbieter für Abokisten, kistenpost.example, will Geschenkabos. Ein Team aus drei teilt die Arbeit am ersten Tag auf: eine baut den Checkout, einer den Kundenbereich, eine die Mails.

Bei der Integration in Woche drei stellen sie fest, dass der Checkout annahm, Käufer und Empfänger seien dieselbe Person, während die Mails annahmen, dass sie es nicht sind. Das zu entwirren kostet jede und jeden vier Tage: $3 \times 4 = 12$ Personentage Nacharbeit.

Eine Person, die zuerst zwei Tage mit Fragen verbringt, hätte am ersten Morgen gefragt: "Wer bekommt die Kiste, und wer bekommt die Rechnung?" Zwei Tage Fragen gegen 12 Tage Nacharbeit, das ist der Tausch, um den es in diesem ganzen Abschnitt geht.

Die Projekte, bei denen ein Experte gewinnt

Nicht jedes Projekt passt zu einer Person. Große Neubauten mit viel unabhängiger, paralleler Arbeit passen zu einem Team, ebenso laufende Wartung, die sich über viele unzusammenhängende Themen verteilt. Aber manche Arten von Arbeit laufen mit einem erfahrenen Entwickler oft besser.

Notfallreparaturen im Betrieb

Die Seite ist down. Der Umsatz rinnt davon. Alle sind in Panik.

Das ist nicht der Moment für einen Krisenraum mit 15 Leuten, von denen die Hälfte das System nicht gut genug kennt, um etwas beizutragen. Es ist der Moment für eine Person, die weiß, wo die Leichen im Keller liegen, und die das Problem findet und behebt.

Eine Menge macht Lärm. Leute schlagen Ursachen vor, die sie nicht geprüft haben, mehrere Engineers jagen derselben Idee nach, jemand ändert etwas, um eine Theorie zu testen, und sagt es niemandem. Eine eng verbundene Gruppe unter Druck kann außerdem in das rutschen, was Irving Janis Gruppendenken nannte: Der Drang zur Einigkeit überlagert den nüchternen Blick auf die Alternativen, und der Raum einigt sich auf die lauteste Erklärung statt auf die richtige.⁹

Ich habe Probleme im Betrieb von Systemen behoben, die ich vor Jahren gebaut habe, Systemen, die Dutzende Entwickler seit meinem Weggang verändert haben, weil die Kernarchitektur noch vertraut ist und mein mentales Modell ungefähr noch passt. Ich kann eine Anfrage vom Load Balancer bis zur Datenbank schneller verfolgen, als sich ein Team einigen kann, wo es anfängt zu suchen.

Ein Beispiel: Ein Hamburger Shop, kerzenkai.example, fällt am Black Friday um 20 Uhr aus. Zwölf Leute kommen in den Call, nach der Formel also $C(12) = \frac{12 \times 11}{2} = 66$ mögliche Gespräche darüber, was falsch sein könnte. Ein Engineer und eine Person aus dem Geschäft sind $C(2) = 1$.

Komplexe Migrationen

Von einem System auf ein anderes wechseln, während das alte noch läuft, mit Daten, die nicht verloren gehen dürfen, und Kunden, die keinen Ausfall sehen dürfen.

Du musst zwei vollständige Systeme gleichzeitig im Kopf halten, dazu die Zuordnung zwischen ihnen und die Reihenfolge der Schritte, die von einem zum anderen führt, ohne etwas fallen zu lassen. Das auf ein Team aufzuteilen heißt, das mentale Modell aufzuteilen, und im mentalen Modell steckt der Wert.

Ich habe Zahlungssysteme für Händler migriert, die Millionen von Transaktionen verarbeiten, und keine einzige Transaktion durfte verloren gehen oder doppelt auftauchen. Ich habe Kundendatenbanken mit Jahren an Kaufhistorie migriert, bei denen jeder Datensatz vor der Umstellung stimmen musste. Ich habe Loginsysteme migriert, und das heißt Passwörter migrieren, und das heißt Hashing Verfahren, Übergangsstrategien und das Ungültigmachen von Sessions verstehen. Diese Migrationen haben funktioniert, weil eine Person alle Teile verstanden hat. Ein Team hätte Wochen an Dokumentation und Abstimmung gebraucht. Ich brauchte Tage tiefer Konzentration.

Arbeit an der Compliance

Compliance ist keine Funktion, die sich isoliert bauen lässt. Personenbezogene Daten fließen durch jedes System, für Kartendaten gelten auf jeder Ebene Regeln, Audit Logs und Zugriffsrechte müssen überall gleich funktionieren. Ein Team braucht Wochen, um das einheitlich zu machen, weil jeder Entwickler die Regeln ein wenig anders liest. Ich lese die Vorschriften, arbeite heraus, was sie wirklich verlangen, und setze einen Ansatz über die ganze Codebasis um. Wenn die Prüfer kommen, passt alles zusammen.

Arbeit an der Performance

Das System ist langsam, und die Kundschaft beschwert sich. Eine langsame Seite ist ein Symptom. Die Ursache kann eine Datenbankabfrage sein, ein fehlender Index, ein N+1 Problem (eine Abfrage für eine Liste, dann eine weitere für jeden Eintrag darin), ein falsch dimensionierter Cache oder mehrere davon, die unter Last zusammenwirken.

Ein Team optimiert gern jeweils seine eigene Schicht, und die Seite wird womöglich gar nicht schneller, weil der Engpass dort lag, wo keiner hingeschaut hat. Ich profiliere das System von vorn bis hinten, mit Flame Graphs (Diagrammen, die zeigen, wo der Prozessor seine Zeit verbringt) und Abfrageplänen der Datenbank, behebe den tatsächlichen Engpass, messe erneut und wiederhole das, bis das Ziel erreicht ist.

Technische Schulden aufräumen

Jahre an Abkürzungen, totem Code und veralteten Abhängigkeiten, und jede Änderung heißt jetzt, um den Schutt herumzunavigieren.

Technische Schulden aufzuräumen ist Chirurgie. Du musst wissen, was jedes Teil tut, welche Teile tatsächlich genutzt werden, welche von welchen abhängen und in welcher Reihenfolge du entfernen oder umbauen kannst, ohne etwas kaputt zu machen. Ein Team hat Lücken im gemeinsamen Verständnis: Eine Entwicklerin entfernt eine Klasse, die sie für ungenutzt hält, ohne zu wissen, dass ein anderes Modul auf ihre Nebenwirkungen angewiesen ist. Ich lese die gesamte Codebasis und verfolge jede Abhängigkeit, bevor ich irgendetwas anfasse, damit der Umbau in einer Reihenfolge passiert, die nichts kaputt macht.

Wann ein Team die richtige Antwort ist

Ich sage nicht, dass Teams schlecht sind oder Zusammenarbeit Verschwendung ist.

Teams sind ein Werkzeug, und wie jedes Werkzeug haben sie richtige und falsche Einsätze. Eine Schraube schlägst du nicht mit dem Hammer ein.

Manche Probleme lassen sich sauber teilen. Zehn unabhängige Funktionen bauen zehn Entwickler viel schneller, abzüglich des Abstimmungsaufwands, und dieser Aufwand lohnt sich, weil der Gewinn durch Parallelität groß ist. Andere Probleme lassen sich nicht teilen. Eine tief verzahnte Funktion, bei der jedes Teil von jedem anderen abhängt, wird mit zehn Entwicklern nicht zehnmal schneller. Die Kosten der Abstimmung wachsen schneller als der Gewinn durch Parallelität, und ab einem gewissen Punkt macht jede weitere Person das Projekt länger, und das ist wieder Brooks' Gesetz.¹

Das Diagramm liest sich von oben. Die erste Frage ist, ob sich die Arbeit in unabhängige Teile zerlegen lässt: Wenn ja, gewinnt ein Team. Wenn nicht, ist die zweite Frage, ob eine Person das Ganze realistisch innerhalb der Deadline im Kopf halten kann. Wenn ja, ist das der Fall für einen Experten. Wenn nein, lautet die Antwort trotzdem nicht Menge, sondern ein kleines Team mit einer einzigen Person, der das Design gehört, damit das mentale Modell in einem Kopf bleibt.

Rechenbeispiel: zehn Funktionen oder eine

Ein Dresdner SaaS Unternehmen, elbtermin.example, hat zwei Aufgaben. Die erste sind 10 unabhängige Berichtsseiten, jede etwa fünf Tage Arbeit für einen Entwickler. Die zweite ist eine neue Preislogik, die Abrechnung, Rechnungsstellung, das Kundenportal und die Steuerlogik berührt, etwa 50 Tage Arbeit für eine Person, die alles davon versteht.

Die Berichte: Ein Entwickler braucht $10 \times 5 = 50$ Tage. Fünf Entwickler brauchen etwa $50 / 5 = 10$ Tage, plus etwas Abstimmung. Ein klarer Sieg für das Team.

Die Preislogik: Auf fünf Entwickler verteilt, hängt jedes Teil von den anderen ab. Fünf Leute haben $C(5) = 10$ Wege, und jede Designentscheidung muss über sie laufen. Nimm für das Beispiel an, dass Abstimmung und Nacharbeit die Hälfte der Zeit jedes Entwicklers fressen. Dann liefern die fünf $5 \times 0{,}5 = 2{,}5$ Entwicklertage echten Fortschritt pro Tag, die 50 Tage Arbeit dauern also $50 / 2{,}5 = 20$ Kalendertage, und das, bevor irgendwer die Teile verstanden hat, die er nicht selbst geschrieben hat. Eine Person, die das Ganze schon versteht, braucht 50 Tage konzentrierter Arbeit, aber ohne Nahtstellen bei der Integration.

Bei der Preislogik ist das Team im Kalender also womöglich trotzdem schneller, aber es kostet $5 \times 20 = 100$ Personentage gegen 50. Ob sich das lohnt, hängt von der Deadline ab, und genau dieses Urteil verlangt das Diagramm.

Die Kunst ist, zu erkennen, welche Art Problem du hast. Die meisten Organisationen greifen bei allem zum Team, weil Teams leicht zu sehen, zu führen und in Tabellen einzutragen sind. Einen Entwickler, der eine Woche verschwindet und mit funktionierender Software zurückkommt, kannst du in Jira nicht verfolgen. Aber es funktioniert.

Arbeiten ohne Netz

Der Zustand, den diese Art Arbeit verlangt, ist kein bequemer. Du trägst das ganze Problem selbst. Niemand teilt die Last, niemand fängt deine Fehler ab, niemand sonst ist schuld, wenn es schiefgeht.

Das ist auf eine Art belastend, wie Teamarbeit es nicht ist. In einem Team gehört das Scheitern allen und damit niemandem im Besonderen. Die Sozialpsychologie hat einen Namen für einen nahen Verwandten davon: Bibb Latané und Kollegen fanden, dass Menschen, die in Gruppen klatschten und riefen, deutlich weniger eigene Anstrengung aufbrachten als allein, ein Rückgang, den sie soziales Faulenzen nannten, zusätzlich zu den Verlusten durch schlechte Koordination.¹⁰

Wenn du allein arbeitest, ist jede Entscheidung deine, jeder Fehler deiner, und dein Name steht am Commit.

Stress entsteht aus Anforderungen ohne Kontrolle

Manche Menschen halten dieses Gewicht nicht aus und brauchen die geteilte Verantwortung eines Teams. Das ist keine Schwäche, es ist eine Vorliebe. Einige der besten Entwickler, die ich kenne, arbeiten lieber im Team, gerade weil die Zusammenarbeit ihnen Energie gibt und die geteilte Verantwortung ihre Anspannung senkt.

Aber manche von uns sind andersherum verdrahtet. Für uns ist der Stress der Abstimmung schlimmer als der Stress der Verantwortung. Von anderen abhängen, durch die Verspätung eines anderen blockiert werden, Entscheidungen Leuten erklären, denen der Zusammenhang fehlt: Das tut mehr weh, als alles allein zu tragen.

Die Forschung gibt dem eine Form. Robert Karaseks Modell von Anforderung und Kontrolle besagt, dass psychische Belastung weniger aus hohen Anforderungen allein entsteht als aus hohen Anforderungen, verbunden mit wenig Kontrolle darüber, wie man sie erfüllt.¹¹ Ein Experte allein vor einer harten Deadline hat hohe Anforderungen und hohe Kontrolle. Ein Entwickler in einem großen Team mit derselben Deadline, der auf drei Freigaben wartet, hat dieselben Anforderungen und viel weniger Kontrolle.

Ein Beispiel: Zwei Entwicklerinnen in München haben dieselbe Deadline am Freitag. Die eine verantwortet das Design und kann jede Entscheidung selbst treffen. Die andere braucht vor jeder Änderung eine Freigabe von einem Architekten, einer Product Ownerin und einem Prüfer für Sicherheit. Gleiche Arbeitslast, gleiche Deadline. Nach Karaseks Modell ist die zweite Stelle die belastendere.

Druck hilft, bis zu einem Punkt

Es gibt die verbreitete Vorstellung, dass ein wenig Druck die Leistung schärft und zu viel sie ruiniert, meist Robert Yerkes und John Dodson zugeschrieben. Ihre Studie von 1908 handelte allerdings von Mäusen, die lernten, eine helle von einer dunklen Box zu unterscheiden, unter leichten Stromschlägen verschiedener Stärke. Sie folgerten, dass sich eine leichte Gewohnheit am besten unter starker Reizung bildet, eine schwierige dagegen am besten unter relativ schwacher.¹² Die weitere Behauptung über Stress und menschliche Arbeit kam später, aber der ursprüngliche Befund ist hier der nützliche Teil: Je schwieriger die Aufgabe, desto niedriger der Druck, bei dem Menschen ihre beste Arbeit leisten.

Deshalb schütze ich die Bedingungen rund um ein stressiges Projekt so sorgfältig. Das Problem selbst liefert genug Druck. Lärm, Meetings und das Warten auf andere legen nur noch etwas drauf.

Wann du eine Person statt eines Teams holen solltest

Ich will offen über die geschäftliche Seite von alldem reden.

Wenn du ein Projekt hast, das ins Profil passt, eng verzahnt, unter Zeitdruck, mit tiefem Verständnis über mehrere Bereiche hinweg und der Notwendigkeit, beim ersten Mal zu funktionieren, hast du eine Wahl.

Du kannst ein Team holen, mit Projektmanager, Zeit für alle, das bestehende System kennenzulernen, Designsitzungen und Integrationstests. Es wird produktiv werden, aber das Hochfahren braucht Zeit, und der Abstimmungsaufwand verschwindet nie.

Oder du holst mich.

Die ersten Tage verbringe ich damit, das Problem vollständig zu verstehen: die rechtlichen Grenzen, die Anforderungen an die Performance, die Schnittstellen, die Politik und die Dinge, die nur im Kopf von irgendjemandem leben. Dann baue ich es und übergebe Umsetzung, Dokumentation, Tests und den Plan fürs Deployment zusammen.

Rechenbeispiel: der Tagessatz, ab dem es sich ausgleicht

Ein Kölner Händler, viertelwohnen.example, wägt eine Migration ab. Die Zahlen sind Annahmen des Beispiels, keine Angebote.

Option eins: ein Team aus vier Entwicklern für 12 Wochen (60 Arbeitstage), dazu ein Projektmanager zur Hälfte seiner Zeit. Das sind $4 \times 60 + 0{,}5 \times 60 = 240 + 30 = 270$ Personentage.

Option zwei: ein erfahrener Entwickler für vier Wochen konzentrierte Arbeit, 20 Arbeitstage.

Die Frage ist nicht, welcher Tagessatz niedriger ist. Sondern wie hoch der Tagessatz der einen Person sein dürfte, bevor Option zwei mehr kostet. Der Ausgleich liegt bei $270 / 20 = 13{,}5$. Unter diesen Annahmen könnte der einzelne Entwickler also bis zum 13,5 fachen des durchschnittlichen Tagessatzes im Team verlangen und würde gleich viel kosten. Selbst wenn sich die Schätzung für die eine Person auf 40 Tage verdoppelt, läge der Ausgleich beim $270 / 40 \approx 6{,}8$ fachen.

Die Annahmen entscheiden. Sind es wirklich zehn unabhängige Funktionen, gewinnt Option eins. Ist es eine eng verzahnte Migration, die eine Person im Kopf halten kann, gewinnt meistens Option zwei.

Das passt nicht für jedes Projekt. Dauerhafte Entwicklung über Jahre oder eine breite Fläche an Funktionen, die parallel gebaut werden, braucht ein Team. Aber wenn du etwas Komplexes schnell gebaut brauchst und es funktionieren muss, lautet die Antwort vielleicht nicht mehr Leute. Sondern die richtige Person.

Kleiner, nicht klüger

Die Vorstellung, dass zusätzliche Leute ein Projekt bremsen, fühlt sich falsch an, weil die meisten von uns Ressourcen als addierbar behandeln.

Aber Software ist kein Graben, den man aushebt. Du kannst nicht einfach mehr Schaufeln dazugeben. Die Arbeit findet im Kopf statt, und die Grenze ist nicht Anstrengung, sondern Verständnis. Ein Problem, das ein zusammenhängendes Verständnis braucht, wird nicht leichter, wenn dieses Verständnis auf viele Köpfe verteilt wird. Es wird schwerer.

Brooks hat das 1975 vertreten, und ein halbes Jahrhundert später gilt es immer noch.¹

Die Antwort ist nicht, schwere Probleme mit mehr Leuten zu bewerfen. Sondern die richtigen Leute zu finden und ihnen Raum zum Arbeiten zu geben.

Für die richtige Art Problem bin ich mehr wert als ein Team. Nicht, weil ich klüger bin als ein Team, sondern weil ich kleiner bin. In einem Team aus einer Person gibt es keine Wege. Meine 20 Jahre Erfahrung bedeuten, dass ich einen Großteil des Ausprobierens überspringe und direkt zur Lösung gehe, weil ich genug Fehlschläge gesehen habe, um sie nicht auf die harte Tour entdecken zu müssen.

Das ist es, was ich anbiete. Keine Stunden, keine Ressourcen, keinen Körper auf einem Stuhl. Ergebnisse, früher als erwartet, und beim ersten Mal richtig.

Wenn du ein Projekt hast, das in der Abstimmung festhängt, ein komplexes Problem, an dem sich ein Team die Zähne ausgebissen hat, oder eine Deadline, die das übliche Hochfahren unmöglich macht, sprich mit mir. Expertise aus einer Hand ist nicht die Antwort auf alles. Aber für bestimmte Probleme ist sie genau die Antwort, und wenn deins eins davon ist, kann ich helfen.

Footnotes

1. Frederick P. Brooks Jr, The Mythical Man Month: Essays on Software Engineering, zuerst erschienen 1975, Jubiläumsausgabe, Addison Wesley Professional, 1995, Kapitel 2, Verlagsseite bei InformIT, https://www.informit.com/store/mythical-man-month-essays-on-software-engineering-anniversary-9780201835953

2. Gloria Mark, Victor M. Gonzalez und Justin Harris, No task left behind? Examining the nature of fragmented work, Proceedings of CHI 2005, ACM, 2005, https://ics.uci.edu/~gmark/CHI2005.pdf

3. Gloria Mark, Daniela Gudith und Ulrich Klocke, The cost of interrupted work: more speed and stress, Proceedings of CHI 2008, ACM, 2008, https://ics.uci.edu/~gmark/chi08-mark.pdf

4. William G. Chase und Herbert A. Simon, Perception in chess, Cognitive Psychology 4(1), 55 bis 81, 1973, doi 10.1016/0010-0285(73)90004-2, Eintrag bei Crossref, https://api.crossref.org/works/10.1016/0010-0285%2873%2990004-2

5. Europäische Union, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung, DSGVO), EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679

6. PCI Security Standards Council, PCI Data Security Standard (PCI DSS), pcisecuritystandards.org, https://www.pcisecuritystandards.org/standards/pci-dss/

7. Bundesministerium der Justiz, Bürgerliches Gesetzbuch (BGB), § 312c Fernabsatzverträge, gesetze im internet, https://www.gesetze-im-internet.de/bgb/__312c.html

8. Bundesministerium der Justiz, Barrierefreiheitsstärkungsgesetz (BFSG), § 1 Zweck und Anwendungsbereich, gesetze im internet, https://www.gesetze-im-internet.de/bfsg/__1.html

9. Irving L. Janis, Groupthink and group dynamics: a social psychological analysis of defective policy decisions, Policy Studies Journal 2(1), 19 bis 25, 1973, doi 10.1111/j.1541-0072.1973.tb00117.x, Eintrag bei Crossref, https://api.crossref.org/works/10.1111/j.1541-0072.1973.tb00117.x

10. Bibb Latané, Kipling Williams und Stephen Harkins, Many hands make light the work: the causes and consequences of social loafing, Journal of Personality and Social Psychology 37(6), 822 bis 832, 1979, doi 10.1037/0022-3514.37.6.822, Eintrag bei Crossref, https://api.crossref.org/works/10.1037/0022-3514.37.6.822

11. Robert A. Karasek Jr, Job demands, job decision latitude, and mental strain: implications for job redesign, Administrative Science Quarterly 24(2), 285 bis 308, 1979, doi 10.2307/2392498, Eintrag bei Crossref, https://api.crossref.org/works/10.2307/2392498

12. Robert M. Yerkes und John D. Dodson, The relation of strength of stimulus to rapidity of habit formation, Journal of Comparative Neurology and Psychology 18(5), 459 bis 482, 1908, Volltext bei Classics in the History of Psychology, York University, https://psychclassics.yorku.ca/Yerkes/Law/