Validación de requisitos, cómo evitar la huida hacia adelante

Estáis en un proyecto en el que empezáis a obtener requisitos mediante entrevistas con interesados. Una vez finalizada cada entrevista, elaboráis un acta de reunión que pretende recoger lo comentado en ella, los principales acuerdos y próximos pasos. Enviáis el acta y nunca recibís respuesta. Como esto ya os ha pasado en otros proyectos, habéis tenido la precaución de poner la coletilla de “si no se recibe respuesta en una semana, se considerará aprobada”. Avanzamos…

Basáis el análisis y documentación de requisitos en la información obtenida en las entrevistas, hasta que obtenéis una primera versión de análisis de requisitos que enviáis a vuestro cliente para que la valide. De nuevo, “si no se recibe respuesta…”. Obtenéis un escueto mail de respuesta diciendo “Recibido. Ok”. Seguimo s avanzando…

No hace falta tener una bola de cristal para saber que, en algún momento, hacia el final del proyecto, descubriremos que el producto no es aceptable, no incluye funcionalidades o características que son “imprescindibles” para el cliente.
Solucionar esto, además de tener que pasar por interminables discusiones respecto a quién asume el coste de estos cambios (“qué cambios?”), será bastante más costoso que si lo hubiéramos detectado antes (es más fácil modificar un documento que un software). ¿Qué ha pasado? ¿Qué podríamos haber hecho mejor?

Si hay algún Project Manager en la sala que realice funciones de obtención y análisis de requisitos en su proyecto, este post va especialmente dirigido a él o ella. A veces el foco en cumplir fechas nos lleva a querer avanzar a cualquier precio, en una eterna huida hacia adelante, cuando aún no tenemos unas buenas bases creadas. En este post reflexionamos acerca de cómo hacer que la validación de requisitos no sea un stopper para el proyecto, cómo conseguir avanzar sobre bases seguras (al menos, aceptadas por todos).

Validación de requisitos: Continua, Explícita, Consciente y Formal

La validación de requisitos debe reunir siempre cuatro características principales: debe ser Continua, Explícita, Consciente y Formal.

Continua

Debemos buscar feedback de nuestro cliente de manera continua. No esperar a que tenga que leerse un documento de 500 páginas, sino debemos ir obteniendo validaciones progresivas. El uso de Historias de Usuario, por ejemplo, en métodos ágiles, facilita esta validación continua al tratarse de requisitos pequeños en tamaño, independientes entre sí, y organizados en iteraciones cortas en tiempo.

Pero no es necesario estar en proyectos ágiles, cuanta más interacción tengamos con nuestro cliente en cualquier tipo de proyecto, mayor implicación conseguiremos por su parte. Para ello, es importante al principio delimitar claramente roles y responsabilidades (quién tiene que validar qué), y acordar con estas personas su disponibilidad y relación con el proyecto.

Explícita

La validación deberá ser obtenida siempre explícitamente, en algún momento nuestro cliente nos tendrá que indicar que está de acuerdo con los requisitos definidos. Hasta ese momento, no los consideraremos validados.

Debemos evitar la validación “automática” una vez superado un periodo de tiempo, debemos insistir para obtener la validación cuanto antes.

Consciente

Relacionado con el anterior. A veces un cliente se sabe cuello de botella y simplemente da su “ok” aunque no acabe de estar de acuerdo (“de momento, avanzad… que ya lo veremos más adelante…”). Realmente no está validando los requisitos y, estamos retrasando una validación que repercutirá (seguro) en costes y fechas de proyecto.

Si nos tiene que dar su conformidad, debemos asegurarnos que ésta se produce de manera consciente, asegurándonos que ha entendido y acepta todo lo que incluye y lo que no incluye el material a validar.

Formal

Aunque a lo largo del proyecto puede haber muchas revisiones y validaciones con diferentes niveles de formalidad, debe haber un momento en el tiempo en el que haya un acto formal de validación. La validación no debería realizarse únicamente por correo electrónico o similar, sino a través de reunión presencial o virtual (videoconferencia).

¿Y cómo conseguimos la validación de requisitos?

La Guía del BABOK v3 habla de las Revisiones de requisitos (Reviews) como la técnica adecuada para asegurar la validación continua, explícita, consciente y formal. (PRINCE2 también se refiere a ella como Técnica de Revisión de Calidad).

Técnica de Revisión de Requisitos

Una revisión formal debe seguir los siguientes pasos:

1. Planificar suficiente tiempo para los participantes
2. Entregar los materiales a revisar
3. Revisar los materiales previo a la reunión de revisión
4. Realizar la reunión de revisión

Las revisiones aplican a todo el trabajo de BA, incluso trabajo en curso (por ejemplo, peer reviews o revisiones de colegas), y pueden incluir:

• Una visión global del producto a revisar y los objetivos de la revisión (en función del momento del proyecto en el que estemos)
• Checklists o material de referencia
• Revisión del producto utilizando diferentes técnicas, como por ejemplo Inspección o Formal walkthrough

5. Documentar los cambios a realizar en los materiales
6. Actualizar los materiales
7. Realizar una segunda revisión, si es necesario