User Stories : La importancia de los roles.

Un punto a tocar  a la hora de refactorizar o diseñar un sistema son los roles. Todas las personas que usaran nuestro sistema son usuarios, o mas bien grupos de usuarios. Cada uno de estos grupos tiene intereses muy distintos y únicos al momento de operar el sistema. No puedes englobarlos todos en una misma categoría (a menos que trabajes con un diseño simple que tenga baja complejidad o nulo crecimiento a futuro), es importante darse un tiempo  de verificar que se cubre las necesidades de todos. Hay que tener en cuenta lo siguiente:

¿Que es un rol de usuario?.

Un rol de usuario es un conjunto de usuarios con las mismas características, intereses y necesidades. Un rol, en principio no debe representar solo a un usuario individual (aunque el sistema solo tenga un usuario de determinado rol, como el tipo de sistemas, por ejemplo).

El interés en el sistema no es igual para todos.

Un sistema en la empresa no le sirve a todos para lo mismo. Imagina un sistema de recepción de facturas. Los proveedores buscan subir sus facturas a un portal para que inicie su proceso de pago. La gente del área de finanzas debe de validar la factura, y en caso de que todo este en orden marcarla como buena. Quizá el gerente de área este interesado en saber que pagos están pendientes y cuales ya han sido liberados. Cada uno de estos actores accede al sistema para cubrir sus propios intereses egoístas, no esta interesado en saber que hacen los otros grupos de usuarios.

Aléjate de los diseños anémicos.

Un error común es englobar el conjunto de usuarios como solamente: “el usuario”, o quizá:  “el cliente”, esto plasmado en una historia usuario no ofrece pista alguna sobre la problemática de quien estas solucionando o el valor que se busca ofrecer al trabajar en ello. Es necesario hacer un esfuerzo para encontrar los grupos de usuarios que van a operar, imagina diseñar historias de usuario con los roles: Usuario y Administrador. En este caso  se sabe que existen usuarios y otra clase con mas poderes, y ya. ¿Que pasaría si haces un esfuerzo y te das cuenta de que hay muchas mas categorías?, por ejemplo: proveedores, dueños de empresa, asociados, comerciales, gerencia, administradores. Es claro, sin saber mucho del requerimiento, que el sistema en cuestión resolverá varias problemáticas, en varios niveles. Y las soluciones pensadas para un rol pueden no aplicar para otro rol. Definitivamente las historias que se redacten con un modelo robusto tendrán mas posibilidades de ser exitosas.

Esta bien no conocer todos los roles al principio.

Diseñar sistemas no es una ciencia, es posible que no conozcas todos los roles. O también roles que inicialmente pensabas que eran uno solo se dividan con la respectiva corrección en las historias de usuario. Las historias de usuario deben de ser buenas, no perfectas. Si esperas por tener un modelo, requerimiento o historias de usuario perfectas también estas generando desperdicio.

Buenos roles hacen buenas historias de usuario.

Uno de los principales objetivos de las historias de usuario es aportar valor medible, un rol bien definido en una historia de usuario indica que tanto valor aporta, que tan importante es y que tan negociable es en la priorización. También ayuda a completar flujos de usuario o incluso estimar tiempos. Si conoces el valor que se aporta a cada rol, puedes usarlo como moneda a la hora de tomar decisiones, por ejemplo: Se debe de priorizar el flujo asociado y proveedores, los reportes gerenciales y el modulo de administración pueden dejarse de lado hasta una nueva etapa. ¡Ves!, medibilidad y visibilidad.

Autor imagen: Marco Verch