Todo lo que necesitas saber sobre la gestión de requisitos

Es viernes por la noche y estás por pedir pizza. Tienes el teléfono en una mano y una lista de pedidos de tus amigos en la otra. Pero primero, debes ordenar las preferencias de cada uno y decidir qué tipo de pizza pedirás. ¿De pepperoni? ¿Mozzarella? ¿Vegetariana?

Pedir una pizza empieza a parecerse inquietantemente a la gestión de requisitos para el lanzamiento de tu último producto. Tal como en la situación anterior, la gestión de requisitos consiste en escuchar a las partes interesadas y entender de qué manera puedes satisfacer las necesidades de todos lo mejor posible.

¿Qué es la gestión de requisitos?

La gestión de requisitos es una opción para garantizar que los entregables finales del proyecto cumplan tanto con las necesidades de los clientes como con las de los participantes internos. En este caso, un requisito es algo que las partes interesadas necesitan o desean de tu producto. Esas partes interesadas pueden ser colaboradores internos (como personas que trabajan en otros departamentos) o participantes externos (como los clientes).

Por lo general, quienes aplican la gestión de requisitos son los equipos de desarrollo que trabajan con productos y funciones de software, pero también se usa en general para la gestión de proyectos. Por ejemplo, un requisito podría ser una función que permitiera que los clientes usaran con éxito el producto o algún aspecto de tu producto que ayudara a que los colaboradores de otros departamentos cumplieran sus objetivos de negocios.

Antes de empezar a trabajar en un producto, deberás acordar los requisitos exactos para brindarles a las partes interesadas lo que realmente necesitan. La gestión de requisitos te permite documentar y establecer las prioridades entre los requisitos, dar seguimiento a los cambios y mantenerte alineado con los demás participantes a lo largo del ciclo de vida del proyecto. Además, te servirá para gestionar los cambios de requisitos y para mantener al proyecto dentro del alcance propuesto.

¿Qué es un requisito?

Un requisito es un componente que necesitas implementar para finalizar una función o producto. En otras palabras, es algo que tu producto debe tener o hacer para cumplir con las expectativas de las partes interesadas. Los productos de software pueden tener cientos de requisitos. Pero, independientemente de cuántos requisitos tenga un producto, todos deben ser:

• Necesarios: necesitas cumplir con este requisito para alcanzar los objetivos del producto o de negocios. 

• Específicos: el requisito debe estar bien detallado y tener un propósito claro.

• Fáciles de entender: el requisito debe estar redactado con claridad y ser fácil de entender. 

• Precisos: el requisito debe contener información precisa suficiente sobre el inconveniente que resuelve o la necesidad que cubre. Es decir, en vez de solamente describir lo que hace falta hacer; además, deberías aclarar por qué es importante satisfacer ese requisito.

• Viables: deberías averiguar si el requisito se puede implementar con la infraestructura de código y tecnología que tienes actualmente.

• Comprobables: deberías poder probar el requisito mediante pruebas de usuarios, pruebas A/B u otro método.

Veamos un ejemplo. Imagina que estás creando una aplicación y que uno de los requisitos es que toda la aplicación debe traducirse al inglés, chino, japonés y francés porque esos idiomas se corresponden con tus principales mercados de comercialización.

• El requisito es necesario para lanzar la aplicación en los principales mercados de la empresa y para cumplir con los objetivos de negocios.

• Es específico porque indicas cuáles son los idiomas que necesitas y que debe traducirse toda la aplicación.

• Es fácil de entender porque no se utiliza terminología técnica; más bien, está redactado de un modo que cualquiera de los miembros del equipo y colaboradores de distintos departamentos puede entender.

• Es preciso porque has especificado claramente por qué es importante este requisito: porque los idiomas inglés, chino, japonés y francés se corresponden con tus principales mercados de comercialización.

• Es viable porque ya has desarrollado prototipos y casos de prueba en otros idiomas. Por lo tanto, sabes que es posible llevar a cabo la localización y que tendrá los resultados esperados.

• Es comprobable porque tienes un sistema organizado para probar y confirmar la precisión de cada una de las versiones traducidas.

¿Por qué es importante la gestión de requisitos?

La gestión de requisitos es indispensable para crear un producto de primer nivel. A continuación, te contamos los motivos:

• Entrega las funciones correctas. El proceso de gestión de requisitos es útil para definir lo que el usuario necesita mediante la interpretación de su interacción con el producto. Resulta muy útil para, primero y ante todo, alinear los entregables con las necesidades esenciales de tus clientes. 

• Se alinea con los objetivos de negocios. Cuando documentes y establezcas las prioridades de los requisitos, asegúrate de que queden alineados con los objetivos generales. Por ejemplo, un requisito de traducir la aplicación a 12 idiomas serviría para respaldar el objetivo de negocios de expandirse a mercados internacionales. Si algún requisito no concuerda con los objetivos de negocios, probablemente signifique que debas invertir los recursos en alguna otra parte o tener una muy buena razón que justifique por qué el requisito es realmente importante.

• Evita la corrupción del alcance. Los requisitos funcionan como el alcance de un proyecto, con ellos se definen los límites y se determina exactamente con qué objetivos y entregables se trabajará. La definición anticipada de los requisitos te ayuda a identificar potenciales obstáculos y a poner un límite cuando alguien intenta agregar requisitos extra.

• Sortea los obstáculos. Crear un producto no es nada fácil; por lo menos, hay una etapa de desarrollo del software, otra de diseño y otra de pruebas; sin mencionar las secuencias de código complejo y sistemas de ingeniería con los que hay que trabajar. La gestión de requisitos te ayuda a planificar el desarrollo de un producto dentro de las limitaciones de ese código y a dar seguimiento a lo que debes lograr a cada paso del proceso de desarrollo del producto.

¿Quién es responsable de la gestión de requisitos?

La persona responsable de la gestión de requisitos dependerá de tu proyecto o equipo en particular. Pero, en general, los encargados o gerentes de producto son quienes gestionan los requisitos de los equipos de desarrollo. Estos dos roles son muy similares, excepto que los encargados de producto son un rol estándar en los equipos Scrum mientras que el rol de los gerentes de producto es más universal, independientemente de si el equipo aplica una metodología ágil o no. Si, en cambio, trabajas con un proyecto más general, el gerente de proyecto será el responsable de la gestión de los requisitos.

En la gestión de requisitos, se requiere una colaboración interdisciplinaria entre tu equipo y los demás participantes del proyecto. Debes reunir los comentarios de todas las partes interesadas, trabajar juntos para entender cada requisito y ayudar al equipo a planificar cómo se ocuparán de cada necesidad planteada. Esto significa que la persona que gestiona los requisitos de tu proyecto debe tener habilidades sólidas para la colaboración y sobresalir en la comunicación interdisciplinaria porque será el centro de todo.

¿Cuáles son los diferentes tipos de requisitos?

Existen tres tipos principales de requisitos: los requisitos comerciales, los del usuario y los del sistema. Resulta muy importante definir los diferentes tipos de requisitos antes de empezar a trabajar, porque esto suele determinar quiénes serán las partes interesadas con las que colaborarás.

A continuación, compartimos un panorama general de los diferentes tipos de requisitos:

Requisitos comerciales

Los requisitos comerciales son los objetivos generales de negocios o métricas a las que contribuye tu producto. No son necesariamente algo que el producto deba hacer, sino más bien cosas que el negocio necesita para satisfacer a las partes interesadas internas y externas.

Por ejemplo, imagina que trabajas para un negocio de ventas minoristas en línea y que el equipo de ventas usa un sistema de gestión de contenido para crear y actualizar las páginas de los productos en el sitio web. Para organizar el inventario en aumento, el equipo de producto trabaja en la elaboración de una función de búsqueda optimizada dentro del sistema de gestión de contenido (CMS). Este proyecto está alineado con el siguiente requisito de negocios: aumentar el inventario de productos en un 50 % durante el 1.º trimestre.

Requisitos del usuario

Con los requisitos del usuario se define qué necesitan los usuarios y cómo interactúan con tu producto. Describen los puntos débiles o alguna acción que el cliente desee cumplir, además de cómo debería funcionar el producto para aliviar esos puntos de conflicto o ayudar a que el usuario cumpla con la acción deseada.

Generalmente, en los equipos ágiles a los requisitos del usuario se les da el formato de historias de usuarios, que consisten en explicaciones informales de una función de software, redactadas desde la perspectiva de un usuario final. Las historias de usuarios siguen este formato: “Como [perfil], quiero [objetivo del software], para lograr [resultado]”.

Volvamos al ejemplo del sistema de gestión de contenido (CMS) descripto anteriormente. A continuación, compartimos un ejemplo de historia de usuario escrita desde la perspectiva del usuario final; en este caso, un agente de ventas que usa el CMS para cumplir con sus funciones.

“Como agente de ventas, quiero buscar y encontrar fácilmente información específica sobre los productos publicados en nuestro CMS, para lograr actualizar y gestionar el inventario en línea que está en constante crecimiento”.

Requisitos del sistema

Con los requisitos del sistema se define qué hará el producto. Piénsalo de este modo, mientras que con los requisitos del usuario se explican el “por qué” y el “qué” de las funciones del producto desde la perspectiva del usuario, con los requisitos del sistema se define “cómo” se construye la función, ahora desde la perspectiva del equipo de ingeniería.

En la mayoría de los casos, los requisitos del sistema se desglosan en requisitos funcionales y no funcionales. Con los requisitos funcionales se define qué hará el producto, mientras que con los no funcionales se determina en qué medida las funciones del producto trabajarán como se espera. Esto significa que, normalmente, los requisitos no funcionales están vinculados a la seguridad, el rendimiento y la fiabilidad.

Por ejemplo, aquí te mostramos cómo un equipo de ingeniería podría desglosar el requisito anterior del CMS en requisitos del sistema:

Requisitos funcionales

• Que en cada listado de productos se almacene la siguiente información: el tipo de producto, la fecha de creación, el autor, la URL y el estado de la publicación.

• Que no se puedan crear productos nuevos a menos que los autores seleccionen un tipo de producto en el menú desplegable.

• Que la barra de búsqueda incluya una opción para aplicar los siguientes filtros extra: el tipo de producto, la fecha de creación, el autor, la URL y el estado de la publicación.

• Que se puedan seleccionar varios filtros a la vez.

Requisitos no funcionales

• Que los resultados de las búsquedas aparezcan en menos de cinco segundos.

• Que los resultados de las búsquedas sean 100 % precisos.

Los 6 pasos del proceso de gestión de requisitos

La gestión de requisitos no tiene por qué resultar abrumadora. Si creas un proceso estandarizado para tu equipo, puedes seguir los mismos pasos cada vez que lo necesites, en vez de preocuparte por saber a quién debes incluir y cuándo.

Para ayudarte a empezar, hemos simplificado el proceso en seis pasos. Después, una vez que lo hayas probado y que sepas qué es lo que funciona para tu equipo, podrás adaptar tu proceso de gestión de requisitos según corresponda.

1. Reúne los requisitos

Antes de poder definir los requisitos del proyecto; primero, debes informarte sobre cuáles son esos requisitos. En esta etapa, que reúnas los requisitos no significa que necesariamente serán parte de tu proyecto, más bien es una oportunidad para que te conectes con las demás partes interesadas y con los clientes para conocer más a fondo sus necesidades.

Existen diferentes formas de abordar esta fase, puedes reunirte con las partes interesadas en persona para comunicar los detalles del producto o la función que estás creando; y después, preguntarles qué necesitan o quieren de tu proyecto para ayudar a los clientes o para alcanzar los objetivos de negocios. Durante este período, puedes desarrollar los requisitos con la ayuda de los demás involucrados hasta entender perfectamente lo que necesitan. También tienes la posibilidad de comunicarte con las partes interesadas de forma asincrónica para no perder tiempo con tantas reuniones. Aunque si lo que necesitas es entender cuáles son los requisitos de los usuarios finales, probablemente te convenga llevar adelante pruebas de usuario o comunicarte con el equipo de investigación de usuarios.

Durante estas conversaciones, no olvides tener en cuenta las expectativas de las partes interesadas: deben saber que no todos los requisitos que solicitan se incluirán en el producto. En definitiva, dependerá de tu equipo y de ti establecer las prioridades y seleccionar los requisitos más importantes en los que trabajarán.

2. Analiza los requisitos

Es hora de clasificar todos esos comentarios y de decidir cuáles se alinean con tu producto y objetivos de negocios. A la larga, cada requisito deberá contribuir a un objetivo de negocios global, como, por ejemplo, aumentar los ingresos, expandirse a nuevos mercados o mejorar la satisfacción de los clientes.

3. Define los requisitos

Ahora que ya has analizado los requisitos y elegido los que se alinean con tus objetivos, es hora de definirlos con claridad, para garantizar que el equipo tenga toda la información que necesita para trabajar. Esta etapa es útil para detallar todo aquello con lo que debe cumplir el equipo de desarrollo para terminar el producto o la función.

Una opción para definirlos es crear historias de usuarios para cada requisito, a fin de articular qué necesitan los usuarios y cómo interactuarán con tu producto. Después, podrás desglosarlos en requisitos del sistema más específicos. A medida que avances, probablemente debas reunir más información de las partes interesadas para asegurarte de tener el contexto suficiente como para cumplir con cada uno de los requisitos.

4. Documenta los requisitos

En realidad, no hay una forma establecida de cómo documentar y dar seguimiento a los requisitos. Es probable que el equipo de producto, históricamente, haya usado especificaciones de requisitos de software (SRS), documentos de requisitos de productos (PRD) o una matriz de trazabilidad de requisitos (RTM).

Pero para confirmar que el equipo tiene una noción clara y actualizada de todos los requisitos de tu proyecto, usa una herramienta de gestión de proyectos como Asana. Ya no tendrás que trabajar con hojas de cálculo desactualizadas. Por el contrario, tanto tu equipo como las demás partes interesadas podrán ver las descripciones más recientes de cada requisito. Además, podrás dar seguimiento al estado de cada requisito mientras trabajas en el proyecto e incluso, tendrás la posibilidad de configurar automatizaciones para mantener a todos actualizados cada vez que se haya avances.

También puedes integrar Asana con aplicaciones y herramientas de gestión de requisitos más especializadas como Jira o Github. Resulta particularmente útil si trabajas con personas que no tienen permisos para acceder a herramientas para desarrolladores.

5. Establece las prioridades de los requisitos

Ahora que ya cuentas con el conjunto de requisitos por escrito, trabaja junto a tu equipo para establecer las prioridades y planificar cómo se ocuparán de cada uno de ellos. Esta etapa de priorización te permitirá trabajar primero con las tareas más importantes, en particular, si bloquean a otras tareas que vienen detrás.

Si el equipo trabaja con metodologías ágiles, agrega los requisitos al trabajo pendiente del producto y después organiza una sesión de planificación de sprint para decidir qué tareas conviene incluir en el siguiente sprint. Si no trabajas en sprints, puedes crear un cronograma del proyecto para disponer cuándo se debería finalizar cada requisito y si tienen dependencias.

6. Elabora un plan para los cambios

La gestión de requisitos no consiste únicamente en planificar los requisitos antes de empezar a trabajar con el proyecto; en realidad, también se trata de gestionar lo cambios en los requisitos a medida que el proyecto avanza. Es decir que debes planificar cómo incorporarás otras tareas que afectarán el alcance de tu proyecto.

Una posibilidad es mediante la creación de un proceso de control de cambios. Esta opción les ofrece a las partes interesadas una forma de solicitar requisitos nuevos que afectarán el alcance del proyecto; y además, se deja en claro quién aprobará o rechazará la solicitud. Con un proceso de control de cambios también puedes documentar y dar seguimiento al modo en que cambian los requisitos durante el curso de un proyecto, a fin de medir el impacto del cambio más adelante.

Herramientas que simplifican la gestión de requisitos

La gestión de requisitos tiene muchas variables, pero ninguna tiene por qué salirse de control. Con las herramientas correctas, puedes preparar un proceso repetible y proyectar exactamente con quién hay que hablar, cuándo hay que hacerlo, y cómo documentar y organizar los requisitos a lo largo del ciclo de vida del proyecto.

Si das seguimiento a los requisitos en Asana, puedes crear una plantilla estandarizada para ayudarte a gestionar los requisitos de todos los proyectos. Es decir, en vez de empezar el proceso desde cero cada vez, puedes reutilizar un flujo de trabajo predeterminado y tener la tranquilidad de saber que no te olvidarás de ningún punto crítico.