Utkontraktering till s.k. låglöneländer är en allt mer populär teknik att försöka spara pengar på systemutvecklingsprojekt, speciellt i mörkare ekonomiska tider. Det lobbas oerhört hårt i IT-branschmedia för att våra företag "ska komma igång med outsourcing" här är några exempel : Outsourcing ökar i Sverige, Hetaste länderna för offshoring 2009, och Så lyckas du med outsourcing, Grundidén bygger på tanken att systemutveckling skulle vara en tjänst som alla andra, dvs. kan göras av vilka utvecklare som helst och kan därför förläggas var som helst i världen, företrädesvis i länder med betydligt lägre löner än i Sverige.
Jag tror att det här är ett stort feltänk och jag kan, utan att sticka ut hakan speciellt långt, förutspå att de flesta av de här projekten blir dyra eller misslyckade eller båda. De kommer att lida av svag kvalitet, mycket omarbete och långa ledtider. Det finns ingen brist på misslyckanden i detta avseende även om företagen inte direkt pratar om dem.
Den första spiken i utkontrakteringskistan är att systemutvecklare inte är utbytbara. Inte alls faktiskt. Många undersökningar har gjorts av detta, blogg: "10x Software Development", Steve McConnell, har referenser till många studier) och skillnaden mellan en duktig, erfaren utvecklare kontra en nybörjare brukar landa på en faktor mellan 5 och 35. Notera att detta inte är angivet i procent. Det är alltså inte ovanligt att en systemutvecklare alltså är 10 gånger(!) mer produktiv än en annan fast lönen kanske skiljer säg 50 %. Jag säger inte att indier är sämre programmerare än svenskar, för det stämmer inte. Det jag säger är att det kan vara svårt för en lekman att se skillnaden även på nära håll. Om avståndet till era systemutvecklare är 500 mil har du helt försatt din chans att se skillnaden. Många stora outsourceingbolag slänger in stjärnorna lokalt, till att börja med, för att sedan ta in massorna när det är långt bort. Är det med den kontrollen du vill spendera tiomiljoner budgeten för ditt nästa projekt?
Den andra spiken i kistan är den som lättrörliga metoder obönhörligen har avslöjat: För ett bra resultat krävs ett nära samarbete och kommunikation mellan de som förstår behoven och de som förstår lösningen. Kunden behöver teamet för att lära känna de tekniska möjligheterna och begränsningarna och teamet behöver lära sig kundens och användarnas behov för att göra ett bra jobb. Inte minst gäller det så kallade verksamhetsregler som ofta IT-folk kan bättre än verksamheten. Det som gör det så svårt är att vi har olika bakgrund, olika värderingar och olika språk. De här mentala avståndens dilemma är ett svårt problem att lösa även om man sitter i samma rum. Om avståndet, geografiskt och kulturellt, mellan kund och team är avskräckande vad tror du då att chanserna är för att lösningen kan möta upp mot dina verkliga behov?
Du riskerar alltså att dina verkliga behov förblir oupptäckta, dina krav missförstådda, få system utan inre kvalitet utförda av personer vars kompetens du inte har kontroll på. Ajj!
Det här är förstås inte nya saker. Alla som har famlat inom utkontraktering känner till eller anar det här. I grund och botten handlar det om kommunikationsproblem. I takt med att de helt utkontrakterade projekten mot färdig specifikation har fallit lika hårt som svenska utförsåkare har nya lösningar provats. De kallas "duo shore", "blended offer" och liknande, men grundtanken är densamma: Att kombinera lokal, styrande kompetens med distribuerad, styrd dito och därmed försöka öka överföringen av information mellan de två platserna.
Kombinerade modeller har en bättre chans att lyckas än tidigare försök därför att man tar kommunikationsproblemet på allvar. Men det finns vissa problem. Det första som slår mig är att det finns ett lätt obehagligt drag av västerländsk överlägsenhet där de, helt beroende, låglönearbetarna sätts på det mindre ansvarsfulla arbetet att "knacka kod" mot specifikation. Men även utan att se det på det sättet så är det ett fruktansvärt ineffektivt sätt att arbeta. Attityden som kan anas bakom det här är att programmering mest skulle handla om att skriva tecken på ett tangentbord efter en detaljerad instruktion. Ju fortare vi kan skriva desto fortare går det. Frederick Taylor måste le i sin grav, för det här är nämligen traditionell (det är ett annat ord för ålderdomlig) taylorism at its finest! Att tro att världen är fint utlagd och väldefinierad och om vi bara lägger ut allt på en lång rad och specialiserar oss på varje moment så blir allt så bra så.
Tyvärr fungerar det inte så. Att programmering är faktiskt till stor del ett designarbete, från användarinteraktion till databastabeller, tas inte hänsyn till. Att systemutveckling måste innebära ett ständigt lärande där alla nivåer av design påverkar varandra på ett intrikat sätt vet de inte. Att systemutvecklingen, med sina många variabler, troligen är något av det mest komplicerade som arten människan har försökt sig på måste vara helt okänt bland de höga herrarna som ansvarar för de här affärerna. Det handlar inte om att skriva fort utan om att tänka fort.
Så här vackert uttrycker sig Donald Knuth om programmering:
"... programming can give us both intellectual and emotional satisfaction, because it is a real achievement to master complexity and to establish a system of consistent rules." Computer Programming as an Art" Donald Knuth,