Si buscamos la definición de «historias de usuario» vamos a encontrar muchas respuestas, además de diferentes perspectivas y metodologías para crearlas. Como es habitual, Wikipedia hace un buen resumen de todas las cosas que se han escrito alrededor del tema:
- son parte de muchas metodologías de desarrollo de software
- describen requerimientos del sistema pero desde la perspectiva del usuario
- ayudan a darle contexto a los requerimientos
- Se validan con el cliente interno
Aquí hay dos hilos comunes: uno es que las historias de usuario son una metodología de desarrollo. El otro, que aparece por omisión, es que no surgen de observaciones reales de usuarios.
Y ese es el gran problema con las historias de usuario: son funcionalidades disfrazadas de «necesidades» de los usuarios que, en la mayoría de los casos, no surgen de las necesidades de los usuarios reales. Son simplemente hipótesis.
Normalmente, los equipos de desarrollo escriben historias de usuario como una actividad grupal o en el contexto de un taller. Cuando se dice que «participan los usuarios» en general se suele referir a los stakeholders, no a los usuarios finales.
Las pocas veces que los usuarios finales efectivamente participan se suele hacer más bien un levantamiento de requerimientos más que un relevamiento de necesidades.
La ilusión de agilidad
El hecho de que no participe ningún usuario real en la elaboración de historias de usuario puede parecer muy ágil y lean. Pero la realidad es completamente lo contrario: desarrollar funcionalidades sin hacer investigación con usuarios pareciera que ahorra tiempo, pero es costoso y crea mucho desperdicio.
Aquí va un ejemplo: hace algún tiempo estábamos trabajando en una plataforma B2B donde los usuarios tenían que iniciar sesión para descargarse información que utilizaban para hacer informes.
Antes de comenzar el proyecto el equipo de Desarrollo había escrito algunas historias de usuario e incluso desarrollado algunas pantallas. Una de ellas decía algo así como «los usuarios quieren usar Gmail o LinkedIn como una forma fácil de iniciar sesión«.
Sin embargo, eso no era más que una hipótesis ya que no se había hecho ningún relevamiento con los usuarios reales. Simplemente habían mirado varios sitios (probablemente B2C) que usaban esta funcionalidad para simplificar el registro e ingreso al sitio y pensaron «esto sería una buena idea para el sistema que estamos construyendo».
Así, la pantalla de inicio de sesión que habían diseñado tenía tres opciones: iniciar sesión con Gmail, con LinkedIn o con un correo electrónico a elección.
Cuando realizamos pruebas de usabilidad, descubrimos que los usuarios no querían usar cuentas personales o redes sociales para iniciar sesión en un sistema que usaban para el trabajo: «No voy a usar mi cuenta de Gmail/LinkedIn para esto. Este es un sistema de trabajo. No quiero que vean mi información personal«, dijeron la mayoría.
Por suerte estábamos probando prototipos y aún no se había construido nada. De no haberse «perdido el tiempo» (y por lo tanto agilidad) validando los prototipos con los usuarios finales, el equipo de desarrollo hubiese perdido tiempo construyendo una funcionalidad basada en un supuesto que sonaba bien, y que se validaba porque otros sitios la tenían, pero que los usuarios reales no hubiesen usado.
Y así, se hubiese desperdiciado ese mismo tiempo que se pretendía ahorrar, construyendo algo que nadie iba a usar.
Esa es la ilusión de la agilidad: pensar que se ahorra tiempo no entrevistando a los usuarios, cuando ese mismo tiempo muchas veces se termina usando en el refactoring, o peor aún desperdiciado, al hacer funcionalidades que no se usan.
Problemas de usuario vs historias de usuario
Entonces, hacer una distinción entre los problemas reales de los usuarios y las historias de usuario que construimos puertas adentro es clave si realmente queremos ser ágiles.
Problemas de usuario
- Expresan un problema o necesidad real que tienen los usuarios al utililzar el sistema
- Son observaciones validadas con usuarios reales que provienen de un proceso investigación con usuarios
- Son parte de un flujo o tarea que el usuario está tratando de realizar y no observaciones aisladas
- Aportan una perspectiva de fuera hacia adentro: lo que los usuarios nos dicen
Historias de usuario
- Suelen ser requisitos disfrazados de necesidades de usuario
- Son suposiciones que hacen los equipos de desarrollo
- Normalmente no surgen de un relevamiento con usuarios reales sino con stakeholders
- Por lo general, son declaraciones desconectadas unas de otras (en vez de provenir de un flujo de tareas)
- Representan una perspectiva de adentro hacia afuera: lo que pensamos que necesitan los usuarios
Ser realmente ágiles: «ganar» tiempo con los usuarios
Como venimos viendo, las historias de usuario deberían describir una necesidad real del usuario o un comportamiento observado durante la investigación con usuarios. Luego, y solo entonces, estos problemas se traducirán en historias de usuario para definir una funcionalidad.
Esta es la única manera en que los equipos de desarrollo pueden ser verdaderamente ágiles y lean.
