Los equipos de ingeniería nearshore en la República Dominicana comparten una jornada laboral completa con el horario del Este de Estados Unidos, lo que elimina el viaje de ida y vuelta nocturno que ralentiza la colaboración offshore. Esto importa sobre todo en aseguramiento de calidad, DevOps, ingeniería de releases y soporte de aplicaciones, donde el trabajo es intensivo en colaboración.
Los líderes de ingeniería que han tenido una mala experiencia offshore suelen describirla como un problema de competencias. Según nuestra experiencia, con más frecuencia es un problema de latencia que se presentó como un problema de competencias.
El mecanismo es sencillo. Cuando un equipo está once horas fuera de fase, cada pregunta se convierte en un viaje de ida y vuelta que toma una noche. Los ingenieros se adaptan agrupando preguntas, y agrupar significa avanzar sobre supuestos en lugar de aclaraciones. Los supuestos que resultan equivocados aparecen un día después, a veces una semana después. El resultado parece falta de criterio. La causa es que no había nadie disponible a quien preguntar.
Esto pesa más en unas funciones que en otras.
Qué funciones son sensibles a la latencia
No todo el trabajo de ingeniería se ve igualmente afectado por la separación horaria, y ser honestos al respecto es más útil que afirmar que el nearshore es superior en todos los casos.
El trabajo tolerante a la latencia incluye desarrollo de funcionalidades bien especificadas con criterios de aceptación claros, trabajo sobre módulos aislados e investigación de ciclo largo. Si una tarea puede especificarse por completo por escrito y entregarse contra esa especificación, la distancia cuesta relativamente poco. La entrega offshore maneja bien esto y con frecuencia a mejor costo.
El trabajo sensible a la latencia incluye aseguramiento de calidad, DevOps e ingeniería de releases, respuesta a incidentes, soporte de aplicaciones y cualquier trabajo desde cero donde los requisitos todavía se están formando. Estas funciones son conversacionales. Implican aclaraciones pequeñas y continuas, depuración conjunta y decisiones que salen más baratas en cinco minutos de diálogo que en dos días de intercambio escrito.
La entrega nearshore vale su prima sobre el offshore específicamente para la segunda categoría. Para la primera muchas veces no la vale, y lo decimos.
Qué cambia concretamente una jornada compartida
Cuatro cosas, en orden aproximado de impacto.
Los standups son reales. Un standup al que ambos equipos asisten en vivo es una reunión de trabajo. Un standup que un equipo graba para el otro es un reporte de estatus. La diferencia suena procedimental y no lo es: los standups en vivo sacan a la luz los bloqueos el mismo día en que ocurren.
Los incidentes se resuelven en un solo ciclo. Cuando producción se rompe, la gente que puede diagnosticarlo está despierta. El tiempo medio de recuperación depende de quién está disponible, y la disponibilidad depende de la zona horaria.
El pairing es posible. La depuración conjunta, las conversaciones de revisión de código y el trabajo en pareja sobre problemas difíciles requieren tiempo sincrónico. Son además los mecanismos principales por los que se profundiza el conocimiento que un equipo tiene de una base de código.
Los requisitos pueden evolucionar. Los productos que todavía están encontrando su forma necesitan conversación continua entre ingeniería y producto. Esa conversación no sobrevive a un viaje de ida y vuelta nocturno, y por eso los acuerdos offshore tienden a funcionar mejor sobre sistemas maduros que sobre sistemas nuevos.
Dónde vemos el mejor encaje
Se repiten tres patrones.
Aseguramiento de calidad e ingeniería de releases. QA es la función de ingeniería con menos recursos de forma más consistente, en parte porque compite por plazas con la ingeniería de funcionalidades y pierde. También es agudamente sensible a la latencia, porque una prueba que falla necesita una conversación, no un ticket. Los equipos nearshore de QA e ingeniería de releases trabajando en el reloj del cliente son, según nuestra experiencia, el proyecto de ingeniería nearshore de mayor valor disponible.
Soporte y mantenimiento de aplicaciones. Mantener funcionando un parque existente no tiene glamour, es continuo y requiere disponibilidad en horario laboral. Es además el trabajo que consume a los equipos internos y les impide mejorar nada.
Ingeniería de datos y trabajo de plataforma. Los pipelines se rompen, y se rompen de formas que exigen que alguien que entienda tanto los datos como el contexto de negocio esté localizable.
Una nota específica sobre las suites de pruebas
Un patrón es lo bastante común como para nombrarlo. Con frecuencia los equipos creen que su problema de QA es de cobertura cuando es de confianza.
Una suite de pruebas con alta tasa de inestabilidad es peor que una más pequeña y confiable, porque los ingenieros aprenden a volver a correr los fallos en lugar de investigarlos, y los fallos genuinos se descartan junto con los espurios. Agregar cobertura a una suite en la que no se confía agrava el problema.
La secuencia correcta es arreglar primero la confiabilidad, restaurar la confianza del ingeniero en que un build en rojo significa algo, y solo entonces ampliar la cobertura, priorizada por el historial de incidentes en producción y por la rotación de código en lugar de por módulo. Hemos ejecutado esta secuencia en proyectos con clientes donde el problema presentado se describía como cobertura insuficiente, y la confiabilidad resultó ser la restricción determinante.
Sobre la transferencia de capacidades
Una preocupación razonable sobre cualquier acuerdo de ingeniería tercerizada es que cree una dependencia permanente.
La forma de atenderlo contractualmente es especificar hitos de transferencia de conocimiento con entregables de documentación y aprobación firmada por los ingenieros del cliente, de modo que el propio equipo del cliente pueda operar lo que se construyó. Pida esto de forma explícita durante la selección. Un proveedor cuyo modelo comercial depende de que el cliente nunca llegue a ser autosuficiente se resistirá, y eso le dice lo que necesita saber.
La medida de un buen proyecto de ingeniería es que el cliente lo continúe por elección y no por necesidad.
Preguntas frecuentes
- ¿Qué es el desarrollo de software nearshore?
- El desarrollo de software nearshore consiste en contratar un equipo de ingeniería en un país cercano con solapamiento sustancial de horario laboral, en lugar de una ubicación offshore distante. Para las empresas de Estados Unidos, el Caribe y América Latina ofrecen colaboración en el mismo día.
- ¿Es el nearshore mejor que el offshore para desarrollo de software?
- Depende de la función. El desarrollo de funcionalidades bien especificadas funciona bien offshore. El aseguramiento de calidad, DevOps, la respuesta a incidentes y el trabajo de producto en evolución son sensibles a la latencia y se benefician sustancialmente de una jornada laboral compartida.
- ¿Qué funciones de ingeniería se benefician más de la entrega nearshore?
- Aseguramiento de calidad e ingeniería de releases, soporte y mantenimiento de aplicaciones, DevOps y trabajo de plataforma, y cualquier desarrollo desde cero donde los requisitos todavía se están formando.
- ¿Cómo se evita depender de un equipo de ingeniería tercerizado?
- Especifique hitos de transferencia de conocimiento en el contrato, con entregables de documentación y aprobación firmada por los ingenieros del cliente, para que el equipo interno pueda operar de forma independiente lo que se construyó.