Dirigir un dev en régie a distancia: el ritual de 30 minutos que evita las desviaciones

He dirigido una decena de misiones en régie a distancia desde 2021, con devs ubicados en Ho Chi Minh, Lisboa e Île-de-France. La conclusión es siempre la misma: sin un ritual diario estructurado, una misión se desvía en silencio a los 10 o 15 días. El dev sigue programando, tú sigues pagando, y la brecha entre lo entregado y lo esperado se agranda un poco más en cada sprint. La buena noticia es que un bloque de 30 minutos al día basta para reconducirlo todo.

Por qué el 80 % de las misiones en régie a distancia se desvían en silencio

El problema no es la competencia del desarrollador. El problema es el vacío entre dos puntos de sincronización. Cuando estás en la misma oficina, captas las señales débiles: un dev que suspira delante de un ticket, una pregunta lanzada en voz alta, una pantalla que muestra un diff sospechoso. A distancia, esas señales desaparecen.

Según Gartner, el 64 % de los managers en modo híbrido o remoto declaran carecer de visibilidad sobre el avance real de sus equipos (datos de 2023). En régie, el riesgo se amplifica: el dev no es asalariado, no tiene ninguna obligación de escalar los bloqueos de forma espontánea. Su contrato estipula una tarifa diaria (alrededor de 400 a 600 € para un senior en Francia según Numeum), no un SLA de comunicación.

¿Cuáles son los tres tipos de desviación que hay que vigilar?

La primera desviación es la de alcance. El dev interpreta un ticket de forma más amplia de lo previsto, o se desvía hacia un refactor no solicitado. En presencial, lo ves en tiempo real. A distancia, lo constatas en la demo del viernes, cuando ya es demasiado tarde para corregir sin romper la planificación.

La segunda es la desviación de calidad. El código funciona, pero los tests están ausentes, el tipado es aproximativo y la deuda se acumula. Antony Cherepanov, CEO de Singula Team (equipo 100 % remoto desde 2008), explica que su equipo implementó un sistema de alerta cuando un ingeniero no envía un commit durante más de dos días. La razón: un portátil destruido había provocado la pérdida de una semana entera de trabajo no subido al repo.

La tercera es relacional. Lucas Puerto, CEO de Palur (acelerador de 14 empresas digitales en Brasil), insiste en un punto que muchos CTO subestiman: la confianza a distancia no se construye de forma natural. Sin un espacio dedicado, el dev y el responsable terminan comunicándose únicamente cuando un problema ya ha explotado.

El ritual de 30 minutos, desglosado

Este ritual no tiene nada de teórico. Lo aplico en cada misión que dirijo y lo he ido afinando a base de errores. Se divide en tres bloques de 10 minutos, en un orden preciso.

¿Cómo estructurar los primeros 10 minutos?

Los primeros 10 minutos son un standup síncrono. El dev responde a tres preguntas: qué entregué ayer (PRs mergeadas, no "estuve trabajando en"), qué entrego hoy (ticket Jira concreto, no "sigo con lo mismo"), y qué me bloquea (aunque la respuesta sea "nada").

El formato es estricto. Nada de conversación libre durante estos 10 minutos.

Este standup es deliberadamente más exigente que la versión clásica. Pido PRs mergeadas, no tiempo invertido. John Wooden, ex entrenador NBA citado por Lucas Puerto, resumía bien el matiz: "No confundas la actividad con el logro." Un dev que ha pasado 7 horas en un ticket sin subir un solo commit no ha entregado nada. Es una realidad que muchos responsables prefieren no ver.

¿Qué verificar durante la revisión de código?

Los 10 minutos siguientes se dedican a la PR más reciente. No una revisión exhaustiva, sino una revisión de encuadre. Tres elementos a verificar: el perímetro del diff (¿el dev ha tocado únicamente lo que se pedía?), la cobertura de tests (un test por camino crítico como mínimo) y la coherencia con la arquitectura del proyecto.

Un diff que toca más de 5 archivos no relacionados con el ticket es una señal de alerta. Es exactamente ahí donde empieza el scope drift. Si el dev ha refactorizado un módulo entero cuando el ticket pedía un fix de CSS, lo ves de inmediato. No el viernes.

Singula Team va más allá: su sistema GitHub monitoriza el número de PRs abiertas por ingeniero. Si un dev tiene varias tareas en paralelo en estado "in progress", es un signo de dispersión. Un solo ticket en curso a la vez, salvo excepción validada por el responsable.

¿Para qué sirven los últimos 10 minutos?

El último bloque es un mini-planning. El dev y tú alineáis los dos siguientes tickets a abordar, su estimación restante y la prioridad. La estimación debe expresarse en horas, no en story points.

Singula Team impone una regla que he adoptado: todo ticket estimado en más de 16 horas se divide en subtareas antes de empezar. Si la estimación restante de un ticket sube en vez de bajar de un día para otro, es una bandera roja que justifica una conversación inmediata.

Este bloque de 10 minutos es el que impide la desviación de planificación. Bocasay, especialista en desarrollo offshore, recomienda en su guía dividir cada proyecto en etapas cortas para "controlar la dirección que toma el proyecto y limitar los errores innecesarios". Mi experiencia lo confirma: un planning revisado a diario no se desvía.

Las herramientas que hacen viable el ritual en el día a día

Un ritual sin herramientas adaptadas se convierte en una carga. Esto es lo que uso en mis misiones, con un coste total cercano a cero para el cliente.

¿Qué herramienta para qué canal de comunicación?

El punto clave es la separación de canales. Slack para los intercambios rápidos, GitHub para todo lo relacionado con el código, Jira para el seguimiento formal. Mezclar los canales destruye la trazabilidad. Si un dev plantea una cuestión de arquitectura en un hilo de Slack que desaparece a los 90 días, has perdido la decisión para siempre.

Bocasay también menciona la importancia de los procesos formales: "Estos procesos son bastante tediosos de establecer al principio, pero realmente merecen la pena a largo plazo." Añado un punto que pocos mencionan: estos procesos deben caber en el ancho de banda real del responsable. Si pilotas 3 devs en paralelo, tienes 90 minutos de ritual al día. Ni uno más, so pena de no producir nada tú mismo.

Lo que cambia cuando el dev está aumentado por la IA

La mayoría de las guías sobre dirección a distancia son anteriores a la ola de herramientas IA de desarrollo. En 2026, un desarrollador senior aumentado que utiliza Claude Code, Cursor o GitHub Copilot entrega entre 2 y 4 veces más código que un dev clásico en tareas de scaffolding y CRUD.

¿Por qué el ritual se vuelve aún más crítico con un dev aumentado?

Esa velocidad incrementada hace que el ritual de 30 minutos sea todavía más necesario. Un dev aumentado que toma la dirección equivocada produce 3 veces más código inútil que un dev clásico en el mismo periodo de tiempo. La velocidad amplifica los errores de encuadre, no solo la productividad.

En mis misiones recientes, he constatado que la revisión de código del bloque 2 adopta una forma diferente con un dev aumentado. El diff es más voluminoso, pero los patrones son más repetitivos (el código generado por IA tiene una firma reconocible). Verifico tres cosas adicionales: las alucinaciones de dependencias (imports de paquetes que no existen), el código muerto (funciones generadas "por si acaso") y la sobreabstracción (al LLM le encanta crear helpers para operaciones que solo aparecen una vez).

Si dudas entre contratar un dev en plantilla o tomar un perfil en régie a 180 €/día, el ritual de 30 minutos inclina la balanza hacia la régie. Con un proceso de dirección claro, obtienes la flexibilidad sin la opacidad que asusta a los CTO. Cada día, sabes exactamente en qué punto está el proyecto.

La herramienta que usa el dev (Claude Code, Cursor o Copilot) importa menos que el proceso que la enmarca. Lo he visto en tres misiones consecutivas: un dev senior con 8 años de experiencia mínimo, armado con Claude Code y dirigido con este ritual, entrega el equivalente a un sprint de dos semanas en 5 días laborables. Sin el ritual, el mismo dev entrega rápido, sí, pero te pasas el sprint siguiente corrigiendo las desviaciones del anterior.

Dirigir un dev en régie a distancia no requiere ni micromanagement ni vigilancia constante. Lo que requiere es una disciplina de 30 minutos al día, dividida en tres bloques que cubren la entrega (standup), la calidad (revisión de código) y la dirección (planning).

He probado alternativas: rituales bisemanales, standups asíncronos solos, demos semanales sin revisión de código diaria. Ninguna ha resistido en una misión de más de 3 meses sin una desviación importante. La cadencia diaria es el único formato que evita la desviación silenciosa que todo responsable de misión conoce.

Mi consejo: empieza desde el primer día de la misión. No la segunda semana "cuando el dev se haya instalado". El ritual establece el marco, y un dev senior prefiere un marco claro a una ambigüedad cortés. Si tu dev se resiste al formato, es una señal. Un buen desarrollador en régie sabe que la transparencia protege a ambas partes.