"Det kører" er gulvet, ikke målet. Et projekt, der lanceres til tiden, men som ingen bruger, eller som virker i dag og pagerer teamet hver nat, er ikke en succes. Som teknisk leder definerer du, hvad succes betyder på forhånd, med interessenter, så teamet bygger mod resultater frem for bare mod "færdig".
Dimensionerne af succes
- Bruger- og forretningsresultater — det virkelige punkt. Adoption, det KPI, det skulle flytte, målbar påvirkning. En funktion med nul brugere er en fiasko uanset hvor rent koden er.
- Kvalitet — pålidelighed, vedligeholdelse, sikkerhed. Holder det under belastning, kan teamet sikkert ændre det, er det fri for åbenlyse sårbarheder?
- Levering — landede det på et rimeligt tidsskema og omfang, uden dødsmarch eller stiltiende omfangsudskæring?
- Teamets sundhed — kom teamet ud stærkere og bæredygtigt, eller udmattet og fornærmet?
- Driftbarhed — kan det køres, observeres og debugges i produktion uden heroik?
Definer kriterier før du bygger
Bliv enig om succesmålinger med interessenter før kodning. "Vi betragter dette som en succes, hvis adoption når X og p99-latens forbliver under Y" gøre et vagt mål til noget, du faktisk kan måle, og forhindrer diskussionen efter lancering om, hvorvidt det virkede.
Hvorfor det betyder noget
Teams, der måler succes kun som "leveret" optimerer for det forkerte: de fejrer lanceringer, der stiltiende fejler i produktion eller hos brugere. En teknisk leder, der definerer succes på tværs af alle disse dimensioner styrer teamet mod arbejde, der virkelig betyder noget, fanger problemer, mens de stadig er billige at reparere, og kan vise ledelsen konkret bevis for påvirkning i stedet for bare aktivitet.