Externalizar desarrollo de software: guía para CTOs

La mayoría de las conversaciones sobre dónde desarrollar software empiezan con una cifra: la tarifa diaria o por hora. Es fácil de comparar, fácil de volcar en una hoja de cálculo y fácil de defender ante el departamento financiero. También es uno de los peores predictores de lo que costará realmente un proyecto. Esta guía está dirigida a CTO, responsables de ingeniería y responsables de compras de Europa, Norteamérica y el Golfo que deben elegir entre equipos onshore, nearshore y offshore, y quieren hacerlo en función del coste total de la entrega y no de la tarifa publicada.

Para conocer los argumentos generales a favor de los equipos remotos, consulte nuestras guías sobre las ventajas del desarrollo web offshore y la entrega ágil offshore. Esta compara los tres modelos con honestidad.

Los tres modelos, en palabras sencillas

Onshore

El equipo está en su propio país, a menudo en su propia ciudad o región. Comparten huso horario, sistema jurídico, idioma y, por lo general, cultura empresarial. Puede reunir a todos en una sala cuando es importante.

Nearshore

El equipo está en un país cercano con el mismo huso horario o uno muy próximo. Para una empresa de Europa occidental puede significar otro país europeo; para una empresa de Estados Unidos suele significar Latinoamérica. Comparten la mayor parte de la jornada laboral y, si hace falta un taller, basta un vuelo corto.

Offshore

El equipo está lejos, con una gran diferencia horaria. UnlockLive trabaja así con muchos clientes: tenemos una sede en Toronto y un centro de ingeniería en Dhaka. La diferencia es real y condiciona cómo se organiza el trabajo, por eso el resto de este artículo le dedica tiempo.

Estas etiquetas describen distancia y solapamiento horario. No dicen nada sobre la capacidad. Hay equipos sólidos y flojos en todas las categorías, y la calidad de gestión de un proveedor suele importar más que su ubicación en el mapa.

Qué incluye realmente el coste total

Al comparar dos presupuestos, la tarifa es la parte visible. Los siguientes conceptos están debajo de ella y difieren entre modelos y entre proveedores. La idea es asegurarse de que cada uno figure en su hoja de comparación.

Sobrecarga de coordinación y gestión

Todo equipo externo necesita a alguien de su lado que priorice, responda preguntas y acepte el trabajo. La distancia añade comunicación escrita, notas de traspaso y reuniones programadas. Pregunte a cada proveedor quién gestiona el trabajo día a día por su parte y cuántas horas por semana espera de su gente.

Solapamiento de husos horarios

El solapamiento es el número de horas laborables que comparten. Decide si una pregunta bloqueante se responde en minutos o a la mañana siguiente. Se trata en detalle más abajo, porque es el factor que los compradores más subestiman.

Retrabajo

El retrabajo, causado por requisitos poco claros y comentarios tardíos, es el mayor coste oculto en la mayoría de los proyectos fallidos. La defensa habitual son los sprints cortos con demos cada una o dos semanas.

Puesta en marcha

Un equipo nuevo necesita tiempo para aprender su dominio, su código base y sus herramientas. Presupuéstelo; un proveedor que prometa plena productividad en la primera semana es optimista.

Propiedad intelectual, contrato y protección de datos

El trabajo jurídico crece con cada nueva jurisdicción: cesión de la propiedad intelectual, un contrato de encargo del tratamiento de datos y, posiblemente, mecanismos de transferencia internacional. Resolverlo antes de la primera línea de código es mucho más barato que arreglarlo durante una disputa.

Rotación y riesgo de continuidad

Si se marcha un ingeniero clave, ¿quién conoce el sistema? La rotación se da en todos los modelos; lo que cambia es si el proveedor dispone de un sustituto y de un proceso de traspaso.

El solapamiento horario, con franqueza

El solapamiento es geometría, y ningún discurso comercial lo cambia. Este es el panorama general para las regiones a las que se dirige este artículo, sin fingir horarios exactos que varían con el cambio de hora estacional.

• Dhaka y Toronto o la costa este de EE. UU.: la diferencia es grande, de aproximadamente medio día. El solapamiento real es una ventana estrecha al inicio de la jornada norteamericana y al final de la jornada en Bangladesh, y los equipos suelen ampliar un poco el horario de una de las partes para que funcione. La mayor parte de la colaboración es asíncrona, con una breve reunión de sincronización diaria.
• Dhaka y Europa central: una diferencia moderada. Hay un tramo compartido utilizable por la mañana y por la tarde en Europa, suficiente para una reunión diaria de seguimiento y sesiones de trabajo en pareja en directo con un calendario regular, aunque no para una jornada común completa.
• Dhaka y el Golfo: una diferencia pequeña, de unas pocas horas. Las jornadas laborales del Golfo y de Bangladesh coinciden durante buena parte del día, lo que facilita mucho la colaboración en directo en comparación con Norteamérica.
• Los pares nearshore (por ejemplo, Europa occidental con países cercanos, o Norteamérica con Latinoamérica) comparten la mayor parte de la jornada o toda ella.

El trabajo bien especificado y revisado mediante pull requests y demos funciona bien con una ventana corta y buena documentación escrita. El trabajo en el que diseñadores, responsables de producto e ingenieros deben decidir juntos durante todo el día, no.

Marco de decisión: tipo de proyecto frente al modelo más adecuado

No existe un modelo mejor para todos los casos. Esta tabla es un punto de partida, no un veredicto, y un buen socio la ajustará a su situación.

Tipo de proyecto	Normalmente, el modelo más adecuado	Por qué
Desarrollo bien definido, con especificaciones y criterios de aceptación claros	Offshore o nearshore	Hay poca necesidad de decisiones constantes en directo; las especificaciones escritas y las demos de sprint sostienen el trabajo.
Producto aún en descubrimiento, con cambios de rumbo frecuentes	Onshore o nearshore para el descubrimiento, y después cualquier modelo	El descubrimiento requiere una conversación rápida y de alto ancho de banda con las partes interesadas.
Producto de larga duración con un backlog constante	Equipo dedicado, offshore o nearshore	La continuidad y el contexto compartido se acumulan con el tiempo, y la puesta en marcha se paga una sola vez.
Modernización o migración de un sistema heredado	Híbrido	Arquitectos y expertos de dominio onshore, con un equipo remoto que realiza la mayor parte de la implementación.
Agentes de IA, RAG o funcionalidades con muchos datos	Depende de la sensibilidad de los datos	Use datos sintéticos o enmascarados con un equipo remoto, o mantenga el tratamiento de los datos sensibles dentro de la región.
Datos muy regulados o requisitos de seguridad in situ	Onshore, o dentro de la región con controles	Las restricciones jurídicas, de auditoría y de residencia de datos pueden pesar más que cualquier diferencia de tarifa.
Proyecto corto y de alcance cerrado, como un sitio web de marketing o una integración	Cualquiera, elegido por calidad y precio	El coste de coordinación sigue siendo pequeño porque el proyecto es corto.

Muchos de los proyectos mejor gestionados son híbridos: un pequeño responsable de producto y arquitectura onshore, más un equipo de entrega remoto más grande. Así estructuramos también muchos proyectos, con un project manager en Toronto como único punto de contacto e ingenieros en Dhaka, como se describe en nuestra página de desarrollo de software a medida.

Contratos que le protegen

Precio cerrado frente a tiempo y materiales

El precio cerrado le da certeza de costes cuando el alcance es realmente claro. Su debilidad es el cambio: cada idea nueva se convierte en una solicitud de cambio, y los proveedores protegen su margen incorporando el riesgo al precio. Funciona mejor en proyectos acotados con diseños aprobados y criterios de aceptación.

El tiempo y materiales le da flexibilidad y transparencia, y se paga el esfuerzo realmente dedicado. Su debilidad es que el coste puede desviarse si no existe una disciplina propia. Protéjase con un tope mensual, un backlog priorizado, demos de sprint e informes de horas visibles.

Una vía intermedia habitual es una fase de discovery breve y remunerada en tiempo y materiales, seguida de la entrega a precio cerrado del alcance que haya resultado de ella. Elija lo que elija, la forma comercial importa menos que el hecho de que ambas partes hayan puesto por escrito qué significa «terminado».

Cesión de la propiedad intelectual

El contrato debe establecer con claridad que usted es propietario de todo lo creado para usted. Compruebe estos puntos:

• Cesión de la propiedad intelectual de todos los entregables a su empresa, no solo una licencia.
• El personal propio del proveedor y sus subcontratistas han cedido antes sus derechos al proveedor.
• Una lista clara de los componentes de código abierto y de terceros utilizados, con sus licencias.
• Código fuente, definiciones de infraestructura y documentación entregados en repositorios que usted controle, desde el primer día.

Las normas varían según el país, así que haga que su propio asesor jurídico revise la redacción.

Tratamiento de datos y confidencialidad

Si el proveedor va a tratar datos personales, necesita un contrato de encargo del tratamiento antes de concederle acceso. Debe nombrar a los subencargados, indicar dónde se almacenan los datos y desde dónde se accede a ellos, fijar las medidas de seguridad, definir la notificación de brechas y establecer qué ocurre con los datos al terminar el contrato. Para datos personales europeos, compruebe el mecanismo que permite cualquier transferencia fuera de la UE o del EEE. En los proyectos del Golfo, las normas de residencia y transferencia de datos del país correspondiente deben consultarse con un asesor jurídico local antes de diseñar la arquitectura. Siempre que sea posible, mantenga los datos personales reales completamente fuera de los entornos de desarrollo y utilice datos enmascarados o sintéticos.

Lista de comprobación de due diligence para cualquier proveedor

Utilice esta lista con proveedores onshore, nearshore y offshore por igual. Son las mismas preguntas, y las respuestas son lo que realmente está comprando.

1. ¿Quién hará el trabajo? Pida conocer a los ingenieros y al responsable reales, no solo al equipo comercial. Averigüe si las personas de la propuesta son las que se asignarán.
2. ¿Cómo se planifica y se muestra el trabajo? Busque sprints cortos, un backlog visible, demos a las que pueda asistir y actualizaciones de estado por escrito.
3. ¿Cómo gestionan el solapamiento? Pida las ventanas de reunión exactas, quién las cubre y qué ocurre con las incidencias urgentes fuera de ellas.
4. ¿Cuál es el proceso de calidad? Revisión de código, pruebas automatizadas, un entorno de staging y una definición de «terminado» que pueda leer.
5. ¿Cómo tratan la seguridad? Control de acceso, secretos, política de dispositivos y cómo se concede y se revoca el acceso a producción.
6. ¿Qué ocurre si alguien se va? Proceso de sustitución, documentación de traspaso y plazos de preaviso.
7. ¿Quién es propietario de qué? Revise con su abogado la cesión de la propiedad intelectual y la configuración de los repositorios.
8. ¿Dónde residen los datos? Ubicaciones, subencargados y un contrato de encargo del tratamiento que realmente estén dispuestos a firmar.
9. ¿Puede hablar con clientes similares? Llame a referencias de proyectos comparables.
10. ¿Cuál es el plan de salida? Debería poder trasladar el trabajo a otro equipo o a su organización con todo el código, las credenciales y la documentación, sin que la cooperación del proveedor sea objeto de negociación.

Un piloto remunerado es la mejor due diligence de todas: nada revela más rápido los hábitos de comunicación y la calidad del código. Si también está sopesando los errores más comunes, nuestro artículo sobre los errores que cometen las agencias al externalizar el desarrollo de software trata varios desde el lado del cliente.

Cuándo conviene el onshore

Trabajamos para nuestros clientes de forma remota y aun así lo decimos claramente: a veces conviene contratar en el ámbito local. El onshore suele ser la mejor opción cuando:

• Los datos o el sistema son muy sensibles o están regulados y su equipo de cumplimiento exige que el personal trabaje dentro de una jurisdicción determinada, con controles in situ o habilitaciones específicas.
• El producto es demasiado incierto para especificarlo. Si cada semana trae decisiones nuevas y necesita ingenieros en la sala con ventas, operaciones y clientes, compartir huso horario y geografía ahorra más de lo que cuesta.
• Las normas de contratación o del sector público favorecen a los proveedores locales. Algunos compradores del Golfo y de Europa exigen una entidad local, presencia local o compromisos de contenido local. En esos casos, un proveedor remoto solo puede encajar como subcontratista de un contratista principal local.
• Todavía no puede gestionar una relación remota. Si nadie de su lado puede asumir las prioridades y la aceptación del trabajo, la distancia amplificará el problema. Resuélvalo primero, o recurra a un proveedor que aporte un project manager sólido.

Si no se da ninguno de estos casos y el trabajo puede especificarse, revisarse y mostrarse en demos, un equipo nearshore u offshore bien gestionado puede aportar un gran valor. La respuesta honesta suele ser una combinación, y un proveedor de confianza le ayudará a encontrarla incluso cuando eso signifique recomendar menos de su propia capacidad.

Siguiente paso

Elabore una hoja de comparación: para cada proveedor preseleccionado, añada a la tarifa su tiempo de gestión, la carga de reuniones, la puesta en marcha, el riesgo de retrabajo, la configuración jurídica y el riesgo de sustitución, marcados como estimaciones propias. El orden suele cambiar. Para una segunda opinión sobre una preselección, hable con nuestro equipo sobre desarrollo de software a medida, o consulte nuestro servicio de desarrollo web.