Al incorporarme a un equipo quiero ver cómo publica un cambio. Basta con uno pequeño: un cliente pide algo, el equipo modifica el software y el cambio llega a producción. Seguir ese recorrido me indica dónde mirar después.
También querría saber qué espera el fundador que haya cambiado dentro de tres meses. Esas dos conversaciones dan un propósito a la revisión técnica. Esto es lo que miraría durante el primer mes.
¿Qué hay que entregar?
“Necesitamos ir más rápido” deja demasiadas cosas abiertas. ¿Hay un contrato pendiente de una función? ¿Se pierden clientes por problemas de fiabilidad? ¿El soporte ocupa toda la semana? Cada situación requiere un trabajo distinto.
Lo preguntaría por separado al fundador, al responsable de producto y a los desarrolladores. Si nombran prioridades diferentes, hay que resolverlo antes de añadir más tareas. Una lista breve de prioridades compartidas basta para empezar.
Seguir un cambio de principio a fin
Elige un ticket reciente y revísalo con las personas que lo trabajaron. Mira la petición original, la pull request, las pruebas y la publicación. Pregunta en qué momentos se quedó esperando y por qué.
Quizá un cambio de un día pasó una semana esperando una decisión. Quizá todas las publicaciones dependen del portátil de un desarrollador. Esos detalles explican un problema de entrega mejor que un diagrama general de arquitectura.
Comprobar qué puede detener el negocio
Revisaría pronto los accesos a producción, las publicaciones y la posibilidad de restaurar los datos. Me preocupa más una copia de seguridad sin probar que un framework que el equipo quiere sustituir.
Para los demás problemas pediría un caso concreto: qué falla, quién lo detecta y cómo nos recuperamos. “El código es antiguo” necesita más explicación. “Solo una persona puede publicar y se va el mes que viene” nos permite actuar.
Terminar una mejora con el equipo
Elegiría un problema recurrente que el equipo pueda resolver durante el mes. Automatizar un paso manual, quitar una aprobación lenta o corregir una alerta que salta sin motivo puede ayudar. El equipo debería participar en la elección.
Trabajar juntos en ese cambio también me ayuda a conocer el código. Puedo revisar la implementación y entender sus límites antes de recomendar un trabajo mayor.
Escribir las próximas decisiones
Al acabar el mes querría un documento breve que podamos usar en una reunión: las prioridades, los riesgos, las próximas decisiones y sus responsables. Una propuesta de reescritura o contratación debería explicar qué problema resuelve y cuánto costará.
Incluiría las preguntas que todavía no sabemos responder. Hay sistemas que requieren más tiempo. El documento debe ayudar a decidir qué hacer la semana siguiente, sin dar por terminada la revisión.