De manier waarop we denken over engineering veranderen om weer bouwers te worden

De manier waarop we denken over engineering veranderen om weer bouwers te worden

Ik werk sinds 2014 bij Buffer en zelfs voordat ik bij Buffer kwam, was ik altijd een fan van de product- en engineeringcultuur van het Buffer-team: hoe snel ze verbeteringen hebben doorgevoerd en hoe dicht iedereen bij gebruikers was (het is niet ongewoon om te zien dat technici reageren reacties op Twitter!).

Ik vond de “power-to-do”-houding inspirerend en aanstekelijk, en het is verbazingwekkend hoe dingen op die manier klikken. Toen ik erbij kwam, waren we natuurlijk een team van 24 mensen; We droegen allemaal veel petten en we hadden geen managers.

Naarmate we vorderden, zijn we begonnen met het creëren van teamstructuren en -processen om ons beter te ondersteunen en deze groei te beheren. Maar samenwerking opschalen met behoud van snelheid is natuurlijk een kunst op zich en er beginnen wrijvingspunten te ontstaan: projecten lopen vaak tegen knelpunten aan en teams blokkeren elkaar. Aangezien het langer zal duren om de functies vrij te geven, zullen we proberen het “correct” te maken door meer tijd te besteden aan het maken van de specificaties van wat we hebben geprobeerd te bouwen, maar natuurlijk, hoe groter de projecten, hoe langer het duurt om ze op te leveren.

We kwamen vast te zitten in een zelfversterkende lus: als het maanden duurt om iets te bouwen, wordt het erg moeilijk om door te gaan en te herhalen, omdat we ook andere prioriteiten zullen hebben! Dit versterkte de noodzaak om meer en beter te doen en zorgde voor meer druk om ‘het goed te doen’.

Vorig jaar realiseerden we ons dat we bepaalde buffergewoonten en -dynamiek wilden veranderen om terug te keren naar die begindagen van vaker opladen: hoe meer u regelmatig oplaadt, hoe gemakkelijker het is om die wijzigingen te beheren (omdat ze kleiner zijn). Het voelt veiliger, zelfs als het ding dat we verzenden faalt – het creëren van meer psychologische veiligheid voor ons team. Het was duidelijk: we wilden weer bouwers zijn en ondernemerschap en een cultuur van terugval omarmen.

Metrieken die ons helpen de bouwsituatie te bepalen

Hoe weten we dat we ons in de bouwmodus bevinden? Dat we sneller handelen, vaker verzenden en de feedbackloops met onze klanten aanhalen? Enkele nuttige statistieken om ons op deze reis te begeleiden: tijdcyclusEn de trek verzoek snelheidEn de defectpercentage. Hier is wat context over wat deze statistieken betekenen en hoe we ze meten:

tijdcyclus
Omdat we de tijd die nodig is om op de markt te komen willen verkorten, willen we meten hoe snel en hoe vaak we waarde leveren aan onze gebruikers. Cyclustijd is voor ons de tijd tussen het begin van het werk aan een functie of verbetering (de eerste wijziging die we daarvoor in de codebase aanbrengen) tot wanneer Intrekkingsverzoek Met wijzigingen worden ze gecombineerd en vrijgegeven voor productie.

Productiviteitsaanvraag
Pull-verzoeken zijn de artefacten die we als ontwikkelaars maken om te beginnen met het integreren van nieuwe codewijzigingen met bestaande code die in productie wordt uitgevoerd.

We kunnen elk pull-verzoek zien als een werkeenheid die waarde biedt (bijvoorbeeld een nieuwe functie, bugfix of andere codebase-optimalisatie). Dit is de reden waarom het totale aantal ingebouwde pull-verzoeken (en hun implementatie naar productie) een proxy kan zijn voor de waarde die wordt geleverd.

defectpercentage
Sneller handelen verbetert natuurlijk niets als het betekent dat we meer gebreken en fouten naar onze klanten sturen!

Het foutpercentage fungeert voor ons als een controlemaatstaf, omdat we het aantal codewijzigingen meten dat we maken om bugs die in eerdere wijzigingen zijn aangebracht, af te handelen.

De dynamiek die we hebben toegepast om deze verandering in engineering-mindset te stimuleren

Net zoals gewoonten essentieel zijn voor de vorming van onze identiteit als individuen, zijn ze van fundamenteel belang voor de ontwikkeling van de mentaliteit en cultuur van het bedrijf.

Als we weten wat we willen bereiken en hoe we het moeten meten, beginnen we na te denken over nieuwe dynamieken, die ons, wanneer we ze omarmen, ons helpen onze identiteit als bouwers op te bouwen. Ook hielden we onze ogen open voor huidige gewoonten die ons de weg blokkeerden en ons ervan weerhielden om naar het volgende niveau te gaan.

Customer Engineering Days
Een essentieel onderdeel van elke bouwer is het contact met zijn klanten: directe interactie met onze klanten is essentieel om inzicht te krijgen in de vragen die ze stellen, de behoeften die ze hebben en de pijnpunten die je voelt in onze systemen.

Met Customer Engineering Days hebben we elk een engineeringteam dat een technicus per cyclus toewijst, gekoppeld aan een advocaat, voor een dag om tickets in de inbox te beantwoorden en samen quick wins op te lossen. Dit is een geweldige kans voor ingenieurs om onze klantenadvocaten vragen te stellen over onze klanten, functies en producten, en voor advocaten om hun ervaringen te delen en geweldige ideeën aan klanten te brengen!

Verwijder blokkerende opnameverzoeken zo veel mogelijk
Nu we een cultuur van sneller handelen aannemen, was een van de eerste dingen die me opvielen het beoordelingsproces voor het opnemen van wijzigingen in de productie: sommige teams hebben een regel die vereist dat een andere ontwikkelaar hun code beoordeelt voordat de wijziging direct wordt doorgevoerd. Industriestandaarden en onderzoek hebben verrassende resultaten opgeleverd: goedkeuringsprocessen voor codewijzigingen zijn niet gerelateerd aan de prestaties van softwarelevering.

We willen de gateway-service verwijderen om wijzigingen aan te brengen, het eigendom te vergroten en mensen in staat te stellen in de flow te blijven, dus teams beginnen af ​​te stappen van standaard naar pull-verzoeken te openen en te wachten op goedkeuring, en een hybride methode te gebruiken genaamd “ship/offer/ vragen”:

  • boot Het betekent gewoon! U hoeft geen beoordeling aan te vragen, breng gewoon de wijziging aan en publiceer deze in productie.
  • Displays Het is geweldig om asynchrone feedback te krijgen of om nieuwe patronen en lessen met het team te delen, maar wacht niet op goedkeuring voordat je het naar productie verzendt.
  • vragen Dit is de traditionele methode waarbij codecontrole vereist is voordat deze wordt samengevoegd en naar productie wordt verzonden.

Door uit te leggen dat er verschillende alternatieven en benaderingen zijn voor verschillende situaties, kunnen teams weten welk evenwicht ze moeten vinden, en weten ze of ze veel in een “vraagmodus” zitten wanneer ze meer naar “verzending” of “presenteren” kunnen gaan.

werk kleiner
Natuurlijk, als we ons alleen concentreren op praktijken uit het verleden, zal het voelen alsof we de teams vragen om meer en sneller werk te doen. Deze doelen en praktijken zijn voor ons om de manier waarop we werken uit te dagen en te verbeteren, niet hoeveel we werken!

Een van de belangrijkste componenten om dit te garanderen, en een belangrijke bijdrage aan het worden van een goed presterend team, is: werk kleiner: Als we ons werk opsplitsen in functies die een snelle ontwikkeling mogelijk maken in plaats van grotere, complexere projecten die niet vaak worden vrijgegeven.

Daarom gebruiken technische teams het gebruik van feature flips (ook wel feature switching genoemd) als een manier om nieuwe functies die nog in ontwikkeling zijn naar productie uit te rollen zonder de gebruikerservaring negatief te beïnvloeden. Dit elimineert grote versies met veel wijzigingen, in plaats daarvan kunnen we nieuwe functies vrijgeven aan onze gebruikers als we ze al in productie hebben getest.

Door in kleinere batches te werken, ontstaat er meer psychologische veiligheid voor onze technici, omdat het risico van het doorvoeren van dringende veranderingen die iedereen raken, drastisch wordt verminderd.

Engineering managers wenden zich ook tot bouwers
Hoewel de rol van de Engineering Director in de verschillende teams voornamelijk gericht was op het managen van mensen, de loopbaangroei van de ingenieur en het coördineren van manieren van werken, is hun belangrijkste verantwoordelijkheid ervoor te zorgen dat onze teams waarde leveren door ons product en onze teams in een manier die aansluit bij zowel onze producten als onze technische doelen.

Dus om echt te rijden met de mentaliteit van deze bouwers, moeten onze technische directeuren ook bouwers worden! We hebben de rol van de Engineering Director opnieuw gedefinieerd en streven er nu naar dat ze ten minste 25% van hun tijd hands-on in het team besteden. Hands-on training kan vele vormen aannemen, zoals:

  • Duik in data-analyse om een ​​nieuwe functie te lanceren.
  • Werk aan niet-kritieke taken.
  • QA’ing nieuwe functies.
  • Met klanten omgaan.

Dit geeft hen context en beter inzicht in de technische beslissingen en afwegingen waarmee hun teams worden geconfronteerd en creëert een gedeeld gevoel van eigenaarschap in het hele team, aangezien we allemaal op onze eigen manier bijdragen om vaak vrij te geven.

De resultaten: hebben we een constructie-mindset aangenomen?

We zijn 9 maanden geleden begonnen aan deze mentaliteitsveranderingsreis en het was een geweldige weg naar afstemming tussen teams: het aantal functies en verbeteringen dat we de afgelopen maanden hebben geleverd, is een weerspiegeling van al deze veranderingen. We vragen ons voortdurend af: “Hoe kunnen we het volgende sneller en met hogere kwaliteit verzenden?”. wij Voelen Er is een verandering in motivatie en energie.
Als we nu teruggaan naar de statistieken die ik eerder in dit bericht heb gedeeld, kunnen we zien dat:

  • De cyclustijd is drastisch afgenomen: van gemiddeld 94,8 uur in 2021 naar 55 uur in 2022 tot nu toe.
  • Verkeer nam toe in PR: 4.155 verzoeken tot intrekking werden gepubliceerd in 2021 vergeleken met 3.687 verzoeken die tot nu toe in 2022 zijn gepubliceerd (1.816 meer verzoeken tot intrekking dan H2 2021!).
  • Het aantal defecten is gedaald: van 18 procent van de tijd dat het defecten verhelpt in 2021 tot 16 procent in 2022 tot nu toe.

Dit betekent dat het engineeringteam daadwerkelijk sneller en vaker vrijgeeft en dat de kwaliteit de snelheid van levering niet in de weg staat.

Er zitten een aantal geweldige technische projecten in de pijplijn die het hele engineeringteam in de tweede helft van het jaar zullen versnellen, dus we zijn nog maar net begonnen! Zijn er gewoontes die uw team heeft om de verzendsnelheid te verhogen en dichter bij uw klanten te komen? Terwijl we doorgaan op dit pad om bouwers te worden, ben ik verheugd om te blijven delen wat we hebben geleerd en gaandeweg vooruitgang te boeken.

Voel je vrij om contact met me op te nemen op Twitter op Tweet insluiten Om je ervaringen te delen!

Leave a Reply

Your email address will not be published.