Erstellung/Aufteilung neuer Entwicklungsteams bei FloQast: Die Perspektive eines Ingenieurs

In meiner kurzen Zeit in dieser runden Welt habe ich zwei Wahrheiten im Leben verstanden.

1. Die Mitochondrien sind das Kraftwerk der Zelle.
2. Phänomene der Naturbiologie werden verwendet, um Produktentwicklungsteams zu beschreiben.

Bei FloQast hatte ich die Gelegenheit, nicht an einem, sondern an zwei Teamsplits teilzunehmen. Hier sind einige spannende Herausforderungen, denen ich durch diese natürliche Entwicklung zum Teambuilding begegnet bin.

Ein kleiner Kern

In einem früheren Artikel, ich sprach über unser Produkt FloQast ReMind und die Lernkurve, die mit der Einführung einer neuen Anwendung in unserem kleinen Team einherging. Mit Zeit, unermüdlichem Einsatz und einer gesunden Feedback-Schleife haben wir etwas geschaffen, das unsere Kunden begeisterte, und verständlicherweise wollten sie mehr!

Nachdem wir festgestellt hatten, dass unser Produkt zum Markt passt, haben wir uns eingehender mit dem Feedback unserer Kunden befasst. Wir haben wiederkehrende Trends beim Nutzerappetit festgestellt:

„Wann wird es in diese Funktion integriert?“ - Kunde A

„Ich möchte das mit ReMind machen, wann wird das verfügbar sein?“ - Kunde B

„Das ist ein Muss, bevor ich mich entscheide, dieses Produkt zu verwenden.“ - Kunde C

Wie Sie sich vorstellen können, führte dies zu einer erheblichen Erweiterung der Produkt-Roadmap. Wir wollen nicht, dass unsere Kunden um unsere Entwicklungszeit miteinander konkurrieren. Um dem entgegenzuwirken, haben wir unser kleines Team verbessert.

Neue Teamkollegen, neue Einblicke und andere Herausforderungen

Unser Team hatte bei jedem Sprint eine gleichbleibende Leistung (auch bekannt als Velocity), was uns eine allgemeine Vorstellung davon gab, wann wir mit der Lieferung unserer Arbeit rechnen konnten. Jeder Sprint brachte ungefähr 15 Leistungspunkte mit sich. Obwohl wir in diesem stetigen, leistungsstarken Tempo arbeiteten, würde es Monate dauern, bis wir die Kundeninteressen am Ende der Roadmap angehen konnten.

Wenn Sie ein kleines Team sind, fühlt es sich an, als wäre die Kavallerie da, wenn Sie mehr Ingenieure hinzuziehen. Letzten Winter, als wir drei weitere Ingenieure hinzuzogen, rechnete ich damit, dass sich unsere Lieferung dramatisch beschleunigen würde. Interessanterweise fand ich, dass dies kontraproduktiv war, um die Geschwindigkeit unseres Teams zu verbessern.

Früher, als wir zwei Ingenieure hatten, waren wir in der Lage, den Code an einem einzigen Tag zu versenden. Mit fünf Entwicklern fühlten sich unsere Code-Reviews eher wie eine Stack-Overflow-Diskussion an, bei der jeder versuchte, seine Lösungen anzubieten. Wie sich herausstellte, hatte jeder Ingenieur seine eigenen Ideen, wie man arbeitet. Es würde mehrere Tage dauern, bis ein Konsens erzielt und der Code endlich in Produktion gebracht wurde. Leider wurden die Probleme unserer Kunden dadurch nicht schneller gelöst.

Die Mathematik

Wenn das Team wächst, steigt auch eine kognitive Belastung, um sicherzustellen, dass Wissen und Perspektiven geteilt werden.

Sie können sich das als Algorithmus vorstellen. Jedes Mal, wenn Sie einem kleinen Team eine neue Person vorstellen, berufen Sie sich auf die Notwendigkeit, für jedes bestehende Teammitglied eine neue Kommunikationslinie einzurichten. Bevor du jetzt sagst: „Chris, diese Mathematik ergibt keinen Sinn“, lass mich das bitte per Code erklären:

let initialMembers = 0 
let projectedMembers = 5
let totalUniquePairs = 0

while(initialMembers < projectedMembers){
    totalUniquePairs+= initialMembers // establish new pairs with new team member
    initialMembers++ // team member is integrated
}

console.log("Unique pairs:", totalUniquePairs) // 10

‍Und für meine visuell veranlagten Kollegen:

Das Team wuchs von 2 auf 7 Ingenieure. Dies ermöglichte es uns jedoch nicht, mehr Code zu versenden. Stattdessen hatten wir mehr Besprechungen und asynchrone Gespräche, um Wissenslücken zu schließen und auf derselben Wellenlänge zu bleiben.

Mehr Teammitglieder auf einem Pod bedeuten nicht unbedingt ein effizienteres Team. Stattdessen gibt es mehr Gespräche darüber, wie wir effizienter und produktiver arbeiten können. Mit mehr Teammitgliedern wachsen die Vorteile des Splittings noch weiter.

Aufspalten und Disambiguieren

Rückblickend empfehle ich dringend, eine Dokument mit technischen Anforderungen (ERD), um Teamsplits zu erleichtern. Ein ERD hilft bei der Behandlung wichtiger Themen wie:

• Wem gehören diese vorhandenen Datensammlungen?
• Wird es neue Datensammlungen oder APIs geben, um unsere Arbeitsvereinbarung zu erleichtern?
• Was sind die Datenverträge zwischen diesen Pods?

Verschiedene Pods, dasselbe Team

Die Aufteilung eines Teams erfolgt nicht über Nacht. Unsere Pods sind mit unterschiedlichen Aufgaben ausgestattet und übernehmen die Verantwortung für ihre Geschäftsfunktionen, aber die verbleibenden Funktionen müssen noch ausgebügelt werden. Vor der Trennung des Teams hatten wir einen Dienst, der Dokumente erfasst, aber wir haben festgestellt, dass es effektiver ist, wenn der neue Pod diese API besitzt. Es dauerte einige Zeit, bis letzteres wieder aufgebaut und in der Produktion eingesetzt wurde. Wir mussten zusammenarbeiten, um sicherzustellen, dass der Kunde nicht ausfällt.

Die neuen Teams haben ein wöchentliches Technical Sync-Meeting, um Fortschritte und Entdeckungen zu besprechen. Die Teammitglieder verwenden ein Google-Dokument, um einen Plan mit Diskussionspunkten zu organisieren, und werden ermutigt, ihn im Voraus auszufüllen. Diese Praxis hilft uns, über die gesamte Produktentwicklung auf dem Laufenden zu bleiben.

Meiner Erfahrung nach teilen wir ein Team nicht nach Auszeichnung oder Neuheit auf. Wir teilen Teams auf, damit wir bei der Produktausführung agil vorgehen können und die oberste Priorität hat, unseren Kunden zu helfen. Heute können die neuen Teams gleichzeitig unterschiedliche Kundenbedürfnisse lösen und gleichzeitig zum größeren Technologie-Ökosystem beitragen.

Ich hoffe, das hat dir einen guten Einblick gegeben, wie Teamsplits bei FloQast aussehen. In Kürze werden wir einen Artikel veröffentlichen, der beschreibt, wie wir Team Mitosis in einer praktischen Umgebung durchführen.