Money Talks: Hvordan man taler forretning som ingeniør

Da jeg fik overdraget nøglerne til ingeniørorganisationen hos min tidligere virksomhed, gjorde jeg, hvad jeg vidste: Jeg sprang først i hovedet og fokuserede på arkitekturen og koden. Og jeg troede, at jeg gjorde et godt stykke arbejde. Vi har skaleret platformen til at håndtere en massiv tilstrømning af trafik, leverede funktioner (for det meste) til tiden og havde flere ekstremt tilfredse virksomhedskunder. Men der var altid en følelse af forkert justering og mistillid i vores udøvende møder. Vi kæmpede for at blive enige om strategi og prioritering. Kravene var tvetydige og kunne ikke afklares. Leveringsforventningerne blev holdt skjult og kunstigt polstret uden samarbejde. Vi havde succes, men noget forhindrede os i at blive en veloljet maskine.

Det viser sig, at der var en hel anden halvdel af mit job, som jeg havde forsømt.

Et

Hvad jeg ikke vidste på det tidspunkt var, at mens vi alle talte engelsk, talte vi virkelig forskellige sprog. Forretningsfolkene vidste alle, at de sandsynligvis skulle stole på mig, fordi mit team og jeg havde bevist, at vi kunne sende funktioner og skalere systemet. Men der var mange tomme blik, når vi talte om systemarkitektur og historiepunkter. De forstod aldrig rigtig og værdsatte, hvad ingeniørarbejde gjorde, og den utrolige dygtighed og tanke, der gik ind i det. Ligeledes fik ingeniører aldrig rigtig forståelse af, hvordan det, de bygger, bidrog til væksten i virksomheden. Der var en stor afbrydelse, og det fremkaldte stammet ”business vs engineering”, som jeg har set for mange dysfunktionelle virksomheder.

Vores samtaler lignede Carol med den spidshårede chef.

Tricket, som jeg har lært siden da, er at finde fælles grund. Så hvad er den samlede faktor på tværs af alle forretningsenheder? Værdi. En salgsdirektør kan let forstå og værdsætte en teknik, hvis den værdi, den giver, er klar og håndgribelig. Den virkelige udfordring er: hvordan bruger man data til at forudsige og måle værdien af ​​en ny funktion? En fejlrettelse? Eller hvad med en refactor eller en infrastrukturopgradering?

Boring til værdi

Med den rette forsknings- og tankeproces kan du vende tilbage til en ret nøjagtig værdi for næsten ethvert ingeniørinitiativ; dette giver dig mulighed for at tale om endda dybe back-end-udviklinger med hensyn til penge, og gør det meget lettere at kommunikere med den ikke-tekniske side af huset.

Værdien af ​​funktioner er relativt let at kvantificere, da funktioner typisk har en direkte indflydelse på dine kunder og dermed din indtægt:

  • Hvor mange flere kunder vurderes det at medbringe? → Hvad er den gennemsnitlige indtægt pr. Kunde?
  • Hvor meget længere tid bruger kunderne på applikationen? → Hvor meget øges sandsynligheden for udgifter som en tidsfaktor på webstedet?
  • Hvilken effekt vil det have på NPS-score? → Hvordan påvirker den gennemsnitlige NPS-score vores indtægter?

For fejlrettelser og refaktorer er værdien sværere at kvantificere. Der er normalt mere end to grader af adskillelse mellem opgaven og værdien. Jeg kan godt lide at tænke på det med hensyn til mulighedsomkostninger:

  • Hvad er prisen for ikke at rette fejlen med det samme? → Hvor mange kunder kan ikke bruge webstedet? → Hvor mange indtægter mister vi?
  • Hvad sker der, hvis vi ikke refaktorerer betalingssystemet nu? → Hvor mange køb kan vi ikke behandle, hvis betalingssystemet går ned i omfang?

SRE / devops er det sværeste, men stadig gennemførlige:

  • Hvor meget vil byggetiden reduceres? → Hvor meget mere vil ingeniører kunne producere i en given sprint? → Hvor mange flere funktioner kan vi opbygge dette kvartal → Hvor meget indtægter vil den ekstra funktionskapacitet medbringe?
  • Hvad sker der, hvis vi ikke har flere AZ-databaserefundance? → Hvad er sandsynligheden for en AZ-fiasko? → Hvor mange indtægter mister vi, hvis webstedet er nede i en time, mens vi spinder en database op i et nyt AZ?

Som du kan fortælle, kræver det meget data at gøre dette med reelle tal. Og det er svært at sikre, at du har de rigtige data, tilgængelige, strukturerede på en anvendelig måde, i det øjeblik, du har brug for at tage en beslutning. Størstedelen af ​​værdien fra denne praksis kommer imidlertid fra tankeprocessen snarere end de faktiske tal bag den. Din COO forstår muligvis ikke kompleksiteten ved belastningstest, men vil helt sikkert forstå, at nedetid på grund af skaleringsproblemer er dyre og forebygges. En kontobestyrer forstår muligvis ikke en flytning fra MySQL til MongoDB, men vil helt sikkert forstå fordelen ved at være i stand til at ombordstille nye virksomhedskunder hurtigere med en mere fleksibel datamodel.

Tangentielle fordele

Flittigt at følge denne proces hjælper ikke kun med kommunikation og tilpasning på tværs af virksomheden, men gør naturligvis prioritering lettere og hjælper ingeniører med at holde sig selv og hinanden ansvarlige.

Prioriteringen af ​​et givet initiativ kan nu blive en funktion af dets forventede værdi i forhold til kompleksiteten af ​​udvikling, i stedet for at blive drevet af magefølelse, håndvågning og ekspertise i branchen. Det er således meget lettere at forklare, hvorfor du skal refaktorere godkendelsessystemet, før du bygger Salesforce-integrationen. Folk er måske uenige, men de er uenige med værdien, ikke med din professionelle mening. Dette er vigtigt, da det forhindrer, at tingene bliver personlige.

Smager som crap. Men undertiden får arbejdet gjort.

Det er også meget nemmere at undgå fordomme i beslutningsprocessen. Jeg har været der: det er svært at holde sig væk fra refactoring af den spaghettikodetjeneste, du skrev for fire år siden, som stadig hjemsøger dig til i dag. Men hvis du gør din research og sætter en værdi på refaktoren, kan du pludselig have det bedre med at skubbe den ud indtil næste år. Hvis det fungerer og er dækket af din overvågningsinfrastruktur, er værdien af ​​en refaktor sandsynligvis ikke så høj, før du har en værdifuld funktion på de bøger, der kræver det.

Endelig hjælper ingeniørerne med at forstå, hvor vigtigt det, de gør, for virksomhedens mål for at gøre værdien af ​​et teknisk initiativ klart for alle. Selv de bedste ingeniører kan motiveres til at udføre en typisk kedelig opgave (som at få den forbandede frontend til at arbejde på IE 10), hvis de forstår og er enige om fordelen. Et begejstret teknikerteam er en højtydende.

I praksis

Vi har for nylig fuldt ud omfattet denne metode på Fincura og har set meget positive resultater indtil videre. Vores produktledere (til funktioner og bugs) og arkitekter (til infrastruktur og systemforbedringer) gør deres research og estimerer den relative forretningsværdi (ved hjælp af en skala fra 1 til 5) af et initiativ. Ingeniører stikker huller i værdiestimatet og anvender deres eget skøn over udviklingskompleksitet ved hjælp af historiepunkter. Og så samarbejder vi for at opdele initiativet i forsendelige komponenter, optimere til at levere mest forretningsværdi med mindst udviklingskompleksitet. Der er selvfølgelig altid afhængigheder og milepæl-datoer, der ikke kan bevæge sig, men denne praksis har lettet en følelse af gensidig tillid og ansvarlighed mellem forretning og teknik, som jeg aldrig har set før hos en softwarevirksomhed. Alle er prioriterede, og vi kan undgå dyre distraktioner, når vi arbejder mod vores høje mål.

I fremtidige indlæg vil jeg undersøge mere om, hvordan vi bruger data til at tage beslutninger og få tilpasning, da vi stræber efter at være den sagnomsuste velolierede maskine.