Es realmente muy simple. Como la mayoría de técnicas y artefactos que utilizamos en proyectos ágiles, lo complicado es entender su objetivo y usarlas bien. Aquí te mostramos cómo hacerlo.
Podríamos definir un requisito, como una necesidad, un deseo o una funcionalidad que los usuarios o cualquier otro interesado en el proyecto, necesitaría o le gustaría que se incorporase. De forma que, de no hacerlo realmente, el producto o servicio final que se generará durante y/o al final del mismo, podría no servir.
La identificación de las necesidades o requisitos de los stakeholders del proyecto y su incorporación en el resultado, es una de las claves fundamentales para alcanzar el éxito del proyecto. Tanto es así, que debemos realizar un esfuerzo muy importante para definirlos correctamente.
Ángel Nájera, CEO Wolf Project
En el PMBoK®, Project Management Body of Knowledge, que edita PMI®, Project Management Institute USA, podemos encontrar un documento denominado “Matriz de trazabilidad de requisitos”. Se utiliza para identificar todos los requisitos a incorporar, así como la información suficiente y relevante para su gestión. De hecho, conecta y vincula a los mismos desde el momento en que se identifican hasta que se decide, o bien no incluirlos, o se han ya implementado. También se describe otro documento: “Documentación de requisitos”, basado en el anterior, pero que sólo incluye a los requisitos que, efectivamente, se ha decidido que formarán parte del proyecto.
Una vez que se han definido todos los requisitos nos damos cuenta que no todos son iguales, ni tienen el mismo impacto en el resultado del proyecto.
Ante todo priorización. Evidentemente no todos los requisitos son iguales ni tienen un mismo impacto en el resultado. Por lo que, una vez los hayamos identificado, el siguiente paso es priorizarlos. Implica conocer dónde está el valor del proyecto y permite que el esfuerzo y los recursos se centren en los requisitos y funcionalidades más determinantes. Esto implica que los documentos que hemos indicado anteriormente deben ordenar los requisitos por su importancia y valor. Además han de ser flexibles y adaptables a los nuevos requisitos que eventualmente puedan surgir, permitiendo una re-priorización constante, según el artículo que te recomiendo: “Ámalo o véndelo: cuestión de requisitos”.
Actualmente, existe un consenso muy extendido sobre esta técnica. Definir estas necesidades siguiendo el esquema de Historias de Usuario, User Story o US en su forma abreviada, es una técnica que funciona realmente bien.
La forma en cómo se describen estas necesidades es de suma importancia, ya que si el equipo de especialistas que tienen que construir o desarrollar una solución que sea capaz de satisfacer dichos requisitos, no los entiende correctamente, el resultado tenderá a ser pobre. Y probablemente, los malos entendidos harán que se trabaje de forma poco eficiente, realizando las cosas “dos veces”.
Una US es un punto de partida, como se apunta en PRINCE2 Agile®, donde se describe la estrategia para agilizar la metodología PRINCE2® cuando sea necesario. Es un medio de comunicación y de entendimiento entre el que necesita algo y quien va a crear un producto para satisfacer dicha necesidad, por lo que tiene que estar escrito de tal forma que ambos se entiendan perfectamente.
Yo, como <rol de usuario>. Se debe incluir qué agente es el que tiene la necesidad. De forma que, si bien, la responsabilidad de la definición y priorización de los requisitos es del Product Owner, del Senior User, del Customer Mattert Expert o del cualquier otro rol que hayamos definido, cualquiera puede definir un requisito, o hacerlo en nombre de otro (la empatía aquí es paramont).
Quiero que <puedo, acción>. En esta parte se debe definir qué se necesita. El lenguaje empleado debe ser tipo business, es decir no técnico y centrado en el problema y desde luego, no en la solución. Este aspecto es muy importante, ya que hay que dejar suficiente espacio al equipo para que, entendiendo la problemática, sean capaces de generar ideas y soluciones novedosas, lo que, sin duda, es un valor añadido y permite empoderar y dar libertad al equipo.
Por ejemplo, si se indicase una afirmación como la siguiente: “quiero una pantalla en la que aparezca el tiempo restante que me queda”, estaríamos encorsetando una posible solución más eficiente. Lo podríamos hacer de otra forma: “necesito conocer en tiempo real, el tiempo que me queda”. La segunda opción, es una ejemplo en el que dejamos la solución abierta para que el equipo pueda explorar distintas soluciones y aportar su experiencia y conocimiento.
Para qué <beneficio>. También es muy importante, para conocer la necesidad, saber para qué se quiere. Sin duda, sirve claramente para comprender mejor la situación.
Podemos poner algún ejemplo:
Como vemos, cuanto más específicos y menos generalistas, mejor se entenderán las necesidades y más ajustado será el producto final.
La US es sólo un principio, una excusa para poder entablar un diálogo entre el que tiene la necesidad y quien la debe satisfacer. A través de la creación de un producto o servicio entregable, el siguiente paso es concretar un poco más. Me refiero a que si se ha descrito una US como la siguiente:
Como director de la oficina, necesito que se reduzca el consumo de papel, para reducir el coste económico y mejorar nuestra imagen como empresa responsable
Parece que está bien definida, pero, ¿a qué nos referimos con “que se reduzca el consumo de papel”?, ¿sería suficiente con reducir un 5% o un 50%?. Realmente necesitamos saber más. Para eso tenemos que incluir –siempre- a la US lo que se denomina criterio/s de aceptación. Que consisten en definir cómo se va a entender que el producto/solución satisface la necesidad.
En el caso anterior, podríamos definir alguno como:
CA01: Que se reduzca en un 80% la compra de papel.
Dedicar tiempo a identificar correctamente los requisitos, es un buen negocio, y el manejo eficiente de User Stories, facilita la labor a la vez que mejora la comunicación entre los que necesitan y los que ejecutan. Por lo que, no lo dejes pasar. Es una técnica que tiende a mejorar a medida que se adquiere más experiencia. Este proceso no debe ser estático y serán mejores cuanto mayor sea su utilidad y tengan un beneficio concreto.
