1. Introducción

Durante dos décadas la oferta ha sido la misma y la aritmética ha parecido irresistible. Un ingeniero en la India cuesta una fracción de lo que cuesta uno en Europa Occidental o en Estados Unidos, su oferta es amplia y está bien formada, y el inglés es la lengua de trabajo, de modo que una empresa que traslade allí su trabajo de software debería, sobre el papel, hacer el mismo trabajo por mucho menos. Una gran cantidad de trabajo se ha trasladado por ese mismo razonamiento, y la India ha construido sobre él una industria de servicios de TI de primer nivel. Y sin embargo los resultados, empresa por empresa, son llamativamente desiguales: algunas organizaciones obtienen software excelente de la India durante años, mientras otras obtienen una factura creciente, una calidad de entrega decreciente y un flujo de defectos que los salarios ahorrados nunca llegan a cubrir, hasta que declaran el offshoring un fracaso y traen el trabajo de vuelta a casa, a menudo para concluir que el problema era la India. No era la India.

El problema es que las empresas deslocalizan lo que no deben. La intuición detrás del offshoring es que el desarrollo de software es ejecución, una cantidad de trabajo que puede medirse en persona-horas y comprarse allí donde las persona-horas son más baratas, y sobre esa intuición una empresa entrega una especificación y una plantilla y espera resultados. Pero el desarrollo de software no es principalmente ejecución; es la resolución de mil pequeñas ambigüedades, cada una de las cuales exige saber qué quiso decir realmente el negocio, cómo se supone que esta parte encaja en el todo y qué significa de verdad «terminado» aquí, y ese conocimiento vive donde está el negocio, no donde están los teclados. Cuando una empresa deslocaliza la ejecución, deslocaliza sin saberlo también esas decisiones, hacia las personas más alejadas del contexto necesario para tomarlas bien, y el resultado es un trabajo localmente plausible y globalmente erróneo, descubierto tarde, a través de una brecha de doce horas, y corregido despacio. El arbitraje laboral es real; la coordinación y el retrabajo que desencadena, mal gestionados, son mayores.

Este artículo trata del modelo operativo que corrige el error no cometiéndolo, y el modelo tiene un nombre que usaremos a lo largo de todo el texto: el centro de mando onshore. La idea es separar, deliberada y estructuralmente, las dos cosas que un offshoring ingenuo confunde. Una es la ejecución, la construcción, que genuinamente puede y debe escalar donde el talento es abundante y asequible, en la India. La otra es el mando: decidir qué construir y en qué orden, ser dueño de la arquitectura y de las interfaces entre las partes, convertir lo que el negocio quiere vagamente en una especificación lo bastante precisa como para construirse lejos sin una conversación, y juzgar si lo que vuelve es correcto. El mando es pequeño, sénior y caro, y permanece onshore, junto al negocio cuya intención existe para portar. La tesis es que el éxito de un programa de offshoring viene determinado casi por completo por si esta capa de mando existe y es buena, y apenas en absoluto por la capacidad bruta del equipo offshore, que suele estar bien; y que las empresas fracasan por infrainvertir en mando precisamente porque el mando es la parte cara y onshore que se suponía que el offshoring debía eliminar.

La contribución es un argumento y un modelo pequeño, no un estudio comparativo. La Sección 2 sitúa la afirmación frente al historial del offshoring y de la ingeniería de software global. La Sección 3 diagnostica el fracaso real: deslocalizar la responsabilidad en lugar de meramente la ejecución. La Sección 4 describe el centro de mando y lo que le pertenece. La Sección 5 ofrece un modelo de dónde debe caer la línea entre mando y entrega, que gira en torno a la carga de contexto y la completitud de la especificación. La Sección 6 trata el reloj, y cómo el follow-the-sun se convierte en palanca y no en latencia. La Sección 7 deriva la razón de mando óptima. La Sección 8 traza un caso construido; las Secciones 9 a 12 extraen las consecuencias, responden a las objeciones, enuncian los límites y concluyen. La pregunta a lo largo de todo el texto es: ¿qué debe mantener una empresa en casa, y cuánto de ello, para que el trabajo que envía a la India vuelva correcto?

2. Antecedentes

2.1 El historial del offshoring

La externalización y el offshoring de las TI tiene una de las literaturas empíricas más amplias de los sistemas de información, y su veredicto no es que el offshoring no sea rentable, sino que su rentabilidad depende de cómo se gestione. Lacity, Khan y Willcocks (2009), al revisar dos décadas de estudios, encuentran que las capacidades del cliente y del proveedor, el diseño del contrato y la gestión de la relación, más que las diferencias salariales por sí solas, explican la brecha entre los compromisos exitosos y los fallidos. Carmel y Tjia (2005) ofrecieron el relato para profesionales del aprovisionamiento con una fuerza de trabajo global y catalogaron las formas en que la distancia erosiona el arbitraje; Sahay, Nicholson y Krishna (2003) ofrecieron el relato, de la extensión de un libro, del desarrollo de software a través de la frontera india, y Oshri, Kotlarsky y Willcocks (2007) trazaron cómo un proveedor indio líder organizó un modelo de entrega global en torno a una pericia dispersa. Rottman y Lacity (2006) destilaron prácticas probadas y hallaron que las empresas que tuvieron éxito invirtieron fuertemente en el trabajo onshore de especificar, coordinar y gobernar, el mismo trabajo que este artículo llama mando. El hallazgo constante es que el ahorro es bruto, no neto, y que lo que media entre ambos es un esfuerzo de gestión que en gran medida permanece en casa.

2.2 Por qué la distancia es cara

Una segunda literatura, sobre el desarrollo de software globalmente distribuido, explica el mecanismo. Herbsleb y Mockus (2003), en el estudio más central para este artículo, mostraron empíricamente que los elementos de trabajo que requerían personas en varios emplazamientos tardaban sustancialmente más en completarse que elementos comparables de un solo emplazamiento, y atribuyeron el retraso al coste y la latencia de la comunicación que exige la coordinación entre emplazamientos. Ramasubbu y Balan (2007), al estudiar proyectos dispersos entre la India y Estados Unidos, midieron la misma penalización directamente en el rendimiento del proyecto. Olson y Olson (2000) dieron el resultado general bajo el título «la distancia importa»: el trabajo colocalizado se beneficia de una comunicación rápida, rica e informal que el trabajo distribuido pierde, y ninguna herramienta la restaura por completo. Kraut y Streeter (1995) ya habían mostrado cuánto del desarrollo de software es coordinación y no codificación, y Brooks (1975) había dado mucho antes la razón por la que añadir personas a un trabajo distribuido puede ralentizarlo: las vías de comunicación crecen más deprisa que las personas. La lección no es que el desarrollo distribuido no pueda funcionar, sino que cada frontera que una pieza de trabajo debe cruzar tiene un precio, y el precio se paga en tiempo y en defectos.

2.3 La ley de Conway y la arquitectura de la frontera

La idea más profunda en la que se apoya el artículo es la de Conway (1968): la estructura de un sistema acaba reflejando la estructura de comunicación de la organización que lo construye. Su corolario para el offshoring es exacto y está infrautilizado. Si el offshore y el onshore son dos grupos que se comunican débilmente, entonces el software será más limpio cuando la frontera entre ellos caiga a lo largo de una costura arquitectónica genuina, un módulo con una interfaz definida, y será más problemático allí donde un único bloque de trabajo fuertemente acoplado se parta a través de la brecha. Herbsleb y Grinter (1999) lo confirmaron directamente, al hallar que el desarrollo distribuido tiene éxito cuando la arquitectura es lo bastante modular como para que cada emplazamiento sea dueño de una parte y las interfaces entre partes sean explícitas, y tiene dificultades cuando no lo es. Parnas (1972) dio la disciplina de diseño, la ocultación de información, que hace posibles tales módulos. La consecuencia práctica, desarrollada en la Sección 4, es que ser dueño de la arquitectura no es uno de los trabajos del centro de mando entre muchos; es el trabajo que hace posibles todos los demás, porque decide dónde cae la costosa frontera.

3. El fracaso real: deslocalizar la responsabilidad

El fracaso característico del offshoring no es teclear despacio; es un trabajo que se termina con confianza y está calladamente equivocado. Se entrega un requisito que es completo en la cabeza del emisor y ambiguo sobre el papel, porque el emisor comparte con el negocio un contexto que el receptor no tiene. El ingeniero offshore, competente y dispuesto, resuelve la ambigüedad de la única manera disponible a doce husos horarios de distancia: conjeturando, razonablemente, y construyendo. La conjetura resulta errónea en la aceptación, si hay aceptación, o en producción, si no la hay, y la corrección cruza la brecha dos veces, una para explicar y otra para verificar, cada cruce un día perdido por el reloj. Multiplíquese esto por cada ambigüedad de un sistema real y el arbitraje desaparece, no porque nadie haya hecho nada incompetente, sino porque las decisiones que necesitaban contexto se tomaron donde no lo había.

Lo que ha ocurrido, en el lenguaje de este artículo, es que la empresa deslocalizó la responsabilidad cuando pretendía deslocalizar solo la ejecución. La responsabilidad sobre una pieza de software es la autoridad acumulada para resolver correctamente sus ambigüedades: saber qué quiso decir el negocio, decidir cómo sirve la parte al todo, declarar qué es «correcto». Esa autoridad es inseparable del contexto, y el contexto es local. La ejecución, la construcción de una cosa una vez resueltas sus ambigüedades, no está ligada al contexto y viaja bien. El error es tratar ambas como un solo paquete y enviarlas juntas; la reparación es separarlas, mantener la responsabilidad onshore donde vive su contexto, y enviar offshore solo la ejecución, con sus ambigüedades ya resueltas en una especificación. Todo lo que sigue es una elaboración de cómo hacer esa separación y dónde.

4. El centro de mando

El centro de mando onshore es el hogar organizativo de la responsabilidad que no debe viajar. Es deliberadamente pequeño y deliberadamente sénior, porque su palanca procede de la calidad de unas pocas decisiones y no de la cantidad de producción, y se sitúa junto al negocio, no junto a los teclados. La Figura 1 dibuja el modelo y la Tabla 3 divide el trabajo. El centro de mando es dueño de cinco cosas, y la disciplina del modelo consiste en que es dueño de las cinco e intenta no ser dueño de nada más.

De la intención a la especificación. El primer producto del centro de mando no es software sino especificación: la traducción de lo que el negocio quiere vagamente a un relato lo bastante preciso como para que lo construya alguien que no puede asomarse a preguntar. Este es el trabajo que resuelve la ambigüedad donde está el contexto, de modo que ninguna tenga que resolverse donde no lo está, y es la actividad de mayor palanca de todo el modelo, porque cada ambigüedad dejada en una especificación se paga más tarde al coste íntegro de un viaje de ida y vuelta a través de la brecha.

Arquitectura e interfaces. Por la ley de Conway el software se fracturará a lo largo de las costuras de comunicación de la organización, de modo que el centro de mando es dueño de la arquitectura precisamente para elegir dónde caen esas costuras: descompone el sistema en módulos con interfaces explícitas de forma que cada pod offshore sea dueño de una parte que pueda construir con pocas dependencias que crucen la frontera. Trazar bien la frontera es lo que convierte la distancia de un impuesto pagado en cada interacción a un impuesto pagado solo en unas pocas interfaces bien definidas.

Priorización. Qué se construye primero es un juicio del negocio, no de la entrega, y permanece con el centro de mando, que retiene el backlog único y su orden. Dispersar la priorización hacia el equipo offshore, o hacia varios interesados a la vez, reintroduce a través de la brecha exactamente la coordinación que el modelo existe para contener.

Aceptación y la puerta de calidad. El centro de mando decide qué es «terminado» y prueba el trabajo devuelto frente a ello, sosteniendo una puerta en la que el negocio confía. Esta es la contrapartida de la especificación: habiendo definido la corrección de antemano, la verifica a la vuelta, y porque está onshore y cerca del negocio puede juzgar la idoneidad, no meramente la función.

Un único dueño responsable. Por último, el centro de mando es donde la responsabilidad es indivisa: un único dueño responsable ante el negocio de lo que se entrega, que no puede señalar al otro lado de la brecha. La responsabilidad repartida a través de la frontera es una responsabilidad que ha desaparecido, y devolverla a un único punto onshore es gran parte de lo que hace gobernable el modelo.

5. Trazar la línea

Si el mando permanece onshore y la ejecución va offshore, todo gira en torno a dónde se traza la línea entre ambos, tarea por tarea. El modelo que gobierna la elección tiene dos ejes. El primero es la carga de contexto de una tarea: cuánto conocimiento local, tácito y específico del negocio exige resolverla correctamente, alta para un cambio que toca una regla regulatoria sutil o un compromiso de larga data con un cliente, baja para un componente bien delimitado con un contrato claro. El segundo es la completitud de la especificación que el centro de mando puede darle: con qué plenitud pueden resolverse sus ambigüedades de antemano, sobre el papel, sin una conversación. Una tarea es segura de deslocalizar cuando la ambigüedad residual que llega al pod offshore, su carga de contexto neta de la completitud de la especificación que se le aplica, es pequeña. Escribiendo $\kappa$ para la carga de contexto y $s$ para la completitud de la especificación, ambas en una escala común, el residual es

y es $\alpha$, no la dificultad bruta del trabajo, lo que predice el retrabajo. El modelo tiene una lectura directiva nítida, dibujada en la Tabla 1. Una tarea de bajo contexto se deslocaliza limpiamente sea cual sea su dificultad técnica. Una tarea de alto contexto no es inadecuada para deslocalizar; es inadecuada para deslocalizar sin especificar, y el trabajo del centro de mando es elevar $s$ hasta que $\alpha$ sea lo bastante pequeña para enviarla. Allí donde la carga de contexto es genuinamente irreducible, donde el conocimiento no puede escribirse en absoluto, la tarea permanece onshore, y reconocer eso con honestidad es parte de la disciplina. El modo de fallo que el modelo nombra es la tarea de alto contexto enviada con una especificación de baja completitud: máxima ambigüedad residual, resuelta offshore por conjetura, a máxima distancia.

6. El reloj

La diferencia horaria entre un negocio occidental y la India, de unas nueve a doce horas, es el rasgo que los profesionales tratan más a menudo como un pasivo puro y el que el centro de mando puede convertir de forma más limpia en un activo. Sin atender, la brecha es latencia: una pregunta formulada al final de la jornada offshore se responde al final de la jornada onshore, y una sola aclaración cuesta un día natural sea cual sea su sustancia, de modo que una cadena de aclaraciones cuesta una semana para resolver una hora de contenido real. Este es el mecanismo por el que un offshoring mal gestionado se siente lento aunque todos trabajen duro: el camino crítico pasa por la brecha, y la brecha añade un día por cruce.

Bien gestionada, la misma brecha es un segundo turno. Si el centro de mando entrega trabajo cuyas ambigüedades ya están resueltas, los pods offshore ejecutan durante la noche onshore y devuelven resultados para la mañana onshore, y el día que el negocio pasa durmiendo es un día de progreso y no un día de espera. La diferencia entre los dos resultados es enteramente la ambigüedad residual $\alpha$ de lo que se entrega: una entrega con $\alpha \approx 0$ no necesita viaje de ida y vuelta y el reloj es pura ganancia; una entrega llena de preguntas sin resolver pone el reloj en tu contra, porque cada pregunta es un día entero. Una forma tosca de verlo es que la aceleración efectiva del segundo turno es

donde $\eta$ mide con qué limpieza puede entregarse el trabajo y $\alpha$ es la ambigüedad residual de la ecuación (1); a medida que $\alpha\to 0$ el reloj se acerca a un turno extra genuino, y a medida que $\alpha$ sube la ganancia se desploma y luego se invierte en el impuesto de un día por pregunta. El centro de mando se gana el reloj siendo dueño de la especificación y de la definición de terminado que hacen pequeña a $\alpha$, por lo que el follow-the-sun es una consecuencia de un buen mando, no un truco de planificación que pueda comprarse por separado.

7. La razón de mando

¿Cuánto mando es suficiente? La pregunta tiene una respuesta real, y no es ni «el menos posible», el instinto que produce el offshoring de lanzar-por-encima-del-muro, ni «el más posible», que reconstruye onshore el coste del que el offshoring pretendía desprenderse. Sea $r$ la razón de mando, la capacidad del centro de mando onshore como fracción de la capacidad de entrega offshore que gobierna. El mando cuesta la elevada tarifa onshore $w_c$ por unidad; la entrega cuesta la baja tarifa offshore $w_o$ por unidad. El valor del mando es que reduce la ambigüedad residual que llega a los pods y, por tanto, el retrabajo que deben hacer: más mando significa más trabajo especificado, revisado y controlado antes y después de cruzar la brecha, y por tanto un menor multiplicador de retrabajo sobre el trabajo entregado. Una forma utilizable para ese multiplicador es

donde $a$ escala el retrabajo en que incurriría la ausencia total de mando, fijado por la ambigüedad intrínseca del trabajo, y $b$ mide con qué eficacia se convierte el mando en ambigüedad resuelta. El coste total de entregar una unidad de trabajo terminado, mando más entrega retrabajada, es entonces

una suma de un término creciente, el coste del mando, y uno decreciente, el retrabajo que el mando evita, de modo que tiene un único mínimo interior. Haciendo $C'(r)=0$ se obtiene la razón de mando que minimiza el coste

que es el resultado cuantitativo central del artículo. Dice tres cosas sobre las que un directivo puede actuar. La cantidad óptima de mando es positiva: $r^\ast > 0$ siempre que $w_o a b > w_c$, es decir, siempre que el mando sea en algo eficaz y la ambigüedad en algo real, de modo que lanzar el trabajo por encima del muro ($r = 0$) nunca es óptimo. Es finita: el mando más allá de $r^\ast$ cuesta más que el retrabajo que ahorra, de modo que mantenerlo todo onshore tampoco es óptimo. Y se mueve en la dirección correcta: $r^\ast$ sube con la ambigüedad del trabajo ($a$) y con cuán bien la resuelve el mando ($b$), y cae a medida que el mando onshore se encarece respecto a la entrega offshore ($w_c/w_o$), de modo que las carteras ambiguas y de alto contexto justifican una capa de mando más gruesa y las simples y bien delimitadas, una más fina. La Figura 2 dibuja $C(r)$ y los dos regímenes de fallo a ambos lados del óptimo.

8. Un caso construido

El caso es construido, no observado: sus cifras son ilustrativas e internamente consistentes, y pretende mostrar las magnitudes del modelo tomando valores plausibles más que informar de un resultado. Un grupo occidental gestiona el desarrollo de aplicaciones para sus sistemas de back-office y, hace tres años, deslocalizó la mayor parte de él a un proveedor en la India en régimen de ampliación de plantilla: mantuvo un puñado de jefes de proyecto onshore, escribió los requisitos en la forma en que siempre lo había hecho, y midió el éxito por la plantilla trasladada y la tarifa diaria ahorrada. Sobre el papel había reducido a la mitad el coste de un desarrollador. En la práctica, la entrega directa de una funcionalidad, desde la petición hasta el cambio aceptado en producción, se había alargado, la tasa de escape de defectos a producción había subido, y una parte grande y creciente de las horas del equipo offshore iba al retrabajo de funcionalidades que se habían construido según una lectura razonable pero errónea de un requisito ambiguo. El ahorro era bruto; neto, era escaso y menguante. La Tabla 2 da la columna del antes.

El grupo reconstruyó entonces el compromiso en torno a un centro de mando. No cambió de proveedor ni trajo el trabajo a casa; añadió una capa onshore fina y sénior, un pequeño porcentaje de la plantilla total, que asumió la propiedad de las cinco cosas de la Sección 4: reescribió los requisitos como especificaciones con criterios de aceptación explícitos, recortó de nuevo la arquitectura de modo que cada pod offshore fuera dueño de un módulo tras una interfaz definida, retuvo un único backlog ordenado, y ejecutó una puerta de aceptación antes de que nada llegara a producción. El equipo offshore y sus tarifas no cambiaron; lo que cambió fue la ambigüedad residual $\alpha$ que le llegaba. El retrabajo cayó a medida que las especificaciones resolvían la conjetura que lo había impulsado, la tasa de escape de defectos bajó a medida que la puerta atrapaba lo que la brecha solía ocultar, y el reloj pasó de latencia a segundo turno a medida que las entregas dejaban de necesitar viajes de ida y vuelta. El coste del mando añadido fue una fracción del retrabajo que eliminó, que es la ecuación (5) en la práctica: el compromiso había estado funcionando muy a la izquierda de $r^\ast$, y moverse hacia él bajó el coste total aun elevando el coste onshore. La Tabla 2 traza el cambio.

9. Qué cambia para el modelo operativo

Adoptar el centro de mando cambia aquello en lo que una empresa debe ser buena, y el cambio es incómodo porque va en contra del instinto que motivó el offshoring. El ahorro sigue siendo real, pero solo se captura gastando, onshore y a tarifas sénior, en la capa de mando que el argumento empresarial ingenuo trató como desperdicio a eliminar. La Tabla 3 expone la división del trabajo que el modelo exige. El recurso escaso pasa a ser el puñado de personas sénior capaces de sostener bien la intención, la arquitectura y la aceptación, y la capacidad de offshoring de una empresa está acotada por cuántas de esas personas tiene, no por cuántos ingenieros offshore puede contratar. La métrica cambia también: la plantilla trasladada y la tarifa diaria ahorrada, los números que hacen quedar bien al offshoring de lanzar-por-encima-del-muro, se sustituyen por el plazo de entrega de una funcionalidad, el escape de defectos y la proporción de horas offshore dedicadas a retrabajo, los números que revelan si el mando está haciendo su trabajo.

Hay un segundo desplazamiento, en dónde se sitúa la seniority. El offshoring de lanzar-por-encima-del-muro tiende a enviar el trabajo interesante y sénior offshore junto con el resto y a mantener en casa una capa de coordinación júnior; el modelo del centro de mando invierte eso, manteniendo la seniority onshore donde está el contexto y dejando que el equipo offshore sea excelente en la ejecución sin pedirle que aporte un contexto que no puede tener. Esto se malinterpreta a menudo como desconfianza hacia el equipo offshore. Es lo contrario: es la disposición que permite a un equipo offshore capaz hacer su mejor trabajo, al no pedirle que resuelva ambigüedades que nadie a su distancia podría resolver bien, y al darle especificaciones lo bastante claras como para que su competencia se gaste en construir y no en conjeturar.

10. Objeciones y respuestas

El centro de mando solo añade coste onshore y erosiona el ahorro. Añade coste onshore y eleva el ahorro neto, que es todo el sentido de la ecuación (5): la mayoría de los compromisos fallidos se sitúan muy a la izquierda de $r^\ast$, donde un poco más de mando elimina mucho más retrabajo del que cuesta. El centro de mando no es un sobrecoste sobre el ahorro; es el mecanismo que convierte un ahorro bruto en uno neto. Una empresa que ya esté genuinamente en $r^\ast$ no debería añadir mando; casi ninguna lo está.

Si hay que especificarlo todo con tanta precisión, ¿por qué no construirlo simplemente onshore? Porque la especificación y la construcción tienen costes muy distintos y escaseces muy distintas. La especificación es una pequeña cantidad de trabajo sénior y ligado al contexto; la construcción es una gran cantidad de trabajo que no está ligado al contexto una vez especificado. El modelo envía la cantidad grande y barata de ubicar a donde es asequible y mantiene en casa solo la cantidad pequeña y ligada al contexto. Volver a colapsar ambas renuncia precisamente al arbitraje que es real.

Las herramientas modernas y las videollamadas han vuelto irrelevante la distancia. La han vuelto más pequeña, no irrelevante, y la evidencia de que la distancia sigue importando es robusta (Olson y Olson, 2000; Herbsleb y Mockus, 2003). Las herramientas abaratan el coste de un cruce; no eliminan el día que el reloj añade a un viaje de ida y vuelta, ni restauran la comunicación informal y ambiental que los equipos colocalizados usan para resolver la ambigüedad sin darse cuenta. El centro de mando es la respuesta estructural que las herramientas complementan pero no sustituyen.

Nuestro socio offshore es muy capaz y puede ser dueño de todo el asunto. La capacidad no es el problema; el contexto lo es. Un equipo offshore altamente capaz sigue sin poder resolver una ambigüedad cuya resolución requiere saber qué quiso decir el negocio, y pedirle que lo haga enfrenta su competencia a un problema que la distancia hace insoluble. El modelo mantiene la responsabilidad onshore no porque el equipo offshore sea débil, sino porque la responsabilidad está ligada a un contexto que es onshore.

11. Limitaciones

Este es un argumento dirigido a profesionales con un modelo deliberadamente sencillo, y sus límites deberían ser evidentes. El modelo de las Secciones 5 a 7 es ilustrativo: la forma de ambigüedad residual de la ecuación (1), el multiplicador de retrabajo exponencial de la ecuación (3) y la razón óptima única de la ecuación (5) son simplificaciones elegidas por legibilidad, y las constantes $a$, $b$, $w_c$ y $w_o$ no se miden aquí; una empresa puede estimarlas a partir de sus propios datos de retrabajo y tarifas, y esperaríamos que la forma cualitativa, un óptimo interior que se mueve con la ambigüedad y el coste relativo, sobreviva incluso allí donde la forma exacta no lo haga. El argumento se circunscribe al trabajo cuyas ambigüedades pueden, con esfuerzo, resolverse en una especificación; el trabajo genuinamente parecido a la investigación, donde aún nadie sabe qué es lo correcto, encaja mal en el modelo y debería en su mayoría permanecer colocalizado. El artículo se apoya en la India porque es allí donde están la profundidad de la oferta y la escala de la práctica, pero nada en el modelo es específico de un país; se aplica a cualquier división onshore–offshore a través de una distancia y un reloj reales. Y el modelo supone una empresa capaz de dotar siquiera de personal a una capa de mando sénior; una empresa que no pueda debería ser honesta en que aún no es capaz de deslocalizar bien, en lugar de deslocalizar mal y llamar al resultado un veredicto sobre la India.

12. Conclusión

El offshoring de trabajo de TI a la India decepciona a las empresas que deslocalizan lo que no deben: envían fuera la responsabilidad junto con la ejecución, desligando el trabajo del contexto y el juicio que lo hacen correcto, y luego ven cómo el retrabajo y el reloj devoran el ahorro que vinieron a buscar. La reparación no es traer el trabajo a casa sino separarlo correctamente, manteniendo onshore el mando fino y sénior que debe permanecer junto al negocio, decidiendo qué construir, siendo dueño de la arquitectura y las interfaces, convirtiendo la intención en especificación y reteniendo la aceptación, mientras la ejecución escala en la India, donde el talento es abundante y asequible. Dónde trazar la línea es una pregunta que responde la ambigüedad residual de una tarea, y el oficio del centro de mando es elevar la especificación hasta que esa ambigüedad sea lo bastante pequeña para cruzar la brecha; cuánto mando mantener es una pregunta con un óptimo real, positivo y finito, que sube con la ambigüedad del trabajo y cae a medida que el mando se encarece. Hecho así, la distancia deja de ser un impuesto y el reloj de doce horas se convierte en un segundo turno, y el arbitraje que siempre fue real por fin se conserva. Deslocaliza la construcción; mándala desde casa. Una empresa que recuerde cuál de las dos está ligada al contexto, y cuál no, puede dominar el offshoring a la India; una empresa que lo olvide seguirá concluyendo, erróneamente, que el problema era el otro extremo de la línea.

Apéndice A. Montaje de un centro de mando

Las prácticas que siguen son lo que hace que la separación de la Sección 4 se sostenga en la práctica. Ninguna es novedosa; la disciplina es el valor.

Referencias

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.