"Vi behöver fler utvecklare – de vi har är inte bra…"

Så låter det ibland när ett utvecklingsprojekt kört fast. Nästan alltid är det fel diagnos. Johan Hogsved om vad vi brukar hitta när vi går in i ett projekt som tappat fart – och varför vi inte föreslår fler utvecklare.

Rubriken är spetsad. Men på ett plan är det precis vad en frustrerad chef eller projektledare känner när IT-projektet, produktutvecklingen eller förvaltningen inte kommer framåt och inte ger de resultat man både lovat själv och blivit lovad.

Nästan alltid är det fel diagnos. Oftast brinner alla i projektet för att göra ett bra jobb – men det hakar upp sig.

Ibland hör en sådan ledare av sig till oss för att få råd. Jag tänkte berätta hur vi tänker då, och vad vi brukar se.

Varifrån mönstren kommer

Jag har haft ett tiotal interimsuppdrag – som VD, vice VD och produktägare – i allt från medtech och logistik-IT till ett joint venture som utvecklade och driftade lösningar som används av miljoner användare i Sverige och Finland. Flera av dem har handlat om precis det här: att ta över ett utvecklingsprojekt som stannat och få det på fötter igen.

Det jag lärt mig är att projekt sällan havererar av en dramatisk orsak. De tappar fart av flera små, som var för sig är hanterbara men tillsammans blir tunga. Här är de jag ser oftast.

Vad vi brukar hitta

Roller som ingen bär. En medelstor produkt eller tjänst behöver många olika specialistkompetenser över sin livscykel – affärsdesign, UX, arkitektur, säkerhet, test, drift, förvaltning. Ingen organisation kan ha en heltidstjänst för var och en. Så några roller lämnas obesatta, och någon annan tar dem inofficiellt, ofta utan mandat och utan tid.

Krav som kastas över muren. Verksamheten formulerar ett önskemål, lämnar över det och förväntar sig att något ska hända. Utvecklingsteamet tolkar efter bästa förmåga. Ingen upptäcker glappet förrän funktionen är byggd – och då är frågan fortfarande obesvarad: vad ville kunderna egentligen ha?

Olika ordförråd. Även när man pratar direkt med varandra. En säljare, en supporttekniker, en systemarkitekt och en devops-ingenjör beskriver samma sak på fyra olika sätt. Kommunikationen sker – men budskapet går ibland förlorat på vägen.

Skygglappar mellan interna och externa. "Not my problem" uppstår sällan av illvilja. Det uppstår när ingen fått ett uttalat ansvar för det som ligger emellan det egna teamet och konsulterna.

Arkitektur som speglar organisationen. Conways lag säger att systemdesignen kommer att avspegla hur organisationen kommunicerar. Med ett internt team och konsulter från flera håll syns sömmarna i koden. Det går att se, och det går att åtgärda – men bara om någon tittar på båda sidor samtidigt.

Oklart ägarskap. Vem är tekniskt ansvarig? Vem äger backloggen och prioriterar? Om svaret tar mer än en mening är det ofta där problemet börjar.

Det dyra är inte att dessa saker inträffar. Det dyra är att de blir synliga sent, när en ändring kostar tio gånger mer än den hade gjort i planeringsfasen.

Vad vi inte föreslår

Fler utvecklare. Om leveranstakten har gått ner utan att arbetsmängden har gjort det är kapacitet inte problemet.

En ensam hjälte som räddar situationen. Det är den vanligaste rekommendationen, och den fungerar en tid. Sedan går personen vidare, och kunskapen om varför besluten togs går med. Ni står där igen, ett halvår senare.

Att byta ut allt. En omstart låter renare än den är. I de flesta fall finns det mycket mer att bygga vidare på än vad stämningen i projektet antyder.

Så går vi in

Först en nulägesbild. Vi går igenom affärsplanen, systemarkitekturen, kodbasen, hur teamet faktiskt arbetar och om kunskapen hos användarna når fram till utvecklarna. Den genomgången gör vi tillsammans med er, och vi delar med oss av vad vi ser utan att det kostar något. Behöver ni gå djupare lägger vi upp ett arbete som ni godkänner, och ni får ett skriftligt underlag med vad vi ser och vad vi skulle prioritera – även om ni väljer att gå vidare med någon annan.

Sedan en plan ni känner igen er i. Vad som ska åtgärdas, i vilken ordning, och vad som kan vänta. Vi säger till om vi tycker att ni ska stoppa nyutveckling ett tag för att sanera.

Och ett team som ändrar form. Vi går in med den sammansättning läget kräver just nu – ofta tyngre på arkitektur och produktledning i början, mer på utveckling och automation när riktningen är satt. När ni går över i förvaltning ser teamet annorlunda ut igen. Det är det vi kallar Yoin Advice, och det ingår i alla våra teamleveranser.

Och sedan?

De flesta räddningsuppdrag tar slut när konsulten går hem. På Yoin vill vi att det bara är början på samarbetet.

Hos många av våra kunder blir vår kompetens ett löpande tillskott i teamet. Andra vill ha det mesta av bemanningen inhouse, men kan inte bemanna varje roll med en heltid. Då erbjuder vi våra specialister på mindre avrop eller som Specialist as a Service – solution architect, agil coach, UX-designer eller annan specialistkompetens, i den omfattning som behövs.

Att utveckla, förvalta och sälja en IT-produkt är inte ett sprintlopp. Det är en investering i framtiden, och vi vill vara med på den resan över tid.

Vill ni prata om var ni står?

Berätta hur ert läge ser ut, så bokar vi två timmar. Om vi tror att någon annan passar er bättre säger vi det.

Johan Hogsved, Interim & Affärsutveckling · 0709-792 579 · johan@yoin.tech

Marcus Melberg, Systemarkitekt & CTO · 0702-335 263 · marcus@yoin.tech