Udvikling i Bulgarien/Ukraine - erfaring?

Hej Amino,

Vi påtænker at hyre 2 udviklere i enten Bulgarien eller Ukraine via
et outsourcing firma.

Nogen der har noget erfaring omkring dette?


Jeg forventer at rejse derned den første uge til igangsætning og derefter
følge op via telefon/skype/grundig test m.v., samt at besøge dem hver 3. uge
et par dage.

Vi hyrer ligeledes en freelance dansk .net programmør nogle timer til at
gennemgå koden.

Vi laver grundigt manuskript / krav mv., ligesom vi faktisk har et system
kørende i den gamle ASP model, men ønsker at få det udviklet forfra i .NET

Udviklerne arbejder udelukkende for os, ligesom vi er med ved ansættelsen.

På forhånd tak for alle input.

/ Kim

ja, det er lidt træls når aftaler ikke holdes.

Jeg håber det er anderledes når de ansættes direkte under os. Så har jeg også muligheden for hele tiden at følge dem tæt - og for at fyre dem. Vi vil selvfølgelig indføre en prøveperiode i kontrakten osv. og så må man jo være lidt socialt med dem når man besøger dem, så vi kan opbygge et godt arbejdsforhold - ligesom med alle andre medarbejdere.

/ Kim

Jeg har været projektleder for en større dansk virksomhed hvor der har været 3 udviklere i Ukraine og nogle udviklere i Danmark i lidt over et år. Udviklere og virksomheder i Ukraine er lige så forskellige som de er i Danmark, så vælg din partner med omtanke og evt. start med et mindre projekt for at danne dig nogle erfaringer. Jeg kan sige følgende:

1) Hvis du ikke er IT-kyndig så vil jeg foreslå at du får en IT-kyndig dansk projektleder i Danmark.

2) Brug en agile udviklingsmodel hvor i har korte iterationer (måske 2 uger) og sørger for at have et system som kan bruges til noget hele tiden under udviklingen (sørg for at afslutte opgaverne så hurtigt som muligt, så de ikke "hænger" i længere tid). Når man smider en stor kravspec. i hovedet på udviklerne og først ser produktet når de mener at de er færdige, så er det at det går galt. Giv feedback til udviklerne under udviklingen - de kan ikke høre dine tanker. Opsplit jeres system i mindre selvstændige dele og prioritér dem (kernefunktionalitet før nice-to-have-funktionalitet). Planlæg så releases iht. prioriteringen. Jeg bruger selv en 5-bruger version fra http://www.versionone.net/ til projektstyring, og jeg kan anbefale denne.

3) Reducér risiko så snart i opdager den. Der er de mennesker der tager det nemmeste først og gemmer det svære til sidst, og så er der dem der tager det sværeste først. Dem der venter med det sværeste render typisk ind i flere overraskelser end dem der tager det svære først. Overraskelser er ikke godt i et udviklingsprojekt, så reducér risikoen!

4) Dokumentér arbejdsprocesserne. Jeg har det sådan at hvis en regel ikke er dokumenteret, så er det ikke en regel der skal følges i udviklingsprocessen. Uskrevene regler giver bare forvirring.

5) Foretræk foreståelig kildekode fremfor dokumentation af uforståelig kildekode. Den vil nogle uerfarne udviklere nok give mig hug for fordi de har hørt at dokumentation er så så så vigtig for at forstå et system, men dette virker for mig. Det er så de samme udviklere der ikke gider at læse dokumentationen når den så er der ;-) Så hvis udvikleren tænker at det her bør dokumenteres, så burde han måske først lige tænke på om han kan refaktorere kildekoden på en måde så den er mere forståelig for en udvikler uden kendskab til systemet. Hvis det så stadig er uforståelig efter refaktorering, så kan han dokumentere den uforståelige kildekode. Teknisk dokumentation er til at beskrive HVORFOR noget er som det er, ikke til at beskrive HVORDAN. Hvis kildekoden er forståelig, så er det meget nemmere at forstå systemet for en ny udvikler. Jeg benytter http://www.jetbrains.com/resharper/ til refactoring og den er guld værd. Refactoring er det at ændre kildekode så softwaren gør det samme som før, men hvor kildekoden er mere forståelig for en udvikler.

6) Benyt unit tests til de vigtigste dele af systemet. De tager ekstra tid at skrive, men så kan de også bruges til at teste de vigtige dele af systemet på få minutter i resten af projektets levetid. De kan ikke erstatte manuelle tests, men de kan komplementere dem.

7) Når der opstår en fejl, så kig på hvordan man kan sørge for at dette ikke sker igen. Alt for mange projekter laver de samme fejl igen og igen.

8) Brug et versionskontrol system til styring af releases og til at holde nyudviklet kode adskilt fra kode i drift. Det koster lidt ekstra udvikling, men det betyder meget færre fejl i kode der er sat i drift, og de kan koste kassen afhængig af vigtigheden af systemet.

Hej Casper,

Tusinde tak for den flotte feedback. Det sætter jeg stor pris på - og er helt sikkert noget jeg vil tage til efterretning. :)

Jeg har selv programmeret i den gamle asp i snart 8-10 år og har også et par udviklere under mig. Og jeg kan give dig ret i at dokumentationen skal være god og at det er ligeså vigtigt at dokumentere og kommentere i koden og at variabler har forståelige navne.

Jeg regner med (håber) at forløbet vil være som sad jeg overfor dem - det vil sige at jeg hele tiden følger med i udviklingen og at vi dagligt tester - og at vi mindst hver anden dag vender det daglige arbejde/udvikling. Og jeg vil gerne indføre webcam m.v. så vi altid er tilstede når der er noget. Da jeg ikke selv kender så meget til .Net programmering, vil jeg have en freelance programmør (Dansker) ind og tjekke koden hver 3. - 4. uge - lidt oftere i starten.

Tak igen Casper

/ Kim

Tag en snak med Jon fra relationhouse (også aminobruger). Han er den danske tekniske projektleder med et team i Bulgarien og jeg har kun positive ting at sige om ham og de produkter, som jeg har fået lavet.

Hej Lars

Jeg har brugt www.rentacoder.com til mere end 30 små og mellemstore projekter. Bare husk der typisk en anden arbejdskultur + tilgang til tingene. Hvis man tror det modsvarer at svinge pisken over et hold danske programmører, så bliver man slemt skuffet.

Men generelt kan man få lavet glimrende software til en ekstrem lav pris. Man skal blot involvere sig mere aktivt i processen, og samtidig splitte udviklingen op i en række klart definerede del-projekter. Som foreslået tidligere i tråden, så er agile modellen ikke en dum tilgang.

Held og lykke med projektet.

Mvh. Henrik

Lidt skamløs reklame for min kærestes website
www.asias.dk - Flotte smykker og perlekæder, direkte import fra sydøstasien