La forma más segura de evaluar a un equipo de ingeniería nearshore no es una propuesta larga, sino una prueba corta en una tarea acotada. Dos semanas bastan para ver cómo se comunica un equipo, cómo revisa su propio trabajo y si entrega algo que tus ingenieros aceptarían. Esta guía explica cómo prepararla para que el resultado sea una decisión y no una opinión.
1. Elige la tarea correcta
Una buena tarea de prueba es:
- Acotada. Se puede terminar en dos semanas con un equipo pequeño, sin rediseñar todo tu sistema.
- Real. Te importa, para que el equipo trabaje en algo que sí vas a usar.
- De bajo riesgo. No requiere secretos de producción, datos de clientes ni cambios irreversibles.
- Medible. Puedes saber si está terminada y si está bien.
- Representativa. Ejercita el trabajo que después delegarías, como una funcionalidad, un paso de migración, un conjunto de pruebas o una integración.
Evita tareas vagas, que dependan de decisiones que nadie ha tomado o que necesiten semanas de contexto antes de empezar.
2. Escribe el alcance
Un alcance por escrito convierte la prueba en algo que puedes evaluar. Incluye:
- Objetivo. Una frase sobre lo que logra la tarea.
- Entregables. Qué existe al final, como pull requests, pruebas, documentación o una demo.
- Criterios de aceptación. Cómo decidirás que el trabajo está terminado y es suficientemente bueno.
- Fuera de alcance. Qué no debe tocar el equipo.
- Dependencias. Qué debes proporcionar y para cuándo.
- Puntos de revisión. Cuándo revisarás el trabajo y darás retroalimentación.
3. Define accesos con el menor privilegio
Dale al equipo solo lo que la tarea necesita: los repositorios, ambientes y herramientas involucrados, con permisos limitados. Acuerden por escrito quién puede aprobar cambios y qué pueden hacer las herramientas automáticas o los agentes. Deja las credenciales de producción fuera de la prueba salvo que la tarea realmente las requiera, y acuerden cómo se retiran los accesos al final.
4. Acuerda un ritmo de trabajo
Con un equipo nearshore puedes aprovechar las horas que comparten. Un ritmo sencillo funciona bien: una reunión breve diaria, una demo a mitad de la prueba y una revisión final. Pide al equipo que trabaje en tus repositorios y siga tu proceso de revisión, para ver cómo se comporta dentro de tu flujo real.
5. Evalúa lo que importa
Al terminar las dos semanas, observa:
- Calidad. ¿Tus ingenieros lo integrarían? ¿Hay pruebas?
- Comunicación. ¿El equipo hizo buenas preguntas desde el inicio y avisó rápido de los problemas?
- Comprensión. ¿Entendieron tu contexto, no solo el ticket?
- Documentación. ¿El trabajo está explicado lo suficiente para que tu equipo lo mantenga?
- Confiabilidad. ¿Entregaron lo que dijeron, cuando lo dijeron?
- Disciplina de revisión. Si se usaron agentes de IA, ¿quién revisó su resultado y cómo?
6. Decide
Al final de la prueba hay tres resultados honestos: continuar con un alcance mayor, ajustar el alcance o la forma de trabajar, o detenerse. Una buena prueba hace fácil cualquiera de los tres porque tienes evidencia.
Señales de alerta
- El equipo no acepta un alcance por escrito.
- Los accesos que piden van mucho más allá de la tarea.
- Nadie puede decir quién revisa el trabajo.
- Las preguntas llegan hasta el final.
- No está claro qué pasa después de la prueba.
Cómo funciona nuestra prueba
En Mexico AI Services, la prueba cubre una tarea acotada con un alcance por escrito. El Pod trabaja en ella dos semanas sin costo y, si no continúas, no debes nada. Si el alcance acordado no se entrega dentro del mes, el trabajo continúa sin costo adicional hasta completarse. Aplican términos. Puedes leer más en la página de Pods de IA nearshore o conocer qué hace un Forward Deployed Engineer.