Documentos del Proyecto · Serie 15 · Semana Inicio · Tema 24
Ayer vimos qué lleva dentro la documentación de requisitos. Este otro documento no lista requisitos: dice cómo se van a manejar los que aparezcan.
Se parecen tanto de nombre que mucha gente escribe uno y cree que tiene los dos.
La diferencia, en una línea
La documentación de requisitos es qué. El plan de gestión de requisitos es cómo: cómo se recogen, cómo se priorizan, cómo se cambian y cómo se comprueban.
Uno crece durante todo el proyecto. El otro se escribe una vez y se toca poco.
Qué va dentro
1. Cómo se recogen
Qué técnicas y con quién. Entrevistas, observación, prototipos, talleres. Y, sobre todo, cuándo se deja de recoger: una fecha a partir de la cual lo nuevo entra como cambio, no como requisito.
Ese corte es el apartado que evita que la recolección se convierta en un pozo.
2. Cómo se priorizan
Con qué escala y quién decide. Una escala de tres niveles bien definida vale más que una de cinco que nadie sabe aplicar.
Lo importante no son los nombres, sino que cada nivel diga qué pasa si no se hace:
- Imprescindible — sin esto no se puede poner en marcha.
- Importante — se puede arrancar sin ello, con un rodeo manual conocido.
- Deseable — mejora el resultado y no impide nada.
Si tu escala no permite decir «esto es deseable» sin que nadie se ofenda, no tienes una escala.
3. Cómo se trazan
De dónde viene cada requisito y hacia dónde va: a qué entregable, a qué prueba. Es lo que hará útil la matriz de trazabilidad, que es el documento de mañana.
4. Cómo se cambian
Un requisito aprobado no se edita en silencio. Aquí se dice quién puede cambiarlo y por qué vía —normalmente, la misma del plan de gestión de cambios.
5. Cómo se verifican
Quién comprueba que cada requisito se cumplió, con qué evidencia y en qué momento. Si esto no está, la verificación acaba siendo una reunión de opiniones al final.
6. Cómo se versiona y dónde vive
Un sitio, una versión vigente, y quién la mantiene. Dos versiones circulando es el fallo más común y el más caro de todos los de este documento.
Qué lo vuelve papel mojado
- No dice cuándo se deja de recoger. Y entonces no se deja nunca.
- La escala de prioridad no distingue nada. Si todo acaba en «alta», la prioridad no existe.
- Nadie mantiene el documento. Un plan sin responsable nombrado no se aplica.
- Repite el plan de cambios. Si ya tienes uno, aquí solo se referencia. Dos procedimientos para lo mismo garantizan que se use el más cómodo.
Y si me falta lo que pide
No puedo fijar una fecha de corte. Fíjala por fase en vez de por proyecto: «los requisitos de la fase 1 se cierran el 30 de octubre». Es más fácil de aceptar y funciona igual.
El cliente prioriza todo como imprescindible. Cambia la pregunta. En vez de «¿qué prioridad tiene?», pregunta «si esto no estuviera el día de arranque, ¿podríais operar?, ¿cómo?». La respuesta prioriza sola.
No tengo herramienta de trazabilidad. Una hoja de cálculo sirve perfectamente hasta unos cuantos cientos de requisitos. Lo que no sirve es no tener ninguna.
Caso práctico: la recolección que no terminaba
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto de sistema de gestión para una red de clínicas planifica seis semanas de recolección de requisitos. En la semana catorce seguía recogiendo.
No por desorden. Cada vez que el equipo presentaba el documento para cerrarlo, alguna de las nueve clínicas señalaba una particularidad suya que no estaba contemplada. Todas tenían razón. Y cada particularidad abría dos más.
El plan de gestión de requisitos existía. Tenía cuatro apartados y ninguno decía cuándo se paraba.
Se cerró cuando la dirección impuso un corte con dos reglas escritas: lo recogido hasta el 15 de mayo entra en la fase 1; lo posterior entra en la lista de la fase 2 y se revisa en septiembre.
Lo interesante es lo que pasó después: de las 34 particularidades que quedaron para la fase 2, en septiembre solo 11 seguían pareciendo necesarias. Las otras se habían resuelto con el sistema en marcha, o dejaron de importar.
Ocho semanas de recolección extra se habrían gastado en construir veintitrés cosas que nadie iba a necesitar.
Checklist
- ¿Dice cuándo se deja de recoger requisitos?
- ¿La escala de prioridad define qué pasa si algo no se hace?
- ¿Hay alguien nombrado que mantiene el documento de requisitos?
- ¿Dice quién verifica cada requisito y con qué evidencia?
- ¿Remite al plan de cambios en vez de inventar otro procedimiento?
- ¿Hay una sola versión vigente y todo el mundo sabe dónde está?
Para cerrar
Este plan es corto —dos páginas bastan— y se nota su ausencia en cosas que parecen otra cosa: recolecciones que no acaban, prioridades que no priorizan, requisitos que cambian sin que nadie se entere.
De sus seis apartados, el que más rinde es el más incómodo: la fecha en que se deja de escuchar.
Te leo en los comentarios: ¿existe en tu proyecto una fecha a partir de la cual lo nuevo entra como cambio?
Referencias
- Project Management Institute, Guía del PMBOK, sobre el plan de gestión de los requisitos.
- International Institute of Business Analysis, BABOK, sobre planificación del análisis de negocio y gobernanza de requisitos.
- Wiegers, K. y Beatty, J., Software Requirements, sobre priorización y línea base de requisitos.
← Anterior en la serie: La documentación de requisitos: el campo que todos omiten
Siguiente en la serie: La matriz de trazabilidad se lee hacia atrás →
Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.