02 Nov KPO de desarrollo nearshore: cómo contratarlo sin quedar atrapado
Casi nadie firma un contrato de desarrollo pensando en cómo va a salir de él. Se firma pensando en arrancar: el proveedor promete un equipo senior, una fecha y una tarifa razonable, y las primeras semanas van bien. El problema aparece al sexto mes. Dos de las personas que conocías ya no están, el conocimiento del sistema vive en la cabeza de quien lo escribió, cada entrega se renegocia y, cuando planteas cambiar de proveedor, descubres que no tienes acceso completo al repositorio ni documentación para que otro equipo lo retome.
Ese es el proveedor al que terminas persiguiendo. Esta guía es para evitarlo: qué es un KPO de desarrollo nearshore, dónde están las trampas y qué dejar por escrito antes de firmar. Está pensada para CTO y directores de desarrollo en España y Latinoamérica que necesitan capacidad sin perder el control.
Qué es un KPO de desarrollo (y en qué se diferencia de tercerizar horas)
KPO significa knowledge process outsourcing: tercerizar un proceso que depende del conocimiento, no solo de la mano de obra. En desarrollo de software, la diferencia es concreta. Cuando contratas horas, el proveedor pone personas y tú pones el proceso, el criterio técnico y la gestión. Cuando contratas un KPO, el proveedor también responde por el método: cómo se estima, cómo se asegura la calidad, cómo se documenta y cómo se transfiere lo que se aprende.
Ninguno de los dos modelos es mejor en abstracto. El staff augmentation funciona muy bien cuando tu equipo tiene un proceso maduro y solo le faltan manos. El KPO tiene sentido cuando lo que te falta es capacidad completa: equipo, método y continuidad. Lo importante es saber cuál estás comprando, porque las trampas son distintas.
Las cuatro formas de quedar atrapado
1. El equipo que rota
Te presentan un equipo en la propuesta y, a los tres meses, la mitad es otra gente. Cada reemplazo cuesta semanas de curva de aprendizaje que nadie te descuenta de la factura. Lo que protege aquí no es la buena voluntad, sino una cláusula: nombres del equipo, dedicación comprometida y ningún reemplazo sin tu aprobación y sin un periodo de solapamiento pagado por el proveedor.
2. El conocimiento que no se escribe
Si la arquitectura, las decisiones técnicas y los procedimientos de despliegue solo existen en la cabeza de dos desarrolladores, el sistema es tuyo en el papel y del proveedor en la práctica. La documentación tiene que ser un entregable con criterio de aceptación, no un favor que se pide al final.
3. Los plazos que se negocian cada sprint
Un proveedor sin método de estimación no entrega tarde por mala fe: entrega tarde porque nunca supo cuánto iba a tardar. La señal se ve pronto, cuando cada reunión de seguimiento termina con una nueva fecha. Pide ver cómo estiman, con qué datos históricos y cómo miden la desviación entre lo estimado y lo real.
4. La salida que cuesta más que la entrada
Código en repositorios del proveedor, infraestructura en cuentas a su nombre, licencias contratadas por él, credenciales que solo conoce su equipo. Ninguna de estas cosas parece grave el primer día. Todas juntas convierten un cambio de proveedor en un proyecto de rescate. Ya lo contamos desde el lado de las compras públicas en el checklist de licitación TI: si la propiedad del código, los datos y la documentación no queda escrita antes de firmar, la salida te va a costar.
Siete puntos para dejar por escrito antes de firmar
| Punto | Qué pedir | Qué te protege |
|---|---|---|
| 01Equipo | Nombres, perfiles y dedicación; reemplazos solo con tu aprobación y solapamiento | Continuidad del conocimiento |
| 02Repositorios y cuentas | Código, infraestructura y licencias en cuentas de tu empresa desde el día uno | Una salida sin rescate |
| 03Documentación | Arquitectura, decisiones y despliegue como entregables con criterio de aceptación | Que otro equipo pueda retomar |
| 04Calidad | Definición de terminado, cobertura de pruebas y revisión de código obligatoria | Deuda técnica visible, no escondida |
| 05Estimación | Método, datos históricos y reporte de desviación por entrega | Fechas que significan algo |
| 06Evidencia de proceso | Certificaciones vigentes con su alcance (por ejemplo, CMMI o ISO 27001 si hay información sensible) | Un proceso auditado por un tercero |
| 07Plan de salida | Transferencia asistida, plazo y costo acordados desde el contrato | Tu libertad de cambiar |
Un buen proveedor no se incomoda con esta lista. Si alguna de estas peticiones genera resistencia, esa resistencia ya es información.
Por qué nearshore, y qué preguntar sobre él
Nearshore no es solo «más barato que en casa». Es trabajar con un equipo que comparte idioma y una ventana horaria útil para hablar en tiempo real. Para empresas en Latinoamérica, la coincidencia de horario con Colombia es casi completa. Para España, la diferencia es de seis o siete horas según la época del año: la mañana en Colombia coincide con la tarde en Madrid, y eso alcanza para revisiones diarias, demos y decisiones el mismo día, siempre que el proveedor organice el trabajo alrededor de esa ventana y no la deje al azar.
La pregunta útil no es «¿dónde están?», sino «¿cómo trabajan con clientes en mi zona horaria hoy?». Pide que te muestren la agenda real de un proyecto en curso: cuándo son las reuniones, quién responde fuera de la ventana compartida y cuánto tarda una duda en resolverse.
Si tu proveedor usa IA, pregunta dónde están las compuertas
Cada vez más equipos de desarrollo trabajan con asistentes y agentes de IA para revisar código, generar pruebas o redactar documentación. Bien gobernado, acelera. Mal gobernado, produce código que nadie entiende del todo y que nadie revisó de verdad. La pregunta que conviene hacer no es si usan IA, sino qué nunca sale sin que una persona lo revise y quién responde cuando algo falla.
Lo decimos desde la práctica. En AIATIC operamos con agentes de IA el contenido de siete marcas del grupo, y el principio es simple: el agente produce, una persona aprueba y nada se publica sin esa compuerta. Contamos cómo funciona en compuertas humanas: gobernanza antes que automatización. Ese mismo criterio es el que conviene exigirle a cualquier proveedor que meta IA en tu código.
Empieza con una célula piloto, no con un contrato de dos años
La forma más segura de evaluar a un proveedor es verlo trabajar. Una célula piloto de cuatro semanas, sobre un problema real y acotado, te deja comprobar lo que ningún documento comercial muestra:
- Si el equipo que vendieron es el que llega. Las mismas personas, con la dedicación acordada.
- Si estiman bien. Al final de las cuatro semanas, compara lo prometido con lo entregado.
- Si documentan sin que se lo pidas. Revisa qué quedó escrito y si otro desarrollador podría retomarlo.
- Si el código queda en tu casa. Repositorio, accesos y entorno en cuentas de tu empresa desde el primer día.
Si el piloto funciona, escalas sobre algo que ya viste. Si no, saliste en cuatro semanas y con el trabajo en tu repositorio.
Preguntas frecuentes
¿Qué diferencia hay entre KPO y outsourcing de desarrollo?
El outsourcing tradicional terceriza la ejecución: el proveedor pone horas y personas. El KPO terceriza también el conocimiento del proceso: el proveedor responde por el método de estimación, la calidad, la documentación y la transferencia de lo aprendido.
¿Cuánto debería durar un piloto con un proveedor de desarrollo?
Lo suficiente para ver al menos un ciclo completo de estimar, construir, probar y entregar. Cuatro semanas suelen bastar para un problema acotado; menos tiempo no deja ver cómo el equipo maneja los imprevistos.
¿Cómo evito depender de un solo proveedor de desarrollo?
Con tres cosas desde el contrato: el código y la infraestructura en cuentas de tu empresa, la documentación como entregable con criterio de aceptación y un plan de salida con plazo y costo acordados antes de empezar.
Capacidad con salida sin fricción
AIATIC es firma consultora y fábrica de software con certificación CMMI Nivel 3 en desarrollo y servicios. En 15 años hemos construido una capacidad de 320.000 horas de desarrollo al año, con clientes en 10 países y el 95 % del negocio fuera de Colombia. Trabajamos con equipo estable, código en tu casa desde el primer día y un plan de salida escrito, porque preferimos que te quedes por los resultados y no por el contrato.