1. Introduzione

Per due decenni l’offerta è stata la stessa e l’aritmetica è sembrata irresistibile. Un ingegnere in India costa una frazione di uno in Europa occidentale o negli Stati Uniti, la loro disponibilità è ampia e ben formata, e l’inglese è la lingua di lavoro, cosicché un’azienda che sposti lì il proprio lavoro software dovrebbe, sulla carta, fare lo stesso lavoro per molto meno. Moltissimo lavoro si è spostato esattamente su questo ragionamento, e l’India vi ha costruito sopra un’industria di servizi IT di livello mondiale. Eppure i risultati, azienda per azienda, sono sorprendentemente disomogenei: alcune organizzazioni ottengono dall’India software eccellente per anni, mentre altre ottengono una fattura crescente, una qualità della consegna calante e un flusso di difetti che gli stipendi risparmiati non coprono mai del tutto, finché non dichiarano fallito l’offshoring e riportano il lavoro a casa, spesso concludendo che il problema era l’India. Non era l’India.

Il problema è che le aziende delocalizzano la cosa sbagliata. L’intuizione alla base dell’offshoring è che lo sviluppo software sia esecuzione, una quantità di lavoro misurabile in ore-persona e acquistabile ovunque le ore-persona costino meno, e su questa intuizione un’azienda consegna una specifica e un numero di addetti e attende l’output. Ma lo sviluppo software non è principalmente esecuzione; è la risoluzione di mille piccole ambiguità, ciascuna delle quali richiede di sapere cosa l’azienda intendesse davvero, come questa parte debba incastrarsi nel tutto e cosa significhi davvero “finito” qui, e quella conoscenza vive dove sta il business, non dove stanno le tastiere. Quando un’azienda delocalizza l’esecuzione, delocalizza inconsapevolmente anche quelle decisioni, alle persone più lontane dal contesto necessario per prenderle bene, e il risultato è un lavoro localmente plausibile e globalmente errato, scoperto in ritardo, attraverso uno scarto di dodici ore, e corretto lentamente. L’arbitraggio sul lavoro è reale; il coordinamento e la rilavorazione che esso innesca, gestiti male, sono maggiori.

Questo articolo tratta del modello operativo che corregge l’errore non commettendolo, e il modello ha un nome che useremo in tutto il testo: il centro di comando onshore. L’idea è separare, deliberatamente e strutturalmente, le due cose che un offshoring ingenuo confonde. Una è l’esecuzione, la costruzione, che davvero può e deve scalare dove il talento è abbondante e accessibile, in India. L’altra è il comando: decidere cosa costruire e in quale ordine, possedere l’architettura e le interfacce tra le parti, trasformare ciò che il business vuole vagamente in una specifica abbastanza precisa da essere costruita a grande distanza senza una conversazione, e giudicare se ciò che è tornato è giusto. Il comando è piccolo, senior e costoso, e resta onshore, accanto al business di cui esiste per portare l’intento. La tesi è che il successo di un programma di offshoring sia determinato quasi interamente dal fatto che questo strato di comando esista e sia buono, e quasi per nulla dalla capacità grezza del team offshore, che di solito va bene; e che le aziende falliscono per sotto-investimento nel comando proprio perché il comando è la parte costosa e onshore che l’offshoring avrebbe dovuto eliminare.

Il contributo è un argomento e un piccolo modello, non un benchmark. La Sezione 2 colloca la tesi rispetto alla storia dell’offshoring e dell’ingegneria del software globale. La Sezione 3 diagnostica il vero fallimento: delocalizzare la responsabilità anziché la sola esecuzione. La Sezione 4 descrive il centro di comando e ciò che possiede. La Sezione 5 fornisce un modello di dove debba cadere la linea tra comando e consegna, imperniato su carico di contesto e completezza della specifica. La Sezione 6 tratta l’orologio, e come il follow-the-sun diventi leva anziché latenza. La Sezione 7 deriva il rapporto di comando ottimale. La Sezione 8 traccia un caso costruito; le Sezioni da 9 a 12 ne traggono le conseguenze, rispondono alle obiezioni, enunciano i limiti e concludono. La domanda di fondo è: cosa deve un’azienda tenere a casa, e quanto, affinché il lavoro che invia in India torni giusto?

2. Contesto

2.1 Il bilancio dell’offshoring

L’outsourcing e l’offshoring dell’IT hanno una delle maggiori letterature empiriche dei sistemi informativi, e il loro verdetto non è che l’offshoring non convenga, ma che il suo ritorno dipende da come viene gestito. Lacity, Khan e Willcocks (2009), passando in rassegna due decenni di studi, rilevano che sono le capacità del cliente e del fornitore, la progettazione del contratto e la gestione della relazione, più delle sole differenze salariali, a spiegare il divario tra incarichi riusciti e falliti. Carmel e Tjia (2005) hanno fornito il resoconto dei professionisti sull’approvvigionamento presso una forza lavoro globale e catalogato i modi in cui la distanza erode l’arbitraggio; Sahay, Nicholson e Krishna (2003) hanno dato il resoconto, lungo quanto un libro, dello sviluppo software attraverso il confine indiano, e Oshri, Kotlarsky e Willcocks (2007) hanno ricostruito come un fornitore indiano di primo piano abbia organizzato un modello di delivery globale attorno a competenze disperse. Rottman e Lacity (2006) hanno distillato pratiche collaudate e scoperto che le aziende che hanno avuto successo hanno investito molto nel lavoro onshore di specificare, coordinare e governare, esattamente il lavoro che questo articolo chiama comando. La constatazione costante è che il risparmio è lordo, non netto, e che ciò che si frappone tra i due è uno sforzo gestionale che per lo più resta a casa.

2.2 Perché la distanza è costosa

Una seconda letteratura, sullo sviluppo software distribuito a livello globale, ne spiega il meccanismo. Herbsleb e Mockus (2003), nello studio più centrale per questo articolo, hanno mostrato empiricamente che gli elementi di lavoro che richiedono persone in più sedi richiedevano un tempo sostanzialmente maggiore per essere completati rispetto ad analoghi elementi di sede unica, e hanno ricondotto il ritardo al costo e alla latenza della comunicazione che il coordinamento tra sedi richiede. Ramasubbu e Balan (2007), studiando progetti dispersi tra India e Stati Uniti, hanno misurato la stessa penalizzazione direttamente nelle prestazioni di progetto. Olson e Olson (2000) hanno enunciato il risultato generale sotto il titolo “la distanza conta”: il lavoro co-locato beneficia di una comunicazione rapida, ricca e informale che il lavoro distribuito perde, e nessuno strumento la ripristina del tutto. Kraut e Streeter (1995) avevano già mostrato quanta parte dello sviluppo software sia coordinamento anziché codifica, e Brooks (1975) aveva da molto tempo dato la ragione per cui aggiungere persone a un lavoro distribuito può rallentarlo: i percorsi di comunicazione crescono più in fretta delle persone. La lezione non è che lo sviluppo distribuito non possa funzionare, ma che ogni confine che un pezzo di lavoro deve attraversare ha un prezzo, e il prezzo si paga in tempo e difetti.

2.3 La legge di Conway e l’architettura del confine

L’idea più profonda su cui l’articolo si appoggia è quella di Conway (1968): la struttura di un sistema finisce per rispecchiare la struttura di comunicazione dell’organizzazione che lo costruisce. Il suo corollario per l’offshoring è esatto e poco sfruttato. Se offshore e onshore sono due gruppi che comunicano debolmente, allora il software sarà più pulito quando il confine tra loro cade lungo una genuina giuntura architetturale, un modulo con un’interfaccia definita, e sarà più problematico dove un unico blocco di lavoro strettamente accoppiato è diviso attraverso lo scarto. Herbsleb e Grinter (1999) lo hanno confermato direttamente, scoprendo che lo sviluppo distribuito riesce quando l’architettura è abbastanza modulare da far sì che ogni sede possieda una parte e che le interfacce tra le parti siano esplicite, e stenta quando non lo è. Parnas (1972) ha fornito la disciplina di progettazione, l’occultamento dell’informazione, che rende possibili tali moduli. La conseguenza pratica, sviluppata nella Sezione 4, è che possedere l’architettura non è uno dei tanti compiti del centro di comando; è il compito che rende possibili tutti gli altri, perché decide dove cade il costoso confine.

3. Il vero fallimento: delocalizzare la responsabilità

Il fallimento tipico dell’offshoring non è la digitazione lenta; è il lavoro portato a termine con sicurezza e silenziosamente errato. Viene consegnato un requisito completo nella testa di chi lo invia e ambiguo sulla pagina, perché chi invia condivide con il business un contesto che chi riceve non ha. L’ingegnere offshore, competente e volenteroso, risolve l’ambiguità nell’unico modo disponibile a dodici fusi orari di distanza: tirando a indovinare, ragionevolmente, e costruendo. L’ipotesi si scopre essere errata in fase di accettazione, se c’è accettazione, o in produzione, se non c’è, e la correzione attraversa lo scarto due volte, una per spiegare e una per verificare, ogni attraversamento un giorno perso all’orologio. Si moltiplichi questo per ogni ambiguità di un sistema reale e l’arbitraggio è svanito, non perché qualcuno abbia fatto qualcosa di incompetente, ma perché le decisioni che richiedevano contesto sono state prese dove non ce n’era.

Ciò che è accaduto, nel linguaggio di questo articolo, è che l’azienda ha delocalizzato la responsabilità quando intendeva delocalizzare solo l’esecuzione. La responsabilità di un pezzo di software è l’autorità accumulata per risolverne correttamente le ambiguità: sapere cosa intendesse il business, decidere come la parte serve il tutto, dire cosa sia “corretto”. Quell’autorità è inseparabile dal contesto, e il contesto è locale. L’esecuzione, la costruzione di una cosa una volta risolte le sue ambiguità, non è legata al contesto e viaggia bene. L’errore è trattare le due come un unico pacco e spedirle insieme; il rimedio è separarle, tenere la responsabilità onshore dove vive il suo contesto, e inviare offshore solo l’esecuzione, con le sue ambiguità già risolte in specifica. Tutto ciò che segue è un’elaborazione di come effettuare questa separazione e dove.

4. Il centro di comando

Il centro di comando onshore è la sede organizzativa della responsabilità che non deve viaggiare. È deliberatamente piccolo e deliberatamente senior, perché la sua leva viene dalla qualità di poche decisioni anziché dalla quantità di output, e siede accanto al business, non accanto alle tastiere. La Figura 1 disegna il modello e la Tabella 3 ripartisce il lavoro. Il centro di comando possiede cinque cose, e la disciplina del modello è che le possiede tutte e cinque e cerca di non possedere nient’altro.

Dall’intento alla specifica. Il primo prodotto del centro di comando non è software ma specifica: la traduzione di ciò che il business vuole vagamente in un resoconto abbastanza preciso da poter essere costruito da qualcuno che non può sporgersi e chiedere. È il lavoro che risolve l’ambiguità dove sta il contesto, così che nessuna debba essere risolta dove non c’è, ed è l’attività a più alta leva dell’intero modello, perché ogni ambiguità lasciata in una specifica viene pagata più tardi al costo pieno di un viaggio di andata e ritorno attraverso lo scarto.

Architettura e interfacce. Per la legge di Conway il software si fratturerà lungo le giunture di comunicazione dell’organizzazione, perciò il centro di comando possiede l’architettura proprio allo scopo di scegliere dove quelle giunture cadono: scompone il sistema in moduli con interfacce esplicite così che ogni pod offshore possieda una parte che può costruire con poche dipendenze trasversali al confine. Tracciare bene il confine è ciò che converte la distanza da una tassa pagata su ogni interazione in una tassa pagata solo a poche interfacce ben definite.

Prioritizzazione. Cosa viene costruito per primo è un giudizio di business, non di consegna, e resta al centro di comando, che detiene l’unico backlog e il suo ordine. Disperdere la prioritizzazione al team offshore, o a più stakeholder contemporaneamente, reintroduce attraverso lo scarto esattamente il coordinamento che il modello esiste per contenere.

Accettazione e gate di qualità. Il centro di comando decide cosa sia “finito” e collauda contro di esso il lavoro restituito, presidiando un gate di cui il business si fida. È la controparte della specifica: avendo definito la correttezza a monte, la verifica al ritorno, e poiché è onshore e vicino al business può giudicarne l’idoneità, non la mera funzione.

Un unico responsabile. Infine, il centro di comando è dove la responsabilità è indivisa: un unico titolare che risponde al business di ciò che viene consegnato, e che non può puntare il dito oltre lo scarto. Una responsabilità divisa attraverso il confine è una responsabilità andata perduta, e riportarla a un unico punto onshore è gran parte di ciò che rende governabile il modello.

5. Tracciare la linea

Se il comando resta onshore e l’esecuzione va offshore, tutto dipende da dove si traccia la linea tra loro, compito per compito. Il modello che governa la scelta ha due assi. Il primo è il carico di contesto di un compito: quanta conoscenza locale, tacita e specifica del business richiede la sua corretta risoluzione, alto per una modifica che tocca una sottile regola normativa o un impegno di lunga data verso il cliente, basso per un componente ben delimitato con un contratto chiaro. Il secondo è la completezza della specifica che il centro di comando può dargli: quanto pienamente le sue ambiguità possano essere risolte in anticipo, sulla carta, senza una conversazione. Un compito è sicuro da delocalizzare quando l’ambiguità residua che raggiunge il pod offshore, il suo carico di contesto al netto della completezza della specifica applicata, è piccola. Scrivendo $\kappa$ per il carico di contesto e $s$ per la completezza della specifica, entrambi su una scala comune, il residuo è

ed è $\alpha$, non la difficoltà grezza del lavoro, a prevedere la rilavorazione. Il modello ha una lettura manageriale netta, disegnata nella Tabella 1. Un compito a basso contesto si delocalizza in modo pulito qualunque sia la sua difficoltà tecnica. Un compito ad alto contesto non è inadatto all’offshoring; è inadatto all’offshoring non specificato, e il compito del centro di comando è alzare $s$ finché $\alpha$ non sia abbastanza piccola da poter essere inviata. Dove il carico di contesto è genuinamente irriducibile, dove la conoscenza non può affatto essere messa per iscritto, il compito resta onshore, e riconoscerlo onestamente fa parte della disciplina. La modalità di fallimento che il modello nomina è il compito ad alto contesto spedito con una specifica a bassa completezza: massima ambiguità residua, risolta offshore a indovinare, alla massima distanza.

6. L’orologio

La differenza di orario tra un’azienda occidentale e l’India, circa da nove a dodici ore, è la caratteristica che i professionisti più spesso trattano come pura passività e quella che il centro di comando può convertire più nettamente in un asset. Non governato, lo scarto è latenza: una domanda posta alla fine della giornata offshore riceve risposta alla fine della giornata onshore, e una singola chiarificazione costa un giorno di calendario qualunque sia la sua sostanza, cosicché una catena di chiarificazioni costa una settimana per risolvere un’ora di contenuto reale. È il meccanismo per cui un offshoring gestito male sembra lento anche quando tutti lavorano sodo: il percorso critico passa per lo scarto, e lo scarto aggiunge un giorno per ogni attraversamento.

Gestito bene, lo stesso scarto è un secondo turno. Se il centro di comando passa lavoro le cui ambiguità sono già risolte, i pod offshore eseguono durante la notte onshore e restituiscono i risultati entro la mattina onshore, e il giorno che il business trascorre dormendo è un giorno di progresso anziché un giorno di attesa. La differenza tra i due esiti è interamente l’ambiguità residua $\alpha$ di ciò che viene passato: un passaggio di consegne con $\alpha \approx 0$ non necessita di alcun viaggio di andata e ritorno e l’orologio è puro guadagno; un passaggio pieno di domande irrisolte volge l’orologio contro di te, perché ogni domanda è un giorno intero. Un modo grossolano di vederlo è che l’accelerazione effettiva dovuta al secondo turno è

dove $\eta$ misura quanto nettamente il lavoro può essere passato e $\alpha$ è l’ambiguità residua dell’equazione (1); quando $\alpha\to 0$ l’orologio si avvicina a un genuino turno aggiuntivo, e quando $\alpha$ sale il guadagno crolla e poi si rovescia nella tassa del giorno-per-domanda. Il centro di comando si guadagna l’orologio possedendo la specifica e la definizione di finito che rendono $\alpha$ piccola, ed è per questo che il follow-the-sun è una conseguenza di un buon comando, non un trucco di pianificazione acquistabile a parte.

7. Il rapporto di comando

Quanto comando è abbastanza? La domanda ha una risposta reale, e non è né “il meno possibile”, l’istinto che produce l’offshoring del gettare-oltre-il-muro, né “il più possibile”, che ricostruisce onshore il costo che l’offshoring doveva eliminare. Sia $r$ il rapporto di comando, la capacità del centro di comando onshore come frazione della capacità di consegna offshore che governa. Il comando costa l’alta tariffa onshore $w_c$ per unità; la consegna costa la bassa tariffa offshore $w_o$ per unità. Il valore del comando è che abbassa l’ambiguità residua che raggiunge i pod e quindi la rilavorazione che devono fare: più comando significa più lavoro specificato, revisionato e sottoposto a gate prima e dopo che attraversa lo scarto, e quindi un moltiplicatore di rilavorazione più basso sul lavoro consegnato. Una forma utilizzabile per quel moltiplicatore è

dove $a$ scala la rilavorazione che l’assenza totale di comando comporterebbe, fissata dall’ambiguità intrinseca del lavoro, e $b$ misura quanto efficacemente il comando si converte in ambiguità risolta. Il costo totale di consegna di un’unità di lavoro finito, comando più consegna rilavorata, è allora

una somma di un termine crescente, il costo del comando, e di uno decrescente, la rilavorazione che il comando previene, cosicché ha un unico minimo interno. Ponendo $C'(r)=0$ si ottiene il rapporto di comando che minimizza il costo

che è il risultato quantitativo centrale dell’articolo. Dice tre cose su cui un manager può agire. La quantità ottimale di comando è positiva: $r^\ast > 0$ ogni volta che $w_o a b > w_c$, cioè ogni volta che il comando è in qualche misura efficace e l’ambiguità in qualche misura reale, perciò gettare il lavoro oltre il muro ($r = 0$) non è mai ottimale. È finita: comando oltre $r^\ast$ costa più della rilavorazione che risparmia, perciò tenere tutto onshore non è ottimale nemmeno. E si muove nella direzione giusta: $r^\ast$ cresce con l’ambiguità del lavoro ($a$) e con quanto bene il comando la risolve ($b$), e cala man mano che il comando onshore diventa costoso rispetto alla consegna offshore ($w_c/w_o$), cosicché portafogli ambigui e ad alto contesto giustificano uno strato di comando più spesso e quelli semplici e ben delimitati uno più sottile. La Figura 2 disegna $C(r)$ e i due regimi di fallimento ai due lati dell’ottimo.

8. Un caso costruito

Il caso è costruito, non osservato: le sue cifre sono illustrative e internamente coerenti, ed è pensato per mostrare le grandezze del modello assumere valori plausibili più che per riportare un risultato. Un gruppo occidentale gestisce lo sviluppo applicativo per i propri sistemi di back-office e, tre anni fa, ne ha delocalizzato il grosso presso un fornitore in India su base di staff augmentation: ha tenuto una manciata di project manager onshore, ha scritto i requisiti nella forma di sempre, e ha misurato il successo in base all’organico spostato e alla tariffa giornaliera risparmiata. Sulla carta aveva dimezzato il costo di uno sviluppatore. In pratica la consegna diretta di una funzionalità, dalla richiesta alla modifica di produzione accettata, si era allungata, il tasso di difetti sfuggiti in produzione era salito, e una quota ampia e crescente delle ore del team offshore finiva nel rilavorare funzionalità costruite su una lettura ragionevole ma errata di un requisito ambiguo. Il risparmio era lordo; al netto, era magro e calante. La Tabella 2 fornisce la colonna del prima.

Il gruppo ha poi ricostruito l’incarico attorno a un centro di comando. Non ha cambiato fornitore né riportato il lavoro a casa; ha aggiunto uno strato onshore sottile e senior, una piccola percentuale dell’organico totale, che ha preso in carico le cinque cose della Sezione 4: ha riscritto i requisiti come specifiche con criteri di accettazione espliciti, ha ri-tagliato l’architettura così che ogni pod offshore possedesse un modulo dietro un’interfaccia definita, ha tenuto un unico backlog ordinato, e ha eseguito un gate di accettazione prima che qualsiasi cosa raggiungesse la produzione. Il team offshore e le sue tariffe erano invariati; ciò che è cambiato è l’ambiguità residua $\alpha$ che lo raggiungeva. La rilavorazione è calata man mano che le specifiche risolvevano le congetture che l’avevano guidata, il tasso di difetti sfuggiti è sceso man mano che il gate intercettava ciò che lo scarto soleva nascondere, e l’orologio si è trasformato da latenza in un secondo turno man mano che i passaggi di consegne smettevano di richiedere viaggi di andata e ritorno. Il costo del comando aggiunto è stato una frazione della rilavorazione che ha rimosso, cioè l’equazione (5) in pratica: l’incarico stava girando molto a sinistra di $r^\ast$, e spostarsi verso di esso ha abbassato il costo totale pur innalzando il costo onshore. La Tabella 2 traccia il cambiamento.

9. Cosa cambia per il modello operativo

Adottare il centro di comando cambia ciò in cui un’azienda deve essere brava, e il cambiamento è scomodo perché va contro l’istinto che ha motivato l’offshoring. Il risparmio è ancora reale, ma lo si cattura solo spendendo, onshore e a tariffe senior, sullo strato di comando che il business case ingenuo trattava come spreco da eliminare. La Tabella 3 espone la divisione del lavoro che il modello richiede. La risorsa scarsa diventa la manciata di persone senior capaci di tenere bene intento, architettura e accettazione, e la capacità di offshoring di un’azienda è limitata da quante persone del genere possiede, non da quanti ingegneri offshore può assumere. Cambia anche la metrica: l’organico spostato e la tariffa giornaliera risparmiata, i numeri che fanno sembrare buono l’offshoring del gettare-oltre-il-muro, sono sostituiti dal lead time delle funzionalità, dai difetti sfuggiti e dalla quota di ore offshore spese in rilavorazione, i numeri che rivelano se il comando sta facendo il suo lavoro.

C’è un secondo spostamento, in dove si colloca la seniority. L’offshoring del gettare-oltre-il-muro tende a mandare offshore il lavoro interessante e senior insieme al resto e a tenere a casa uno strato junior di coordinamento; il modello del centro di comando lo inverte, tenendo la seniority onshore dove sta il contesto e lasciando che il team offshore sia eccellente nell’esecuzione senza che gli si chieda di fornire un contesto che non può avere. Questo viene spesso frainteso come sfiducia nel team offshore. È il contrario: è l’assetto che permette a un team offshore capace di dare il meglio, non chiedendogli di risolvere ambiguità che nessuno alla sua distanza potrebbe risolvere bene, e fornendogli specifiche abbastanza chiare da far sì che la sua competenza si spenda nel costruire anziché nell’indovinare.

10. Obiezioni e risposte

Il centro di comando non fa che aggiungere costo onshore ed erodere il risparmio. Aggiunge costo onshore e innalza il risparmio netto, che è l’intero senso dell’equazione (5): la maggior parte degli incarichi fallimentari si colloca molto a sinistra di $r^\ast$, dove un po’ più di comando rimuove molta più rilavorazione di quanta ne costi. Il centro di comando non è un sovraccarico sul risparmio; è il meccanismo che converte un risparmio lordo in uno netto. Un’azienda genuinamente già a $r^\ast$ non dovrebbe aggiungere comando; quasi nessuna lo è.

Se bisogna specificare tutto con tanta precisione, perché non costruirlo direttamente onshore? Perché specifica e costruzione hanno costi molto diversi e scarsità molto diverse. La specifica è una piccola quantità di lavoro senior e legato al contesto; la costruzione è una grande quantità di lavoro che, una volta specificato, non è legato al contesto. Il modello invia la grande quantità, facile da ricollocare, dove è accessibile e tiene a casa solo la piccola quantità legata al contesto. Far ricollassare le due insieme rinuncia esattamente all’arbitraggio che è reale.

Gli strumenti moderni e le videochiamate hanno reso la distanza irrilevante. L’hanno resa più piccola, non irrilevante, e l’evidenza che la distanza conti ancora è robusta (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Gli strumenti abbassano il costo di un attraversamento; non eliminano il giorno che l’orologio aggiunge a un viaggio di andata e ritorno, né ripristinano la comunicazione informale e ambientale che i team co-locati usano per risolvere l’ambiguità senza accorgersene. Il centro di comando è la risposta strutturale che gli strumenti integrano ma non sostituiscono.

Il nostro partner offshore è molto capace e può farsi carico di tutto. La capacità non è il problema; il contesto lo è. Un team offshore altamente capace non può comunque risolvere un’ambiguità la cui risoluzione richiede di sapere cosa intendesse il business, e chiederglielo mette la sua competenza contro un problema che la distanza rende insolubile. Il modello tiene la responsabilità onshore non perché il team offshore sia debole, ma perché la responsabilità è legata a un contesto che è onshore.

11. Limiti

Questo è un argomento rivolto ai professionisti, con un modello deliberatamente semplice, e i suoi limiti dovrebbero essere evidenti. Il modello delle Sezioni da 5 a 7 è illustrativo: la forma dell’ambiguità residua dell’equazione (1), il moltiplicatore di rilavorazione esponenziale dell’equazione (3) e l’unico rapporto ottimale dell’equazione (5) sono semplificazioni scelte per leggibilità, e le costanti $a$, $b$, $w_c$ e $w_o$ non sono qui misurate; un’azienda può stimarle dai propri dati di rilavorazione e di tariffa, e ci aspetteremmo che la forma qualitativa, un ottimo interno che si sposta con l’ambiguità e il costo relativo, sopravviva anche dove la forma esatta non lo fa. L’argomento è circoscritto al lavoro le cui ambiguità possono, con sforzo, essere risolte in specifica; un lavoro genuinamente simile alla ricerca, dove nessuno sa ancora cosa sia corretto, si adatta male al modello e dovrebbe per lo più restare co-locato. L’articolo si appoggia all’India perché è lì che stanno la profondità dell’offerta e la scala della pratica, ma nulla nel modello è specifico di un paese; si applica a qualsiasi divisione onshore–offshore attraverso una distanza e un orologio reali. E il modello presuppone un’azienda in grado di dotarsi di uno strato di comando senior; un’azienda che non può dovrebbe essere onesta sul fatto di non essere ancora in grado di delocalizzare bene, anziché delocalizzare male e chiamare il risultato un verdetto sull’India.

12. Conclusione

L’offshoring del lavoro IT verso l’India delude le aziende che delocalizzano la cosa sbagliata: spediscono fuori la responsabilità insieme all’esecuzione, staccando il lavoro dal contesto e dal giudizio che lo rendono corretto, e poi guardano la rilavorazione e l’orologio divorare il risparmio per cui erano venute. Il rimedio non è riportare il lavoro a casa, ma dividerlo correttamente, tenendo onshore il comando sottile e senior che deve restare accanto al business, decidere cosa costruire, possedere l’architettura e le interfacce, trasformare l’intento in specifica, e detenere l’accettazione, mentre l’esecuzione scala in India, dove il talento è abbondante e accessibile. Dove tracciare la linea è una domanda a cui risponde l’ambiguità residua di un compito, e l’arte del centro di comando è alzare la specifica finché quell’ambiguità non sia abbastanza piccola da attraversare lo scarto; quanto comando tenere è una domanda con un ottimo reale, positivo e finito, che cresce con l’ambiguità del lavoro e cala man mano che il comando diventa caro. Fatto così, la distanza smette di essere una tassa e l’orologio di dodici ore diventa un secondo turno, e l’arbitraggio che è sempre stato reale viene finalmente conservato. Delocalizza la costruzione; comandala da casa. Un’azienda che ricorda quale delle due è legata al contesto, e quale no, può padroneggiare l’offshoring verso l’India; un’azienda che dimentica continuerà a concludere, erroneamente, che il problema era l’altro capo della linea.

Appendice A. Allestire un centro di comando

Le pratiche seguenti sono ciò che fa reggere nella pratica la separazione della Sezione 4. Nessuna è nuova; il valore sta nella disciplina.

Bibliografia

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.