Revisiones ligeras y risk-storming

Por qué fracasan a menudo las juntas de revisión pesadas

Muchas organizaciones gobiernan la arquitectura mediante una junta de revisión de arquitectura: un panel de arquitectos sénior que se reúne cada mes, recibe una presentación de diapositivas o un documento largo, y aprueba o rechaza diseños. La intención es buena: ojos independientes y con experiencia sobre las decisiones significativas. Los resultados suelen ser pobres, por razones estructurales más que personales.

El momento es el primer problema. Una junta que se reúne en momentos fijos ve un diseño o demasiado pronto (todavía no hay nada decidido) o, mucho más a menudo, demasiado tarde, cuando el equipo ya ha construido un prototipo, se ha comprometido con un proveedor y ha prometido una fecha. Entonces el rechazo es tan costoso que la junta aprueba con condiciones a las que nadie da seguimiento. El contexto es el segundo: los revisores que dedican una hora a un sistema que nunca han visto hacen preguntas genéricas y pasan por alto los riesgos concretos que los propios desarrolladores, el personal de operaciones y los ingenieros de seguridad del equipo podrían nombrar en minutos. Los incentivos son el tercero: cuando una revisión es un examen, los equipos presentan el diseño que quieren que se apruebe, no las dudas que tienen, y la junta aprende poco. La cola es el cuarto: una reunión mensual con el orden del día lleno añade semanas de espera a cada decisión significativa, lo que empuja a los equipos a esquivar la junta etiquetando las decisiones como menores.

Nada de esto significa que la revisión independiente no valga nada. Los sectores regulados (banca, sanidad, aviación) suelen necesitar una aprobación documentada, y algunas decisiones realmente necesitan la autoridad de un grupo sénior. La lección es que la revisión debe ser frecuente, temprana, colaborativa y centrada en los riesgos, reservando la aprobación formal para las pocas decisiones que de verdad la requieren. La Sección 11.4 vuelve sobre cómo puede funcionar la gobernanza sin compuertas lentas.

Lo que te aporta una buena revisión ligera

Una revisión ligera es una sesión breve y estructurada, normalmente de una o dos horas, en la que las personas que mejor conocen un diseño y unas pocas que lo ven por primera vez buscan riesgos juntas. Persigue cuatro cosas: descubrir los riesgos mientras todavía es barato abordarlos, construir una comprensión compartida del diseño en todo el equipo, ofrecer un cuestionamiento independiente de los supuestos del arquitecto y dejar constancia de los riesgos aceptados, mitigados o descartados. Su resultado es una lista de riesgos priorizada con responsables, no un veredicto.

Varias técnicas encajan en esta descripción. Se diferencian en lo que examinan (un diagrama, un plan, un documento o un sistema en funcionamiento) y en aquello para lo que mejor sirven, y se combinan bien.

Risk-storming

El risk-storming es una técnica visual y colaborativa creada por Simon Brown, el autor del modelo C4 (Sección 4.3). Se basa en una observación sencilla: personas distintas ven riesgos distintos, y la mejor forma de recogerlos es poner a todos delante de los mismos diagramas y pedirles que miren por su cuenta antes de debatir. Tiene cuatro pasos.

1. Dibuja la arquitectura. Muestra diagramas de lo que piensas construir o cambiar, idealmente en más de un nivel: un diagrama de contexto del sistema y un diagrama de contenedores suelen bastar, con un diagrama de componentes para el contenedor más arriesgado. 2. Identifica los riesgos de forma individual. Cada participante escribe en silencio un riesgo por nota adhesiva, con una descripción breve y una prioridad, durante unos diez minutos. El silencio importa: evita que la primera persona en hablar, o la más sénior, condicione a todas las demás, que es la principal forma en que los debates en grupo pierden información. 3. Haz converger los riesgos sobre los diagramas. Cada persona coloca sus notas en la parte del diagrama a la que se refiere el riesgo. Los grupos aparecen de inmediato, y el diagrama se convierte en un mapa de calor. 4. Revisa y resume. El grupo comenta los grupos de notas y después presta especial atención a dos tipos de nota: los riesgos que ha planteado una sola persona (a menudo alguien con conocimientos que les faltan a los demás, como el ingeniero de soporte) y los riesgos a los que distintas personas han dado prioridades muy diferentes (señal de un malentendido). Los riesgos acordados pasan a un registro de riesgos con responsables; también se registran los elementos que se acuerda que no son riesgos.

La prioridad suele puntuarse como probabilidad por impacto, cada uno valorado como bajo (1), medio (2) o alto (3), lo que da puntuaciones de 1 a 9. La guía de Brown las agrupa en alta (6 o 9), media (3 o 4) y baja (1 o 2), que por convención se muestran con notas rosas o rojas, amarillas o ámbar, y verdes. Una lista de sugerencias ayuda a las personas a pensar más allá de su especialidad: escalabilidad, disponibilidad, rendimiento, seguridad, consistencia de los datos, dependencias de terceros, costo, madurez de la tecnología, competencias del equipo, y entrega y operación.

Pre-mortems

El risk-storming examina una estructura. Un pre-mortem examina un plan. Gary Klein lo describió en la Harvard Business Review en septiembre de 2007. Un post-mortem explica por qué murió un paciente, lo que ayuda a todos menos al paciente; un pre-mortem se hace antes de que empiece el proyecto, cuando las respuestas todavía pueden cambiar su rumbo.

El procedimiento es breve. El líder explica al grupo el plan o la decisión y después anuncia que ahora es dentro de unos meses y que el proyecto ha fracasado, y de mala manera. Cada persona dedica unos minutos a anotar, por su cuenta, todas las razones del fracaso que se le ocurran. Después, el líder recorre la sala recogiendo una razón cada vez hasta agotar las listas, y el responsable del plan las revisa en busca de formas de reforzarlo. Klein cita una investigación de Deborah Mitchell, Jay Russo y Nancy Pennington (1989) que concluyó que imaginar que un acontecimiento ya ha ocurrido (retrospectiva prospectiva) aumenta en torno a un 30% la capacidad de las personas para identificar las razones de resultados futuros. El enfoque también cambia la dinámica social: la pregunta ya no es si el plan podría fracasar, lo que suena desleal, sino por qué fracasó, lo que invita a la creatividad.

En arquitectura, los pre-mortems son especialmente útiles antes de los grandes compromisos: adoptar un estilo dirigido por eventos, migrar a una nube nueva, sustituir un sistema heredado (Sección 11.6) o introducir una plataforma. Entre los resultados habituales que una revisión basada en diagramas pasaría por alto están que el equipo carezca de competencias en la nueva tecnología, que la migración se estanque a medio camino con dos sistemas que operar, que un proveedor clave cambie sus precios y que el negocio pierda la paciencia antes de que lleguen los beneficios.

Katas de arquitectura

Las katas arquitectónicas las creó Ted Neward, inspirándose en las katas de código de Dave Thomas, como ejercicios de práctica para arquitectos. Una kata es un enunciado breve sobre un sistema ficticio (unos pocos párrafos de requisitos, usuarios y restricciones, incompletos a propósito). Equipos pequeños de tres a cinco personas trabajan en ella durante un tiempo fijo, haciendo preguntas a un moderador que hace de cliente para descubrir los requisitos que faltan; después esbozan una arquitectura y la presentan a los demás equipos, que la cuestionan con dureza pero con justicia antes de que la sala vote. Neal Ford mantiene una colección pública de katas, y O'Reilly ha organizado competiciones de katas arquitectónicas.

Las katas no son revisiones de un diseño real, pero contribuyen a la cultura de revisión de dos maneras. Desarrollan la habilidad de explicar y defender un diseño ante las preguntas, y la de hacer buenas preguntas sobre el diseño de otra persona, que es exactamente lo que necesitan las revisiones ligeras. Y una kata interna sobre un problema real que se avecina, con dos o tres equipos diseñando por separado, es una forma barata de explorar el espacio de opciones antes de comprometerse: cuando tres equipos producen tres diseños distintos, las diferencias muestran dónde están los compromisos reales.

TARA y revisiones basadas en listas de comprobación

Las revisiones de sistemas que ya existen se enfrentan a un problema distinto: la arquitectura tal como está construida puede diferir de la arquitectura tal como está descrita, y las pruebas están repartidas entre personas, documentos, código y datos de producción. Eoin Woods, coautor de Software Systems Architecture, describió en 2011 el Tiny Architectural Review Approach (TARA) como una alternativa industrial, deliberadamente ligera, a los métodos muy basados en escenarios. Un número reducido de revisores recaba los requisitos clave y el contexto del sistema, establece su estructura real, evalúa su implementación mediante análisis automatizado (dependencias entre módulos, tamaño, métricas de código, cobertura de pruebas) junto con información de tiempo de ejecución como los logs, usa el juicio experto para vincular lo que encuentra con los requisitos, y presenta los hallazgos y las recomendaciones en un formato predefinido. Su punto fuerte es la rapidez y la evidencia; su debilidad, que Woods reconoció, es que depende de la pericia de los revisores.

Las listas de comprobación complementan todas las técnicas. Una lista de comprobación no encuentra riesgos por sí sola, pero evita que una revisión olvide una categoría entera (la restauración de copias de seguridad, los secretos, el costo a escala) porque a nadie de la sala se le ocurrió pensar en ella. Mantén las listas de comprobación cortas, específicas del historial de incidentes de tu organización y formuladas como preguntas que exijan pruebas en lugar de respuestas de sí o no.

Documentos de diseño y revisiones de RFC

La Sección 4.8 describió los documentos de diseño y los RFC como una forma de proponer un cambio por escrito antes de construirlo. Revisarlos bien es una habilidad en sí misma. Una revisión por escrito tiene ventajas reales sobre una reunión: los revisores comentan cuando tienen tiempo para pensar, los compañeros en remoto y los más callados contribuyen en igualdad de condiciones, y los comentarios quedan como registro. Sus fallos típicos son documentos que nadie lee, hilos de comentarios que nunca se cierran y revisiones que se convierten en una compuerta extraoficial.

Una buena práctica es indicar al principio la decisión que se busca y el plazo para los comentarios, nombrar a los revisores cuya opinión es obligatoria (seguridad, operaciones, los responsables de los servicios afectados) e invitar a cualquier otra persona; pedir a los revisores que etiqueten cada comentario como pregunta, sugerencia o inquietud bloqueante, para que el autor sepa cuáles debe resolver; revisar frente a los escenarios de calidad y la lista de comprobación de más abajo, no frente a los gustos personales; cerrar con una reunión breve solo para las inquietudes sin resolver; y registrar las decisiones significativas como ADR. En las organizaciones que usan el proceso de consejo (Sección 11.4), el RFC es el vehículo para pedir consejo, y la decisión sigue siendo de su autor.