1. Innledning

I to tiår har tilbudet vært det samme og regnestykket sett uimotståelig ut. En ingeniør i India koster en brøkdel av en i Vest-Europa eller USA, tilgangen på dem er stor og velutdannet, og engelsk er arbeidsspråket, så en bedrift som flytter programvarearbeidet sitt dit, burde på papiret kunne gjøre det samme arbeidet for langt mindre. Svært mye arbeid har flyttet på nettopp det resonnementet, og India har bygget en IT-tjenesteindustri i verdensklasse på det. Og likevel er resultatene, bedrift for bedrift, slående ujevne: noen organisasjoner får utmerket programvare fra India i årevis, mens andre får en stigende regning, en fallende leveransekvalitet og en strøm av feil som de sparte lønningene aldri helt dekker, inntil de erklærer utflaggingen mislykket og henter arbeidet hjem, ofte for å konkludere med at problemet var India. Det var ikke India.

Problemet er at bedrifter flagger ut feil ting. Intuisjonen bak utflagging er at programvareutvikling er utførelse, en mengde arbeid som kan måles i persontimer og kjøpes der persontimer er billigst, og på den intuisjonen overleverer en bedrift en spesifikasjon og en bemanning og venter på resultater. Men programvareutvikling er ikke hovedsakelig utførelse; det er oppløsningen av tusen små tvetydigheter, hver av dem krever å vite hva forretningssiden faktisk mente, hvordan denne delen skal passe inn i helheten, og hva «ferdig» egentlig betyr her, og den kunnskapen bor der forretningen er, ikke der tastaturene er. Når en bedrift flagger ut utførelsen, flagger den uvitende ut også de beslutningene, til dem som er lengst unna konteksten som trengs for å ta dem godt, og resultatet er arbeid som er lokalt plausibelt og globalt feil, oppdaget sent, over en tolv timers avstand, og rettet langsomt. Lønnsarbitrasjen er reell; koordineringen og omarbeidingen den utløser, dårlig håndtert, er større.

Denne artikkelen handler om driftsmodellen som retter feilen ved ikke å begå den, og modellen har et navn vi vil bruke gjennomgående: kommandosentralen i hjemlandet. Tanken er å skille, bevisst og strukturelt, de to tingene en naiv utflagging slår sammen. Den ene er utførelse, selve byggingen, som genuint kan og bør skaleres der talent er rikelig og rimelig, i India. Den andre er kommando: å bestemme hva som skal bygges og i hvilken rekkefølge, å eie arkitekturen og grensesnittene mellom delene, å gjøre det forretningssiden vagt ønsker, om til en spesifikasjon presis nok til å bygges langt unna uten en samtale, og å vurdere om det som kom tilbake, er riktig. Kommando er lite, senior og dyrt, og det blir værende i hjemlandet, ved siden av forretningen hvis intensjon det finnes for å bære. Tesen er at suksessen til et utflaggingsprogram nesten utelukkende avgjøres av om dette kommandolaget finnes og er godt, og nesten ikke av offshore-teamets rene dyktighet, som vanligvis er god nok; og at bedrifter mislykkes ved å underinvestere i kommando nettopp fordi kommando er den dyre delen i hjemlandet som utflaggingen skulle eliminere.

Bidraget er et argument og en liten modell, ikke en målestokk. Avsnitt 2 plasserer påstanden opp mot erfaringene fra utflagging og global programvareutvikling. Avsnitt 3 diagnostiserer den egentlige svikten: å flagge ut ansvar snarere enn bare utførelse. Avsnitt 4 beskriver kommandosentralen og hva den eier. Avsnitt 5 gir en modell av hvor grensen mellom kommando og leveranse bør falle, avhengig av kontekstbelastning og spesifikasjonsfullstendighet. Avsnitt 6 behandler klokken, og hvordan follow-the-sun blir et fortrinn snarere enn forsinkelse. Avsnitt 7 utleder det optimale kommandoforholdet. Avsnitt 8 følger et konstruert eksempel; avsnitt 9 til 12 trekker konsekvensene, besvarer innvendinger, angir begrensninger og konkluderer. Spørsmålet gjennomgående er: hva må en bedrift beholde hjemme, og hvor mye av det, for at arbeidet den sender til India, skal komme riktig tilbake?

2. Bakgrunn

2.1 Erfaringene med utflagging

Outsourcing og utflagging av IT har en av de større empiriske litteraturene i informasjonssystemer, og dens dom er ikke at utflagging ikke lønner seg, men at gevinsten avhenger av hvordan den styres. Lacity, Khan og Willcocks (2009), som gjennomgår to tiår med studier, finner at kundens og leverandørens evner, kontraktsutforming og relasjonsstyring, snarere enn lønnsforskjeller alene, forklarer spennet mellom vellykkede og mislykkede engasjementer. Carmel og Tjia (2005) ga praktikerredegjørelsen for innkjøp fra en global arbeidsstyrke og katalogiserte måtene avstand uthuler arbitrasjen på; Sahay, Nicholson og Krishna (2003) ga bokredegjørelsen for programvareutvikling på tvers av India-grensen, og Oshri, Kotlarsky og Willcocks (2007) sporet hvordan en ledende indisk leverandør organiserte en global leveransemodell rundt spredt ekspertise. Rottman og Lacity (2006) destillerte velprøvde praksiser og fant at bedriftene som lyktes, investerte tungt i arbeidet i hjemlandet med å spesifisere, koordinere og styre, nettopp det arbeidet denne artikkelen kaller kommando. Det gjennomgående funnet er at besparelsen er brutto, ikke netto, og at det som står mellom de to, er en styringsinnsats som i stor grad blir værende hjemme.

2.2 Hvorfor avstand er dyrt

En annen litteratur, om globalt distribuert programvareutvikling, forklarer mekanismen. Herbsleb og Mockus (2003), i studien mest sentral for denne artikkelen, viste empirisk at arbeidsoppgaver som krevde folk på flere lokasjoner, tok vesentlig lengre tid å fullføre enn sammenlignbare oppgaver på én lokasjon, og sporet forsinkelsen til kostnaden og forsinkelsen ved kommunikasjonen som koordinering på tvers av lokasjoner krever. Ramasubbu og Balan (2007), som studerte prosjekter spredt mellom India og USA, målte samme straff direkte i prosjektytelsen. Olson og Olson (2000) ga det generelle resultatet under tittelen «avstand betyr noe»: samlokalisert arbeid nyter godt av rask, rik, uformell kommunikasjon som distribuert arbeid mister, og ingen verktøy gjenoppretter den fullt ut. Kraut og Streeter (1995) hadde allerede vist hvor mye av programvareutvikling som er koordinering snarere enn koding, og Brooks (1975) hadde lenge før gitt grunnen til at det å legge folk til distribuert arbeid kan sinke det: kommunikasjonsveiene vokser raskere enn folkene gjør. Lærdommen er ikke at distribuert utvikling ikke kan fungere, men at hver grense et arbeidsstykke må krysse, har en pris, og prisen betales i tid og feil.

2.3 Conways lov og grensens arkitektur

Den dypeste ideen artikkelen lener seg på, er Conways (1968): et systems struktur kommer til å speile kommunikasjonsstrukturen i organisasjonen som bygger det. Dens følgesetning for utflagging er presis og underbrukt. Hvis offshore og hjemland er to løst kommuniserende grupper, vil programvaren være renest når grensen mellom dem faller langs en genuin arkitektonisk skjøt, en modul med et definert grensesnitt, og vil være mest plaget der en enkelt tett koblet arbeidsklump splittes over avstanden. Herbsleb og Grinter (1999) bekreftet dette direkte, og fant at distribuert utvikling lykkes når arkitekturen er modulær nok til at hver lokasjon eier en del og grensesnittene mellom delene er eksplisitte, og sliter når den ikke er det. Parnas (1972) ga designdisiplinen, informasjonsskjuling, som gjør slike moduler mulige. Den praktiske konsekvensen, utviklet i avsnitt 4, er at det å eie arkitekturen ikke er én av kommandosentralens oppgaver blant mange; det er oppgaven som gjør alle de andre mulige, fordi den avgjør hvor den dyre grensen faller.

3. Den egentlige svikten: å flagge ut ansvar

Den karakteristiske utflaggingssvikten er ikke langsom tasting; det er arbeid som er selvsikkert ferdigstilt og stille feil. Et krav overleveres som er fullstendig i avsenderens hode og tvetydig på papiret, fordi avsenderen deler en kontekst med forretningen som mottakeren ikke gjør. Offshore-ingeniøren, kompetent og villig, løser tvetydigheten på den eneste måten som er tilgjengelig fra tolv tidssoner unna: ved å gjette, rimelig, og bygge. Gjetningen oppdages å være feil ved godkjenning, hvis det er godkjenning, eller i produksjon, hvis det ikke er det, og rettelsen krysser avstanden to ganger, én gang for å forklare og én gang for å verifisere, hver kryssing en dag tapt til klokken. Gang dette med hver tvetydighet i et reelt system, og arbitrasjen er borte, ikke fordi noen gjorde noe inkompetent, men fordi beslutningene som trengte kontekst, ble tatt der det ikke fantes noen.

Det som har skjedd, i denne artikkelens språk, er at bedriften flagget ut ansvar da den mente å flagge ut bare utførelse. Ansvar for et stykke programvare er den akkumulerte myndigheten til å løse tvetydighetene dens riktig: å vite hva forretningen mente, å avgjøre hvordan delen tjener helheten, å si hva «riktig» er. Den myndigheten er uløselig knyttet til kontekst, og kontekst er lokal. Utførelse, konstruksjonen av en ting når tvetydighetene dens er løst, er ikke kontekstbundet og reiser godt. Feilen er å behandle de to som én pakke og sende dem sammen; reparasjonen er å dele dem, holde ansvaret i hjemlandet der konteksten bor, og sende offshore bare utførelse, med tvetydighetene allerede løst opp i spesifikasjon. Alt som følger, er en utdyping av hvordan man gjør den delingen og hvor.

4. Kommandosentralen

Kommandosentralen i hjemlandet er det organisatoriske hjemmet for ansvaret som ikke må reise. Den er bevisst liten og bevisst senior, fordi dens gjennomslag kommer fra kvaliteten på noen få beslutninger snarere enn mengden produsert, og den sitter ved siden av forretningen, ikke ved siden av tastaturene. Figur 1 tegner modellen og Tabell 3 deler arbeidet. Kommandosentralen eier fem ting, og modellens disiplin er at den eier alle fem og forsøker ikke å eie noe annet.

Fra intensjon til spesifikasjon. Kommandosentralens første produkt er ikke programvare, men spesifikasjon: oversettelsen av det forretningen vagt ønsker, til en redegjørelse presis nok til å bygges av noen som ikke kan lene seg bort og spørre. Dette er arbeidet som løser tvetydighet der konteksten er, slik at ingen må løses der den ikke er, og det er den enkeltaktiviteten med størst gjennomslag i hele modellen, fordi hver tvetydighet som etterlates i en spesifikasjon, betales for senere til den fulle kostnaden av en tur-retur over avstanden.

Arkitektur og grensesnitt. Etter Conways lov vil programvaren sprekke langs organisasjonens kommunikasjonsskjøter, så kommandosentralen eier arkitekturen nettopp for å velge hvor de skjøtene faller: den dekomponerer systemet i moduler med eksplisitte grensesnitt, slik at hver offshore-pod eier en del den kan bygge med få avhengigheter på tvers av grensen. Å trekke grensen godt er det som gjør avstand om fra en skatt betalt ved hver interaksjon til en skatt betalt bare ved noen få veldefinerte grensesnitt.

Prioritering. Hva som bygges først, er en forretningsvurdering, ikke en leveransevurdering, og den blir hos kommandosentralen, som holder den ene backloggen og dens rekkefølge. Å spre prioriteringen til offshore-teamet, eller til flere interessenter samtidig, gjeninnfører over avstanden nettopp den koordineringen modellen finnes for å begrense.

Godkjenning og kvalitetsporten. Kommandosentralen bestemmer hva «ferdig» er og tester det tilbakeleverte arbeidet mot det, og holder en port forretningen stoler på. Dette er motstykket til spesifikasjon: etter å ha definert riktighet på forhånd, verifiserer den den ved retur, og fordi den er i hjemlandet og nær forretningen, kan den bedømme egnethet, ikke bare funksjon.

Én ansvarlig eier. Til sist er kommandosentralen stedet der ansvaret er udelt: én eier som står til ansvar overfor forretningen for det som leveres, og som ikke kan peke over avstanden. Ansvar som er delt over grensen, er ansvar som har forsvunnet, og å gjenopprette det til ett punkt i hjemlandet er mye av det som gjør modellen styrbar.

5. Å trekke grensen

Hvis kommando blir i hjemlandet og utførelsen går offshore, avhenger alt av hvor grensen mellom dem trekkes, oppgave for oppgave. Modellen som styrer valget, har to akser. Den første er en oppgaves kontekstbelastning: hvor mye lokal, taus, forretningsspesifikk kunnskap det kreves å løse den riktig, høy for en endring som berører en subtil reguleringsregel eller en langvarig kundeforpliktelse, lav for en veldefinert komponent med en klar kontrakt. Den andre er spesifikasjonsfullstendigheten kommandosentralen kan gi den: hvor fullstendig tvetydighetene dens kan løses på forhånd, på papiret, uten en samtale. En oppgave er trygg å flagge ut når den gjenværende tvetydigheten som når offshore-poden, dens kontekstbelastning fratrukket spesifikasjonsfullstendigheten anvendt på den, er liten. Med $\kappa$ for kontekstbelastning og $s$ for spesifikasjonsfullstendighet, begge på en felles skala, er resten

og det er $\alpha$, ikke arbeidets rå vanskelighetsgrad, som forutsier omarbeiding. Modellen har en skarp ledelsesmessig lesning, tegnet i Tabell 1. En lavkontekstoppgave flagges ut rent uansett sin tekniske vanskelighetsgrad. En høykontekstoppgave er ikke uegnet for utflagging; den er uegnet for utflagging uspesifisert, og kommandosentralens jobb er å heve $s$ inntil $\alpha$ er liten nok til å sendes. Der kontekstbelastningen er genuint ureduserbar, der kunnskapen ikke kan nedskrives i det hele tatt, blir oppgaven i hjemlandet, og å erkjenne det ærlig er en del av disiplinen. Sviktmåten modellen navngir, er høykontekstoppgaven sendt med en spesifikasjon av lav fullstendighet: maksimal gjenværende tvetydighet, løst offshore ved gjetning, på maksimal avstand.

6. Klokken

Tidsforskjellen mellom en vestlig forretning og India, noen ni til tolv timer, er egenskapen praktikere oftest behandler som en ren belastning, og den kommandosentralen renest kan gjøre om til et aktivum. Uten tilsyn er avstanden forsinkelse: et spørsmål stilt ved slutten av offshore-dagen besvares ved slutten av hjemmedagen, og en enkelt avklaring koster en kalenderdag uansett sitt innhold, så en kjede av avklaringer koster en uke for å løse en time med reelt innhold. Dette er mekanismen som gjør at dårlig drevet utflagging føles langsom selv når alle jobber hardt: den kritiske veien går gjennom avstanden, og avstanden legger til en dag per kryssing.

Drevet godt er den samme avstanden et ekstra skift. Hvis kommandosentralen overleverer arbeid hvis tvetydigheter allerede er løst, utfører offshore-podene gjennom natten i hjemlandet og returnerer resultater innen morgenen i hjemlandet, og dagen forretningen sover gjennom, er en dag med fremdrift snarere enn en dag med venting. Forskjellen mellom de to utfallene er helt og holdent den gjenværende tvetydigheten $\alpha$ i det som overleveres: en overlevering med $\alpha \approx 0$ trenger ingen tur-retur og klokken er ren gevinst; en overlevering full av uløste spørsmål vender klokken mot deg, fordi hvert spørsmål er en hel dag. En grov måte å se det på er at den effektive hastighetsøkningen fra det ekstra skiftet er

der $\eta$ måler hvor rent arbeid kan overleveres og $\alpha$ er den gjenværende tvetydigheten fra ligning (1); når $\alpha\to 0$ nærmer klokken seg et genuint ekstra skift, og når $\alpha$ stiger, kollapser gevinsten og vender så om til dag-per-spørsmål-skatten. Kommandosentralen fortjener klokken ved å eie spesifikasjonen og definisjonen av ferdig som gjør $\alpha$ liten, og det er derfor follow-the-sun er en konsekvens av god kommando, ikke et planleggingstriks som kan kjøpes separat.

7. Kommandoforholdet

Hvor mye kommando er nok? Spørsmålet har et reelt svar, og det er verken «så lite som mulig», instinktet som produserer kast-det-over-gjerdet-utflagging, eller «så mye som mulig», som gjenoppbygger i hjemlandet kostnaden utflaggingen var ment å kvitte seg med. La $r$ være kommandoforholdet, kapasiteten til kommandosentralen i hjemlandet som en brøkdel av offshore-leveransekapasiteten den styrer. Kommando koster den høye hjemmesatsen $w_c$ per enhet; leveranse koster den lave offshore-satsen $w_o$ per enhet. Verdien av kommando er at det senker den gjenværende tvetydigheten som når podene, og dermed omarbeidingen de må gjøre: mer kommando betyr mer arbeid spesifisert, gjennomgått og portet før og etter at det krysser avstanden, og dermed en lavere omarbeidingsmultiplikator på det leverte arbeidet. En brukbar form for den multiplikatoren er

der $a$ skalerer omarbeidingen som ingen kommando i det hele tatt ville pådra seg, bestemt av arbeidets iboende tvetydighet, og $b$ måler hvor effektivt kommando omsettes til løst tvetydighet. Den totale kostnaden ved å levere én enhet ferdig arbeid, kommando pluss omarbeidet leveranse, er da

en sum av et stigende ledd, kostnaden ved kommando, og et fallende, omarbeidingen kommando forhindrer, så den har ett enkelt indre minimum. Å sette $C'(r)=0$ gir det kostnadsminimerende kommandoforholdet

som er artikkelens sentrale kvantitative resultat. Det sier tre ting en leder kan handle på. Den optimale mengden kommando er positiv: $r^\ast > 0$ når som helst $w_o a b > w_c$, det vil si når som helst kommando i det hele tatt er effektivt og tvetydighet i det hele tatt er reell, så å kaste arbeid over gjerdet ($r = 0$) er aldri optimalt. Den er endelig: kommando utover $r^\ast$ koster mer enn omarbeidingen den sparer, så å beholde alt i hjemlandet er heller ikke optimalt. Og den beveger seg riktig vei: $r^\ast$ stiger med arbeidets tvetydighet ($a$) og med hvor godt kommando løser den ($b$), og faller når kommando i hjemlandet blir dyrt i forhold til offshore-leveranse ($w_c/w_o$), så tvetydige porteføljer med høy kontekst tilsier et tykkere kommandolag og enkle, veldefinerte et tynnere. Figur 2 tegner $C(r)$ og de to sviktregimene på hver side av optimumet.

8. Et konstruert eksempel

Eksempelet er konstruert, ikke observert: tallene er illustrative og internt konsistente, og det er ment å vise modellens størrelser ta plausible verdier snarere enn å rapportere et resultat. En vestlig gruppe driver applikasjonsutvikling for sine backoffice-systemer og flagget for tre år siden ut mesteparten av den til en leverandør i India på innleiebasis: den beholdt en håndfull prosjektledere i hjemlandet, skrev krav i den formen den alltid hadde, og målte suksess etter antall hoder flyttet og dagrate spart. På papiret hadde den halvert kostnaden ved en utvikler. I praksis hadde den gjennomgående leveransen av en funksjon, fra forespørsel til godkjent produksjonsendring, blitt lengre, feilslipraten ut i produksjon hadde steget, og en stor og voksende andel av offshore-teamets timer gikk til å omarbeide funksjoner som var bygget til en rimelig, men feil lesning av et tvetydig krav. Besparelsen var brutto; netto var den tynn og fallende. Tabell 2 gir før-kolonnen.

Gruppen bygget deretter engasjementet om rundt en kommandosentral. Den byttet ikke leverandør eller flyttet arbeid hjem; den la til et tynt, senior lag i hjemlandet, noen få prosent av den totale bemanningen, som tok eierskap til de fem tingene fra avsnitt 4: den omskrev krav til spesifikasjoner med eksplisitte akseptkriterier, skar om arkitekturen slik at hver offshore-pod eide en modul bak et definert grensesnitt, holdt én enkelt ordnet backlog, og kjørte en godkjenningsport før noe nådde produksjon. Offshore-teamet og satsene var uendret; det som endret seg, var den gjenværende tvetydigheten $\alpha$ som nådde det. Omarbeiding falt ettersom spesifikasjoner løste gjetningen som hadde drevet den, feilslipraten sank ettersom porten fanget det avstanden pleide å skjule, og klokken vendte fra forsinkelse til et ekstra skift ettersom overleveringer sluttet å trenge tur-retur. Kostnaden ved den tilførte kommandoen var en brøkdel av omarbeidingen den fjernet, som er ligning (5) i praksis: engasjementet hadde kjørt langt til venstre for $r^\ast$, og å bevege seg mot det senket den totale kostnaden selv om det hevet kostnaden i hjemlandet. Tabell 2 følger endringen.

9. Hva som endrer seg for driftsmodellen

Å ta i bruk kommandosentralen endrer hva en bedrift må være god på, og endringen er ubehagelig fordi den går mot instinktet som motiverte utflaggingen. Besparelsen er fortsatt reell, men den fanges bare ved å bruke penger, i hjemlandet og til seniorsatser, på kommandolaget som den naive forretningsanalysen behandlet som sløsing å eliminere. Tabell 3 angir arbeidsdelingen modellen krever. Den knappe ressursen blir håndfullen seniorfolk som kan holde intensjon, arkitektur og godkjenning godt, og en bedrifts utflaggingskapasitet begrenses av hvor mange slike folk den har, ikke av hvor mange offshore-ingeniører den kan ansette. Målestokken endrer seg også: antall hoder flyttet og dagrate spart, tallene som får kast-det-over-gjerdet-utflagging til å se bra ut, erstattes av ledetid for funksjoner, feilslipp og andelen offshore-timer brukt på omarbeiding, tallene som avslører om kommando gjør jobben sin.

Det finnes et annet skifte, i hvor senioriteten sitter. Kast-det-over-gjerdet-utflagging har en tendens til å sende det interessante, seniore arbeidet offshore sammen med resten og beholde et juniort koordineringslag hjemme; kommandosentralmodellen snur dette, og holder senioriteten i hjemlandet der konteksten er, og lar offshore-teamet være utmerket på utførelse uten å bli bedt om å levere kontekst det ikke kan ha. Dette feiltolkes ofte som mistillit til offshore-teamet. Det er det motsatte: det er ordningen som lar et dyktig offshore-team gjøre sitt beste arbeid, ved ikke å be det om å løse tvetydigheter som ingen på dets avstand kunne løst godt, og ved å gi det spesifikasjoner klare nok til at kompetansen dets brukes på å bygge snarere enn å gjette.

10. Innvendinger og svar

Kommandosentralen legger bare til kostnad i hjemlandet og uthuler besparelsen. Den legger til kostnad i hjemlandet og hever nettobesparelsen, som er hele poenget med ligning (5): de fleste mislykkede engasjementer sitter langt til venstre for $r^\ast$, der litt mer kommando fjerner langt mer omarbeiding enn det koster. Kommandosentralen er ikke overhead på besparelsen; den er mekanismen som gjør en bruttobesparelse om til en nettobesparelse. En bedrift som genuint allerede er ved $r^\ast$, bør ikke legge til kommando; nesten ingen er det.

Hvis du må spesifisere alt så presist, hvorfor ikke bare bygge det i hjemlandet? Fordi spesifikasjon og konstruksjon har svært ulike kostnader og svært ulik knapphet. Spesifikasjon er en liten mengde senior, kontekstbundet arbeid; konstruksjon er en stor mengde arbeid som ikke er kontekstbundet når det først er spesifisert. Modellen sender den store, billig-å-plassere mengden dit den er rimelig, og beholder bare den lille, kontekstbundne mengden hjemme. Å slå de to sammen igjen gir avkall på nettopp den arbitrasjen som er reell.

Moderne verktøy og videosamtaler har gjort avstand irrelevant. De har gjort den mindre, ikke irrelevant, og bevisene for at avstand fortsatt betyr noe, er robuste (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Verktøy senker kostnaden ved en kryssing; de fjerner ikke dagen klokken legger til en tur-retur, og gjenoppretter heller ikke den uformelle, omsluttende kommunikasjonen samlokaliserte team bruker til å løse tvetydighet uten å merke det. Kommandosentralen er det strukturelle svaret som verktøy utfyller, men ikke erstatter.

Vår offshore-partner er svært dyktig og kan eie det hele. Dyktighet er ikke problemet; kontekst er det. Et svært dyktig offshore-team kan fortsatt ikke løse en tvetydighet hvis løsning krever å vite hva forretningen mente, og å be det om å gjøre det, setter kompetansen dets opp mot et problem avstand gjør uløselig. Modellen holder ansvaret i hjemlandet ikke fordi offshore-teamet er svakt, men fordi ansvar er bundet til en kontekst som er i hjemlandet.

11. Begrensninger

Dette er et praktikerrettet argument med en bevisst enkel modell, og dens begrensninger bør være tydelige. Modellen i avsnitt 5 til 7 er illustrativ: formen for gjenværende tvetydighet i ligning (1), den eksponentielle omarbeidingsmultiplikatoren i ligning (3) og det ene optimale forholdet i ligning (5) er forenklinger valgt for lesbarhet, og konstantene $a$, $b$, $w_c$ og $w_o$ er ikke målt her; en bedrift kan anslå dem fra sine egne omarbeidings- og satsdata, og vi ville forvente at den kvalitative formen, et indre optimum som beveger seg med tvetydighet og relativ kostnad, overlever selv der den eksakte formen ikke gjør det. Argumentet er avgrenset til arbeid hvis tvetydigheter, med innsats, kan løses opp i spesifikasjon; genuint forskningslignende arbeid, der ingen ennå vet hva riktig er, passer modellen dårlig og bør stort sett forbli samlokalisert. Artikkelen trekker på India fordi det er der dybden i tilbudet og omfanget av praksisen er, men ingenting i modellen er spesifikt for et land; den gjelder for enhver deling mellom hjemland og offshore over en reell avstand og klokke. Og modellen forutsetter en bedrift som i det hele tatt er i stand til å bemanne et senior kommandolag; en bedrift som ikke kan det, bør være ærlig på at den ennå ikke er i stand til å flagge ut godt, snarere enn å flagge ut dårlig og kalle resultatet en dom over India.

12. Konklusjon

Utflagging av IT-arbeid til India skuffer bedrifter som flagger ut feil ting: de sender ut ansvar sammen med utførelsen, kobler arbeidet løs fra konteksten og dømmekraften som gjør det riktig, og ser så omarbeiding og klokken spise opp besparelsen de kom for. Reparasjonen er ikke å hente arbeidet hjem, men å dele det riktig, og holde i hjemlandet den tynne, seniore kommandoen som må bli værende ved siden av forretningen, å bestemme hva som skal bygges, å eie arkitekturen og grensesnittene, å gjøre intensjon om til spesifikasjon, og å holde godkjenning, mens utførelsen skaleres i India der talent er rikelig og rimelig. Hvor grensen skal trekkes, er et spørsmål den gjenværende tvetydigheten i en oppgave besvarer, og kommandosentralens håndverk er å heve spesifikasjonen inntil den tvetydigheten er liten nok til å krysse avstanden; hvor mye kommando man skal beholde, er et spørsmål med et reelt optimum, positivt og endelig, som stiger med arbeidets tvetydighet og faller når kommando blir dyrt. Gjort på denne måten slutter avstanden å være en skatt, og tolvtimersklokken blir et ekstra skift, og arbitrasjen som alltid var reell, beholdes endelig. Flagg ut byggingen; styr den hjemmefra. En bedrift som husker hvilken av de to som er bundet til kontekst, og hvilken som ikke er det, kan mestre utflagging til India; en bedrift som glemmer, vil fortsette å konkludere, feilaktig, med at problemet var den andre enden av linjen.

Tillegg A. Å reise en kommandosentral

Praksisene nedenfor er det som får delingen fra avsnitt 4 til å holde i praksis. Ingen er ny; disiplinen er verdien.

Referanser

Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley. ISBN 978-0-201-83595-3. (Original work published 1975.)

Carmel, E. (1999). Global software teams: Collaborating across borders and time zones. Prentice Hall. ISBN 978-0-13-924218-6.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22–29. https://doi.org/10.1109/52.914734

Carmel, E., & Tjia, P. (2005). Offshoring information technology: Sourcing and outsourcing to a global workforce. Cambridge University Press. ISBN 978-0-521-84355-4.

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

Herbsleb, J. D., & Grinter, R. E. (1999). Splitting the organization and integrating the code: Conway’s law revisited. In Proceedings of the 21st International Conference on Software Engineering (ICSE) (pp. 85–95). ACM. https://doi.org/10.1145/302405.302455

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494. https://doi.org/10.1109/TSE.2003.1205177

Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81. https://doi.org/10.1145/203330.203345

Krishna, S., Sahay, S., & Walsham, G. (2004). Managing cross-cultural issues in global software outsourcing. Communications of the ACM, 47(4), 62–66. https://doi.org/10.1145/975817.975818

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. Journal of Strategic Information Systems, 18(3), 130–146. https://doi.org/10.1016/j.jsis.2009.06.002

Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87–119. https://doi.org/10.1145/174666.174668

Olson, G. M., & Olson, J. S. (2000). Distance matters. Human–Computer Interaction, 15(2–3), 139–178. https://doi.org/10.1207/S15327051HCI1523_4

Oshri, I., Kotlarsky, J., & Willcocks, L. P. (2007). Managing dispersed expertise in IT offshore outsourcing: Lessons from Tata Consultancy Services. MIS Quarterly Executive, 6(2), 53–65. https://aisel.aisnet.org/misqe/vol6/iss2/3/

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Ramasubbu, N., & Balan, R. K. (2007). Globally distributed software development project performance: An empirical analysis. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2007) (pp. 125–134). ACM. https://doi.org/10.1145/1287624.1287643

Rottman, J. W., & Lacity, M. C. (2006). Proven practices for effectively offshoring IT work. MIT Sloan Management Review, 47(3), 56–63. https://sloanreview.mit.edu/article/proven-practices-for-effectively-offshoring-it-work/

Sahay, S., Nicholson, B., & Krishna, S. (2003). Global IT outsourcing: Software development across borders. Cambridge University Press. ISBN 978-0-521-81604-5.