En este post, voy a tratar sobre un paso crítico en la planificación de un proyecto, la recopilación de los requisitos. Y es que, en cualquier proyecto, los requisitos son un factor clave para determinar su éxito o fracaso, y en mi opinión, es uno de los aspectos más infravalorados en la mayoría de los proyectos.

Comenzar un proyecto con unos requisitos adecuados ​​puede eliminar, o al menos, reducir significativamente los problemas en forma de retrasos y sobrecostes, que se presentan en muchos proyectos. Vamos a empezar viendo qué es un requisito.

Qué es un Requisito

Un requisito es una condición o capacidad que debe tener un producto, servicio o resultado, para satisfacer una necesidad de negocio. Simplificando un poco, un requisito no es más que un resultado esperado del proyecto. 

Tipos de Requisitos

  • Requisitos de Negocio. Los requisitos de negocio son una declaración de alto nivel que describe lo que se requiere desde la perspectiva del negocio, tales como los problemas u oportunidades y las razones por las que se ha emprendido un proyecto.
  • Requisitos de los Interesados. Describen las necesidades de un interesado o grupo de interesados.
  • Requisitos del producto y de la solución. Describen las prestaciones, funciones y características del producto o servicio que cumplirán los requisitos del negocio y de los interesados. Suelen ser de dos tipos:
    • Funcionales: describen en detalle las características del producto.
    • No funcionales: complementan a los funcionales Describen las condiciones ambientales necesarias para poder cumplir con los requisitos funcionales.
  • Requisitos del proyecto. Describen las acciones, los procesos y las condiciones que el proyecto debe cumplir.
  • Requisitos de transición. Describen capacidades temporales necesarias para pasar del estado actual al estado futuro.

La recopilación de Requisitos

Consiste básicamente en:

  1. Determinar las expectativas y necesidades para satisfacer a los Interesados (Stakeholders).
  2. Formalizarlas a través de un documento que refleje esta comprensión.
  3. Y finalmente, administrarlas a lo largo del proyecto para cumplir los objetivos. 

Este proceso constituye la base para la definición del Alcance del proyecto.

El primer paso para la recopilación de los requisitos de un proyecto, debe ser determinar cuáles deben ser los roles y responsabilidades durante esta fase:

  • Normalmente, recae en el director del proyecto, la responsabilidad de garantizar la captura de todos los requisitos. Debe ser muy ágil, y utilizar las herramientas más adecuadas para recopilar los requisitos durante la vida del proyecto.
  • Por su parte, el cliente, o un analista, deberían ser los responsables de establecer los requisitos del producto.

Dificultades habituales para la obtención de requisitos

El principal problema que hay con los requisitos es que siempre están cambiando, lo que hace casi imposible definirlos de manera precisa antes de comenzar un proyecto. Son muy pocos los proyectos se pueden permitir tener unos requisitos precisos antes de su inicio.

Tratar de evitar que un cliente cambie sus requisitos, es como tratar de evitar que un adolescente utilice su smartphone.

Veamos cuáles son algunas de las principales dificultades que se presentan a la hora de captar los requisitos de los interesados:

  • Incorrecta descripción del problema a resolver: «No puedo describirlo, pero lo reconoceré cuando lo vea«. Esta es una situación bastante habitual. En ocasiones, el cliente no tiene claro lo que necesita, y el resultado es una especificación ambigua de requisitos.
  • Los requisitos se deben recopilar de todos los interesados. Esta situación provoca que, en aquellos proyectos en los que hay muchos interesados, la recopilación de requisitos resulte muy larga y costosa.
  • Los requisitos se redactan en una fase demasiado temprana del proyecto, con lo que se obtienen requerimientos incompletos de lo que realmente se necesita.
  • Otro error habitual, que se produce durante las etapas iniciales del proyecto, es NO identificar adecuadamente a los Interesados que se verán afectados por los resultados del proyecto.

En este vídeo, podemos ver un ejemplo de lo complicado que puede resultar la recopilación de los requisitos de un proyecto.



Seguramente, esta situación te resulte familiar y puede que te hayas visto reflejado en alguno de los roles que se muestran en esta simpática reunión. Por razones como las que se describen en el vídeo, la recopilación de los requisitos de un proyecto, es probablemente una de las partes más complejas en la planificación de un proyecto.

Métodos de recopilación de requisitos del proyecto

Juicio de Expertos

Es un conjunto de opiniones que pueden brindar profesionales expertos en una industria o disciplina, relacionadas al proyecto que se está ejecutando. Cuando estamos a cargo de un proyecto, muchas veces no somos expertos en el tema, y es por eso que necesitamos acudir a ellos para determinar los requisitos especializados.

Entrevistas

Entrevistar a los interesados es una técnica muy adecuada para la recopilación de requisitos. Al comprender lo que esperan los interesados, siempre estaremos en mejor disposición para conocer qué requisitos cumplirán el proyecto.

Las entrevistas se pueden hacer de forma individual, o en grupo. Por lo general, las entrevistas individuales, te ayudarán a comprender información más detallada sobre cómo cada parte interesada quiere utilizar cada producto o servicio.

Siempre es conveniente preparar las entrevistas y decidir qué preguntas deben hacerse, y lo
que es más importante, cómo se va a utilizar esa información. La preparación ayudará a que la entrevista se desarrolle de una manera más organizada.

Análisis de datos

También se conoce como análisis de documentos. Como su nombre indica, esta técnica se utiliza para analizar los documentos existentes para obtener los requisitos del proyecto. Consiste en la revisión y evaluación de cualquier información que esté documentada y sea pertinente.

Toma de decisiones

  • Técnicas de Votación:
    • Unanimidad: Todos los miembros del grupo acuerdan una decisión final.
    • Mayoría: aquí, más del 50% de los miembros del grupo acuerdan la decisión final.
    • Pluralidad: el grupo más numeroso de personas toma la decisión, aun cuando no se alcance la mayoría.
  • Autocrática o dictatorial: Solo una persona toma la decisión sobre la definición de los requisitos del proyecto.
  • Toma de decisiones multi-criterio: Se utiliza una matriz que incorpore varios factores de análisis para cada requisito como por ejemplo: riesgos, beneficios de negocio, disponibilidad de recursos, etc.

Talleres facilitados

Son sesiones que reúnen a los interesados clave para definir los requisitos del producto. Estos talleres se consideran como una de las técnicas principales para definir rápidamente los requisitos multidisciplinares y conciliar las diferencias entre los interesados. Ejemplos:

  • Sesiones conjuntas de desarrollo (J.A.D. – Joint Application Design): Técnica introducida por IBM a finales de la década de 1970. En la industria de desarrollo de software se suelen realizar estos talleres, en los que los desarrolladores de producto trabajan en conjunto con el cliente (o usuario) para establecer los requisitos finales
  • Despliegue de funciones de calidad (Q.F.D. – Quality Function Deployment): propia de la industria manufacturera. El Q.F.D. ayuda a establecer las características críticas para el desarrollo de nuevos productos. Se realizan talleres con el cliente para transformar sus requisitos cualitativos, en planes específicos cuantitativos y poder desarrollar un producto que satisfaga esas necesidades.

Prototipos

Consiste en elaborar una versión preliminar tangible del producto final para obtener una retroalimentación temprana sobre los requisitos del proyecto. El proceso a seguir sería el siguiente:

  1. Se desarrolla un modelo preliminar y tangible del producto final basado en la necesidad de los interesados.
  2. Se solicita a las partes interesadas que den su opinión sobre este modelo.
  3. Los comentarios negativos se capturan para identificar otros requisitos. Las retroalimentaciones positivas se conservan tal como son.
  4. Una vez obtenidos los requisitos completos a partir del prototipo, podemos pasar a la fase de diseño o construcción.

Los Requisitos en los proyectos ágiles. Las Historias de usuario

Las metodologías ágiles  están especialmente indicadas para proyectos en entornos complejos, y trabajos de alta incertidumbre donde se necesita tener capacidad de reacción ante el mercado e impulsar la innovación y creatividad de sus equipos.

Se caracterizan porque permiten adaptar la forma de trabajo a las condiciones del proyecto, con equipos que trabajan de manera altamente colaborativa y autoorganizados.

Respecto a los requisitos, en las metodologías ágiles, en lugar de escribir requisitos funcionales con un lenguaje técnico, la descripción de las necesidades se realiza a partir de las historias de usuario (user story) que describen lo que el cliente o el usuario quiere que se implemente.

Las historias de usuario siguen un patrón definido:

  • Yo como un [Rol de usuario]
  • Necesito [Descripción de la funcionalidad]
  • Con la finalidad de [Descripción de la consecuencia]

Para concluir, la recopilación de requisitos de un proyecto es un proceso crítico. La guía PMBOK describe distintas técnicas y herramientas, todas tienen su momento y lugar, y es bueno que el equipo del proyecto dedique un tiempo, a determinar cuál es la más adecuada para cada proyecto y para cada organización.

Deja un comentario