(Blot for at sikre at version2 ikke kommer til at nærme sig CW i forhold til kvaliteten af artiklerne)
Kan I (Tania Andersen) ikke skrive/spørge ind til ulemperne ved offshoring, så det ikke kommer til at ligne en pressemeddelelse for Isys/workcompany. Det er synd og skam, da de sikkert er dygtige.
Vi har selv fulgt tre offshoring projekter fra sidelinjen, som gik mindre godt og hvor projektet desværre efterfølgende er blevet meget dyrere end hvis det var blevet udviklet i eksempelvis Skandinavien.
Lars Pedersen (
http://www.bnp.dk)
(Blot for at sikre at version2 ikke kommer til at nærme sig CW i forhold til kvaliteten af artiklerne)
Kan I (Tania Andersen) ikke skrive/spørge ind til ulemperne ved offshoring, så det ikke kommer til at ligne en pressemeddelelse for Isys/workcompany. Det er synd og skam, da de sikkert er dygtige.
Vi har selv fulgt tre offshoring projekter fra sidelinjen, som gik mindre godt og hvor projektet desværre efterfølgende er blevet meget dyrere end hvis det var blevet udviklet i eksempelvis Skandinavien.
Lars Pedersen (http://www.bnp.dk)
Kan I (Tania Andersen) ikke skrive/spørge ind til ulemperne ved offshoring
Jeg ved, at Tania skam *har* spurgt ind til de negative sider - og at svaret var, at dem var der ingen af.
Vh Morten K. Thomsen
Redaktør, Version2
[quote]Kan I (Tania Andersen) ikke skrive/spørge ind til ulemperne ved offshoring [/quote]
Jeg ved, at Tania skam *har* spurgt ind til de negative sider - og at svaret var, at dem var der ingen af.
Vh Morten K. Thomsen
Redaktør, Version2
og at svaret var, at dem var der ingen af.
o_O
Selvfølgelig er der ulemper. Med den slags svar får man vidst et godt tegn på troværdigheden af firmaet...
[quote]og at svaret var, at dem var der ingen af.[/quote]
o_O
Selvfølgelig er der ulemper. Med den slags svar får man vidst et godt tegn på troværdigheden af firmaet...

Hej Lars,
En af de store udfordringer med offshore udvikling er uden tvivl at sikre en god og effektiv kommunikation mellem forretningen og udviklingsteamet.
Det er det iøvrigt også hvis udviklingsteamet sidder i Randers og forretningen i København. :)
Kernen i det vi altid anbefaler vores kunder og samarbejdspartnere - er at for at sikre en god kommunikation, er det nødvendigt at man betrager udviklerne som egne ansatte og at man fysisk tilbringer tid samme relativt ofte. Det uanset fysisk afstand.
Rent praktisk ved at udviklingschefen rejser til udviklerne 6 gange årligt - og udviklerne som rejser til Danmark 2 gange årligt.
Derudover er der daglige (korte) møder med udviklerne over Skype.
Arbejder man med nogle knusende skarpe udviklere og tager man ledelsesopgaven, ja så kan udfordringerne bestemt takles - og der er ingen tvivl om at man kan hente betydelige besparelser og kvalitetsløft.
De dygtigste programmører i udlandet kan naturligvis måle sig med de dygtigste herhjemme.
Nøjes man med nogle mellemgode udviklere som næsten har en smule erfaring og tager man sig ikke tid til at sikre en god udviklingsledelse, ja så plejer det at give spøjse resultater både i Ukraine, Polen, Kenya, Indien såvel som Danmark - og så er det nok svært at høste besparelserne ved at se til øst eller syd :)
Det korte af det lange er at netop i tilfældet med Workcompany så har udviklingschefen sikret en god kommunikation med en flok specialister som er superdygtige. Det er ikke fordi der ingen udfordringer - men de væsentligste er faktisk blevet taklet! Resultaterne er der!
Jeg ved ikke om det bliver for langt her - men jeg vil da mægtig gerne høre lidt om de (halvtriste) erfaringer du har gjort dig i de 3 projekter du har fulgt.
Byder gerne på en kop hjemmeristet kenyansk kaffe? :)
mvh.
Kristian
www.iSys.dk
Hej Lars,
En af de store udfordringer med offshore udvikling er uden tvivl at sikre en god og effektiv kommunikation mellem forretningen og udviklingsteamet.
Det er det iøvrigt også hvis udviklingsteamet sidder i Randers og forretningen i København. :)
Kernen i det vi altid anbefaler vores kunder og samarbejdspartnere - er at for at sikre en god kommunikation, er det nødvendigt at man betrager udviklerne som egne ansatte og at man fysisk tilbringer tid samme relativt ofte. Det uanset fysisk afstand.
Rent praktisk ved at udviklingschefen rejser til udviklerne 6 gange årligt - og udviklerne som rejser til Danmark 2 gange årligt.
Derudover er der daglige (korte) møder med udviklerne over Skype.
Arbejder man med nogle knusende skarpe udviklere og tager man ledelsesopgaven, ja så kan udfordringerne bestemt takles - og der er ingen tvivl om at man kan hente betydelige besparelser og kvalitetsløft.
De dygtigste programmører i udlandet kan naturligvis måle sig med de dygtigste herhjemme.
Nøjes man med nogle mellemgode udviklere som næsten har en smule erfaring og tager man sig ikke tid til at sikre en god udviklingsledelse, ja så plejer det at give spøjse resultater både i Ukraine, Polen, Kenya, Indien såvel som Danmark - og så er det nok svært at høste besparelserne ved at se til øst eller syd :)
Det korte af det lange er at netop i tilfældet med Workcompany så har udviklingschefen sikret en god kommunikation med en flok specialister som er superdygtige. Det er ikke fordi der ingen udfordringer - men de væsentligste er faktisk blevet taklet! Resultaterne er der!
Jeg ved ikke om det bliver for langt her - men jeg vil da mægtig gerne høre lidt om de (halvtriste) erfaringer du har gjort dig i de 3 projekter du har fulgt.
Byder gerne på en kop hjemmeristet kenyansk kaffe? :)
mvh.
Kristian
www.iSys.dk

Tak for svarene
Jeg kan kun snakke ud fra egne erfaringer.
Fem ulemper:
- Udviklerne (offshore) tager som regle konsekvent de forkerte beslutninger, dvs du skal bruge rigtig mange ressourcer på projektledelse
- Alt materiale skal oversættes til engelsk - også design skal oversættes (forestil dig at skulle udvikle en applikation, hvor alt indhold er på kinesisk, hvor der ikke er en kontekst at forholde sig til)
- Ikke alle kunder er flydende på engelsk - der skal som regel kommunikeres på UK uagtet den danske projektleder
- Testkulturen er i Danmark ikke noget at råbe hurra for og med et ekstra led til udviklerne offshore, hvor der er endnu mindre fokus på dette, vil det ofte skabe mange gnidninger og længere udviklingsforløb end nødvendigt. Løsningen sendes oftere frem og tilbage ved kundens tilbagevisning af mangelfulde rettelser fra mv.
- Kultur er (på trods af alle lovord om, at det ikke er et problem) en stor udfordring
Du skriver et andet sted, at man ikke behøver at specificere sig til kvalmepunktet. Jo - det mener jeg faktisk at du ofte er tvunget til. Det ser jeg derimod ikke som et problem indenfor webprojekter hvor man i 99,5 % af tilfældene bevæger sig på kendt domæne. Dvs. at det ikke er raketvidenskab, og man skal egentlig bare gøre det samme, som de bedste gør.
Det er altså ikke farligt at tænke sig om inden der tages fat på kodningen og hele verden ændrer sig ikke i løbet af et år (som det jo ofte påstås fra de Agile Diciple :-) ).
Lars (http:/
www.bnp.dk)
Tak for svarene
Jeg kan kun snakke ud fra egne erfaringer.
Fem ulemper:
- Udviklerne (offshore) tager som regle konsekvent de forkerte beslutninger, dvs du skal bruge rigtig mange ressourcer på projektledelse
- Alt materiale skal oversættes til engelsk - også design skal oversættes (forestil dig at skulle udvikle en applikation, hvor alt indhold er på kinesisk, hvor der ikke er en kontekst at forholde sig til)
- Ikke alle kunder er flydende på engelsk - der skal som regel kommunikeres på UK uagtet den danske projektleder
- Testkulturen er i Danmark ikke noget at råbe hurra for og med et ekstra led til udviklerne offshore, hvor der er endnu mindre fokus på dette, vil det ofte skabe mange gnidninger og længere udviklingsforløb end nødvendigt. Løsningen sendes oftere frem og tilbage ved kundens tilbagevisning af mangelfulde rettelser fra mv.
- Kultur er (på trods af alle lovord om, at det ikke er et problem) en stor udfordring
Du skriver et andet sted, at man ikke behøver at specificere sig til kvalmepunktet. Jo - det mener jeg faktisk at du ofte er tvunget til. Det ser jeg derimod ikke som et problem indenfor webprojekter hvor man i 99,5 % af tilfældene bevæger sig på kendt domæne. Dvs. at det ikke er raketvidenskab, og man skal egentlig bare gøre det samme, som de bedste gør.
Det er altså ikke farligt at tænke sig om inden der tages fat på kodningen og hele verden ændrer sig ikke i løbet af et år (som det jo ofte påstås fra de Agile Diciple :-) ).
Lars (http:/www.bnp.dk)

@Kristian Mogensen
Typisk har offshoring et dårligt ry (dog ikke i ledelseskredse) fordi ledelserne stirrer sig blinde på prisniveau og det store udbud af arbejdskraft. Man skeler ikke til om en specifik opgave egner sig til offshoring eller ej eller om en specifik opgave overhovedet kan betale sig at få udviklet offshore. Ej heller kærer man sig om kvalifikationsniveauet for de offshore resurser man benytter sig af - en udvikler er en udvikler. Kvaliteten af den leverede kode er måske slet ikke et issue - hvis det kan kompilere og eksekveres så er kvalitetsparametrene opfyldt.
Hvis man skal specificere frem og tilbage i månedsvis på en opgave, pga offshore-resurserne manglende erfaring som udviklere, som specifitøren selv kunne implementere i løbet af en uges tid - hvad er så vundet?
Det lyder som om I har fat i noget i og med at I rent faktisk kigger på kvalitet og kvalifikationer af de udviklere i bruger - en udvikler er ikke bare en udvikler - det tror jeg er en ret vigtig erkendelse.
@Morten K Thomsen og Tania Andersen
"De gode programmører er i Afrika" - vil det så sige at der ikke findes gode programmører andre steder? - næppe. Hvad med "Der findes også gode programmører i Afrika"
@Kristian Mogensen
Typisk har offshoring et dårligt ry (dog ikke i ledelseskredse) fordi ledelserne stirrer sig blinde på prisniveau og det store udbud af arbejdskraft. Man skeler ikke til om en specifik opgave egner sig til offshoring eller ej eller om en specifik opgave overhovedet kan betale sig at få udviklet offshore. Ej heller kærer man sig om kvalifikationsniveauet for de offshore resurser man benytter sig af - en udvikler er en udvikler. Kvaliteten af den leverede kode er måske slet ikke et issue - hvis det kan kompilere og eksekveres så er kvalitetsparametrene opfyldt.
Hvis man skal specificere frem og tilbage i månedsvis på en opgave, pga offshore-resurserne manglende erfaring som udviklere, som specifitøren selv kunne implementere i løbet af en uges tid - hvad er så vundet?
Det lyder som om I har fat i noget i og med at I rent faktisk kigger på kvalitet og kvalifikationer af de udviklere i bruger - en udvikler er ikke bare en udvikler - det tror jeg er en ret vigtig erkendelse.
@Morten K Thomsen og Tania Andersen
"De gode programmører er i Afrika" - vil det så sige at der ikke findes gode programmører andre steder? - næppe. Hvad med "Der findes også gode programmører i Afrika"

Hej Lars,
Tak i lige måde.
Det lyder ikke som de bedste oplevelse, må man jo indrømme.
Men er der tale om opgaver som man "for at spare en masse penge" lige har lavet en specifikation af og så bare sendt den ud til fjernøsten og afventet leverancen? Eller er det udviklere din kunde har interviewet, testet og udvalgt - hvor mange gange har udviklingschefen rejst til udviklerne? Hvor mange gange har udviklerne rejst den anden vej? Hvordan har man kommunikeret?
Jeg er ret sikker på at det kan være vanskeligt at høste besparelser hvis man ikke har fokus på at løse kommunikationsudfordringen - og er indstillet på at flytte sig for at sikre en god proces. Tilgengæld er der generelt gode muligheder for at man kan arbejde med dygtigere ressourcer end dem man kan tiltrække og fastholde i Danmark (de dygtigste i Danmark er DYRE og har allesammen mange spændende ting om ørerne).
Samlet er der et ikke ubetydeligt besparelsespotentiale.
Ikke at sikre en ordentlig test i sin udviklingsproces oplever jeg som en mangelfuld udviklingsledelse.
Jeg har ikke oplevet nogen konsekvens med forkerte beslutninger blandt dem jeg har arbejdet med - og hvis man fokuserer snævert på alene at arbejde med de allerdygtigste, så er min erfarning også at de kulturelle forskelle ikke er en hindring overhovedet.
Du har naturligvis helt ret i at tingene skal foregå på engelsk - både skrifteligt og mundtligt. Det er en forudsætning - tolke o. lign. duer ikke.
Det er også klart at en udvikler 6000 km væk ikke ved hvad et CVR-nummer eller arbejdsmarkedsbidrag er - men jeg kan godt hilse og sige at jeg har oplevet danske udviklere som heller ikke vidste det (eller endnu værre: som troede de vidste det).
Min pointe er at alene at det kan lade sig gøre - man kan få noget rigtig godt ud af det.
mvh. Kristian (som beklager de lange svar)
www.iSys.dk
PS. Jeg vil helst ikke stå som fortaler for at man ikke behøver at tænke sig om inden man koder - men der er nu store fordele i at have hyppige leverancer og smide løsningen i hovedet på brugerne løbende - frem for at tænke sig godt om i et halvt års tid og så kode derefter...
Uanset hvor dygtig man er til at specificere og strukturere systemer så oplever man nu alligevel at ønskerne til et system nuanceres når det tages i brug. Om man kalder det agilt, scrum, RUP er jeg mindre engageret i - men leverancer og gennemgange i faste iterationer er der mange fordele i langt de fleste situationer. Ikke kun offshore.
Hej Lars,
Tak i lige måde.
Det lyder ikke som de bedste oplevelse, må man jo indrømme.
Men er der tale om opgaver som man "for at spare en masse penge" lige har lavet en specifikation af og så bare sendt den ud til fjernøsten og afventet leverancen? Eller er det udviklere din kunde har interviewet, testet og udvalgt - hvor mange gange har udviklingschefen rejst til udviklerne? Hvor mange gange har udviklerne rejst den anden vej? Hvordan har man kommunikeret?
Jeg er ret sikker på at det kan være vanskeligt at høste besparelser hvis man ikke har fokus på at løse kommunikationsudfordringen - og er indstillet på at flytte sig for at sikre en god proces. Tilgengæld er der generelt gode muligheder for at man kan arbejde med dygtigere ressourcer end dem man kan tiltrække og fastholde i Danmark (de dygtigste i Danmark er DYRE og har allesammen mange spændende ting om ørerne).
Samlet er der et ikke ubetydeligt besparelsespotentiale.
Ikke at sikre en ordentlig test i sin udviklingsproces oplever jeg som en mangelfuld udviklingsledelse.
Jeg har ikke oplevet nogen konsekvens med forkerte beslutninger blandt dem jeg har arbejdet med - og hvis man fokuserer snævert på alene at arbejde med de allerdygtigste, så er min erfarning også at de kulturelle forskelle ikke er en hindring overhovedet.
Du har naturligvis helt ret i at tingene skal foregå på engelsk - både skrifteligt og mundtligt. Det er en forudsætning - tolke o. lign. duer ikke.
Det er også klart at en udvikler 6000 km væk ikke ved hvad et CVR-nummer eller arbejdsmarkedsbidrag er - men jeg kan godt hilse og sige at jeg har oplevet danske udviklere som heller ikke vidste det (eller endnu værre: som troede de vidste det).
Min pointe er at alene at det kan lade sig gøre - man kan få noget rigtig godt ud af det.
mvh. Kristian (som beklager de lange svar)
www.iSys.dk
PS. Jeg vil helst ikke stå som fortaler for at man ikke behøver at tænke sig om inden man koder - men der er nu store fordele i at have hyppige leverancer og smide løsningen i hovedet på brugerne løbende - frem for at tænke sig godt om i et halvt års tid og så kode derefter...
Uanset hvor dygtig man er til at specificere og strukturere systemer så oplever man nu alligevel at ønskerne til et system nuanceres når det tages i brug. Om man kalder det agilt, scrum, RUP er jeg mindre engageret i - men leverancer og gennemgange i faste iterationer er der mange fordele i langt de fleste situationer. Ikke kun offshore.
Hej Jan,
Tak for den positive tiltro! :)
Det kan ikke betale sig at sætte en mand der kan kode til at specificere i en uge hvis det ville tage ham en uge at lave løsningen selv - heller ikke offshore :)
Og derudover har du fanget min pointe.
Basalt set så handler det om mennesker.
Jeg sværger til at "dygtighed" er den mest væsentlige parameter for succes - ihvertfald for mindre og mellemstore udviklingsorganisationer som vi har fokus på.
Der findes dygtige programmører allevegne - men konkurrencen om at tiltrække og fastholde de dygtigste programmører er meget forskellig fra sted til sted.
mvh. Kristian
www.iSys.dk
Hej Jan,
Tak for den positive tiltro! :)
Det kan ikke betale sig at sætte en mand der kan kode til at specificere i en uge hvis det ville tage ham en uge at lave løsningen selv - heller ikke offshore :)
Og derudover har du fanget min pointe.
Basalt set så handler det om mennesker.
Jeg sværger til at "dygtighed" er den mest væsentlige parameter for succes - ihvertfald for mindre og mellemstore udviklingsorganisationer som vi har fokus på.
Der findes dygtige programmører allevegne - men konkurrencen om at tiltrække og fastholde de dygtigste programmører er meget forskellig fra sted til sted.
mvh. Kristian
www.iSys.dk

Man kan gøre en hel del for at reducere risikoen ved offshore it-udvikling. Først og fremmest handler det om, at man må stille krav til offshore leverandøren, og kravene skal være andet og mere end blot til timeprisen. Eksempelvis kan man stille krav til følgende forhold:
- Leverandøren skal arbejde i henhold til en professionel udviklingsmetode
- Leverandøren skal udvikle i et professionelt udviklingsmiljø, og her tænker jeg på at stille krav om et fornuftigt miljø med Continuous Integration, versionsstyring m.v.
- Leverandøren skal være i stand til at kommunikere fornuftigt
Hos os arbejder vi med Scrum som udviklingsmetode, hvilket sikrer kunderne en fornuftig indsigt i udviklingsprojekterne (transparens). Kunderne kan hele tiden følge med i udviklingsteamets produktivitet og resultater. Herudover arbejder vi i et professionelt udviklingsmiljø med Continuous Integration og anvender fornuftige principper som refactoring og TDD (sidstnævnte ikke i ekstrem grad, men på fornuftig vis). Endelig har vi danskere på plads offshore i dagligdagen, og således kan kunderne altid få en snak med en dansktalende ScrumMaster, der sidder tæt på udviklingen og effektivt kan sikre, at Product Owner (kunden) og teamet kommunikerer på begavet vis, således at kundens krav bliver overført fra Danmark til offshore teamet.
Vi arbejder typisk med Sprints (iterationer) af 2 ugers varighed, og således kan kunden hele tiden se, hvordan arbejdet skrider frem.
Jeg er i øvrigt enig i, at verden ikke ændrer sig konstant, sådan som nogle agile-ekstremister råber op om, og således skal man naturligvis ikke smide alle de gode dyder omkring grundig planlægning overbord, blot fordi at man nu arbejder efter en agile metode. Det gode ved agile er i mine øjne, at man får hyppigere leverancer, hvilket gør, at kunden hurtigere kan se, hvad han/hun får for sine penge og dermed også kan se, at projektet er på rette vej. Herudover er det naturligvis en styrke ved agile udvikling, at kunden har mulighed for at omprioritere features undervejs i projektet.
vh. Ole
http://www.codelean.com
Man kan gøre en hel del for at reducere risikoen ved offshore it-udvikling. Først og fremmest handler det om, at man må stille krav til offshore leverandøren, og kravene skal være andet og mere end blot til timeprisen. Eksempelvis kan man stille krav til følgende forhold:
- Leverandøren skal arbejde i henhold til en professionel udviklingsmetode
- Leverandøren skal udvikle i et professionelt udviklingsmiljø, og her tænker jeg på at stille krav om et fornuftigt miljø med Continuous Integration, versionsstyring m.v.
- Leverandøren skal være i stand til at kommunikere fornuftigt
Hos os arbejder vi med Scrum som udviklingsmetode, hvilket sikrer kunderne en fornuftig indsigt i udviklingsprojekterne (transparens). Kunderne kan hele tiden følge med i udviklingsteamets produktivitet og resultater. Herudover arbejder vi i et professionelt udviklingsmiljø med Continuous Integration og anvender fornuftige principper som refactoring og TDD (sidstnævnte ikke i ekstrem grad, men på fornuftig vis). Endelig har vi danskere på plads offshore i dagligdagen, og således kan kunderne altid få en snak med en dansktalende ScrumMaster, der sidder tæt på udviklingen og effektivt kan sikre, at Product Owner (kunden) og teamet kommunikerer på begavet vis, således at kundens krav bliver overført fra Danmark til offshore teamet.
Vi arbejder typisk med Sprints (iterationer) af 2 ugers varighed, og således kan kunden hele tiden se, hvordan arbejdet skrider frem.
Jeg er i øvrigt enig i, at verden ikke ændrer sig konstant, sådan som nogle agile-ekstremister råber op om, og således skal man naturligvis ikke smide alle de gode dyder omkring grundig planlægning overbord, blot fordi at man nu arbejder efter en agile metode. Det gode ved agile er i mine øjne, at man får hyppigere leverancer, hvilket gør, at kunden hurtigere kan se, hvad han/hun får for sine penge og dermed også kan se, at projektet er på rette vej. Herudover er det naturligvis en styrke ved agile udvikling, at kunden har mulighed for at omprioritere features undervejs i projektet.
vh. Ole
http://www.codelean.com
Når man tænker i at offshore software udvikling så skal man holde en ting for øje:
Kapitalismen er IKKE sat ud af kraft! Hvis en polsk / kenyansk programmør koster kr.200,- i timen, så er det fordi han er han er det værd! Hvis han havde været kr.1000,- værd ville han ikke blive solgt for kr.200,- i timen.
Når man tænker i at offshore software udvikling så skal man holde en ting for øje:
Kapitalismen er IKKE sat ud af kraft! Hvis en polsk / kenyansk programmør koster kr.200,- i timen, så er det fordi han er han er det værd! Hvis han havde været kr.1000,- værd ville han ikke blive solgt for kr.200,- i timen.
@Ole Rønberg
Jeg er helt enig, det vigtigt stille krav til en offshoring-partner. Men det forudsætter at man er i stand til det. Prøv at sig fx 'Continous Integration' til en udviklingschef i en bank eller forsikringsselskab. Typisk har disse en forretningsmæssig baggrund og de vil formentligt ikke ane hvad du taler om. Med andre ord har de beslutningstagere der skal vælge offshoring-partner ikke forudsætningerne for at gøre det. Derfor ender kravene med at begrænse sig til pris.
@Ole Rønberg
Jeg er helt enig, det vigtigt stille krav til en offshoring-partner. Men det forudsætter at man er i stand til det. Prøv at sig fx 'Continous Integration' til en udviklingschef i en bank eller forsikringsselskab. Typisk har disse en forretningsmæssig baggrund og de vil formentligt ikke ane hvad du taler om. Med andre ord har de beslutningstagere der skal vælge offshoring-partner ikke forudsætningerne for at gøre det. Derfor ender kravene med at begrænse sig til pris.
Kapitalismen er IKKE sat ud af kraft! Hvis en polsk / kenyansk programmør koster kr.200,- i timen, så er det fordi han er han er det værd! Hvis han havde været kr.1000,- værd ville han ikke blive solgt for kr.200,- i timen.
Både og. Hvis det var sådan at alle højindkomstlande havde behov for at hyre alle programmører fra lavindkomstlande så ville kapitalismen få prisen til at udligne sig. Men sådan er jo ikke, mange af programmørerne i lanvindkomstlandende må jo også tage opgaver fra lokale kunder, hvor der der er helt andre forventinger til priserne.
Typisk er leveomkostningerne jo også langt lavere i disse lande, jeg har f.eks. selv et par folk siddende i Indien, som jeg benytter til noget grafisk arbejde, og jeg betaler dem en del mindre om måneden end en person på bistandshjælp får her i Danmark, og de personer i Indien lever alligevel fint af det.
[quote]
Kapitalismen er IKKE sat ud af kraft! Hvis en polsk / kenyansk programmør koster kr.200,- i timen, så er det fordi han er han er det værd! Hvis han havde været kr.1000,- værd ville han ikke blive solgt for kr.200,- i timen.
[/quote]
Både og. Hvis det var sådan at alle højindkomstlande havde behov for at hyre alle programmører fra lavindkomstlande så ville kapitalismen få prisen til at udligne sig. Men sådan er jo ikke, mange af programmørerne i lanvindkomstlandende må jo også tage opgaver fra lokale kunder, hvor der der er helt andre forventinger til priserne.
Typisk er leveomkostningerne jo også langt lavere i disse lande, jeg har f.eks. selv et par folk siddende i Indien, som jeg benytter til noget grafisk arbejde, og jeg betaler dem en del mindre om måneden end en person på bistandshjælp får her i Danmark, og de personer i Indien lever alligevel fint af det.

Kapitalismen er IKKE sat ud af kraft! Hvis en polsk / kenyansk programmør koster kr.200,- i timen, så er det fordi han er han er det værd! Hvis han havde været kr.1000,- værd ville han ikke blive solgt for kr.200,- i timen.
Kapitalismen har i mange år været sat ud af kraft. Som oftest, får du det værste bras, til højeste pris. Og bedste kvalitet, til laveste pris. Det væsentlige, når du har billig arbejdskraft, er din evne som leder, til at kunne vejlede dine ansatte, f.eks. i algorithmer, metoder osv. således at de udfører arbejdet, men bruger din viden. Så kan du godt opnå højeste kvalitet, med billig arbejdskraft. Opnås lav kvalitet, så er det - i alle tilfælde - fordi at lederne ikke er dygtige nok, til at kunne hjælpe dem de har ansat, til at udvikle tingene godt og stabilt. I at være gruppeleder, er også et krav til at selv kunne - og ikke mindst, at kunne undervise sine ansatte, så de kan opnå god kvalitet. Mangler denne evne, er du ikke i stand til, at få selv de højst lønnede, til at yde noget. Jeg har selv været i en virksomhed, hvor det lykkedes at få mange højtlønnede og dygtige mennesker, til at ikke kunne præstere et hak - alene på grund af mangel på korrekt styring og videregivning af information der var nødvendigt for at løse opgaven, samt undervisning af ansatte.
En persons værdi, afhænger ikke af lønnen, men af virksomhedens evne - og ikke mindst grupperlederens evne - til at kunne bruge vedkommende. Ofte, er en lavtlønnet endog dygtigere, end en højt lønnet, til at løse mange job.
Vi har set mange eksempler på, at højtlønnede danskere, ikke har kunnet løse en opgave så godt, og med så høj kvalitet, som billige kinesere kunne. Det er ikke altid på grund af lønninger, at man flytter til kina - årsagen er, at de ganske simpelt kan løse jobs godt, som danskere ikke formår. Det er meget karakteristisk for arbejdsmarkedet i dag, at løn, og kvalifikationer, ikke har et hak med hinanden at gøre. Løn, afspejler din evne, til at forhandle - og kræve. Og oftest, er netop denne type de dårligste. De er gode til at kræve, og dårlige til at yde. Men de er perfekte, til jobs, hvor deres job netop er at kræve, f.eks. at sælge noget dyrt, eller at kræve noget af kunden. Men, skal de selv yde - så er andre, der må gøre det, og ofte til langt lavere løn, og uden at nogen ved noget om det.
Skal jeg ansætte folk, vil jeg bestemt ikke gå efter dyre hoveder - med mindre, at det er "typen" jeg har brug for. Lønnen, siger meget om typen. En, der kræver meget, kan ikke nødvendigvis meget, men er ofte hurtig, til at lave noget bras. Derved, kan de præstere meget, og har en lang liste af kvalifikationer. Oftest er det også typen, med de bedste forhandlingsevner overfor arbejdsgiveren, og typen der bør kommunikere med kunden. Dem, der får lav løn, kan nemt give et forkert indtryk overfor kunden.
Arbejdskraft, er som når du køber varer i Bilka - noget er billigt, og andet er dyrt. Og ofte, er det det billigste, der er bedst, hvis det bruges korrekt. Bruger du billigt arbejdskraft forkert - og måske på måder, som du ikke havde brugt dyrt arbejdskraft - så får du en skandale.
[quote]Kapitalismen er IKKE sat ud af kraft! Hvis en polsk / kenyansk programmør koster kr.200,- i timen, så er det fordi han er han er det værd! Hvis han havde været kr.1000,- værd ville han ikke blive solgt for kr.200,- i timen.[/quote]Kapitalismen har i mange år været sat ud af kraft. Som oftest, får du det værste bras, til højeste pris. Og bedste kvalitet, til laveste pris. Det væsentlige, når du har billig arbejdskraft, er din evne som leder, til at kunne vejlede dine ansatte, f.eks. i algorithmer, metoder osv. således at de udfører arbejdet, men bruger din viden. Så kan du godt opnå højeste kvalitet, med billig arbejdskraft. Opnås lav kvalitet, så er det - i alle tilfælde - fordi at lederne ikke er dygtige nok, til at kunne hjælpe dem de har ansat, til at udvikle tingene godt og stabilt. I at være gruppeleder, er også et krav til at selv kunne - og ikke mindst, at kunne undervise sine ansatte, så de kan opnå god kvalitet. Mangler denne evne, er du ikke i stand til, at få selv de højst lønnede, til at yde noget. Jeg har selv været i en virksomhed, hvor det lykkedes at få mange højtlønnede og dygtige mennesker, til at ikke kunne præstere et hak - alene på grund af mangel på korrekt styring og videregivning af information der var nødvendigt for at løse opgaven, samt undervisning af ansatte.
En persons værdi, afhænger ikke af lønnen, men af virksomhedens evne - og ikke mindst grupperlederens evne - til at kunne bruge vedkommende. Ofte, er en lavtlønnet endog dygtigere, end en højt lønnet, til at løse mange job.
Vi har set mange eksempler på, at højtlønnede danskere, ikke har kunnet løse en opgave så godt, og med så høj kvalitet, som billige kinesere kunne. Det er ikke altid på grund af lønninger, at man flytter til kina - årsagen er, at de ganske simpelt kan løse jobs godt, som danskere ikke formår. Det er meget karakteristisk for arbejdsmarkedet i dag, at løn, og kvalifikationer, ikke har et hak med hinanden at gøre. Løn, afspejler din evne, til at forhandle - og kræve. Og oftest, er netop denne type de dårligste. De er gode til at kræve, og dårlige til at yde. Men de er perfekte, til jobs, hvor deres job netop er at kræve, f.eks. at sælge noget dyrt, eller at kræve noget af kunden. Men, skal de selv yde - så er andre, der må gøre det, og ofte til langt lavere løn, og uden at nogen ved noget om det.
Skal jeg ansætte folk, vil jeg bestemt ikke gå efter dyre hoveder - med mindre, at det er "typen" jeg har brug for. Lønnen, siger meget om typen. En, der kræver meget, kan ikke nødvendigvis meget, men er ofte hurtig, til at lave noget bras. Derved, kan de præstere meget, og har en lang liste af kvalifikationer. Oftest er det også typen, med de bedste forhandlingsevner overfor arbejdsgiveren, og typen der bør kommunikere med kunden. Dem, der får lav løn, kan nemt give et forkert indtryk overfor kunden.
Arbejdskraft, er som når du køber varer i Bilka - noget er billigt, og andet er dyrt. Og ofte, er det det billigste, der er bedst, hvis det bruges korrekt. Bruger du billigt arbejdskraft forkert - og måske på måder, som du ikke havde brugt dyrt arbejdskraft - så får du en skandale.