Specify, Refine, Plan, Build, Verify, Learn: seis etapas para saber en qué punto está un proyecto

Pregunta a cinco personas del mismo equipo en qué punto está una funcionalidad. El product owner responde “la spec está validada”. El desarrollador responde “me quedan dos tickets”. QA responde “no he recibido nada que probar”. La dirección responde “está previsto para la próxima versión”. Todos dicen la verdad, y nadie habla de lo mismo.

El problema no es la falta de información. Es la falta de un vocabulario común para situar el trabajo en el tiempo.

Las herramientas ordenan por objeto, los equipos piensan por momento

Abre cualquier herramienta de gestión de proyectos. El menú enumera tipos de objetos: tickets, tableros, versiones, documentos, pruebas. Es un orden de base de datos. Responde a “¿dónde está tal cosa?”, nunca a “¿qué hay que hacer ahora?”.

Un equipo, en cambio, razona por momento. Estamos definiendo. Estamos produciendo. Estamos verificando. Ese desfase obliga a cada persona a reconstruir mentalmente el estado del proyecto a partir de listas que no lo muestran.

Seis verbos, siempre en el mismo orden

Sinra organiza su navegación en torno a seis etapas:

• Specify: describir lo que el producto debe permitir. Aquí se redactan las capabilities y sus specs.
• Refine: comprobar que está lo bastante claro para comprometerse. El equipo revisa, aclara las zonas grises, estima.
• Plan: decidir qué se entrega y cuándo. Las releases y los cycles se llenan según la capacidad real del equipo.
• Build: realizar. Cada persona ve sus issues, el cycle actual, la release actual.
• Verify: asegurarse de que está listo. Se ejecutan las pruebas, la revisión de fase decide.
• Learn: sacar lecciones. La retrospectiva y el postmortem alimentan la siguiente especificación.

Estas seis palabras están en la barra lateral, en ese orden. No hay nada más que aprender.

El V-Model, sin decirlo

Lee la lista de arriba abajo: las tres primeras etapas precisan, la cuarta produce, las dos últimas controlan lo que se precisó. Es la forma de una V. Nada se construye sin spec, nada se entrega sin verificación.

Pero esa V no se recorre una vez por proyecto, durante dieciocho meses. Se recorre en cada release, a veces en cada cycle. El rigor viene del orden de las etapas. El ritmo viene de su repetición.

Es lo que los equipos que “combinan V-Model y Agile” ya hacen sin formularlo. Las seis etapas le dan un nombre.

Lo que cambia en el día a día

Las conversaciones se acortan. “La capability de pagos está en Refine” dice en pocas palabras lo que antes requería una reunión: la spec existe, aún no está estimada, no está en ninguna release.

Los huecos se hacen visibles. Un equipo que nunca abre Verify o Learn lo ve en su propia navegación. Ningún informe lo dice con tanta claridad.

Las personas nuevas se orientan solas. Un desarrollador abre Build. Alguien de QA abre Verify. Nadie necesita formación para saber dónde empieza su trabajo.

Lo que no es

No es un proceso impuesto. Ninguna etapa bloquea, y un equipo de tres personas puede pasar de Specify a Build sin ceremonia.

No es un método que haya que certificar. No hay rol que nombrar, ni ritual obligatorio, ni coach que contratar.

No es una cascada. Varias capabilities están en etapas distintas al mismo tiempo. Las seis etapas describen el recorrido de una funcionalidad, no el calendario del equipo.

Un orden más que un método

Los métodos suelen fracasar porque piden al equipo que cambie antes de producir. Un orden pide menos: basta con saber qué va antes y qué va después.

Specify, Refine, Plan, Build, Verify, Learn. Seis palabras para que cinco personas den por fin la misma respuesta.

El detalle de cada etapa está en la documentación del Workflow.