Cómo elegir un equipo nearshore: preguntas y evidencia para decidir

La primera llamada con un posible equipo nearshore debería ayudarte a responder una pregunta concreta: ¿puede trabajar en tu producto con responsabilidades claras y evidencia que puedas revisar?

El portafolio y la propuesta aportan información, pero también necesitas saber quién hará el trabajo, cómo se tomarán las decisiones y qué pasará después de una entrega. Usa esta lista para evaluar la forma de trabajar que realmente estás contratando.

1. Lleva un brief que el proveedor pueda cuestionar

Prepara un documento breve con:

• El problema de negocio, los usuarios afectados y el resultado que buscas mejorar.
• Tu producto actual, arquitectura, integraciones y restricciones conocidas.
• La capacidad o especialidad que le falta a tu equipo.
• La primera entrega útil, sus criterios de aceptación y las fechas inamovibles.
• Los límites del presupuesto y las preguntas todavía abiertas.
• Quién decide sobre producto y tecnología, y cuánto tiempo tendrá para revisar.

Separa los requisitos de los supuestos. Pregunta: ¿Qué investigarían antes de comprometerse con este alcance? ¿Qué dejarían fuera de la primera versión? Una respuesta útil explica las consecuencias de cada decisión, en lugar de aceptar todas las funcionalidades. Si todavía no definiste el modelo, aclara primero qué conviene mantener internamente y qué tercerizar.

2. Asigna responsabilidades a ambos equipos

Pregunta: ¿Quién prioriza el backlog, aprueba la arquitectura, revisa el trabajo, autoriza las entregas y responde ante incidentes? ¿Qué queda a nuestro cargo? Pide un mapa de responsabilidades por escrito, con roles definidos y una vía de escalamiento.

En la ampliación de equipos, tu organización suele dirigir el trabajo de los ingenieros. Si contratas una entrega gestionada, necesitas un responsable de ejecución explícito; las prioridades de producto y su aceptación siguen requiriendo decisiones de tu empresa. El modelo debe coincidir con el tiempo y la capacidad de gestión que puedes aportar.

3. Evalúa a las personas que se incorporarían

Pide conocer al líder técnico y a los ingenieros propuestos. Solicita experiencia relevante, información sobre su evaluación y una entrevista que permita entender cómo razonan sobre las restricciones de tu producto. La presentación comercial no demuestra las capacidades del equipo asignado.

Pregunta: ¿Estas personas están disponibles? ¿Son empleados o subcontratistas? ¿Quién gestiona la contratación y el desempeño? ¿Qué ocurre si alguien se va o no se adapta? Revisa el plan de incorporación, el proceso de reemplazo, los plazos de aviso y la transferencia de conocimiento. Distingue disponibilidad confirmada de una búsqueda que comenzaría después de firmar.

4. Revisa las decisiones de arquitectura y mantenimiento

Pregunta: ¿Cómo trabajarían con nuestro stack? ¿Qué justificaría cambiarlo? ¿Qué fallas posibles y supuestos de crecimiento validarían? Pide un ejemplo de decisión de arquitectura y sus efectos sobre despliegue, observabilidad, dependencias y mantenimiento.

La experiencia pertinente vale más que una lista larga de tecnologías. Averigua quién podrá mantener el software tras el traspaso, cómo se gestionan las actualizaciones y qué licencias o servicios externos generan obligaciones recurrentes. Un framework nuevo, un componente de código abierto o un lenguaje conocido no resuelven esas preguntas por sí solos.

5. Pide evidencia del control de calidad

Pregunta: ¿Quién revisa las solicitudes de cambio? ¿Qué pruebas deben pasar antes de publicar una versión? ¿Cómo verifican los recorridos críticos, las integraciones, los cambios sensibles para la seguridad y la reversión de una entrega? Cuando la confidencialidad lo permita, solicita una revisión anonimizada, el enfoque de pruebas y una lista de verificación para releases.

Acuerden qué significa trabajo terminado y qué evidencia permitirá aceptarlo. Evalúa software funcional, defectos, riesgos abiertos y preparación para operar. Las líneas de código o las horas registradas no demuestran que una entrega resuelva la necesidad del usuario. Si no es posible acceder a un repositorio durante la evaluación, acuerden otra forma de revisar el proceso de ingeniería.

6. Aclara accesos, propiedad intelectual y horarios

Pregunta: ¿Dónde estarán el código y la documentación? ¿Quién controlará las cuentas de nube, credenciales y entornos? ¿Cómo se autorizan y revocan los permisos? Define el acceso necesario para cada tarea y cómo se tratarán los datos de producción y los subcontratistas.

Haz revisar el acuerdo para precisar la propiedad de los entregables, la reutilización permitida, la confidencialidad, los componentes externos y las obligaciones al terminar. Un acuerdo de confidencialidad no define por sí solo los controles de acceso ni la propiedad.

Confirma los horarios reales, el idioma de las conversaciones técnicas, la cobertura de feriados y los tiempos de respuesta. Las modalidades onshore, offshore y nearshore describen ubicación, no acreditan calidad de colaboración. Calcula las horas compartidas entre las personas que participarán, incluidos los cambios estacionales de horario cuando correspondan.

7. Expón los supuestos comerciales

Pregunta: ¿Qué incluye el precio? ¿Sobre qué supuestos se calculó la estimación? ¿Cómo afectan los cambios al presupuesto, al equipo y a las fechas? Separa ingeniería, gestión, incorporación, herramientas, infraestructura, soporte y transición.

Pide una primera entrega, las dependencias que tu equipo debe resolver y un punto de revisión de la estimación. Si quedan incógnitas importantes, una evaluación paga y acotada puede servir para comprobar el encaje técnico y la colaboración. Define qué se entregará, cómo se aceptará y cuándo se decidirá continuar; una prueba vaga no corrige un proyecto sin alcance.

8. Acuerda el soporte y la salida antes de firmar

Pregunta: ¿Quién se ocupará del monitoreo, los incidentes, los defectos, las actualizaciones y las mejoras después del lanzamiento? ¿Qué tiempos de respuesta quedarán en el contrato? Distingue la garantía sobre defectos del mantenimiento continuo y del soporte fuera de horario.

Pide un traspaso que incluya repositorios, instrucciones de compilación y despliegue, notas de arquitectura, guías operativas, inventario de accesos y una sesión de transferencia de conocimiento. Confirma el precio del soporte, el aviso de terminación y la disponibilidad para la transición. La entrega cierra un hito; la operación del software mantiene responsabilidades.

Termina la llamada con evidencia y una decisión pendiente

Clasifica cada respuesta como verificada, prometida o no resuelta. Valida referencias de trabajos comparables, preguntando por dificultades de entrega, cambios de equipo y traspaso. Compara proveedores con el mismo brief y los mismos requisitos de evidencia.

Avanza cuando las responsabilidades, las personas propuestas, el enfoque técnico y los límites comerciales estén suficientemente claros para evaluarlos. Pausa si faltan respuestas críticas o tu equipo todavía no puede tomar las decisiones necesarias.

Si tienes un producto, una necesidad de capacidad definida y una decisión de entrega pendiente, conversa con un ingeniero de Sophilabs. Lleva tu brief y las preguntas que necesitas resolver.