Requerimientos de un proyecto

Ya sea cuando estaba trabajando para clientes pequeños, a nivel interno de una empresa, o para grandes clientes externos dentro de una consultora, me ha tocado en muchas ocasiones estar con los stakeholders (interesados)de un proyecto, definiendo sus requerimientos. Es decir, la lista de funciones, capacidades o características necesarias que debe tener y los planes para crearlos.

Según la definición del PMBOK® (Project Management Body of Knoledgement), un requerimiento es la condición o capacidad que debe tener un sistema, producto, servicio o componente para satisfacer un contrato, estándar, especificación, u otros documentos formalmente establecido.

Se deben definir en la fase inicial junto con los stakeholders  implicados para obtener una visión completa y compartida de todas las piezas y poder priorizar en base a los objetivos del proyecto.

Los requerimientos no te indican que diseño debe tener tu producto o como desarrollarlo. Te indican que features, funciones y contenidos se espera que tenga, y como deben los usuarios interactuar con él.

Los requerimientos pueden incluso variar con el tiempo, ya que si el proyecto se desarrolla correctamente, en cuanto el MVP se haya desarrollado y se realicen pruebas con usuarios, los resultados pueden cambiar los requisito iniciales.

Tipos de requerimientos

Existen diferentes tipos de requisitos, casi tantos como implicados haya en un proyecto 😉 En un macronivel obtenemos los siguientes:

Requerimientos de negocio

Definen los objetivos y problemas que la empresa quiere resolver con el producto. Deben estar basados en una necesidad real del usuario, sea esta conocida o no por él.

Requerimientos de los usuarios

Describen las expectaciones de los usuarios y como éste interactuará con el producto. Sino son similares a los requerimientos de negocio, el proyecto irá mal encaminado.

Las técnicas de personas, escenarios y customer journeys sirven de ayuda para definir las funciones, tareas y características que definen los requisitos de usuario.

Requerimientos funcionales

Proporcionan detalle de como debe comportarse un producto y especifican lo que se necesita para su desarrollo.

Requerimientos de calidad

Detallan las características que un producto debe poseer para mantener su efectividad y prever posibles problemas y limitaciones.

En términos de experiencia de usuario, si la calidad del producto no concuerda con las expectativas que el usuario posee sobre él, no funcionará.

Requerimientos de implementación

Se usan para detallar cambios en los procesos, roles en el equipo, migraciones de un sistema a otro…

Escribiendo requerimientos

Para definirlos se recomienda usar una sentencia descriptiva que indique qué debe hacer el sitio o producto o debe permitir hacer a los usuarios, detallándola más adelante al ir avanzando en el proceso e ir obteniendo feedback de los test iniciales.

Su definición puede ser muy compleja pero ayuda a conseguir que el proyecto sea un éxito o no se desperdicien recursos.

• Único. El requerimiento sólo puede interpretarse de una manera.
• Específicos. No se deben mezclar 2 requisitos diferentes.
• Claros, completos y bien definidos.
• Viables (realístico y posible). Debe ser factible según las restricciones actuales de tiempo, dinero y recursos disponibles.
• Consistentes y priorizados en base a los objetivos de negocio
• Capaces de verificar durante pruebas y tests
• Necesario: Un requerimiento no es necesario si ninguno de los interesados lo necesita o bien si su retirada no tiene ningún efecto.

Trazabilidad

Es muy importante que se mantenga la trazabilidad de un requerimiento en el tiempo, siguiendo su historia desde su formulación original hasta el momento actual. Cada cambio realizado debe por tanto ser reportado.

Esto no quiere decir que haya que generar una documentación extensa. Hoy en día herramientas como JIRA permiten mantener una trazabilidad de manera fluida y organizada, y con conocimiento de los implicados, sin generar una documentación que nadie se lee.

Así en el caso de que los integrantes del equipo cambien, o se quiera ver de dónde viene esa propuesta, se deja de una manera sencilla y clara toda la información, permitiendo que se genere una conversación controlada, aparte de controlar que otros requerimientos y funciones puede impactar al hacerse ese cambio.

¿Quieres saber más?

• • Conceptualización de un proyecto en experiencia de usuario
  • Checklist de arranque de un proyecto UX
  • Entrevistas con los diferentes usuarios y stakeholders que participan
  • Consultoría  UX para simplificar un proceso complejo para el usuario
  • Consultoría UX para empresas
  • Design Thinking
  • Workshop de Design Thinking