Documento de requisitos del producto

Un documento de requisitos de producto establece qué debe hacer un producto o funcionalidad, para quién y por qué, junto con las restricciones que debe respetar y los criterios para evaluar su éxito. Si bien es anterior al desarrollo iterativo y a menudo se descarta como un vestigio de la entrega secuencial, la necesidad fundamental que satisface no ha desaparecido: un trabajo sustancial aún requiere una descripción escrita y compartida de las intenciones.

La objeción al formato radica, en realidad, en su uso. Un documento que especifica cada detalle por adelantado, se aprueba y se considera definitivo durante un año es incompatible con el aprendizaje, y su fracaso está más que demostrado. Un documento que describe el problema, los usuarios, los resultados previstos y las limitaciones, dejando que los detalles de la solución se desarrollen a medida que se profundiza en la comprensión, cumple una función diferente y sigue siendo valioso.

Las secciones más útiles son las que describen el problema, no la solución. ¿Quién tiene este problema?, ¿qué evidencia lo demuestra?, ¿qué alternativas existen actualmente?, ¿qué resultado constituiría un éxito?, y ¿qué se excluye deliberadamente del alcance del documento? Un documento que comienza con una lista de características omite el razonamiento que permitiría evaluar si dichas características son las adecuadas.

Es importante mencionar explícitamente las limitaciones, ya que suelen ser el origen de la mayoría de las sorpresas de última hora. Las obligaciones normativas, los requisitos de seguridad, los estándares de accesibilidad, las expectativas de rendimiento, las plataformas compatibles, las dependencias de integración y los límites operativos determinan lo que se puede construir, y descubrirlos durante la implementación resulta costoso. Registrarlos desde el principio es económico y evita una serie de retrabajos totalmente prevenibles.

Los criterios de éxito son la sección que con mayor frecuencia se omite y la que determina si la inversión puede evaluarse. Definir de antemano qué cambios medibles se esperan del trabajo y en qué plazo convierte una funcionalidad en una propuesta comprobable y permite a la organización aprender de los resultados. Los documentos que describen lo que se construirá sin especificar qué se espera lograr imposibilitan la evaluación posterior a la implementación.

El documento debe considerarse como un documento vivo, no como un acuerdo firmado. La comprensión mejora durante el desarrollo, se obtienen nuevas pruebas y las limitaciones cambian; un documento que no se actualiza se convierte en un registro histórico que queda obsoleto con el resultado final. Mantenerlo como la declaración de intenciones actual, con los cambios sustanciales visibles, lo hace útil para quienes se incorporan al proyecto posteriormente y necesitan comprender el porqué de las decisiones.

Las cuestiones pendientes merecen su propia sección, en lugar de omitirse para dar una imagen de decisión. Registrar lo que aún se desconoce, quién lo resolverá y cuándo, transforma la incertidumbre de un riesgo oculto en un trabajo supervisado, y evita la situación común en la que una cuestión sin resolver se descubre durante la implementación por alguien que la daba por resuelta.

A partir de cierto punto, la extensión es inversamente proporcional a la utilidad. Un documento que nadie lee por tener cuarenta páginas ha fracasado independientemente de su exhaustividad. La disciplina de exponer de forma concisa el problema, los usuarios, los resultados, las limitaciones y las preguntas abiertas da como resultado un documento que sí se consulta. El detalle debe incluirse en los documentos que lo requieren, como diseños, criterios de aceptación y especificaciones técnicas, en lugar de concentrarse en un único documento que nadie lee.

Debido a que el valor del documento radica en establecer un entendimiento común entre funciones que de otro modo procederían bajo supuestos diferentes, necesita contribuciones más allá de la gestión de productos. En la práctica, se produce dentro de un estudio de productos compromiso con el problema evidencia proporcionada por investigación de producto, las restricciones confirmadas por desarrollo de productosy los criterios de éxito acordados con análisis de datos para que puedan medirse después del lanzamiento.