Att förändra vårt sätt att tänka teknik för att bli byggare igen

Att förändra vårt sätt att tänka teknik för att bli byggare igen

Jag har varit på Buffer sedan 2014, och även innan jag började, har jag alltid varit ett fan av Buffer-teamets produkt- och ingenjörskultur: hur snabbt de skickade förbättringar och hur nära alla var användarna (det är inte ovanligt att se ingenjörer svara till kommentarer på Twitter!).

Jag tyckte att “power-to-do”-attityden var inspirerande och smittsam, och det är fantastiskt hur saker klickar på det sättet. Naturligtvis, när jag gick med var vi ett team på 24 personer; Vi bar alla många hattar och hade inga chefer.

Allt eftersom vi har gått framåt har vi börjat anamma att skapa teamstrukturer och processer för att bättre stödja oss och hantera denna tillväxt. Men att skala samarbete med bibehållen hastighet är förstås en konst i sig, och friktionspunkter börjar dyka upp: projekt kommer ofta att stöta på flaskhalsar, och team kommer att blockera varandra. Eftersom det kommer att ta längre tid att släppa funktionerna kommer vi att försöka göra det “korrekt” genom att lägga mer tid på att skapa specifikationerna för det vi har försökt bygga, men naturligtvis, ju större projekt, desto längre tid tar de att leverera.

Vi fastnade i en självförstärkande loop: om det tar månader att bygga något gör det det väldigt svårt att följa och upprepa eftersom vi också kommer att ha andra prioriteringar att göra! Detta fortsatte att förstärka behovet av att göra mer och bättre och fortsatte att skapa mer press för att “göra rätt”.

Förra året insåg vi att vi ville ändra vissa buffertvanor och dynamik för att komma tillbaka till de tidiga laddningsdagarna oftare: ju mer du laddar regelbundet, desto lättare är det att hantera dessa ändringar (eftersom de är mindre). Det känns säkrare även om det vi skickar misslyckas – vilket skapar större psykologisk säkerhet för vårt team. Det var tydligt: ​​Vi ville bli byggare igen och anamma entreprenörskap och en tillbakagångskultur.

Mätvärden som hjälper oss att avgöra byggsituationen

Hur vet vi att vi är i byggläge? Att vi rör oss snabbare, skickar oftare och drar åt feedbackslingor med våra kunder? Några användbara mätvärden för att vägleda oss på denna resa: tidscykelOch den dra begäran hastighetOch den defektfrekvens. Här är lite sammanhang om vad dessa mätvärden betyder och hur vi mäter dem:

tidscykel
Eftersom vi vill minska tiden det tar att komma ut på marknaden vill vi mäta hur snabbt och hur ofta vi levererar värde till våra användare. Cykeltid är för oss tiden mellan det att vi börjar arbeta med en funktion eller förbättring (den första ändringen vi gör i kodbasen för det) till när uttagsbegäran Med ändringar kombineras de och släpps för produktion.

Produktivitetsrekvisition
Pull-förfrågningar är artefakterna som vi skapar som utvecklare för att påbörja processen att integrera nya kodändringar med befintlig kod som körs i produktion.

Vi kan tänka på varje pull-begäran som en arbetsenhet som ger värde (till exempel en ny funktion, buggfix eller annan kodbasoptimering). Det är därför det totala antalet inbyggda pull-förfrågningar (och deras distribution till produktion) kan vara en proxy för värdet som levereras.

defektfrekvens
Att gå snabbare förbättrar naturligtvis ingenting om det innebär att vi skickar fler brister och fel till våra kunder!

Felfrekvensen fungerar som ett kontrollmått för oss, eftersom vi mäter antalet kodändringar vi gör som hanterar buggar som gjorts i tidigare ändringar.

Dynamiken vi tillämpade för att driva denna förändring i tekniskt tänkesätt

Precis som vanor är avgörande för bildandet av vår identitet som individer, är de grundläggande för att utveckla företagets tankesätt och kultur.

När vi vet vad vi vill uppnå och hur vi mäter det, börjar vi tänka på nya dynamik, som, när vi omfamnar dem, hjälper oss att bygga vår identitet som byggare. Dessutom höll vi ögonen öppna för nuvarande vanor som blockerade vår väg och hindrade oss från att ta oss till nästa nivå.

Customer Engineering Days
En viktig komponent för alla byggare är att vara i kontakt med sina kunder: Direkt interaktion med våra kunder är nyckeln för att få insikt i de frågor de ställer, de behov de har och de smärtpunkter du känner i våra system.

Med Customer Engineering Days har vi ett ingenjörsteam som tilldelar en ingenjör per cykel tillsammans med en advokat för en dag för att svara på biljetter i inkorgen och fixa snabba vinster tillsammans. Det här är ett utmärkt tillfälle för ingenjörer att ställa frågor till våra kundförespråkare om våra kunder, funktioner och produkter, och för förespråkare att dela sina erfarenheter och ge kunderna några fantastiska idéer!

Ta bort blockerande begäranden om uttag så mycket som möjligt
När vi anammar en kultur att röra oss snabbare, var en av de första sakerna som fångade mitt öga granskningsprocessen för att införliva ändringar i produktionen: vissa team kommer att ha en regel på plats som kräver att en annan utvecklare granskar sin kod innan de direkt driver förändringen. Branschstandarder och forskning har visat överraskande resultat: Godkännandeprocesser för kodändringar är inte relaterade till mjukvaruleveransprestanda.

Vi vill ta bort gateway-tjänsten för att göra ändringar, öka ägandet och göra det möjligt för människor att hålla sig i flödet, så team börjar gå från standard till öppna pull-förfrågningar och väntar på godkännande och använder en hybridmetod som kallas “ship/offer/ fråga”:

  • båt Det betyder bara! Du behöver inte begära en recension, bara gör ändringen och publicera den i produktion.
  • Displayer Det är bra för att få asynkron feedback, eller dela några nya mönster och lärdomar med teamet, men vänta inte på godkännande innan du skickar till produktion.
  • fråga Detta är den traditionella metoden där kodgranskning krävs innan sammanslagning och leverans till produktion.

Att förklara att det finns olika alternativ och tillvägagångssätt för olika situationer innebär att team kan veta vilken balans de ska hitta, och veta om de är i ett “frågeläge” mycket när de kan driva mer mot “frakt” eller “presentera”.

arbeta mindre
Naturligtvis, om vi bara fokuserar på tidigare praxis, kommer det att kännas som att vi ber teamen att göra mer och snabbare arbete. Dessa mål och metoder är till för att vi ska utmana och förbättra vårt sätt att arbeta, inte hur mycket vi arbetar!

En av nyckelkomponenterna för att säkerställa detta, och en stor bidragsgivare till att bli ett högpresterande team, är arbeta mindre: Om vi ​​bryter ner vårt arbete i funktioner som tillåter snabb utveckling snarare än större, mer komplexa projekt som släpps sällan.

Därför använder ingenjörsteam användningen av funktionsvängningar (även kallat funktionsbyte) som ett sätt att rulla ut nya funktioner som fortfarande är under utveckling till produktion utan att negativt påverka användarupplevelsen. Detta eliminerar stora versioner med många ändringar, istället kan vi släppa nya funktioner till våra användare när vi redan har testat dem i produktion.

Att arbeta i mindre omgångar genererar större psykologisk säkerhet för våra ingenjörer, eftersom risken för att implementera brådskande förändringar som påverkar alla minskar dramatiskt.

Ingenjörschefer vänder sig också till byggare
Medan rollen som ingenjörsdirektören i de olika teamen främst har fokuserat på att leda människor, ingenjörens karriärtillväxt och samordna arbetssätt, är deras huvudansvar att se till att våra team levererar värde genom att bygga vår produkt och våra team i en sätt som passar både våra produkter och våra tekniska mål.

Så för att verkligen kunna köra med dessa byggares tankesätt måste våra ingenjörschefer också bli byggare! Vi har omdefinierat rollen som ingenjörsdirektör och siktar nu på att de ska spendera minst 25 % av sin tid praktiskt i teamet. Praktisk träning kan ta många former, till exempel:

  • Dyk in i dataanalys för att lansera en ny funktion.
  • Arbeta med icke-kritiska uppgifter.
  • QA’ing av nya funktioner.
  • Hantera kunder.

Detta ger dem sammanhang och bättre insikter i de tekniska beslut och avvägningar som deras team står inför och skapar en delad känsla av ägarskap i hela teamet eftersom vi alla bidrar på vårt eget sätt för att släppa ofta.

Resultaten: Har vi anammat ett byggtänkande?

Vi började på denna tankeförändringsresa för 9 månader sedan och det har varit en fantastisk väg till anpassning mellan team: antalet funktioner och förbättringar som vi har levererat under de senaste månaderna är en återspegling av alla dessa förändringar. Vi frågar oss hela tiden “Hur kan vi skicka nästa sak tidigare och med högre kvalitet?”. vi Känna Det sker en förändring i motivation och energi.
Om vi ​​nu går tillbaka till mätvärdena jag delade tidigare i det här inlägget kan vi se att:

  • Cykeltiden har minskat dramatiskt: från ett genomsnitt på 94,8 timmar 2021 till 55 timmar 2022 hittills.
  • Trafiken ökade i PR: 4 155 förfrågningar om återkallelse publicerades 2021 jämfört med 3 687 förfrågningar publicerade 2022 hittills (1 816 fler förfrågningar om återkallelse än H2 2021!).
  • Antalet fel minskade: från 18 procent av tiden är defekter åtgärdade 2021 till 16 procent 2022 hittills.

Detta innebär att ingenjörsteamet faktiskt släpper snabbare och oftare och att kvaliteten inte stör leveranshastigheten.

Det finns några fantastiska tekniska projekt i pipelinen som kommer att få fart på hela ingenjörsteamet under andra halvåret, så vi har precis börjat! Finns det några vanor som ditt team har som har hjälpt dem att öka leveranshastigheten och komma närmare dina kunder? När vi fortsätter på den här vägen att bli byggare, är jag glad över att fortsätta dela med oss ​​av vad vi har lärt oss och framsteg på vägen.

Kontakta mig gärna på Twitter på Tweet bädda in För att dela med dig av dina erfarenheter!

Leave a Reply

Your email address will not be published.