Qué esperar en tus primeros 90 días con un equipo nearshore
La luna de miel, la fricción y el momento en que hace clic. Una línea de tiempo realista de cómo se ven los primeros tres meses.
El pitch deck dice que el desarrollo nearshore es “sin fricción.” No lo es. Funciona, y funciona bien, pero los primeros 90 días tienen una forma que nadie menciona en la llamada de ventas. Así se ve esa forma, basado en onboardear docenas de clientes en los últimos 11 años.
Semana 1-2: El setup
Logística. Se crean canales de Slack. Se configuran boards de ClickUp. Se comparten repos de GitHub. Se distribuyen links de Zoom. Alguien descubre que su VPN bloquea nuestro rango de IPs. Alguien más se da cuenta de que las credenciales del staging están en un Google Doc que nadie encuentra.
Lo aburrido, lo tedioso. Importa más de lo que la gente cree. Una mala semana de setup crea fricción que dura meses. Una buena establece el ritmo sobre el que corre todo lo demás.
Lo que hacemos: mandamos un checklist de kickoff antes de la primera llamada. Accesos a herramientas, acceso a repos, archivos de diseño, documentación, deuda técnica existente, issues conocidos. Cuanto más sepamos antes del día uno, menos tiempo se pierde durante el mismo.
Esperá que esta fase tome las dos semanas completas. Apurarla crea problemas después.
Semana 3-4: Primer sprint, primera fricción
El primer sprint siempre es un poco incómodo. Tu equipo tiene convenciones que no están escritas. Nuestros developers las siguen una vez que las ven, pero el primer code review va a tener comentarios tipo “eso no lo hacemos así” o “este archivo debería ir en otro directorio.” Es normal. Así es como el equipo aprende los estándares del otro.
Acá es donde emergen los patrones de comunicación. Algunos clientes quieren un standup diario. Otros prefieren un update por Slack y una llamada semanal. Algunos quieren descripciones detalladas en los tickets. Otros quieren una nota de voz rápida. No hay una respuesta universal correcta. El objetivo de la semana 3-4 es descubrir qué funciona para este equipo en particular.
La fricción en esta fase es saludable. Significa que ambos lados están prestando atención.
Mes 2: Se construye confianza, aumenta velocidad
En algún momento del segundo mes, algo cambia. Los code reviews se hacen más rápidos porque nuestros developers internalizaron tus patrones. Los mensajes de Slack se acortan porque el contexto es compartido. Alguien hace un chiste en el standup. Ahí es cuando sabés que está funcionando.
Acá es también cuando pasa el primer desacuerdo real. Tal vez creemos que un feature debería construirse diferente a lo que dice el spec. Tal vez hay un issue de deuda técnica que queremos señalar antes de que empeore. Cómo ambos lados manejan este primer desacuerdo marca el tono para el resto de la relación.
Nuestro approach: lo planteamos directo, explicamos nuestro razonamiento y dejamos que vos tomés la decisión final. Es tu producto. Pero si vemos un problema y no decimos nada, no estamos haciendo nuestro trabajo.
Mes 3: Dejan de ser “el equipo nearshore”
Para el mes tres, la distinción entre “tu equipo” y “nuestro equipo” empieza a difuminarse. Nuestros developers están en el mismo sprint board, los mismos hilos de Slack, el mismo ciclo de code review. Alguien de tu lado hace una pregunta y nuestro developer la responde antes que vos. Ese es el momento.
No todos los engagements llegan acá en exactamente 90 días. Codebases complejos toman más. Simples son más rápidos. Pero este es el arco general.
Tropiezos comunes y cómo evitarlos
Subestimar la fase de setup. No intentes entregar código en la semana uno. Invertí en el setup y lo recuperás en el mes dos.
Sin punto de contacto designado. Si tres personas de tu lado dan dirección a nuestros developers, nadie sabe el feedback de quién priorizar. Elegí una persona. Aunque otros contribuyan, una persona toma la decisión.
Esperar velocidad máxima inmediata. Un developer nuevo, sea nearshore o in-house, necesita tiempo de rampa. El output del sprint uno va a ser menor que el del sprint cuatro. Planificá para eso.
Saltarse la primera retrospectiva. Después del sprint dos o tres, hacé un retro. No la plantilla de “qué salió bien / qué no.” Una conversación honesta sobre qué funciona y qué molesta. Acá es donde arreglos chicos previenen problemas grandes.
¿Vale la pena?
Soy parcial, obvio. Pero los datos están de nuestro lado: la mayoría de nuestros engagements que sobreviven el mes tres se convierten en relaciones de varios años. El arco de 90 días es real, y es una inversión menor relativa a lo que viene después.
Si estás considerando nearshore por primera vez y querés entender cómo se ven los primeros tres meses con un equipo específico, no con un pitch deck, con gusto te lo explicamos.
¿Tienes un proyecto en mente?
ContáctanosMás Artículos
El costo real de una mala agencia de desarrollo
Nos han contratado para arreglar el desastre. Más de una vez. Esto es lo que cuesta y cuáles eran las señales de alerta.
LeerPor qué las empresas SaaS están contratando developers en Costa Rica
La zona horaria, el talento, el costo. Por qué más equipos de producto de EE.UU. están construyendo con ingenieros de Costa Rica.
LeerConstruir una plataforma de noticias que no se caiga con noticias de último momento
Qué pasa cuando el tráfico sube 10x en 30 minutos, y lo que aprendimos construyendo más de 5 plataformas de medios que lo aguantan.
Leer