Fem sätt att krascha projektet
Jimmy Nilsson.
Jimmy Nilsson är en av grundarna av konsultbolaget Factor10 och har 26 år bakom sig som utvecklare. Han har arbetat inom många olika teknikområden och intresserat sig för olika arbetssätt som testdriven utveckling och domändriven design. Han har främst utvecklat verksamhetsnära system inom till exempel bank- och telekomindustrierna och i statliga verk.
Missa inte vår sajt om systemutveckling!
Under sin karriär har Jimmy Nilsson stött på fem säkra sätt att misslyckas med utvecklingsprojekt:
1. Utveckla ett enda heltäckande system
Stora monolitiska system är fortfarande normen, trots att människans naturliga sätt att angripa stora problem är att bryta ner dem i mindre och hanterbara delar.
– Jag tror att det handlar om vanans makt, säger Jimmy Nilsson.
En förklaring finns i Conways lag som formulerades 1968: ”Organisationer som skapar system är begränsade till att skapa designer som är kopior av strukturerna för kommunikation inom organisationerna”. Organisationerna måste förändras för att systemen ska kunna förändras.
2. Maximera antalet projektdeltagare
Det finns en inneboende tro på att det bästa sättet att angripa ett problem är att öka antalet människor som arbetar med att lösa det. Men i utvecklingssammanhang leder ett ökat antal projektdeltagare ofta till problem, till exempel med kommunikationen inom projektgruppen.
– Att öka antalet personer är jättebra om man ska gräva ett dike för hand. Men allt är inte diken. I ett utvecklingsprojekt måste man studera uppgiften innan man tar itu med den.
Jimmy Nilsson liknar en duktig utvecklare vid en grävskopa. En nyckelperson kan alltså motsvara ett stort antal andra personer.
3. Hyr in de billigaste utvecklarna
Det är naturligtvis viktigt att hålla kostnader nere, men att prioritera lågt pris per utvecklare är att bara mäta kostnader i en dimension. Risken är att brist på kompetens blir dyr i längden eftersom lösningarna som skapas blir undermåliga.
– Man måste mäta utfall per person. Problemet är att det är svårt att bedöma personers kompetens. Den som bedömer måste själv ha kompetens för att göra det.
Ett tips är att prova nya sätt att bedöma utvecklares kompetens i mindre projekt.
Jimmy Nilssons liknelse i det här sammanhanget är om du behöver göra en hjärnoperation. Skulle du anlita den allra billigaste kirurgen då?
4. Tänk ut allt i förväg – i detalj
Trenden i dag går från vattenfallsprojekt med detaljerade kravspecifikationer i början av projekten, till agila projekt med möjligheter att ändra kraven. Men vattenfallsprojekten är fortfarande normen. Och det leder till problem.
Det går helt enkelt inte att förstå alla aspekter av projekt tidigt. Lägg till det att verkligheten runt det system som utvecklas hinner ändras under projektets gång, med följden att det utvecklade systemet fungerar dåligt. Antagandena som var korrekta tidigt i projektet kan mycket väl vara inkorrekta när projektet avslutas. Det är tvunget att revidera kraven under ett projekts gång.
Det finns saker som är bra att besluta tidigt, exempelvis övergripande mål.
– Det är även bra att utforma protokoll som alla inblandade ska förhålla sig till tidigt i ett projekt.
5. Låt projektet vara i fred
Om ett projekt lever sitt eget liv, utan insyn och medverkan från kunder, beställare, framtida användare och högsta ledningen ökar risken för att en urspårning inte upptäcks. Och tvärtom, om ”utomstående” är inblandade ökar chansen för ett lyckat projekt.
Jimmy Nilssons erfarenheter är entydiga:
– Om kunden är jätteengagerad blir det alltid bra.
Hur externa intressenter engagerar sig i ett projekt är en fråga om hur företagskulturen ser ut på det företag där projektet drivs. Om det saknas traditioner för engagemang krävs en förändring av företagskulturen för att skapa engagemanget.
