3 forschungsbasierte Prinzipien, mit denen Sie Ihre technische Organisation skalieren können

3 forschungsbasierte Prinzipien, mit denen Sie Ihre technische Organisation skalieren können


Wenn die Entwicklungsteams wachsen, treten offensichtliche Schwierigkeiten auf. Es ist eine einfache Mathematik. Sie können nicht mit allen und allem mithalten, wie Sie es getan haben, als das Team klein war. Um die hohe Wirkung zu erzielen, die Sie immer hatten, müssen sich Ihre Arbeitsweisen ändern.

Die gute Nachricht ist, dass einige Prinzipien und Gesetze aus der Sozialwissenschaft und dem Projektmanagement hervorgegangen sind – wie das Conway-Gesetz, die Dunbar-Nummer und das Brooks-Gesetz -, die Ihr Wachstum beeinflussen können. Die Wahrheiten, die diese Prinzipien über Teamdynamik und Systemdesign enthüllen, weisen den Weg zu besseren Ergebnissen und mehr Teamzufriedenheit.

Diese Prinzipien gelten zwar für alle Bereiche, sind jedoch im Kontext von Entwicklungsteams besonders wirksam. Verwenden Sie sie, um durch Skalierung, Änderung und optimales Organisationsdesign zu führen.

Prinzip Nr. 1: Dunbars Nummer

Erstmals vorgeschlagen in den 1990er Jahren, Forschung des Anthropologen Robin Dunbar zeigt, dass der menschliche Neokortex (auch bekannt als der am weitesten entwickelte Teil des Gehirns) eine maximale soziale Gruppengröße von etwa 150 beibehalten kann. In einem kleinen Team kennen Sie möglicherweise das Lieblingsessen aller oder wie sie ihre Freizeit verbringen. Wenn das Team wächst, kennen Sie möglicherweise nur die Vornamen oder jemand sitzt im Allgemeinen im x-Team. In großen Unternehmen erkennen Sie möglicherweise nicht einmal die Personen in Ihrer eigenen Organisation!

Dunbars Nummer

Zahlreiche Studien und soziale Experimente bestätigen Dunbars Ergebnisse. Bei der Gestaltung von Engineering-Organisationen ist dies hilfreich für Entscheidungen über Tools, Prozesse und Organisationsstrukturen, die sich alle auf die Geschwindigkeit auswirken, wenn Teams skalieren. Zum Beispiel könnte das Anwenden der Dunbar-Nummer ins Spiel kommen, wenn Entscheidung, sich zu spezialisieren horizontal nach Technologie wie einem bestimmten Produkt oder vertikal nach Funktionsbereich wie Mobil, Web oder Infrastruktur. Oder es kann angewendet werden, um Entscheidungen über eine effektive Erweiterung des geografischen Fußabdrucks zu treffen oder um ein Verantwortungsbewusstsein innerhalb eines Teams für die Komponenten aufrechtzuerhalten, die sie besitzen.

Obwohl die Schwelle von 150 Personen am meisten diskutiert wird, tauchen bei wachsenden Organisationen auch Probleme auf, die unter dieser Zahl liegen. Wenn ein Team aus zehn oder weniger Personen besteht, gilt es als für die Zusammenarbeit optimiert. Da das Team jedoch auf mehr als 35 Mitarbeiter angewachsen ist, erfordert die Optimierung Schnittstellen und Roadmaps auf Systemebene, um Ziele und Zeitpläne aufeinander abzustimmen. (Dies schließt Tools wie Jira ein.)

Bei 150 oder mehr Personen muss das System vollständig eigenständig sein. Bei dieser Größe verlieren Sie allmählich die Vertrautheit (z. B. wenn Sie nicht jeden Namen oder jede Rolle kennen), die Sichtbarkeit (unsicher über alle Arbeiten im gesamten Unternehmen) und die Kommunikation (Komplexität in Bezug auf Zeitpläne und Kanäle).

Als wir das Confluence Cloud-Team von einem Standort an einen anderen verlegten, haben wir die Teamgröße angepasst, um den von Dunbars Nummer vorgeschlagenen Herausforderungen gerecht zu werden. Zunächst haben wir das Team verkleinert, um Rapport, Vertrauen und effektive Prozesse im neu gebildeten Team aufzubauen. Sobald wir wussten, dass wir über die Systeme und Tools verfügen, mit denen das Team mit mehr Kollegen zusammenarbeiten kann, haben wir die Skalierung wieder aufgenommen. Während dieser Änderungen haben wir wichtige Lektionen über die anfängliche Teameinrichtung gelernt, was im Laufe der Zeit erforderlich ist, um den Zusammenhalt aufrechtzuerhalten, und die horizontale oder vertikale Ausrichtung.

Hier sind einige Tipps, um die Auswirkungen von Dunbars Nummer abzuschwächen:

  • Halten Sie die Teamgröße möglichst klein. Beginnen Sie beispielsweise bei der ersten Teameinrichtung mit 3-5 Entwicklern unter einem Manager, der sich am selben Ort befindet, damit sie eine Beziehung aufbauen können.
  • Probieren Sie monatliche teamübergreifende Demos aus, um Wissen auszutauschen.
  • Nehmen Sie sich Zeit, um Beziehungen zu anderen aufzubauen, während das Team wächst.
  • Von ungezwungenen Kaffees bis hin zu Besprechungen mit allen Händen ist es wichtig, dass sich alle nicht nur mit der Arbeit, sondern auch mit ihren Kollegen verbunden fühlen.

Prinzip Nr. 2: Conways Gesetz

Erstmals vorgeschlagen im Jahr 1967, Conways Gesetz heißt es: „Organisationen, die Systeme entwerfen… sind gezwungen, Entwürfe zu erstellen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.“ In der Praxis läuft dies darauf hinaus, „Ihr Organigramm zu versenden“, was Ihren Benutzern selten großartige Erlebnisse bringt. Das Conway-Gesetz kann für wirkungsvolle Ergebnisse genutzt oder für vorhersehbare Ergebnisse ignoriert werden.

Beim Entwerfen einer Organisation spiegelt die Systemarchitektur das ausgewählte Modell wider. Wenn beispielsweise zwei Subteams einen Teil eines Systems bilden, besteht dieses System aus zwei Komponenten. Dies geschieht immer wieder in Software auf allen Ebenen. Indem Sie beim Erstellen Ihres Organisationsmodells das Strategiemodell -> Organisation -> Personen anwenden, können Sie das Conway-Gesetz zu Ihrem Vorteil nutzen. Es kann Ihnen helfen, einfachere Software zu geringeren Koordinierungskosten mit weniger Doppelarbeit bereitzustellen.

Das jüngste Auftauchen des „inverses Conway-Manöver"(Oder die Strukturierung Ihrer Unternehmensorganisation, um Ihre gewünschte Softwarearchitektur widerzuspiegeln), ist eine Taktik, die aus dem Conway'schen Gesetz entwickelt wurde und von einer warnenden Geschichte zu einem leistungsstarken Werkzeug führt. In einem Szenario, in dem doppelte Systeme erstellt werden, können Sie beispielsweise die Eigentümerschaft der beiden Systeme in einem einzigen Team oder einer einzigen Organisation zusammenführen, und die Duplizierung wird von selbst schnell reduziert.

Während eines Übergangs bei Atlassian hatten wir die Gelegenheit, ein neues Team aufzubauen und das Modell der Trupps und Stämme auszuprobieren. Aber es hat nicht funktioniert. Für ein so komplexes System war es zu zufällig. Es stellt sich heraus, dass es schwierig ist, monatlich oder vierteljährlich zu einem Teil des Trupp- und Stammessystems zu wechseln und das Wissen zu erweitern, das erforderlich ist, um effektiv zu sein.

Hier sind einige Tipps, um die Auswirkungen des Conway-Gesetzes abzuschwächen:

  • Wenn zwei Teams ähnliche Systeme erstellen, wenden Sie das umgekehrte Conway-Manöver an, sodass sie ein einziges Team sind, das über doppelte Systeme verfügt.
  • Es ist schwer zu wissen, dass ähnliche Systeme gebaut werden. Beispielsignale sind Verwirrung von Benutzern des Systems ("Sie scheinen sehr ähnlich zu sein, warum sollte ich sie übereinander verwenden?") Oder Technologiedebatten ("Wir sollten Tech X verwenden, weil es in diesem System besser als Tech Y ist." )
  • Wenn dasselbe Team die duplizierenden Systeme besitzt, werden sie zu einem einzigen System konvergieren.

Prinzip Nr. 3: Brooks'sches Gesetz

Das Brooks'sche Gesetz kommt vom Grundstein Mythischer Mannmonat Buch. Darin heißt es: "Durch Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt wird es später."

Es wird regelmäßig von Ingenieuren aufgerufen, normalerweise, wenn ein Projekt zu spät läuft und das Team an Minderungsplänen arbeitet. Diese oxymoronische Aussage wurde Projekt für Projekt von Ingenieurteams aller Größen und Projekten aller Dauer validiert. Hofstadter-Gesetz"Es dauert immer länger als erwartet, auch wenn Sie das Hofstadter-Gesetz berücksichtigen", wird häufig in Verbindung mit Mythical Man-Month zitiert. Der doppelte Aufwand, länger als erwartet zu dauern, zusammen mit der Verzögerung eines bereits abrutschenden Projekts durch Hinzufügen von Personen, kann sich nachteilig auf ein Projekt auswirken, wenn es sich am wenigsten zusätzliche Verzögerungen leisten kann.

Durch die Anwendung der Lehren aus dem Mythical Man-Month können Teams Projekte in Zeiten großen Stresses vorhersehbar planen. Es ermöglicht technischen Managern, zusätzliche Kapazitäten zu integrieren, ohne die positiven Auswirkungen des Hinzufügens von mehr Mitarbeitern auf den Zeitplan zu überbeanspruchen. (Was manchmal eine schlechte Situation verschlimmert.) Das Hinzufügen von Personen mag das Richtige sein, aber diese Entscheidung sollte durch Mythical Man-Month-Erkenntnisse beeinflusst werden.

Bei Atlassian sehen wir uns dem oft gegenüber. Wenn wir bei großen, lang laufenden Projekten die Zeitpläne verkürzen müssen, versuchen wir, Personen zu finden, die praktische Erfahrung mit der Codebasis haben. Es gibt oft weniger schmerzhafte Optionen, aber wir akzeptieren den Kompromiss. In einigen Fällen untersuchen wir die Auswirkungen zweiter Ordnung, wenn Personen in mehreren Teams gemischt werden. Und manchmal akzeptieren wir, dass der Zeitplan nicht wiederherstellbar ist, und verschieben Daten.

Tipps zur Abschwächung der Auswirkungen des Mythical Man-Month:

  • Finden Sie den wahren Break-Even-Punkt für das Hinzufügen von Personen zu einem vorhandenen Projekt, berücksichtigen Sie die Anlaufzeit für die neuen Mitarbeiter sowie die Schulungszeit für das vorhandene Team. Dieser Break-Even-Punkt ist weiter entfernt als Sie denken.
  • Während der Titel des Gesetzes "mythisch" lautet, haben wir es immer mit echten Menschen zu tun. Die Beratung des Managers einer Person ist der Schlüssel zum Verständnis der potenziellen Vorteile und Risiken, die sich aus der Verlagerung eines Teamkollegen in ein anderes Projekt ergeben.



Source by [author_name]

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.