Gestión de Alcance y Tiempo · Serie 3 · Semana 1 · Tema 1
El dato más citado de la industria sigue siendo incómodo: buena parte de los proyectos que fracasan no lo hacen por problemas técnicos, sino porque se construyó algo que nadie pidió. Y cuando rastreas hacia atrás, el origen casi siempre es el mismo: la recolección de requerimientos se hizo en una junta de dos horas y se dio por terminada.
Recolectar requerimientos no es levantar una lista de deseos. Es un proceso con técnicas propias, entregables definidos y una trampa muy concreta: el interesado no siempre sabe lo que necesita, y casi nunca sabe expresarlo en términos verificables.
Un plan de proyecto se sostiene sobre esto. Vimos qué contiene de verdad; el apartado de alcance empieza aquí.
Primero: ¿qué es un requerimiento bien escrito?
Un requerimiento sirve si se puede verificar. "El sistema debe ser rápido" no es un requerimiento, es una aspiración. "El sistema debe responder en menos de 2 segundos para el 95% de las consultas con hasta 500 usuarios concurrentes" sí lo es, porque alguien puede medirlo y decir sí o no.
La regla mnemotécnica más usada para esto es SMART:
- Specific / específico: sin ambigüedad sobre qué se pide.
- Measurable / medible: existe una forma de comprobarlo.
- Achievable / alcanzable: es posible con los recursos previstos.
- Result-oriented / orientado a resultados: describe un resultado, no una actividad.
- Time-limited / con fecha límite: se sabe para cuándo.
El criterio que más se descuida es el cuarto. "Capacitar al personal" es una actividad; "el 90% del personal operativo aprueba la evaluación de certificación interna" es un resultado. La diferencia decide si puedes dar algo por terminado o te quedas discutiendo.
Los tipos de requerimiento que se olvidan
Casi todos los equipos recogen bien los requerimientos funcionales: lo que el producto debe hacer. Los que se pierden son los otros tres, y son los que aparecen tarde y caro:
| Tipo | Pregunta que responde | Ejemplo |
|---|---|---|
| Funcional | ¿Qué debe hacer? | Generar un reporte mensual de consumo |
| De operación | ¿Cómo se sostiene en el día a día? | Respaldos diarios y ventana de mantenimiento de 4 h |
| De calidad | ¿Qué tan bien debe funcionar? | Disponibilidad del 99.5% mensual |
| Ambientales / de la organización | ¿Qué restricciones impone el entorno? | Cumplir la normativa de protección de datos vigente |
Los requerimientos de operación son los más traicioneros. El proyecto termina, el equipo se disuelve, y seis meses después alguien descubre que nadie definió quién hace los respaldos. Ese costo existe: simplemente se cargó al área operativa en lugar de al proyecto.
Técnicas de recolección: cuál usar y cuándo
No hay una técnica superior; hay técnicas adecuadas a cada situación.
- Entrevistas. Cuando necesitas profundidad y hay temas sensibles. Caras en tiempo, insustituibles en calidad.
- Talleres facilitados. Cuando hay interesados con intereses en conflicto y necesitas que negocien en la misma sala. Resuelven en un día lo que por correo toma un mes.
- Encuestas. Cuando el universo es grande y las preguntas son cerradas. No sirven para explorar.
- Observación directa. Cuando lo que la gente dice que hace y lo que hace no coinciden. Sorprendentemente frecuente.
- Prototipos. Cuando el interesado no puede imaginar el resultado. Un prototipo desechable ahorra meses de reproceso.
- Análisis de documentos. Cuando ya existen procesos, normas o sistemas que condicionan la solución.
- Lluvia de ideas y técnicas de grupo nominal. Para generar opciones y luego priorizarlas con votación.
Un consejo práctico: combina siempre al menos dos. Lo que un interesado te dice en una entrevista y lo que hace cuando lo observas son dos conjuntos de requerimientos distintos, y ambos son ciertos.
Los tres entregables que cierran el proceso
Recolectar sin documentar no cuenta. El proceso produce tres cosas concretas:
1. Documentación de requerimientos
El listado completo, con un identificador único por requerimiento, su prioridad, su criterio de aceptación y quién lo solicitó. El identificador no es burocracia: es lo que hace posible el tercer entregable.
2. Plan de gestión de requerimientos
Cómo se van a analizar, priorizar y cambiar los requerimientos a lo largo del proyecto. Responde: ¿quién autoriza añadir uno nuevo? ¿Con qué criterio se prioriza cuando no caben todos?
3. Matriz de trazabilidad
La tabla que conecta cada requerimiento con su origen, con el entregable que lo satisface y con la prueba que lo verifica. Es el documento más subestimado del proceso y el más útil cuando hay que recortar alcance: te dice exactamente qué se cae si eliminas algo, y a quién hay que avisarle.
De requerimiento malo a requerimiento útil
La teoría se entiende rápido; el músculo se hace transformando ejemplos reales. Mira la misma necesidad escrita de tres formas:
| Versión | Problema |
|---|---|
| "El sistema debe ser intuitivo" | No es verificable. ¿Quién decide si lo es? |
| "El sistema debe tener una interfaz sencilla con pocos clics" | Mejor, pero sigue sin umbral. ¿Pocos son tres o siete? |
| "Un usuario sin capacitación previa completa el registro de una solicitud en menos de 3 minutos y con un máximo de 5 clics, en 8 de cada 10 intentos" | Verificable: se puede probar con diez personas y contar |
Fíjate en lo que aporta la tercera versión: define el sujeto (usuario sin capacitación), la tarea, el umbral y la tasa de éxito aceptable. Ese último elemento es el que más se olvida, y es el que evita la discusión de "a mí me funcionó".
Cuidado con los requerimientos que esconden una solución
Cuando un interesado pide "un botón de exportar a Excel", te está dando una solución, no un requerimiento. El requerimiento detrás puede ser "necesito enviar los datos del mes a mi jefe", y quizá se resuelve mejor con un reporte automático por correo.
La técnica para destaparlo es preguntar "¿para qué?" hasta llegar al resultado de negocio. No más de tres veces, o se vuelve un interrogatorio. Pero esas tres preguntas suelen revelar que la solución pedida no era la mejor disponible.
Priorizar cuando no cabe todo
Nunca caben todos los requerimientos. Priorizar por "urgente / importante" no funciona porque todos los interesados marcan lo suyo como ambas cosas. El método MoSCoW obliga a una conversación más honesta:
- Must have. Sin esto, el entregable no sirve. Si falla, el proyecto fracasa.
- Should have. Importante, pero existe una alternativa manual o temporal.
- Could have. Mejora real, prescindible si aprieta el tiempo.
- Won't have (this time). Queda explícitamente fuera de esta entrega. No es un "no", es un "ahora no".
El truco está en la última categoría. Escribir lo que no se va a hacer, y que el interesado lo firme, evita el 80% de las discusiones posteriores. Y hay una regla práctica que impone disciplina: los "Must" no deben superar el 60% del esfuerzo estimado. Si todo es imprescindible, nadie priorizó.
La matriz de trazabilidad en la práctica
Así se ve una fila real, y por qué cada columna gana su lugar:
| ID | Requerimiento | Origen | Prioridad | Entregable | Prueba |
|---|---|---|---|---|---|
| REQ-014 | Registro de solicitud en menos de 3 min | Taller 12/03, área de Atención | Must | Módulo de captura | PRU-07 usabilidad |
| REQ-015 | Exportar histórico mensual | Entrevista, Dirección | Should | Módulo de reportes | PRU-11 funcional |
Cuando llegue el recorte —y siempre llega— esta tabla te dice en treinta segundos qué se cae, qué prueba deja de tener sentido y a quién hay que avisarle. Sin ella, esa misma conversación son dos días de reuniones y alguien que se entera tarde.
Cuándo dejar de recolectar
La recolección no termina porque se acabó el tiempo asignado, sino cuando aparecen tres señales:
- Saturación. Las últimas dos entrevistas no aportaron nada nuevo. Si el requerimiento 40 y el 41 son variantes del 12, ya llegaste.
- Cobertura de interesados. Hablaste con quien paga, quien usa y quien opera. Los tres, no dos. El área de operación es la que más se olvida y la que más problemas reporta después.
- Trazabilidad completa. Cada objetivo del proyecto tiene al menos un requerimiento que lo sostiene, y cada requerimiento remite a un objetivo. Si un requerimiento no se conecta con ningún objetivo, sobra o falta un objetivo.
Esa tercera señal es la más útil y la que casi nadie revisa. Hazla al revés también: recorre los objetivos y pregunta cuál requerimiento los cumple. Los huecos saltan solos.
Caso práctico: el requisito que nadie había pedido
Escenario construido con patrones habituales; las cifras son ilustrativas.
Un proyecto de portal interno cierra su recolección con 87 requisitos. Todos redactados con criterio de aceptación, todos con identificador. Un trabajo aparentemente impecable.
Al construir la matriz de trazabilidad apareció una anomalía: catorce requisitos no se podían enlazar hacia atrás con ninguna necesidad del acta ni con ningún interesado identificado. Estaban escritos, numerados y estimados, y no se sabía de dónde habían salido.
Doce venían de una reunión donde el equipo técnico había ido apuntando «esto también estaría bien». El resto, de un documento de otro proyecto usado como plantilla.
Sumaban alrededor del 20 % del esfuerzo estimado.
Once se eliminaron sin que nadie los echara de menos. Tres resultaron importantes, y el área usuaria los priorizó por encima de otros que sí tenían origen.
La matriz de trazabilidad no sirvió para demostrar que todo estaba cubierto, que es para lo que suele presentarse. Sirvió para encontrar lo que sobraba.
Es su uso más rentable y el que menos se le da: recorrerla hacia atrás, del requisito a la necesidad, y mirar lo que no enlaza con nada.
Checklist antes de cerrar la recolección
- ¿Cada requerimiento tiene un criterio de aceptación medible?
- ¿Identificaste requerimientos de operación, no solo funcionales?
- ¿Usaste al menos dos técnicas distintas de recolección?
- ¿Hay un dueño nombrado por cada requerimiento, no un área?
- ¿La matriz de trazabilidad conecta requerimiento, entregable y prueba?
- ¿Los interesados firmaron sabiendo qué no se va a hacer?
Para cerrar
La recolección de requerimientos es la etapa donde más barato sale corregir y donde menos tiempo se invierte. Es una inversión con retorno asimétrico: cada hora que le dedicas al inicio te ahorra varias cuando el producto ya está construido.
¿Cuál es la técnica que mejor te ha funcionado? Yo tengo debilidad por la observación directa, porque es la única que descubre lo que nadie pensó en contarte.
Referencias
- Project Management Institute, Guía del PMBOK, 7.ª edición, sobre el dominio de desempeño de planificación.
- International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK Guide).
- Standish Group, informes CHAOS, sobre las causas recurrentes de fracaso en proyectos.
- ISO 21502:2020, apartado sobre gestión del alcance.
Siguiente en la serie: Alcance y tiempo: por qué no se pueden gestionar por separado →
Este artículo forma parte de Gestión de Alcance y Tiempo, una serie de 52 artículos. Ver todos los de esta serie · Índice completo por materia.