Dette indlæg er alene udtryk for skribentens egen holdning.

Opbyg domæneviden på dit team, selvom du outsourcer din softwareudvikling!

4. februar 2014 kl. 14:475
Artiklen er ældre end 30 dage

Domæneviden er viden om anvendelsen af den software, du udvikler: Hvem der skal bruge den, hvad deres behov er, hvad de gerne vil opnå med softwaren m.m. Det betyder også, at det stort set er umuligt at udvikle den helt rigtige løsning, hvis man ikke har adgang til domæneviden, eller som minimum at udviklingsprocessen bliver væsentlig langsommere, fordi man hele tiden skal spørge andre til råds.

Hvis du skal opbygge domæneviden, er det en fordel at være tæt på ”kilden” til viden, og af den grund er der mange, der tror, at man ikke kan opbygge domæneviden, når man som virksomhed outsourcer sin softwareudvikling. Og det kan jeg godt forstå, for hvis man ser helt sort/hvidt på det, er grundlaget for at opbygge domæneviden på et udviklingsteam ikke optimalt, når man outsourcer.

For det første sidder de sourcede udviklere ikke fysisk hos dig, og de har derfor måske sværere ved at opbygge en relation til din virksomhed og til de personer, de arbejder sammen med på distancen. For det andet kender de sourcede udviklere ikke nødvendigvis den kulturelle kontekst, som den software, de udvikler, skal fungere under. For det tredje er der en tendens til, at sourcede udviklere ikke bliver på opgaver for den samme virksomhed i længere tid ad gangen, og derfor starter du hele tiden forfra med domæneviden på teamet.

Men selvom det måske ikke ligger lige til højrebenet at opbygge domæneviden på et udviklingsteam i forbindelse med outsourcing, er det altså ikke umuligt, så længe du sørger for, at rammerne er på plads.

Opbyg relationer fra første dag

Allerede fra dag ét skal du have fokus på, at de sourcede udviklere skal kende din virksomhed, det team, de skal arbejde sammen med, og ikke mindst hvad softwaren skal udvikles til. Her anbefaler jeg, at du får de sourcede udviklere på besøg i din virksomhed i forbindelse med opstart af udviklingsopgaven. Den personlige relation, de opbygger ved at møde virksomheden og de andre teammedlemmer, er, ud fra min erfaring, i høj grad med til at forbedre samarbejdet om udviklingsopgaverne.

Forstå den kulturelle kontekst

Uanset om dine sourcede ansatte skal udvikle software til virksomhedens egne eller jeres kunders løsninger, er det vigtigt, at de kender til den virkelighed, softwaren skal udvikles til. Hvis udviklerne fx skal udvikle softwareløsninger til sundhedsvæsnet i Danmark, har de behov for at vide, hvordan sundhedsvæsnet arbejder i Danmark. Det er nemlig ikke sikkert, at det billede, de sourcede udviklere har af et ”sundhedsvæsen”, stemmer overens med den måde, sundhedsvæsnet arbejder på i Danmark. Her vil jeg helt klart anbefale, at softwareudviklerne besøger den virksomhed og gerne den afdeling, de skal udvikle software for, så de får en tilbundsgående forståelse af - og viden om - hvordan softwaren skal anvendes.

Fokus på dedikerede teams

Når du outsourcer softwareudvikling, kommer du længst med dedikerede teams, altså teams hvor det er de samme softwareudviklere, der arbejder på din virksomheds opgaver. Jo længere tid teamet bliver sammen, jo mere domæneviden bliver der opbygget, og det betyder, at du får en bedre ROI på dine udviklingsprojekter. Det gør du blandt andet, fordi det er de udviklere, der har lavet løsningen, som også kan stå for løbende vedligehold. Men for at få dedikerede teams kræver det, at dine sourcede udviklere bliver på dit team. Hvordan du får dem til at blive det, kan du læse i mit tidligere blogindlæg om motivation og fastholdelse her på Version2.

Tæt samarbejde på teamet

Din virksomhed er uden tvivl kilden til domæneviden, og derfor kan der godt opstå problemer, hvis jeres udviklere ikke sidder fysisk i virksomheden. Her er det vigtigt, at det danske team og det sourcede team arbejder tæt sammen om de opgaver, de løser. Det danske team er tæt på kilden (virksomheden) og dén viden, de får, skal føres videre til de sourcede udviklere, så de altid har en klar fornemmelse af, hvad der sker i virksomheden i Danmark. Her vil jeg foreslå, at I fx kører udviklingsopgaver som scrum-forløb, hvor teamet har daglige standup meetings via Skype. Her kan I planlægge dagens opgaver, og teamet kan gennemgå, hvad der er gået godt, hvad der er gået skidt, og hvilke udfordringer de måske kan løbe ind i.

Rammerne for domæneviden skal være på plads

Min erfaring er altså kort og godt, at man godt kan opbygge domæneviden, selvom man outsourcer en del af sin udvikling til et andet land. Bare sørg for at have rammerne på plads!

5 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
5
5. februar 2014 kl. 09:29

Nu kunne man få den tanke, at jeg har outsourcet kommenteringen til Ole Jeppesen, men det er langt fra tilfældet, omed jeg langt hen ad vejen er enig i Ole's kommentarer...

@Ole Jeppesen: Jeg er helt enig i at modellen med at have distribuerede udvikligsteam har mange fordele. Jeg oplever også at man ved at benytte den model kan opnå en situation, hvor alle - uanset om de er virksomhedens egne udviklere eller om de er sourcede medarbejdere på en remote lokation - for opbygget en fællesskabsfølelse og en sammenhørighed, der resulterer i lav personaleudskiftning og dermed at der opbygges mere og mere domæneviden på teamet. Langt hovedparten af de teams vi har hos Conscensia er opbygget efter denne model. Der kan være nogen variation i hvilke roller der ligger hvor, men fælles dog, at productowner skal være meget tæt på forretningen og derfor naturlig ligger på den danske banehalvdel.

@Mikkel Knudsen og Ole Jeppesen: Jeg er enig i at der er stor forskel på hvor sikkert det er at færdes omkring Uafhængighedspladsen i Kiev og IPR og driftssikkerhed. Samtidig må jeg også konstatere, at det billede man får fra pressen alene ikke altid er lige nuanceret, men det ændrer ikke ved det faktum, at situationen i Ukraine er uafklaret lige nu og at dette helt naturligt vil påvirke folk i Ukraine.

@Peter Johan Bruun: Conscensia har andre kunder end Systematic der leverer til sundhedssektoren ikke alene i Danamrk men også andre steder på jorden. Vi har imidlertid en aftale om ikke at nævne deres navn, hvorfor jeg ikke kan give dig de projekter du efterspørger.

Når det er sagt så skal jeg ikke gøre mig til talsmand for om Columna er et dårlgere eller bedre end det amerianske system som region Hovedsatden valgte, men jeg ved dog at man er glade for systemet i Region Midtjylland, så din lettere provokerende udtalelse om at det er et fejlslagent projekt kan jeg ikke genkende.

Dit sidste afsnit forstår jeg overhoveder ikke. At Conscensia blev solgt for at skaffe penge til Celenia som siden gik konkurs er vel næppe Conscensia's problem?

4
4. februar 2014 kl. 23:02

@Carsten Hansen: Hvilke dele af den danske sundheds sektor, har Conscensia leveret software til, og hvad var de specifikke erfaringer hermed ? Jeg tænker specielt på at Systematic i en årrække har benyttet sig af Ukrainske udviklere, men alligevel måtte se sig slået af andre firmaer, i den seneste udbudsrunde Systematic har deltaget i.

Er det de erfaringer - fra de historier vi senest har læst om i pressen - der fortælles om her, eller er der andre mere successfulde projekter som har vist at den tilgang, der foreslåes i dit blogindlæg, fungerer bedst ?

Findes der andre mere successfulde projekter at skrive om, kunne det være interessant at høre om, da man ellers får et lidt forkert billede når man dykker i Conscensia's historie, fortalt gennem google og et par kritiske programmør briller; Specielt når man leder efter historier om Conscensia siden frasalget fra Celenia Software i 2009.

/Peter Bruun.

2
4. februar 2014 kl. 19:40

Er det sikkert at bruge ukrainsk know-how for tiden?

Jeg er ikke helt med på hvordan stabiliteten i landet er for tiden.

3
4. februar 2014 kl. 22:07

Det er selvfølgelig et meget aktuelt spørgsmål om Ukraine som land giver den sikkerhed man har brug for som virksomhed til at drive sin forretning. Det er kun historien som vil kunne give dig et svar - alt andet vil være gætteri. Historisk set er der dog mange outsourcing lande som har været, og er i samme situation som Ukraine - uden at det har haft negativ indflydelse på hverken IP eller daglig drift. Alt andet lige bør sikkerheds-spørgsmålet indgå i en fremadrettet outsourcing strategi og risikovurdering.Udenrigsministeriet har netop (01/02-2014)opdateret deres vurdering af sikkerhed og terrorrisiko. Så, hvis du har tænkt dig at begive dig til Ukraine er det her du bør søge objektiv information om den momentane situation og hvilke forholdsregler du bør benytte dig af.

1
4. februar 2014 kl. 16:42

Hos IT247 anbefaler vi altid vores kunder at lave distribuerede udviklingteams hen over landegrænserne. I anbefalingen inkluderer vi en arkitekt og evt. en scrummaster i den danske lejer for til stadighed at være tæt på forretningen. Arkitekt-rollen kan alt efter det aktuelle load godt håndtere flere teams og gør dermed modellen både skalerbar, velegnet til kontinuerlig opbygning af domæneviden og sidst men ikke mindst giver det en meget lav churn-rate.

Dermed ikke sagt at man ikke kan placere hele sit udviklingsteam i udlandet. Her skal man blot gøre sig nogle organisatoriske overvejelser som bibringer forretningen den agile forståelse og påregne hyppigere insourcing samt besøg hos det autonome team.