I min förra bloggpost skrev jag om osynliga problem inom system och systemutveckling samt vilka effekter dessa kan få över tid. Denna gången tänkte jag skriva om ett annat problem jag ofta stött på: personberoenden.

Ohälsosamma personberoenden orsakar flaskhalsar och sänker leveranstakten hos utvecklingsteam, de får leveranser att misslyckas, företag att gå i konkurs, och de leder till utbrändhet bland personalen. Trots detta är det otroligt vanligt att företag och leveranser sätter sig i beroendeställning till nyckelpersonal.

Systemutveckling ett kunskapsyrke

För att förtydliga varför personberoenden är ett sånt problem just i IT-branschen så börjar jag med att skriva lite om systemutveckling.

System existerar för att, på ett automatiserat sätt, lösa problem av olika slag. Att bygga system är ett utforskande arbete där utvecklare, tillsammans med intressenter, försöker hitta de bästa lösningarna på problemen utifrån en rad kriterier som till exempel kostnad, förvaltningsbarhet, användarvänlighet, automatiseringsgrad och time-to-market.

Den bästa lösningen är nästan aldrig känd i förväg utan måste tas fram genom ett samarbete mellan domänexperter och utvecklingsexperter. Detta arbete kräver ofta att teamet provtrycker idéer genom att bygga något litet, “känna” på det, och sedan anpassa det efter de lärdomar som upptäcks (så kallat iterativt eller “agilt” arbete). Systemutveckling är alltså ett kunskapsyrke där man genom experiment, analys, tankekraft och diskussion samlar på sig kunskap som man sedan använder för att lösa problem.

Personberoenden är farliga på grund av det faktum att systemutveckling handlar om kunskap och förståelse: försvinner personen så försvinner förståelsen. Det kan vara extremt svårt att bygga upp den förståelsen igen när det inte finns någon som kan förklara hur saker hänger ihop och varför vissa saker gjorts på vissa sätt.

Risk versus Reward

En vanlig orsak till att personberoenden uppstår är ett fokus på kortsiktiga vinster framför långsiktig hållbarhet. Vinsterna kan vara ekonomiska men ibland även tidsbesparande eller känslomässiga (typ “jag pratar hellre med den här personen än den här personen”):

• Det är “mer effektivt” att låta den som bäst kan en viss kodbas/system/domän/osv utföra allt arbete där, istället för att låta någon annan göra det (som över tid kunde lära sig att bli lika duktig).
• Det är “lättare” att låta dialog med ett leveransteam gå via den i teamet som bäst förstår verksamheten (t.ex. en produktägare eller “lead developer”). Det blir färre “dumma frågor” och personen i fråga kan, tillsammans med verksamheten, snabbare hitta en gemensam förståelse. Att resten av teamet lämnas “in the dark” ses inte som ett problem om man betraktar dem som “utförare” istället för “tänkare”.
• Det är “billigare” att lägga mer ansvar på ett team istället för att anställa fler (läs på om kognitiv belastning: att ge teamet mer ansvar än de mäktar med leder lätt till att teammedlemmarna delar upp ansvarsområdena, och kunskapen om dem, mellan sig).

De kortsiktiga vinsterna går inte att bortse från: man kan spara både tid och pengar genom att strunta i personberoenden och fortsätta på samma spår, istället för att stanna upp och jobba med kompetensspridning. Men är det värt risken? Ni som sitter i beslutsfattande position behöver fundera över den frågan. Hur länge dröjer det innan nyckelpersonerna blir flaskhalsar som bromsar upp, istället för att effektivisera, genom att andra tvingas vänta på dem? Vad skulle hända om en av dem plötsligt försvann? Klarar ni av att ett system slutar fungera under en längre tid när ingen vet hur man lagar det? Och hur stor är risken att någon av dessa saker inträffar?

Vad är er bussfaktor?

Bussfaktorn är ett (skämtsamt) sätt att mäta personberoenden. Den definieras som det minsta antalet personer som plötsligt kan försvinna (bli påkörda av bussen, träffade av blixten, osv.) innan en leverans stannar upp på grund av kompetensbrist. Det lägsta (och sämsta) värdet på skalan är en bussfaktor av 1, som innebär att det finns en person som teamet/leveransen/företaget inte klarar sig utan, förmodligen någon som sitter på kunskap som ingen annan har. Skulle den personen försvinna gör den resulterande kompetensbristen att leveransen stannar upp eller misslyckas.

Vad är er bussfaktor? Under covid-pandemin såg jag flera leveranser där bussfaktorn var 1. Oftast var det någon person i ett team, exempelvis en arkitekt eller lead developer, som satt på domänkunskap som ingen annan hade. Istället för att dela med sig av kunskapen så hade denna person gjort det till sin uppgift att dirigera de andra teammedlemmarna i vad de skulle göra. De teammedlemmarna slutade, i sin tur, att tänka efter och gjorde istället bara som de blev tillsagda, något som ytterliggare ökade beroendet till “dirigenten”. Detta skedde alltså MITT I EN PANDEMI. Det kunde räcka med att en nyckelperson blev hostad på i mataffären så kunde en hel leverans, ibland värd miljoner, gå i stöpet. När man tar ett steg tillbaka och beskriver det på det här sättet så håller de flesta med om att det inte är särskilt smart att riskera en hel leverans (eller hela företaget) på något som så lätt kan hända.

Att vara en nyckelperson

Att vara en nyckelperson kan kännas roligt. Du bidrar till din arbetsgivares framtid, får ta stort ansvar, och känner dig behövd. Du har bra belägg till löneförhandlingar och kanske till och med kan starta eget för att fortsätta din anställning som konsult (med ännu bättre betalt).

Det finns dock baksidor: nyckelpersoner blir ofta flaskhalsar. Så mycket information/frågor/beslut måste gå via dem att de inte hinner med. De bromsar upp utvecklingen och pushas samtidigt till att arbeta övertid för att hinna utföra sina arbetsuppgifter. Kombinera känslan av otillräcklighet med vetskapen om att allt vilar på deras axlar och vi har ett recept till utbrändhet för några av de viktigaste personerna på företaget. Om inte det så har vi ett recept till tidspressade och ogenomtänkta lösningar.

Nyrekrytering och konsulter för att fylla kompetensluckor

Kan vi inte fylla kompetensluckorna med rekrytering och konsulter? Svar: nej. De tekniska luckorna kan fyllas genom att rekryta och/eller ta in konsulter med samma tekniska erfarenhet, men eftersom ert företag och era system oftast är någorlunda unika så är de domänmässiga och luckorna svåra att snabbt täppa igen, likaså den historiska kunskapen om varför saker är byggda som de är. När nyckelkompetensen väl försvunnit så sitter ni illa till. Det är säkrare att proaktivt arbeta bort personberoenden och försöka bibehålla en nöjd personal.