Onboarding de un equipo nearshore en 2 semanas
Casi siempre que un onboarding sale mal se le echa la culpa a la capacidad técnica del equipo. Casi nunca fue eso.
Lo que pasó es que nadie definió quién responde las preguntas, el primer ticket era demasiado grande para terminarlo, y para el día nueve había cuatro ingenieros adivinando requisitos en paralelo.
Aquí tienes un plan de dos semanas que evita eso. Está escrito para ti, no para el proveedor: casi todo el trabajo de la semana cero es tuyo.
Semana cero: lo que preparas antes de que alguien empiece
Haz esto antes de la fecha de inicio del contrato. Si te lo saltas, la semana uno se convierte en la semana cero y perdiste cinco días.
Nombra un responsable interno. Una persona de tu lado que responda preguntas dentro de la jornada. No un comité. Si nadie tiene el tiempo, retrasa el arranque: un equipo que no puede alcanzarte va a construir lo equivocado de forma eficiente.
Arranca la provisión de accesos. Repositorios, CI, staging, gestor de tickets, archivos de diseño, VPN si la tienes. Las solicitudes de acceso que pasan por IT son la causa más común de una primera semana desperdiciada. Empieza diez días antes.
Escribe lo que das por sabido. No documentación completa: una sola página con qué hace el producto, quién lo usa, cuáles son los tres servicios principales y qué partes del código se sabe que están mal. Esa última ahorra más tiempo que todas las demás juntas.
Elige tú el primer ticket. Tiene que tocar código real, poder terminarse en menos de dos días y tener un criterio de terminado evidente. Ni cazar un bug. Ni "lee el código".
Semana uno: accesos, contexto y un PR mergeado
El objetivo de la semana uno es estrecho a propósito: un pull request mergeado en tu rama principal. No velocidad. No un sprint entero de tickets. Un PR mergeado demuestra que toda la cadena funciona: accesos, build, revisión y despliegue.
Días 1–2
Accesos confirmados y verificados usándolos de verdad. El equipo clona, compila y levanta el proyecto en local. Si el build tarda dos días, eso no es un problema de onboarding, es un problema de build del que ahora te enteraste.
Una sesión de trabajo con tu responsable interno: recorrido del producto, arquitectura a nivel de pizarra y dónde están enterrados los cadáveres.
Días 3–4
Primer ticket en curso. Espera preguntas, y espera que algunas sean sobre cosas que dabas por obvias. De eso se trata: las preguntas están sacando a la luz tus supuestos no documentados.
Día 5
Primer PR abierto y revisado por tu equipo. Revísalo en serio. Una revisión blanda aquí le enseña al equipo que tus estándares son negociables, y te vas a pasar tres meses deshaciendo eso.
Semana dos: propiedad de una porción real
Ahora amplía el alcance. El equipo toma un área pequeña pero completa —un servicio, una funcionalidad, un conjunto de endpoints— y es dueño de ella de punta a punta.
El cambio que importa es pasar de tareas a resultados. En la semana uno entregaste tickets. En la semana dos entregas un problema y dejas que el equipo lo descomponga.
Al terminar la semana dos deberías tener: entre tres y cinco PR mergeados, un área con un dueño con nombre dentro del equipo, y al equipo participando en tus ceremonias normales en lugar de en una vía paralela de onboarding.
Las señales de que va mal
Vigila estas cuatro. Todas se corrigen en la semana dos y salen caras en el mes dos.
Dejaron de llegar preguntas. El silencio no es fluidez, normalmente es gente adivinando. Un equipo que no pregunta nada en la semana uno es un equipo a punto de entregarte algo que no pediste.
Todos los PR se aprueban sin comentarios. O tus revisores se desconectaron, o el equipo solo está tomando trabajo seguro.
La misma pregunta llega de tres personas distintas. Nadie está consolidando el contexto de su lado. Esto es exactamente lo que un lead de equipo existe para evitar.
Las estimaciones llegan sin rango y sin salvedades. Un equipo que nunca dice "esto puede ser más grande de lo que parece" es un equipo que te va a contar del retraso el día del vencimiento.
Por qué el lead cambia la forma de todo esto
Si trabajas con contractors individuales, todo lo anterior es tu trabajo. Tú respondes cada pregunta, tú consolidas el contexto, tú notas cuando alguien está atascado y es demasiado educado para decirlo.
Con un equipo dedicado, un lead absorbe eso. Tu responsable interno tiene una contraparte en lugar de cuatro. Las preguntas se filtran y se agrupan: las que necesitan una decisión de producto te llegan, las que necesitan contexto del código se resuelven internamente.
Es el mecanismo que describimos en nuestra guía sobre staff augmentation en Colombia: el lead es lo que te permite comprar profundidad técnica sin que cada ingeniero tenga que ser tu interfaz.
También significa que tu preparación de la semana cero importa más, no menos. El lead solo puede enrutar preguntas hacia alguien que exista.
Lo que dos semanas no te compran
Sé honesto contigo mismo sobre el techo de esto.
Dos semanas dejan a un equipo productivo en una porción. No lo vuelven autónomo en todo tu sistema: eso toma un trimestre en la mayoría de los códigos, y más si tu arquitectura tiene sorpresas.
Tampoco se comprime si tu proyecto no tiene entorno local, ni pruebas, ni nadie que entienda la ruta de despliegue. La velocidad de onboarding depende sobre todo de qué tan legible sea ya tu sistema. Si dos semanas te parecen imposibles, el plan de onboarding no es lo que hay que arreglar.
Por dónde empezar
Si estás evaluando a un partner, pídele que te recorra sus primeras dos semanas en detalle: no una promesa, el cronograma real y qué necesita de ti en la semana cero. Un partner que no ha pensado en la semana cero no ha hecho onboarding de muchos equipos.
Agenda una llamada de 30 minutos. Trae tu configuración actual y te decimos con honestidad dónde se atascaría tu onboarding.