Los requisitos son descritos como una condicion o capacidad que un cliente necesita para solucionar un problema o alcanzar un objetivo. Si no tienes esto claro, ¿como puedes cumplir con esos requisitos y hacer un proyecto exisoso? No es extraño las asombrantes cifras que se alegan en un rango del 60% al 80% sobre proyectos fallidos solamente en la industria de la tecnologia (IT). Aunque que es un “proyecto fallido” tiene que ser mejor definido, y este es un topico para otro articulo, y hay muchas causas para proyectos fallidos (aun subjetivas), la falta de acopio de requisitos y su documentacion es ciertamente una de ellas.

El proceso de acopio de requisitos y su documentacion puede tomar muchas formas pero todas tienen que incluir a todos los stakeholders del proyecto, sin excepciones. Puedes optener y documentar los requisitos de una sola vez para proyectos pequeños o muchas veces para proyectos grandes. Puedes tener a todo el mundo presente en una oficina para proyectos complejos o remotamente para proyectos menos complejos. Puedes entrevistar a cada uno de los stakeholders por separados. Todas estas formas tienen ventajas y desventajas dependiendo de la naturaleza del proyecto y es la responsabilidad del gerente del proyecto de guiar al analista de negocios y a los stakeholders a llegar a un concenso sobre el metodo apropiado.

Ahora, todo los participantes tienen su propia agenda. Este es un reto que debe se roto desde el principio! ¿Cuáles son los retos de acopiar requisitos?

• Stakeholders
Tener una idea pre-concevida de la solucion
No saber que realmente quieren
Ser incapaz de articular lo que quieren
Creer que saben lo que quieren pero no reconocerlo cuando es entregado
Querer decir otra cosa
• PMs / analistas de negocio
Creer que entienden los problemas mejor que los usuarios
Haberlo hecho antes
• Todo el mundo
Ver las cosas desde su propio punto de vista
Creer que todos estan politicamente motivados

Es indispensable, y terriblemente importante, tener los mejores requisitos que se pueda. Durante el acopio y la documentacion de requisitos asegurate de que como minimo esto sea capturado:

• Funciones – Ejemplo: la casa tiene que tener 4 cuartos y 2 baños
• Restricciones – Ejemplo: la pintura exterior no puede ser basada en agua y tiene que tener un brillo ligero
• Otros elementos que deben estar presente para cumplir las necesidades de cada stakeholder – Ejemplo: un cuarto tiene que tener un baño adentro

Que haces con un requisito:

• Se obtiene
• Se anticipa
• Se documenta
• Se aclara
• Se cuantifica
• Se cualifica
• Se administra
• Se satisface
• Se cumple

Documenta los requisitos de una manera legible y amigable para el usuario sin asumir nada. Lanza la documentacion, repasala, obten sugerencias de todos los stakeholders y ponla al dia si es necesario.

Es sabido que el uso efectivo de la practica de acopio de requisitos y su documentacion conduce a proyectos exitosos, clientes satisfechos y aumento de profesionalismo. Hay beneficios de un buen proceso de acopio y documentacion de requisitos:

• Un claro entendimiento de las necesidades de los usuarios, clientes y stakeholders
• Una relacion colaborativa entre usuarios, clientes y stakeholders y el equipo tecnico
• Un fuerte compromiso de los requisitos por parte de los miembros del equipo de desarrollo a los objetivos del proyecto
• Uso de un proceso repetido de requisitos que es continuamente mejorado
• Un sistema de arquitectura que apoya las necesidades actuales y futuras de los usuarios, clientes y stakeholders
• La abilidad de acomodar cambios a los requisitos a medida que estos son progresivamente elaborados
• Alta calidad de entregables
• Ahorro en los costos de desarrollo, cronogramas exactos, satisfaccion del cliente

Establece un buen plan de gerencia de cambios porque los requisitos pueden cambiar. Ahora, la gran pregunta: ¿por que los requisitos cambian?

• Nuestro entendimiento del problema o objetivo mejoro
• El problema siendo resuelto o el objetivo cambio
• Fallamos en preguntar a las personas correctas las preguntas correctas en el momento correcto
• Fallamos en crear o seguir un proceso para asistir en administrar cambios
• Los usuarios cambiaron sus mentes o sus percepciones
• El ambiente exterior cambio

Evita los cambios y sigue todos los pasos desde el principio o alguien va a perder algo. ¿A ti no te parece…? Pues, a mi si.