Sådan får du succes med outsourcing til Indien
At hyre billige udviklere i Indien er snart lige så almindeligt som at købe billige dåseøl i Tyskland. Men transaktionen er ikke helt lige så enkel. Selvom mange danske virksomheder har brugt indiske udviklere i en årrække, er der stadig grumme eksempler på, at det ikke går som planlagt.
Det fortæller Rasmus Kristiansen, som de sidste otte år har været projektleder på en lang række udviklingsopgaver i teleindustrien, hvor opgaver blev outsourcet til lavtlønslande, først og fremmest Indien. I dag har han startet sit eget firma med navnet 80%, der primært hjælper med outsourcingprojekter.
»Det er nemt at begå fejltagelser med offshore outsourcing, og det er endnu nemmere bare at skyde skylden på outsourcing-partneren, når det går galt,« siger han.
Kræver noget ekstra
Generelt set har han haft gode erfaringer med at få opgaver løst i Indien, men det kræver noget ekstra af dem, der stiller opgaverne.
»Forvent ingenting og specificer alt. Selvom nogle ting virker logiske for os, er det ikke sikkert, at det er logisk, hvis man sidder langt væk. Man glemmer hurtigt, at der er nogle gevaldige kulturelle forskelle,« siger han.
Som eksempel nævner han et projekt, hvor der skulle udvikles et analyseværktøj. Alting kørte fint, lige indtil produktet var afleveret fra de indiske udviklere.
»Det gled i olie, blev leveret til tiden, og alle var glade ? men så opdagede man, at det var udviklet til en anden produktplatform, end det var meningen. Det var der bare ikke nogen, der havde specificeret, for det stod så klart i alle danskernes hoveder, at de tog det for givet,« fortæller Rasmus Kristiansen.
Se bjælken i egne øjne
Det vigtige i sådan en situation er at modstå fristelsen til at sige grimme ting om de indiske udvikleres tankegang, men i stedet vende blikket indad, lyder rådet.
»Outsourcing er et samarbejde. Det er sjældent, at det kun er den ene part, der er skyld i et problem, men alt for ofte mangel på kommunikation,« siger Rasmus Kristiansen.
For at få succes med outsourcing til Indien, er det nødvendigt med først og fremmest en meget klart defineret opgave, er hans erfaring. Inderne griber ikke lige en bold i luften og begynder at improvisere, men gør præcist, som de bliver bedt om, uden at påpege eventuelle problemer.
»Det er ikke fordi, de er dumme, eller ikke kan se det, men de arbejder bedst inden for en klart defineret ramme og bevæger sig i den med skyklapper på. Og så siger de altid ja, også hvis man kommer med noget, som ikke giver mening eller ikke kan lade sig gøre,« siger han.
Outsourcing udstiller din inkompetence
God dokumentation under udviklingen er også en afgørende faktor.
»Hvis der i forvejen ikke er helt styr på dokumentation af systemdesign og kode, så bliver det tifold værre ved outsourcing. Og generelt vil outsourcing udstille et firmas inkompetence de steder, hvor det halter. For eksempel hvis der ikke er en god, stabil informationsstrøm i firmaet. Det vil indiske udviklere mærke meget tydeligt,« siger Rasmus Kristiansen.
Personlig kontakt ansigt-til-ansigt er en god hjælp under samarbejdet. Mindst to fysiske møder om året, anbefaler Rasmus Kristiansen, samtidig med at det er en fordel med en udsendt fra det indiske firma fast stationeret i Danmark til at fungere som mellemmand og lynafleder.
»Det tager brodden af diskussionerne med en personlig kontakt. Når noget går galt, er det en stor fordel, har jeg kunnet se, for tonen bliver mindre hård. Så kan man tale om problemerne, i stedet for bare at sende vrede emails frem og tilbage. Den slags fremmer bestemt ikke produktiviteten,« siger han.
Følg op - hele tiden
Men det vigtigste råd, han kan give, er løbende at følge op på, hvordan opgaven forløber, og hvad udbyttet er. Både for at sikre sig at eventuelle misforståelser bliver taget i opløbet, men også for at vise de indiske udviklere, at der bliver stillet krav og at det er vigtigt med god kode og godt systemdesign.
»Det er ekstremt vigtigt. Jeg har prøvet nogle projekter, hvor der ikke blev fulgt godt nok op. Så kunne man hurtigt se, at koden ikke levede op til kravene om dokumentation, kodestruktur og test. Det er nødvendigt med et fast greb i opgaven, hvis det skal leve op til kravene, og man ønsker at få en sund og læsbar kode tilbage,« siger Rasmus Kristiansen.
Det gælder især, når projekterne vokser sig større, eller der skal pilles ved eksisterende kode.
»Nogle af telecom-projekterne, jeg har været med til, handlede om rigtig store kodebaser, der var fem og ti år gamle. Så er det virkelig vigtigt, at der er en skarp kontrol med, hvad der ryger ind. Ellers er det meget nemt at miste fingerspitzgefühl med, hvordan koden har det,« siger han.
Kommentarer (6)
Hvis man skal have folk med kompetencer til at sikre at opgaven udføres tilfredsstillende, hvorfor så ikke bare sætte dem til at udføre arbejdet? Hvorfor overhovedet outsource?
Jeg har selv fungeret som konsulent for en virksomhed, der valgte at outsource udviklingen af et websystem. Jeg skulle stå for at lave en outline af det ønskede system, samt at tjekke at det der blev udviklet var godt nok. Det endte med jeg brugte mere tid på at fixe deres kode end det ville have taget mig selv at skrive koden.
I mine øjne bør programmører ikke have skyklapper på. De skal i stedet se mulige faldgruber i det foreslåede design og gå i dialog med beslutningstagerne.
-
0 -
0
Programmeringsarbejde er at specificere systemløsningen i enhver detalje. Systemløsningen skitserer, programmeringen specificerer. Maskinen har ingen indføling, og man får det man programmerer og intet andet. Hvis programmøren heller ikke har nogen føling med ens virkelighed, får man et ekstra programmeringsarbejde - nemlig opgaven at specificere systemløsningen i enhver detalje som oplæg til programmeringen. Det kan her anbefales at bruge et programmeringssprog til dette specifikations-arbejde: programmeringssprog har den præcision der skal til for at få fastlagt enhver detalje. Det er også en rigtig god idé at prøve at køre det udviklede programmel mod virkelige data, så man får efterprøvet om beskrivelsen rammer.
Det giver tre mulige rammefortællinger for succes-historier vedrørende Indien:
1) Opgaven er ren konvertering, dvs. fra et programmeringssprog til et andet.
2) Man er bundet til at bruge et programmeringssprog som ikke egner sig til opgaven, og det er derfor nemmere at specificere i en meget formel pseudokode frem for i det valgte programmeringssprog.
3) Der er blevet etableret et samarbejde: Indien har fået indføling med ens virkelighed, og man behøver ikke længere at specificere alt. Man har betalt etableringsomkostningerne.
Punkt 1 er oplagt.
Indiens relative succes kan pege på punkt 2 må være af et vist omfang: At man i dag ofte bruge programmeringssprog som ikke egner sig til opgaverne. Konkret kunne der være tale om at objektorienterede sprog ikke egner sig til specifikation af 'bussiness-rules'. Jeg ved det ikke, men der er en diskussion her.
Punkt 3 giver meget lille spillerum for små aktører. Store aktører som fx. IBM kan muligvis få klaveret til at spille.
Diskussionen handler ikke bare om Indien. EU' s udbudsregler, og andre incitamenter til brugen af fastpris-kontrakter, med den skarpe adskillelse mellem specifikation og programmering, rummer det samme paradoks.
-
0
-
0
Min erfaring er nu at såfremt man benytter både erfarne og dygtige programmører, så kan man sagtens få rigtig gode resultater også uden at specificere sig ihjel.
Jeg synes der er en udbredt misforståelse at offshore udvikling automatisk betyder at man enten skal specificere alt til lige omkring kvalmegrænsen - ellers er det helt uklart hvad du får. Sagen er jo nu engang at det handler om hvordan man styrer sine udviklingsprojekter - ønsker man som forretning alene at give input i starten af et projekt og så alene involvere sig igen når produktet skal bruges, ja så kommer man nok ikke uden om at specificere rimelig detaljeret - uanset om udviklerne sidder i Bangalore, Randers eller Nairobi.
Min erfaring er at hvis man benytter offshore udvikling som en mulighed hvor man billigere og lettere end ellers kan få fat på de allerdygtigste udviklere, så kan man faktisk få et udviklingsteam som selvstændigt kan bidrage i udviklingsprocessen. Være garanter for kvalitet, for brugskvalitet og for løsningerne simplicitet. Vælger man en specificer->lav tilgang alene med juniorressourcer, ja så skal man nok også være forberedt på at eksplicitere en del.
Der findes mange dygtige udviklere rundt omkring - de dygtigste i udlandet kan naturligvis direkte måle sig med de dygtigste herhjemme.
Er man usikker som organisation på hvorvidt man er rustet til at høste fordelene ved offshoring så synes jeg derudover bestemt der kan være meget værdi i at støtte sig til en erfaren udviklingschef/projektleder (måske ham som nævnt i artiklen ovenfor - men der er også mange andre erfarne at vælge imellem), eventuelt blot i en opstartsperiode indtil man får en god udviklingsprocess ind under huden.
Der er mange fordele ved offshore udvikling, specielt hvis man skal have 3 mand eller mere på en opgave. For enkeltmandsopgaver er fordelen begrænset.
Der er et betydeligt besparelsespotentiale, ja - men vigtigst tror jeg nu er muligheden for at tiltrække og fastholde ressourcer som er dygtigere end hvad de ville koste herhjemme... :)
De findes selvfølgelig også herhjemme - men de er for dyre også selvom man indregner et intensivt rejse- og kommunikationsoverhead.
mvh. Kristian
www.isys.dk
-
0
-
0
Jeg tror, at mange fejler med offshore outsourcing, fordi de stirrer sig blind på timepriserne. Det vrimler med tilbud om udviklere helt ned til 5 USD i timen, men man kan naturligvis sige sig selv, at hvis timeprisen er meget lav, så er lønnen til udviklerne tilsvarende meget lav, og er udviklernes løn meget lav, tja så er det jo nok fordi, at der er tale om juniorudviklere eller at leverandøren ikke sørger for ordentlig videreuddannelse, rare kontorfaciliteter m.v.
Jeg mener, at man i det store hele skal stille de samme krav til en offshore it-leverandør, som man ville stille til et dansk it-udviklingshus. Der skal stilles krav om en professionel tilgang til udviklingsarbejdet, kompetente ressourcer, god kommunikation osv., og hvis man i udgangspunktet ikke lader sig nøje, så vil man få siet alle de useriøse offshore it-leverandører fra og ende med en leverandør, som plus/minus det løse er på højde med et dansk udviklingshus. Det kan så godt være, at man ikke får timerne til 5-6 USD, men er det ikke også bedre at få kode af høj kvalitet og spare 35-40% frem for at sidde med et ubrugeligt og ikke-vedligeholdelsesvenligt stykke software og have "sparet" 70-80%.
Mvh.
Ole Rønberg
http://www.codelean.com
-
0
-
0
Jeg hører rigtig mange war stories om virksomheder, der har svært ved at få det til at kunne betale sig at outsource, men mange havde på den anden side ikke et valg fordi de ikke havde kompetencerne i det land de kommer fra.
For at det skal være fornuftigt er man nød til at opnå en tålelig produktivitet, og her har jeg for nyligt læst noget om hvad en hollandsk firma Xebia og Jeff Sutherland har arbejdet med i forhold til at køre Scrum distribueret. Det var der nemlig en præsentation om på QCon London, som jeg lige er kommet hjem fra :-). (Slidesne kan findes her: http://qconlondon.com/london-2009/file?path=/qcon-london-2009/slides/Gui...)
Xebia og Jeff Sutherland gav også et videointerview til JAOO 2007 om netop distibueret Scrum:
http://blog.jaoo.dk/2008/09/23/the-secrets-of-doing-agile-offshoring-wit...
-
0
-
0
God artikel, vi har på vores website et par artikler som omhandler nettop dette emne (læs dem der ellers bliver denne post meget lang)
Om outsourcing generalt
http://www.1902software.dk/index.php?id=93
Om outsourcing priser
http://www.1902software.dk/index.php?id=94
Jeg går i artiklerne ikke i detalje om tingene, den opmærksomme læser vil hurtigt forstå meningen.
Outsoucing er ikke rocket science, god fornøjelse :-)
-
0
-
0
