2 publicaciones etiquetados con "Recopilación de Requisitos"

¿Alguna vez has estado en una reunión de requisitos donde todos asienten, pero en el fondo sabes que cuando empiece el desarrollo, la mitad de esos "requisitos" se habrán olvidado, malinterpretado o simplemente ignorado? ¿Y cuando el software finalmente sale, no es del todo lo que nadie quería?

Bienvenido al mundo de la documentación de requisitos de negocio. Se supone que debe ser el puente entre las necesidades del negocio y las soluciones técnicas, pero con demasiada frecuencia se convierte en un juego del teléfono roto, donde el mensaje final tiene poco que ver con la intención original.

¿El problema real? La mayoría de los documentos de requisitos se redactan como contratos legales: llenos de jerga, voz pasiva y suposiciones que parecen obvias para quien escribe, pero que dejan a todos los demás confundidos.

El mes pasado hablé con un equipo de desarrollo sobre sus mayores arrepentimientos. El tema recurrente fue este: construyeron funcionalidades basadas en requisitos vagos y luego tuvieron que reconstruirlas dos veces cuando las necesidades reales quedaron claras. Cada reconstrucción costó tiempo y dinero.

Algo que compartió un product manager me quedó grabado: "Nuestros desarrolladores preguntaron qué debía hacer una funcionalidad, y nosotros dijimos 'que sea flexible.' Seis meses después, la funcionalidad estaba sobrediseñada, era confusa y nadie la usaba. Tendríamos que haber sido específicos sobre lo que necesitaba hacer."

Ese es el costo de los requisitos poco claros.