Der mythische mythische Mann-Monat

Als Produktleiter in einem Technologieunternehmen bin ich ein Fass ohne Boden. Meine Aufgabe als Chief Product Officer bei Mailchimp ist es, das Produkt auf den Markt zu bringen, das sich in einem sehr wettbewerbsintensiven Umfeld durchsetzen wird. Die Ambitionen von Mailchimp sind hoch, und um sie zu verwirklichen, müssen wir eine beträchtliche Menge an Produkten auf den Markt bringen. Oft haben viele im Unternehmen das Gefühl, dass wir zu viel tun. Wir sind immer am Rande der sich lösenden Räder.

Und wenn Sie zu viel tun und sich entscheiden, mehr als das zu tun, werden Sie unweigerlich anfangen, auf The Mythical Man-Month Bezug zu nehmen. Es ist wie einer dieser Bälle zum Stressabbau, bei denen, wenn Sie ein Ende zusammendrücken, am anderen Ende der mythische Mann-Monat herausspringt.

Dieses Buch wurde 1975 von Frederick Brooks veröffentlicht (Sie erinnern sich an 1975, oder? Als die Softwareentwicklung 2020 zu 100 % der Softwareentwicklung ähnelte?), ist dieses Buch unter Softwareentwicklern ziemlich berühmt. Insbesondere gibt es einen Punkt im gesamten Buch, der berühmt ist (ich bin nicht überzeugt, dass die Leute etwas anderes als diesen Punkt lesen, wenn sie das Buch überhaupt gelesen haben):

„...das Hinzufügen von mehr Männern verlängert den Zeitplan, nicht er verkürzt ihn.“

Einfache Lösung. Ich werde von nun an nur noch Frauen für Projekte einsetzen (siehe Die Rückkehr des Königs und der Kampf gegen den Hexenkönig von Angmar).

Aber nehmen wir an, dass Brooks' Argument unabhängig von der Geschlechtsidentifikation der betreffenden Softwareentwickler gilt. Hier ist der Punkt: Software mit vielen komplexen Abhängigkeiten ist schwierig zu erstellen. Und alle müssen zusammenarbeiten, um dies zu erreichen.

Wenn ich Leute zu einem Team hinzufüge, müssen sie an Bord genommen und in das Projekt eingepfropft werden. Jemand muss ihnen die richtige Arbeit abhauen. Das Team muss kommunizieren, um sicherzustellen, dass alles zusammenarbeitet, und jede weitere Person erhöht diese Kommunikationskomplexität geometrisch. Und irgendwann wird das Hinzufügen von Personen zu einer Belastung für das Projekt – kein Vorteil.

Hier ist die Grafik aus dem Buch, die diesen Punkt veranschaulicht:

Das ist absolut ein fairer Punkt. Deshalb höre ich es so oft bei der Arbeit. Erschöpfte einzelne Mitwirkende und erschöpfte Führungskräfte werden es gleich wegwerfen – wir können nicht schneller werden, wir können nicht mehr tun, stoppen Sie die Einstellung, lesen Sie The Mythical Man-Month und verzweifeln Sie! Die einzige Lösung besteht anscheinend darin, das Wachstum einzustellen und einige Projekte zu töten.

Wenn ich als CPO sage: „Wir machen das Ding!“ Die Antwort lautet dann oft: „Okay, was werden wir dann töten?“ Der Mythical Man-Month macht die Produktentwicklung zum Nullsummenspiel. Wenn wir das eine wollen, müssen wir das andere stoppen. Nun, das ist ein echter Mythos, und ich nenne es Quatsch.

Und zu seiner pathologisch falsch interpretierten Schlussfolgerung (dazu kommen wir noch) sagt das Buch offenbar, dass das schnellste Technologieunternehmen eines ist, das alle vier Mitarbeiter beschäftigt – anscheinend vier Männer . Alles andere verlangsamt es nur. Jemand sollte Kopien des Buches an Amazon, Apple und Google senden, damit sie ihre offensichtlich aufgeblähten Organisationen reparieren können.

Das einzige Problem bei diesem Ansatz ist, dass in einem Bereich, in dem die Konkurrenz wächst und iteriert und ausgeführt wird – lediglich das Unternehmenswachstum gebremst wird – die Bearbeitung und Fokussierung der entsprechenden Arbeitslast ein Rezept für das Aussterben sein kann. Sie werden bei Verstand und weniger gestresst sein – bis Sie arbeitslos sind.

Und als Inhaber des Produktmanagements meines Unternehmens bin ich nicht unsympathisch gegenüber dieser Notwendigkeit, langsamer zu werden und mich zu konzentrieren. Wir müssen rücksichtslos Prioritäten setzen! Kein Zweifel. Aber ein Produkt zu betreiben ist eine Übung im Widerspruch. Ich muss priorisieren, was ich habe, und gleichzeitig planen, mehr zu erledigen. Aber was soll ich angesichts des mythischen Mannesmonats tun?

Überraschenderweise kommt die Antwort auf diese Frage aus demselben Buch von Brooks. Hier ist eine weitere Grafik im selben Kapitel:

Es gibt einen Kampf um die Skalierung der Produktentwicklung. Wenn die Arbeit, die Sie zu erledigen versuchen, rein partitionierbar ist, dann fahren Sie fort und fügen Sie Personen hinzu! Wenn Ihre Arbeit alle miteinander verbunden ist, dann ist das Hinzufügen von Personen irgendwann einfach falsch.

Wenn jemand sagt, dass ich unbedingt ein Projekt beenden muss, um ein neues zu starten, ist das einfach nicht der Fall. Wenn die beiden Projekte nur sehr wenig Kommunikation und Koordination erfordern, können wir skalieren.

Aus diesem Grund kann das Hinzufügen von Kernen zu einer CPU die erlebte Geschwindigkeit Ihres Computers oder Telefons bis zu einem gewissen Punkt erhöhen – etwas, worüber Ingenieure alles wissen sollten. Sicher, das Hinzufügen von Kernen hilft mir nicht, eine komplexe Single-Thread-Berechnung abzuschließen. Aber es kann mir helfen, eine Reihe unabhängiger Aufgaben zu erledigen.

Der Konflikt zwischen Skalierung und rücksichtsloser Priorisierung kann dann für einen Produktmanager bewältigt werden.

1. Sie priorisieren rücksichtslos Stellen, die Single-Threaded sind (sagen wir, der Rückstand für ein Produktteam).
2. Sie skalieren, indem Sie weitere Kerne hinzufügen, um unabhängige Aufgaben zu bewältigen.

Sehr selten ist jedoch etwas völlig unabhängig von allem anderen in einem Unternehmen. Als absolutes Minimum wird Ihr Unternehmen unterstützende Funktionen (globale IT, Recht, Personal usw.) zentralisieren, was zu Engpässen führt.

Es dreht sich alles um das Abhängigkeitsmanagement

Die Aufgabe eines Produktmanagers besteht dann darin, nicht nur eine Strategie zu entwickeln, sondern sie so auszuführen, dass der Wert für den Kunden und das Unternehmen maximiert wird, indem der Durchsatz sichergestellt und das Risiko gegenseitiger Abhängigkeiten so weit wie möglich reduziert wird. „So viel wie möglich“ ist hier der Schlüssel. Auf diese Weise können Sie das Unternehmen genauso wie das letztere Diagramm aussehen lassen und nicht wie das erstere. Interdependenz ist eine Krankheit, für die es keine Heilung gibt, aber ihre Symptome können mit vielen Behandlungen behandelt werden.

Eine Lösung besteht darin, eine strategische Ausrichtung für das Unternehmen zusammenzustellen, die die Abhängigkeit durch ein sorgfältig ausgewähltes Portfolio von Initiativen minimiert oder begrenzt. Das Lustige hier ist, dass viele Leute darauf zurückdrängen werden. Nehmen wir an, ich habe zwei Optionen, eine, bei der ich die Projekte A, B und C ausführen kann, die sehr wenig Koordination haben (sagen wir, sie wirken sich auf verschiedene Produkte aus), und eine andere Option mit den Projekten D1, D2 und D3, die jede Menge Abhängigkeiten haben ( nehmen wir an, sie wirken sich alle auf dasselbe Produkt aus). Es ist oft der Fall, dass der Mythical Man-Month eher gegen den ersteren Plan als gegen den letzteren angerufen wird. Denn auf dem Papier sieht es nach mehr aus .

In der Tat ist es weniger „fokussiert“. Aber aus der Perspektive der Abhängigkeit ist es tatsächlich weniger schwierig und daher besser mit zusätzlichem Personal.

Denken Sie daran, ich sage nicht, dass Sie eine Menge Arbeit für das Unternehmen auswählen sollen, die nicht verwandt ist. Mailchimp wird in absehbarer Zeit keinen Mikrowellenherd bauen. Alle Arbeiten sollten langfristig in die gleiche Richtung gehen. Dieser Ansatz kann das Risiko des Kundenerlebnisses (auf das wir später noch eingehen werden) sowie die Belastung globaler Funktionen wie der Kundenforschung erhöhen. Achten Sie darauf.

Eine andere Vorgehensweise besteht darin, einen Produkt- und Programmmanagementprozess zu erstellen, der die Abhängigkeitskoordination und -kommunikation erleichtert, wo dies erforderlich ist, ohne die Teams mit Koordination zu überlasten, wenn dies nicht erforderlich ist . Wenn wir versuchen, die Koordination so zu steuern, dass wir mehr tun können , schaffen wir manchmal so belastende Prozesse, dass wir am Ende weniger tun. Es ist ein Gleichgewicht zwischen zu wenig Koordination, was dazu führt, dass die Teile nicht zusammenarbeiten, und zu viel Koordination, was dazu führt, dass die Teile nie gebaut werden, weil wir alle für die Ewigkeit in Stand-ups sind.

Die Behauptung im Mythical Man-Month ist, dass die Kommunikation geometrisch zunehmen muss, wenn Sie Leute zu einem Softwareprojekt hinzufügen. Wenn Sie beispielsweise 3 Personen an dem Projekt haben, sind das 3 Kommunikationswege. Aber wenn Sie 4 haben, sind das 6 Kommunikationslinien. Eine zusätzliche Person führt in diesem Fall zu einer doppelten Kommunikation! Spaß. (Dies ist natürlich eine zu starke Vereinfachung der Kommunikation bei Softwareentwicklungsprojekten.)

Unterschiedliche Personen haben unterschiedliche Rollen und erhalten daher unterschiedlich viel Autonomie. Vielleicht muss der Projektmanager mit allen im Team kommunizieren. Aber muss ein Ingenieur, der an der API arbeitet, mit dem Produktvermarkter kommunizieren? Oder kann der Vermarkter einfach den Produktmanager durchgehen? Ein guter Prozess- und Besprechungsrhythmus kann dann unnötige Kommunikation und Besprechungen eliminieren. Der Punkt ist, dass Brooks' Interkommunikationsformel eine Obergrenze für die Koordination ist, kein Todesurteil.

Verwenden Sie schließlich Tools, Prinzipien und Frameworks in Kombination mit unabhängiger Arbeit statt tatsächlicher Zusammenarbeit, um Interdependenzsymptome zu bekämpfen. Wenn ich zum Beispiel die Key Performance Indicators (KPIs, dh Erfolgsmessungen) zweier Teams koordinieren kann, um Anreize für Bewegungen in mehr oder weniger die gleiche Richtung zu schaffen, dann ist es wahrscheinlicher, dass ihre unabhängige Arbeit „enger zusammenkommt“, als wenn Ihre KPIs fördern die orthogonale Bewegung. Das wird nicht sicherstellen, dass die Dinge perfekt zusammenpassen, nur dass der Aufwand, den ich machen muss, damit sie in Zukunft zusammenpassen, geringer ist, als es sonst sein könnte. Andere Beispiele könnten die Verwendung von „Even-Over“-Anweisungen, Designsystemen und automatisierten Tests umfassen.

Es gibt also einen Anfang. Aber Abhängigkeiten nehmen viele Formen jenseits des Codes an. Lassen Sie mich ein Beispiel von Mailchimp geben.

Kundenerfahrungsrisiko: Die versteckten (aber akzeptablen?) Kosten der Firewall-Arbeit

Da der Kunde von Mailchimp oft ein Kleinunternehmer ist, der ein Marketing-Neuling ist (und es gibt weltweit Millionen von Kleinunternehmern, die zu Vermarktern geworden sind), müssen wir ein nahtloses und sofort verständliches End-to-End- Erlebnis bieten . Wir haben nicht den Luxus, ein Frankenstein-Wolkenmonster durch Akquisition zusammenzubauen, wie es Enterprise-Spieler können. Wir können schlecht integrierte Software nicht mit Beratern und Kundenbetreuern vertuschen.

Als Verbraucherprodukt (denken Sie an Instagram oder einen Nintendo Switch oder einen Roomba) müssen wir sofort einsatzbereit sein. Für eine All-in-One-Marketingplattform, die Ihr Unternehmen voranbringen soll, ist das schwierig! Und das bedeutet, dass alles, was Mailchimp erstellt, aus Sicht der Erfahrung nahtlos miteinander verbunden sein muss.

Aber die perfekte Partitionierung von Projekten führt dann zu Erfahrungsrisiken . Es ist nicht so, dass der Code nicht unabhängig geschrieben werden kann. Das kann erreicht werden, aber es besteht immer noch das Risiko, dass die Produkte so aussehen, als wären sie von verschiedenen Teams entwickelt worden, und diese Erfahrung kann für den Benutzer wirklich verdammt verwirrend sein. Wir stoßen auf Conways Gesetz – unsere Kunden können erkennen, wo die Arbeit des einen Teams endet und die des anderen Teams beginnt.

Sie versuchen also, die Arbeit aller miteinander zu verbinden – nicht nur am Back-End, sondern auch am Front-End. In der Ökosystem-Ära, die von CX-Exzellenz von Spielern wie Apple dominiert wird, ist dies im Verbraucherbereich fast zu einem Tisch geworden. Aber dies ist ein Mythical Man-Month- Albtraum, wenn auch diesmal nicht aus technischer Sicht. Es ist aus einer Service-Design-Perspektive. Wenn wir mehr Leute zu all dieser „End-to-End“-vernetzten Arbeit hinzufügen, verlangsamt sich alles zu einem kollaborativen Kriechen.

Abgesehen von der dritten Lösung, die ich oben erwähnt habe, bei der Tools und Frameworks anstelle von Overwatchern und Stage-Gates verwendet werden, gibt es ein weiteres Entlastungsventil: Machen Sie einige bewusste Kompromisse bei der Kundenerfahrung . Insbesondere, wo fühlen wir uns wohl dabei, eine Erfahrung zu veröffentlichen, die vom Rest getrennt ist (dh unterdurchschnittlich ist)? Risiken einzugehen und voranzukommen, ist die Aufgabe des Produktführers. Und so verwenden Sie einige Kriterien, um es zu sortieren (vielleicht halten neue, wenig frequentierte Bereiche der App nicht die gleichen Erfahrungsstandards wie Ihre „Cash Cows“) und treffen eine Entscheidung (z. B. Iteration und Lernen über Polieren auf benachbarten Innovationen). Dies geht natürlich über das Design hinaus.

Sie können das Gesetz von Brooks immer kurzschließen, indem Sie sich dafür entscheiden, Bemühungen mit einer Firewall zu versehen, einschließlich Bemühungen, die in einer perfekten Welt nicht durch eine Firewall geschützt werden sollten!

„

Ich möchte dies einschränken, indem ich sage, dass die Software, die ich baue, niemanden umbringt. Ich würde diesen Ansatz nicht befürworten, wenn ich ein medizinisches Gerät bauen würde. Aber bei einem Marketing-Softwareunternehmen kann ich Teams absichtlich isolieren, da ich weiß, dass ich die Wahrscheinlichkeit einer Inkompatibilität als Gegenleistung für die Aufstockung des Personals und die Beschleunigung erhöht habe.

Ich muss leider zugeben, dass der Mythical Man-Month in meinem Unternehmen Realität ist, und ich vermute, dass es auch in Ihrem Unternehmen so ist. Aber es ist überschaubar – das ist die Quintessenz. Parallelisierung und Abhängigkeitsminderung bieten uns einen Ausweg, der den fast mythischen Status des Mythical Man-Monats einschränkt. Wenn also in Ihrem Unternehmen das nächste Mal die starke Gegensätzlichkeit angesprochen wird (skalieren Sie, um langsamer zu werden oder Ihre Ambitionen aufzugeben), denken Sie daran, dass Sie immer noch groß werden können, wenn Sie die Arbeit klug aufstellen.

Vergessen Sie nicht die weichere Seite der Skalierung

Denken Sie daran, dass die Verwaltung des Mythical Man-Monats die Ingenieure nicht davon abhält, ihn wie dunkle Magie aufzurufen. Sie berufen sich nicht nur auf das Prinzip, weil etwas Wahres daran ist, sondern weil Skalierung aus emotionaler und kognitiver Sicht (immer) einfach scheiße ist. Wenn ich denke, dass ich dafür bezahlt werde, Code zu schreiben und Kundenprobleme zu lösen, dann ist das Letzte, was ich tun möchte, meine Routine zu ändern und herauszufinden, wie ich mit neuen Leuten und einem größeren Team arbeiten kann.

Wenn Sie Ihr Unternehmen skalieren, denken Sie daran, sich in den Schmerz der Skalierung und des Wandels hineinzuversetzen. Ein Team, das nur ein einziges Mitglied hinzufügt, wird aus einer Vertrauens- und kulturellen Perspektive zu einem ganz neuen Team. Die Menschen haben diese Veränderung satt. Das bedeutet, dass Sie, während Sie den Mythical Man-Monat managen und mildern, die Emotionen rund um das Wachstum managen müssen. Das ist vielleicht die kritischste Aufgabe von allen.

Der starke Glaube an den mythischen Mann-Monat durch ein Team an und für sich kann seine Schlussfolgerungen in die Realität umsetzen. Es ist im Grunde das Äquivalent zum Glauben an das Fliegen in Peter Pan. Wenn das Team glaubt, dass die Skalierung sie verlangsamen wird, und sie die Änderung nicht akzeptieren, werden sie tatsächlich langsamer.

Wenn Sie also daran arbeiten, Abhängigkeiten zu verwalten und Tools zur Unterstützung der Skalierung einzuführen, stellen Sie sicher, dass Sie das Warum hinter den Praktiken klar kommunizieren. Beteiligen Sie die Leute an der Auswahl der Arbeit und der Prozesse, die die mannmonatlichen Probleme mindern, denn wenn sie Teil der Veränderung sind und sich ihre Perspektive ändert, wird Skalierung plötzlich zumindest kulturell möglich.