Respuesta

Historia del asunto:
A menudo, al inicio de un proyecto, el cliente formula la tarea de manera poco clara: los objetivos pueden ser generales y los detalles, no descritos. Esto es típico al iniciar nuevas direcciones o digitalizar procesos tradicionales. El analista se enfrenta a deseos contradictorios y conceptos dispares sobre el producto futuro.

Problema:
La incertidumbre en los requisitos conduce a riesgos de errores en el diseño, conflictos, retrasos y aumento de presupuesto. Los cuellos de botella son las contradicciones entre las partes interesadas y la imposibilidad de evaluar la carga de trabajo.

Solución:
El analista debe organizar una identificación de requisitos por etapas:

1. Realizar entrevistas y sesiones de facilitación con los principales interesados, identificando no solo expectativas explícitas, sino también ocultas.
2. Utilizar técnicas de prototipado y creación de MVP para obtener retroalimentación rápida.
3. Aplicar herramientas analíticas: historias de usuario, diagramas de procesos de negocio, así como métodos de preguntas aclaratorias (5 Porqués, aclarar "¿qué significa el éxito?", etc.).
4. Documentar todas las suposiciones y acordarlas con el negocio — esto permite reducir el nivel de incertidumbre.

Características clave:

• Enfoque estructural para aclarar requisitos incompletos
• Uso de diversas técnicas para recopilar información oculta
• Documentación obligatoria y formalización de suposiciones para acordar

Preguntas capciosas.

¿Qué documentación se requiere con requisitos implícitos: es suficiente con solo anotar la historia de usuario?

La historia de usuario es una herramienta útil, pero no revela todas las sutilezas si los requisitos son difusos. Es necesario desarrollar artefactos adicionales: prototipos de pantallas, ejemplos de escenarios de uso y tablas de reglas de negocio.

¿Qué es más importante al inicio: obtener resultados rápidamente (MVP) o recopilar requisitos de manera completa?

El equilibrio entre velocidad y completitud depende de la situación. Al inicio, es más valioso un producto mínimo viable (MVP) que proporciona retroalimentación y ayuda a corregir la visión rápidamente, que un largo proceso de aprobación de todo el conjunto de requisitos.

¿Se pueden tomar decisiones basándose solo en las palabras del cliente?

No. El cliente expresa deseos, posiblemente sin tener en cuenta detalles técnicos y limitaciones. El analista debe validar los deseos comprendiendo los procesos, solicitando opiniones alternativas y analizando las consecuencias.

Errores comunes y anti-patrones

• Confianza ciega en las palabras del cliente sin un análisis detallado de los procesos
• Transmitir requisitos difusos directamente a tareas para desarrollo
• Desestimar la retroalimentación sobre resultados intermedios

Ejemplo de la vida real

Caso negativo: El analista solo anotó los deseos del cliente y los transmitió a los desarrolladores. Resultado: se implementó una funcionalidad que no resolvía las verdaderas necesidades del negocio. Ventajas: El desarrollo comenzó rápidamente. Desventajas: El producto no fue utilizado, se requirió mucho trabajo adicional.

Caso positivo: El analista llevó a cabo una serie de reuniones con los usuarios, construyó un prototipo, acordó los escenarios. Los requisitos se aclararon — el MVP rápidamente trajo valor al negocio. Ventajas: Valor rápido, retroalimentación positiva, mínimas modificaciones. Desventajas: Se gastó un poco más de tiempo en la etapa de recopilación de requisitos.