Ändern Sie die Art und Weise, wie wir Ingenieurwesen denken, um wieder zu Bauherren zu werden

Ändern Sie die Art und Weise, wie wir Ingenieurwesen denken, um wieder zu Bauherren zu werden

Ich bin seit 2014 bei Buffer und schon bevor ich zu meinem Eintritt kam, war ich immer ein Fan der Produkt- und Entwicklungskultur des Buffer-Teams: wie schnell sie Verbesserungen lieferten und wie nah jeder an den Benutzern war (es ist nicht ungewöhnlich, dass Ingenieure antworten zu Kommentaren auf Twitter!).

Ich fand die „Power-to-do“-Einstellung inspirierend und ansteckend, und es ist erstaunlich, wie die Dinge so funktionieren. Als ich dazu kam, waren wir natürlich ein Team von 24 Leuten; Wir alle trugen viele Hüte und hatten keine Manager.

Im Laufe unserer Fortschritte haben wir begonnen, Teamstrukturen und -prozesse zu schaffen, um uns besser zu unterstützen und dieses Wachstum zu bewältigen. Aber natürlich ist es eine Kunst für sich, die Zusammenarbeit zu skalieren und gleichzeitig die Geschwindigkeit beizubehalten, und es treten Reibungspunkte auf: Projekte geraten oft in Engpässe, und Teams blockieren sich gegenseitig. Da die Veröffentlichung der Funktionen länger dauern wird, werden wir versuchen, es “korrekt” zu machen, indem wir mehr Zeit damit verbringen, die Spezifikationen dessen zu erstellen, was wir zu bauen versucht haben, aber je größer die Projekte sind, desto länger dauert es natürlich, bis sie geliefert werden.

Wir sind in einer sich selbst verstärkenden Schleife stecken geblieben: Wenn es Monate dauert, etwas aufzubauen, wird es sehr schwierig, es durchzuziehen und zu wiederholen, weil wir uns auch um andere Prioritäten kümmern müssen! Dies verstärkte weiterhin die Notwendigkeit, mehr und besser zu werden, und erzeugte weiterhin mehr Druck, „es richtig zu machen“.

Letztes Jahr haben wir erkannt, dass wir bestimmte Buffer-Gewohnheiten und -Dynamiken ändern wollten, um häufiger zu den Anfängen des Aufladens zurückzukehren: Je mehr Sie regelmäßig aufladen, desto einfacher ist es, diese Änderungen zu verwalten (weil sie kleiner sind). Es fühlt sich sicherer an, selbst wenn das Ding, das wir versenden, ausfällt – und schafft mehr psychologische Sicherheit für unser Team. Es war klar: Wir wollten wieder Bauherren sein und uns dem Unternehmertum und einer Kultur des Rückschritts verschrieben haben.

Metriken, die uns helfen, die Bausituation zu bestimmen

Woher wissen wir, dass wir uns im Baumodus befinden? Dass wir schneller vorankommen, häufiger versenden und die Feedbackschleifen mit unseren Kunden verkürzen? Einige nützliche Metriken, die uns auf dieser Reise leiten: ZeitzyklusUnd die Pull-Request-GeschwindigkeitUnd die Fehlerrate. Hier ist etwas Kontext dazu, was diese Metriken bedeuten und wie wir sie messen:

Zeitzyklus
Da wir die Markteinführungszeit verkürzen möchten, möchten wir messen, wie schnell und wie oft wir unseren Benutzern einen Mehrwert liefern. Zykluszeit ist für uns die Zeit zwischen dem Beginn der Arbeit an einem Feature oder einer Verbesserung (die erste Änderung, die wir dafür in der Codebasis vornehmen) bis wann Auszahlungsantrag Bei Änderungen werden sie zusammengeführt und für die Produktion freigegeben.

Produktivitätsanforderung
Pull Requests sind die Artefakte, die wir als Entwickler erstellen, um mit dem Prozess der Integration neuer Codeänderungen in bestehenden Code zu beginnen, der in der Produktion ausgeführt wird.

Wir können uns jede Pull-Anfrage als eine Arbeitseinheit vorstellen, die einen Mehrwert bietet (z. B. ein neues Feature, eine Fehlerbehebung oder eine andere Optimierung der Codebasis). Aus diesem Grund kann die Gesamtzahl der integrierten Pull-Requests (und ihre Bereitstellung in der Produktion) ein Proxy für den gelieferten Wert sein.

Fehlerrate
Natürlich verbessert schnelleres Handeln nichts, wenn wir dadurch mehr Mängel und Fehler an unsere Kunden liefern!

Die Fehlerrate fungiert für uns als Kontrollmetrik, da wir die Anzahl der Codeänderungen messen, die wir vornehmen, um Fehler zu beheben, die in früheren Änderungen vorgenommen wurden.

Die Dynamik, die wir angewendet haben, um diesen Wandel in der Denkweise der Ingenieure voranzutreiben

So wie Gewohnheiten für die Bildung unserer Identität als Individuen von entscheidender Bedeutung sind, sind sie von grundlegender Bedeutung für die Entwicklung der Denkweise und Kultur des Unternehmens.

Wenn wir wissen, was wir erreichen wollen und wie wir es messen können, beginnen wir, über neue Dynamiken nachzudenken, die uns, wenn wir sie annehmen, helfen, unsere Identität als Bauherren aufzubauen. Außerdem haben wir die Augen offen gehalten für aktuelle Gewohnheiten, die uns den Weg versperren und uns daran hindern, das nächste Level zu erreichen.

Kunden-Engineering-Tage
Ein wesentlicher Bestandteil jedes Bauunternehmens ist der Kontakt zu seinen Kunden: Die direkte Interaktion mit unseren Kunden ist der Schlüssel, um einen Einblick in die Fragen, die sie stellen, die Bedürfnisse, die sie haben, und die Schwachstellen zu erhalten, die Sie in unseren Systemen spüren.

Bei den Customer Engineering Days haben wir jeweils ein Engineering-Team, das einen Ingenieur pro Zyklus zusammen mit einem Anwalt für einen Tag zuweist, um Tickets im Posteingang zu beantworten und gemeinsam schnelle Erfolge zu erzielen. Dies ist eine großartige Gelegenheit für Ingenieure, unseren Kundenbefürwortern Fragen zu unseren Kunden, Funktionen und Produkten zu stellen, und für Befürworter, ihre Erfahrungen auszutauschen und Kunden einige großartige Ideen vorzustellen!

Entfernen Sie blockierende Auszahlungsanfragen so weit wie möglich
Da wir eine Kultur des schnelleren Handelns annehmen, war eines der ersten Dinge, die mir aufgefallen sind, der Überprüfungsprozess für die Integration von Änderungen in die Produktion: Einige Teams haben eine Regel, die verlangt, dass ein anderer Entwickler ihren Code überprüft, bevor er die Änderung direkt vorantreibt. Branchenstandards und Untersuchungen haben überraschende Ergebnisse gezeigt: Genehmigungsprozesse für Codeänderungen stehen in keinem Zusammenhang mit der Leistung der Softwarebereitstellung.

Wir möchten den Gateway-Dienst entfernen, um Änderungen vorzunehmen, die Eigentümerschaft zu verbessern und es den Mitarbeitern zu ermöglichen, im Fluss zu bleiben, also beginnen die Teams, sich von der Standardeinstellung zu entfernen, um Pull-Anforderungen zu öffnen und auf die Genehmigung zu warten, und verwenden eine hybride Methode namens „ship/offer/ Fragen”:

  • Boot Es bedeutet nur! Sie müssen keine Überprüfung anfordern, nehmen Sie einfach die Änderung vor und veröffentlichen Sie sie in der Produktion.
  • Anzeigen Es ist großartig, um asynchrones Feedback zu erhalten oder einige neue Muster und Erkenntnisse mit dem Team zu teilen, aber warten Sie nicht auf die Genehmigung, bevor Sie es an die Produktion senden.
  • Fragen Dies ist die traditionelle Methode, bei der eine Codeüberprüfung erforderlich ist, bevor sie zusammengeführt und an die Produktion gesendet wird.

Das Erklären, dass es unterschiedliche Alternativen und Ansätze für unterschiedliche Situationen gibt, bedeutet, dass Teams wissen, welches Gleichgewicht sie finden müssen, und wissen, ob sie sich häufig in einem „Fragemodus“ befinden, wenn sie mehr in Richtung „Liefern“ oder „Präsentieren“ drängen können.

kleiner arbeiten
Wenn wir uns natürlich nur auf frühere Praktiken konzentrieren, wird es sich anfühlen, als würden wir die Teams bitten, mehr und schneller zu arbeiten. Mit diesen Zielen und Praktiken wollen wir unsere Arbeitsweise herausfordern und verbessern, nicht wie viel wir arbeiten!

Eine der Schlüsselkomponenten, um dies zu gewährleisten, und ein wichtiger Beitrag dazu, ein leistungsstarkes Team zu werden, ist kleiner arbeiten: Wenn wir unsere Arbeit in Funktionen aufteilen, die eine schnelle Entwicklung ermöglichen, anstatt in größere, komplexere Projekte, die selten veröffentlicht werden.

Daher nutzen Engineering-Teams Feature-Flips (auch als Feature-Switching bezeichnet), um neue Features, die sich noch in der Entwicklung befinden, in die Produktion einzuführen, ohne die Benutzererfahrung negativ zu beeinflussen. Dadurch entfallen große Versionen mit vielen Änderungen, stattdessen können wir unseren Benutzern neue Funktionen freigeben, wenn wir sie bereits in der Produktion getestet haben.

Das Arbeiten in kleineren Chargen schafft eine größere psychologische Sicherheit für unsere Ingenieure, da das Risiko, dringende Änderungen vorzunehmen, die alle betreffen, drastisch reduziert wird.

Auch Ingenieure wenden sich an Bauherren
Während sich die Rolle des Engineering Director in den verschiedenen Teams in erster Linie auf das Management von Mitarbeitern, das Karrierewachstum des Ingenieurs und die Koordinierung von Arbeitsweisen konzentriert hat, besteht seine Hauptverantwortung darin, sicherzustellen, dass unsere Teams einen Mehrwert liefern, indem sie unser Produkt und unsere Teams in einem aufbauen Weise, die sowohl mit unseren Produkten als auch mit unseren technischen Zielen übereinstimmt.

Um also wirklich mit der Denkweise dieser Baumeister zu fahren, müssen unsere technischen Direktoren auch Baumeister werden! Wir haben die Rolle des Engineering Director neu definiert und streben nun an, dass er mindestens 25 % seiner Zeit praktisch im Team verbringt. Praktisches Training kann viele Formen annehmen, wie zum Beispiel:

  • Tauchen Sie ein in die Datenanalyse, um eine neue Funktion zu starten.
  • Arbeiten Sie an unkritischen Aufgaben.
  • QA für neue Funktionen.
  • Mit Kunden umgehen.

Dies gibt ihnen Kontext und bessere Einblicke in die technischen Entscheidungen und Kompromisse, mit denen ihre Teams konfrontiert sind, und schafft ein gemeinsames Gefühl der Verantwortung im gesamten Team, da wir alle auf unsere eigene Weise dazu beitragen, häufig zu veröffentlichen.

Die Ergebnisse: Haben wir ein Bau-Denken angenommen?

Wir haben vor 9 Monaten mit dieser Reise zur Änderung der Denkweise begonnen und es war ein großartiger Weg zur Abstimmung zwischen den Teams: Die Anzahl der Funktionen und Verbesserungen, die wir in den letzten Monaten ausgeliefert haben, spiegelt all diese Änderungen wider. Wir fragen uns ständig „Wie können wir das nächste Ding früher und mit höherer Qualität versenden?“. wir Gefühl Motivation und Energie verändern sich.
Wenn wir nun zu den Metriken zurückkehren, die ich zuvor in diesem Beitrag geteilt habe, können wir Folgendes sehen:

  • Die Durchlaufzeit ist dramatisch gesunken: von durchschnittlich 94,8 Stunden im Jahr 2021 auf bisher 55 Stunden im Jahr 2022.
  • Der Verkehr in PR nahm zu: 4.155 Anträge auf Widerruf wurden im Jahr 2021 veröffentlicht, verglichen mit 3.687 Anträgen, die im Jahr 2022 bisher veröffentlicht wurden (1.816 Anträge auf Widerruf mehr als im zweiten Halbjahr 2021!).
  • Fehlerquote gesunken: von 18 Prozent der Zeit, in der Fehler behoben werden, im Jahr 2021 auf 16 Prozent im Jahr 2022 bisher.

Das bedeutet, dass das Engineering-Team tatsächlich schneller und häufiger Releases veröffentlicht und die Qualität die Liefergeschwindigkeit nicht beeinträchtigt.

Es sind einige großartige Technologieprojekte in der Pipeline, die das gesamte Engineering-Team in der zweiten Jahreshälfte beschleunigen werden, also fangen wir gerade erst an! Gibt es Gewohnheiten Ihres Teams, die ihnen geholfen haben, die Versandgeschwindigkeit zu erhöhen und näher an Ihre Kunden heranzukommen? Während wir diesen Weg fortsetzen, Baumeister zu werden, freue ich mich darauf, weiterhin zu teilen, was wir gelernt haben und auf dem Weg vorankommen.

Fühlen Sie sich frei, sich mit mir auf Twitter zu verbinden unter Tweet einbetten Um Ihre Erfahrungen zu teilen!

Leave a Reply

Your email address will not be published.