Utveckling och förvaltning

När ett bolag når en viss storlek kommer det till en punkt när man konstant har ett antal heltidskonsulter inom området systemutveckling. Det finns ingen fast formel för att räkna ut när detta händer i din organisation, det ser olika ut i olika branscher och olika för olika företag inom samma bransch. Ofta inträffar detta lite oväntat på grund av att organisationer i tillväxtfaser inte är förberedda på övergången från utvecklingsfasen till förvaltningsfasen. Detta är egentligen inget fel, ett företag som växer fort har inte processer på plats för att stödja en organisation som är större än den är, det finns liksom ingen anledning till detta innan tillväxten har skett.

När det väl har skett att man alltid har ett antal systemutvecklare som jobbar med ett eller flera system finns det lite olika skolor om hur man bör hantera detta. En variant är att hantera all utveckling som olika stora projekt och en annan vanlig variant är att gå in i en förvaltningsfas av systemen. Båda dessa varianter har många fördelar och en del nackdelar.
Att hantera allting som projekt är väldigt lätthanterligt om målen och kraven är lite otydliga, men blir snabbt problematiskt när de flesta uppgifter är för små för att hanteras som projekt och inte logiskt kan grupperas i större leveranser.
Förvaltningsidén har många fördelar gentemot projektapproachen från ett administrativt och budgetmässigt perspektiv, men kan lätt bli kostsamt då man har en fast kostnadskostym per system oavsett hur prioriterat systemet är över tid.
Ett annat problem med förvaltningsmodellen är att de flesta utvecklare föredrar att utveckla, inte att förvalta. Titeln är systemutvecklare, inte systemförvaltare. Jag är fullt medveten om att det finns folk med titeln systemförvaltare och de kan vara fullt nöjda med detta, men fråga vilken programmerare som helst om de helst jobbar med utveckling eller förvaltning så kan jag garantera att ni kommer att få en övervägande majoritet som föredrar utveckling.
En enkel lösning skulle kunna vara att bara byta titel på alla systemförvaltare till systemutvecklare, men sannolikt löser det inget problem.

Ett annat förslag som jag förordar är att man bestämmer sig för hur mycket pengar man tycker sig ha råd och lust att lägga på all sin systemutveckling och systemförvaltning i genomsnitt per månad och sedan räknar ut hur mycket man hinner med att göra varje månad. På detta sätt får alla systemutvecklare ett varierande och förhoppningsvis roligare jobb och det blir väldigt enkelt att budgetera med hur mycket man behöver lägga centralt på systemutvecklingskompetens. Detta kräver dock lite förändrade processer, där samtliga system tävlar om samma resurser. För att lyckas med detta krävs bättre planering inför varje sprint/månad/cykel, men detta borde borga för en centralt effektivare prioritering av resurserna.
Målet med denna förändring är att öka engagemanget och lojaliteten hos utvecklarna genom att ge dem variation i sitt jobb samtidigt som detta också ger fördelen att de får större förståelse för hela verksamheten. Denna förståelse leder i längden till att man ökar kvaliteten hos det som utvecklas och minskar risken för missförstånd i processen.

Scrum och andra agila metoder är allmänt erkända som de bästa sätten att driva utveckling på. En av grundtankarna i Scrum är att alla deltagare i ett team skall kunna utföra samtliga uppgifter. Även om jag personligen inte tycker den punkten är den viktigaste att följa i Scrum tycker jag ändå att tanken bakom den är bra. Det ger ett flexibelt team där uppgifter kan utföras efter deras inbördes prioritering snarare än efter resursers tillgänglighet. Denna grundtanke borde även gå att applicera i ett större sammanhang, enligt det ovan och i de fallen tillåta en bättre prioritering av utvecklingsuppgifter.

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *