Plantilla de coordinación de revisión de código

Las revisiones de código son donde la calidad se encuentra con la velocidad—y donde ambas pueden estancarse. Cuando los PRs quedan sin revisar, los autores pierden contexto, los merges se acumulan, y el lead time del equipo se infla silenciosamente. Esta plantilla hace visible el pipeline de revisión cada día para que los PRs estancados y revisores sobrecargados se detecten antes de volverse problemas.

Preguntas de la plantilla

Pregunta 1: PRs esperando revisión

Tipo: Texto libre (o número + enlaces)

Indicación: “¿Cuántos PRs estás esperando que alguien más revise? Listarlos si es posible.”

Esto muestra el lado del autor de la ecuación. Cuando una persona consistentemente tiene tres o más PRs esperando, o el equipo necesita rebalancear la carga de revisión o los PRs son muy grandes y deberían dividirse.

Pregunta 2: PRs asignados a ti

Tipo: Texto libre (o número + enlaces)

Indicación: “¿Cuántos PRs tienes asignados para revisar? ¿Has empezado alguno?”

Esto muestra el lado del revisor. Si alguien tiene cinco revisiones pendientes y no ha empezado ninguna, el equipo sabe dónde está el cuello de botella. El calificador “has empezado” separa el trabajo en cola del trabajo activamente bloqueado.

Pregunta 3: Bloqueos de revisión

Tipo: Sí/No con seguimiento condicional

Indicación: “¿Alguna revisión está bloqueada? (alcance poco claro, contexto faltante, tests fallando, etc.)”

Seguimiento (si sí): “¿Qué está bloqueando la revisión y quién puede ayudar?”

No todos los retrasos de revisión son por tiempo. Algunos PRs no pueden revisarse porque los tests están fallando, el alcance no es claro, o el revisor carece de contexto sobre la funcionalidad. Esta pregunta separa problemas de capacidad de problemas de información.

Instrucciones de configuración

Horario

Ejecuta este check-in diariamente, a media mañana. El momento ideal es después de que el equipo ha tenido oportunidad de revisar su bandeja de entrada pero antes de comenzar trabajo de concentración profunda. Para equipos en múltiples zonas horarias, prográmalo durante la ventana de superposición.

Esta plantilla funciona como un check-in independiente o como preguntas adicionales agregadas a tu standup diario existente. Si tu standup ya pregunta sobre bloqueos, el check-in de revisión agrega especificidad sin duplicar la pregunta de bloqueos.

Enrutamiento

Publica las respuestas en un canal compartido de desarrollo para que el equipo tenga visibilidad colectiva. Cuando se reporta un bloqueo de revisión, considera enrutarlo directamente al revisor asignado vía DM como un recordatorio amable.

Para gerentes, agrega los datos semanalmente: total de PRs abiertos en cualquier momento, tiempo promedio de espera, y qué miembros del equipo cargan la mayor cantidad de revisiones. Estas métricas alimentan conversaciones de salud del equipo y balance de carga de trabajo.

Expectativas de respuesta

Mantén las respuestas breves. Una buena respuesta se ve así: “2 PRs esperando (auth-refactor, pagination-fix). 1 asignado a mí, empecé a leerlo.” El objetivo no es un reporte detallado—es un dato diario que hace visible lo invisible.

Consejos para reducir el tiempo de ciclo de revisión

Establece un SLA de equipo: acuerden que las revisiones deberían recibir una primera respuesta dentro de cuatro horas laborales. Rastrea el cumplimiento a través de los datos del check-in.

Rota parejas de revisión: evita el patrón donde las mismas dos personas siempre se revisan mutuamente. La rotación amplia distribuye conocimiento y previene puntos únicos de falla.

El tamaño importa: los PRs grandes toman más tiempo para revisar y es más probable que queden esperando. Promueve PRs de menos de 400 líneas cambiadas. Los datos del check-in mostrarán si los PRs grandes se correlacionan con tiempos de espera más largos.

Revisar antes de trabajo nuevo: promueve el hábito de limpiar tu cola de revisión antes de empezar trabajo de funcionalidades nuevo. El check-in hace visible la cola para que este hábito se vuelva natural.

Medir el impacto

Después de ejecutar esta plantilla durante dos sprints, compara tu tiempo promedio de revisión de PR contra la línea base. La mayoría de los equipos ve una reducción de 30-50% en el tiempo desde la apertura del PR hasta el primer comentario de revisión simplemente porque la cola se hizo visible. Si la mejora se estanca, agrega recordatorios automatizados o escalación para PRs que excedan el SLA.

La plantilla funciona porque resuelve el problema raíz: las revisiones son trabajo invisible que compite con trabajo visible de funcionalidades. Al hacer las revisiones visibles cada día, el equipo las trata como trabajo real en lugar de ruido de fondo.