La mayoría de los acuerdos de outsourcing te entregan capacidad. Describes un ticket, alguien lo implementa en otro sitio y el resultado vuelve para revisión. El modelo funciona hasta que llegan los problemas interesantes: los que se resuelven cambiando el ticket.
Integrados, no adyacentes
Un squad forward deployed trabaja dentro de tu código, sobre tu roadmap y con tus estándares. Eso significa:
- Leer los mismos dashboards que lee tu equipo
- Estar en la misma rotación de incidentes
- Revisar pull requests mutuamente, en ambas direcciones
La diferencia no es la cercanía por sí misma. Es que el contexto no tiene que serializarse en un ticket antes de poder empezar a trabajar.
Responsables de resultados
Medimos los engagements por si la cosa se envió y aguantó en producción, no por story points quemados. Esa distinción aparece en sitios muy mundanos:
// No "el endpoint devuelve 200"
expect(response.status).toBe(200);
// Sino "el saldo del cliente queda correcto después"
expect(await getBalance(customerId)).toEqual(expected);Si una feature se envía y luego despierta a alguien a las 3 de la mañana, el trabajo no estaba terminado.
Por qué esto es menos ambicioso de lo que suena
Muchos equipos operan así internamente y no lo consideran destacable. Lo raro es comprarlo desde fuera. Eso exige ingenieros senior capaces de sostener contexto sin supervisión, y por eso nuestros squads están estructurados como están: un principal para arquitectura, seniors que han operado producción antes, y QA dedicado en lugar de QA como añadido.
Es un modelo más caro por persona. Suele ser más barato por resultado.