Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Product Owner. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Product Owner. Mostrar todas las entradas

jueves, abril 20, 2023

[Learning Lab] El poder de las historias de usuario: cómo crear productos que agreguen valor

Esta es la presentación “El poder de las historias de usuario: cómo crear productos que agreguen valor” que hice para el Learning Lab con Certiprof el 19 de abril de 2023.

Algunos aspectos de la presentación:

Las historias de usuario son una herramienta poderosa en el desarrollo ágil de productos porque ayudan a los equipos a centrarse en las necesidades y los deseos de los usuarios finales. Al crear historias de usuario, los equipos pueden identificar cómo su producto agregará valor a la vida de los clientes y asegurarse de que están construyendo algo útil y relevante.

El poder de las historias de usuario radica, entre otros, en los siguientes aspectos:

1. Centrarse en el cliente: las historias de usuario ponen al cliente en el centro del proceso de desarrollo del producto, asegurando que sus necesidades y preferencias impulsen las características y mejoras del producto.

2. Simplicidad: las historias de usuario son concisas y directas, lo que ayuda a los equipos a comunicarse de manera efectiva sobre los requisitos y objetivos del producto.

3. Colaboración: las historias de usuario fomentan la colaboración entre los miembros del equipo, fomentando una comprensión compartida del propósito y la visión del producto.

4. Adaptabilidad: las historias de los usuarios se pueden ordenar fácilmente, lo que permite a los equipos responder a las condiciones cambiantes del mercado o a los comentarios de los clientes.

Ahora bien, para crear productos que agreguen valor en todas las industrias, considera los siguientes pasos:

1. Identifica a tus usuarios objetivo: ¿Quiénes son las personas que se beneficiarán más de tu producto? Entiende sus necesidades y deseos.

2. Crea historias de usuario: haz narraciones concisas y centradas en el cliente que describan cómo tu producto abordará las necesidades y los deseos de los usuarios objetivo.

3. Ordena las historias de usuario: clasifica las historias de usuario en función de su impacto potencial, viabilidad y alineación con los objetivos estratégicos de tu empresa.

4. Itera y valida: prueba continuamente tu producto con usuarios reales para recopilar retroalimentación y refinar tus historias de usuario. Adapta su plan de desarrollo del producto según sea necesario para asegurarte de que estás entregando valor.

5. Considera los beneficios sociales y ambientales: Esfuérzate por crear productos que no solo generen ganancias financieras, sino que también contribuyan positivamente a la sociedad y el medio ambiente. Esto puede incluir la reducción de residuos, el apoyo a las comunidades locales o la promoción de la sostenibilidad.

Puedes descargar la presentación aquí:

lunes, enero 16, 2023

Historias de usuario basadas en el comportamiento

 

 Foto de Icons8 Team en Unsplash

Ya sabemos que el así llamado Desarrollo Conducido por Comportamiento (BDD por las siglas en inglés de Behavior-driven development) es un proceso de desarrollo de software que se enfoca en el comportamiento de una aplicación. BDD acentúa la comunicación y la colaboración entre los desarrolladores, y aquí estoy usando “desarrolladores” en el sentido amplio de Scrum, es decir, las personas que elaboran software, sean especialistas en áreas como desarrollo o aseguramiento de la calidad, o en el sentido preferido de los practicantes ágiles, personal más especialista-generalista o simplemente más multifuncionales. Pero BDD no solo resalta la comunicación entre ellos, sino también entre estos desarrolladores y las personas no técnicas dentro y fuera de los equipos, como un Product Owner, usuarios o interesados.

En general, BDD implica la creación de casos de prueba que describen el comportamiento del sistema desde la perspectiva del usuario final. Estos casos de prueba, llamados "características" (“features”), se escriben en una sintaxis de lenguaje natural llamada "Gherkin", lo que posibilita que todos los miembros del equipo puedan leer y, mejor aún, entender las funciones de la aplicación, independientemente de su experiencia técnica.

Por ejemplo, si el sistema que se está desarrollando es un sitio web o una aplicación para un servicio de emisión o transmisión en directo por suscripción que les permita a usuarios ver series y películas en un dispositivo con conexión a internet, puedo tener la posibilidad de adicionar películas a una lista de películas favoritas:

Característica: Lista de Favoritas

Como usuario, Quiero agregar películas a mi lista de favoritas y conservarlas allí para poder verlas posteriormente

Luego, puedo agregar uno o más bloques de "escenario" que describen comportamientos o acciones específicas que el sistema debería poder realizar.

Escenario: Agregar película a la lista de favoritas

Dado que estoy en la página principal

Cuando busque por “películas de Ciencia Ficción”

Y haga clic en el botón “Adicionar a la lista” del primer resultado

Entonces la película debe ser adicionada a mi lista de favoritas

Y se repite la adición de escenarios para cada comportamiento que se quiera probar de la aplicación. Como siempre, es importante tener en cuenta que el comportamiento y sus escenarios solo deben se definen desde la perspectiva del usuario final. No debe contener detalles de implementación ni jerga técnica.

Ejemplos de historias de usuario tipo Gherkin

Y es aquí donde entran las historias de usuario. Podemos usar este “lenguaje natural” tipo “Gherkin” para representarlas. Sigamos con el ejemplo de la aplicación de transmisión que llamaremos RedTV.

Dado: un usuario tiene una cuenta con la plataforma RedTV

Cuando: el usuario intenta iniciar sesión

Entonces: El usuario se autentica y puede acceder al servicio de streaming

 

Dado: un usuario está buscando una película o una serie

Cuando: el usuario ingresa el título que quiere

Entonces: al usuario se le presentan las opciones de transmisión disponibles

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario detiene la transmisión

Entonces: el contenido se detiene y se puede reanudar más tarde

 

A estas historias de usuario podemos agregar algunos criterios de aceptación:

1.    El usuario puede iniciar y cerrar sesión en la plataforma de transmisión con las credenciales de su cuenta.

2.    El usuario puede buscar cualquier título, ya sea una película o serie, y ver las opciones de transmisión disponibles.

3.    El usuario puede poner en pausa el contenido de transmisión y reanudarlo más tarde.

4.    El contenido no debe interrumpirse ni detenerse mientras el usuario está transmitiendo.

5.    La calidad de la transmisión debe ser constante durante toda la duración de la transmisión.

6.    La plataforma de transmisión debe ser accesible tanto en dispositivos móviles como en computadoras de escritorio.

Advertencia: no todos estos criterios son para todas las historias de usuario anteriormente descritas. Dejo al lector para que use su habilidad de discernir sobre cuáles criterios serían de qué historias.

Ahora sí, veamos algunos ejemplos de historias de usuario con sus respectivos criterios de aceptación:

Dado: un usuario está navegando por el servicio de transmisión

Cuando: al usuario se le presentan recomendaciones basadas en su historial de visualización

Entonces: El usuario recibe recomendaciones de contenido personalizadas.

Criterios de aceptación:

1.    El usuario debe recibir recomendaciones personalizadas basadas en su historial de visualización y preferencias.

2.    El algoritmo de recomendación de contenidos debe ser eficaz y preciso.

3.    El usuario debe poder filtrar las recomendaciones por género, clasificación por edad y otros parámetros.

4.    El usuario debe recibir las recomendaciones más actualizadas.

 

Dado: un usuario está navegando por el servicio de transmisión

Cuando: el usuario intenta ver una película o un programa de televisión

Entonces: al usuario se le presentan todas las opciones de transmisión disponibles

Criterios de aceptación:

1.    Al usuario se le deben presentar todas las opciones de transmisión disponibles para una película o programa de televisión.

2.    Las opciones de transmisión deben incluir opciones premium y opciones gratuitas.

3.    El usuario debe poder filtrar las opciones de transmisión por precio, calidad y otros parámetros.

4.    El usuario debe tener la información más actualizada sobre las opciones de transmisión.

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario intenta cambiar la calidad de la transmisión

Entonces: Al usuario se le presenta una gama de opciones de calidad.

Criterios de aceptación:

1.    Al usuario se le debe presentar una variedad de opciones de calidad para elegir.

2.    La calidad de transmisión no debe degradarse al cambiar la configuración de calidad.

3.    El usuario debe poder cambiar entre configuraciones de calidad con una interrupción mínima.

4.    La configuración de calidad debe ser uniforme en todos los dispositivos.

 

Dado: un usuario está navegando por el servicio de transmisión

Cuando: el usuario intenta comprar una película o una serie

Entonces: Al usuario se le presentan opciones de pago

Criterios de aceptación:

1.    Al usuario se le debe presentar una variedad de opciones de pago.

2.    El proceso de pago debe ser seguro y fácil de usar.

3.    El usuario debe tener la opción de comprar contenido por tiempo limitado o de forma permanente.

4.    El proceso de pago debe explicarse claramente al usuario.

Ahora sí, una brevísima explicación de esta forma BDD "dado-cuando-entonces" de historias de usuario

El formato Gherkin-BDD "dado-cuándo-entonces" es una forma de representar historias de usuario que se centra en el punto de vista del usuario. La forma se divide en tres partes: Dado, Cuándo y Entonces. La parte "Dado" de la historia de usuario establece el contexto y describe la situación actual. La parte "Cuando" describe la acción que está realizando el usuario. La parte "Entonces" describe el resultado esperado de la acción. Esta forma permite que las historias de usuario se expresen desde la perspectiva del usuario, asegurando que se consideren las necesidades y expectativas del usuario.

Podemos usar diferentes estilos para relatar o representar historias de usuario. Veamos un ejemplo de una historia de usuario primero en el estilo clásico "Como - Quiero - Para " y luego, la misma historia en la forma “Dado - Cuando - Entonces”.

Como usuario,

Quiero modificar la información de mi perfil

Para poder mantenerla actualizada.

Ahora en “Gherkin”:

Dado: Un usuario tiene una cuenta

Cuando: el usuario intenta modificar la información de su perfil

Entonces: el usuario puede actualizar correctamente la información de su perfil

Y algunos criterios de aceptación:

1.    El usuario puede ver la información de su perfil.

2.    El usuario puede modificar la información de su perfil.

3.    El usuario puede guardar los cambios que realiza en la información de su perfil.

4.    El usuario puede eliminar la información de su perfil si así lo decide.

5.    Las modificaciones a la información del perfil deben ser seguras y privadas.

Algunas recomendaciones para narrar mejores historias de usuario con la forma BDD

Usa mi modelo de las 5 C:

1.    Céntrate en la perspectiva del usuario: representar historias de usuario desde el punto de vista del usuario es clave para asegurarse de que se cumplan sus necesidades y expectativas. Esto no es exclusivo para esta forma de representación, pero siempre es bueno recordarlo, las historias son “de usuario”, no de desarrollador, de interesado ni de gerencia.

2.    Concretiza: Sé específico. Asegúrate de incluir tantos detalles como sea posible, ya que esto facilitará que quienes implementen las características del producto comprendan el resultado deseado. Esto no tienes que hacerlo solo “escribiendo” historias de usuario. Recuerda que la parte más importante de estas es la conversación que tengas alrededor de la misma. Esto no cambia con una modificación en la forma de representarlas.

3.    Colabora: invita a los interesados y los desarrolladores a colaborar al describir historias de usuario, ya que esto ayuda a garantizar que estas sean claras y brinden la mayor cantidad de detalles posible. Las historias de usuario son un protocolo de colaboración, es una forma de realizar el trabajo en torno a un objetivo deseado.

4.    Considera casos extremos: asegúrate de incluir cualquier caso extremo al contar historias de usuario, ya que esto ayudará a garantizar que se contemplen todos los resultados posibles. Pero no te estreses con tratar de adjuntar todos los casos: primero los más críticos u obligatorios, luego los importantes y por último, si hay tiempo y presupuesto, los buenos, bonitos y baratos.

5.    Cata: Prueba y perfecciona. Después de crear historias de usuario, evalúalas para asegurarte de que sean claras y precisas, y perfecciona según corresponda. La calidad del producto comienza con la calidad de las conversaciones que tengas sobre cada historia de usuario de este.

Conclusión

Esta apenas es una forma más de representar historias de usuario que puedes incluir en tu caja de herramientas y enseñarla a tus equipos lo más pronto posible. Los beneficios de usar una forma u otra vienen dados por el contexto y por los resultados que quieras obtener. No te voy a decir que una forma es mejor que otra, porque no es cierto.

Anexo # 1: historias de usuario de la aplicación RedTV en la forma BDD, cada una con sus respectivos criterios de aceptación.

 

Dado: un usuario está buscando películas o series para ver

Cuando: al usuario se le presenta una variedad de opciones de género

Entonces: El usuario puede filtrar las recomendaciones por género

Criterios de aceptación:

1.    Al usuario se le debe presentar una lista de opciones de género para elegir.

2.    La lista de opciones de género debe ser completa y estar actualizada.

3.    El usuario puede filtrar el contenido recomendado en función de su selección de géneros.

 

Dado: un usuario ha comenzado a ver una película o serie

Cuando: el usuario desea saltar a una escena o sección específica

Entonces: el usuario puede buscar escenas específicas dentro del contenido

Criterios de aceptación:

1.    El usuario puede buscar escenas específicas dentro del contenido que está viendo.

2.    La búsqueda debe ser efectiva y precisa.

3.    El usuario puede saltar fácilmente a la escena que está buscando.

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario intenta ajustar la configuración de audio

Entonces: el usuario puede ajustar la configuración de audio

Criterios de aceptación:

1.    El usuario puede ajustar la configuración de audio del contenido que está transmitiendo.

2.    El usuario puede ajustar el volumen, el balance y otras configuraciones de audio.

3.    La configuración de audio debe ser uniforme en todos los dispositivos y plataformas.

 

Dado: un usuario está transmitiendo contenido

Cuando: el usuario intenta compartir el contenido con amigos

Entonces: el usuario puede compartir el contenido en las redes sociales y otras plataformas

Criterios de aceptación:

1.    El usuario puede compartir el contenido con amigos en las redes sociales y otras plataformas.

2.    El proceso de compartir debe ser fácil y seguro.

3.    Los usuarios deben poder compartir contenido desde su dispositivo, así como desde la plataforma de transmisión.

 

Dado: un usuario está buscando películas y series

Cuando: al usuario se le presentan opciones de control parental

Entonces: el usuario puede restringir el contenido según las clasificaciones de edad

Criterios de aceptación:

1.    Al usuario se le deben presentar opciones de control parental cuando busca películas y programas de televisión.

2.    El usuario debe poder restringir el contenido según las clasificaciones de edad.

3.    Las clasificaciones de edad deben ser consistentes y estar actualizadas.

4.    Las opciones de control parental deben ser seguras y fáciles de usar.

Anexo # 2: historias de usuario de una Billetera Digital en la forma BDD

Como usuario de la Billetera Digital,

Quiero agregar mi tarjeta de crédito a mi billetera digital

para hacer pagos usando mi teléfono.

Dado que estoy conectado a mi cuenta

Cuando hago clic en el botón "Agregar tarjeta"

E ingreso los datos de mi tarjeta de crédito

Entonces mi tarjeta de crédito debe agregarse a mi billetera digital

 

Como usuario,

Quiero poder realizar pagos con mi monedero digital

para no tener que llevar mi tarjeta física conmigo.

Dado que tengo una tarjeta de crédito agregada a mi billetera digital

Cuando elijo la tarjeta en un punto de venta

E ingreso mi número de teléfono o escaneo un código QR

Luego, el pago debe procesarse utilizando mi billetera digital.

 

Como usuario,

Quiero ver mi historial de transacciones

para hacer un seguimiento efectivo de mis pagos.

Dado que estoy conectado a mi cuenta

Cuando hago clic en la pestaña "Historial de transacciones"

Entonces debería ver una lista de todas mis transacciones anteriores

Criterios de aceptación:

1.    El usuario debe poder ver una lista de todas sus transacciones anteriores

2.    El historial de transacciones debe incluir la fecha, el monto y el comerciante de cada transacción

3.    El usuario debe poder filtrar y ordenar el historial de transacciones por varios criterios (por ejemplo, fecha, monto, comerciante)

 

Como cliente,

Quiero seguir el estado de mis transacciones actuales o en curso

para conocer el momento exacto en que mis transacciones se hagan efectivas

Dado que estoy conectado a mi cuenta

Y estoy en la página "Mis transacciones"

Cuando hago clic en el botón "Rastrear transacción" para una transacción actual

Entonces debería ver el estado actual de la transacción seleccionada (por ejemplo, "Procesando", "Enviada", etcétera.)

 

Como usuario,

Quiero agregar varias tarjetas de crédito a mi billetera digital

para que pueda elegir qué tarjeta usar para cada pago.

Dado que estoy conectado a mi cuenta

Cuando hago clic en el botón "Agregar tarjeta"

E ingreso los datos de mi tarjeta de crédito

Entonces mi tarjeta de crédito debe agregarse a mi billetera digital

 

Como usuario,

Quiero ver y administrar todas mis tarjetas de crédito en mi billetera digital

para seleccionar fácilmente la tarjeta que quiero usar para cada pago.

Dado que tengo varias tarjetas de crédito agregadas a mi billetera digital

Cuando hago clic en la pestaña "Tarjetas"

Entonces debería ver una lista de todas mis tarjetas de crédito.

Y debería poder seleccionar una tarjeta para hacer un pago.

 

Como usuario,

Quiero eliminar tarjetas de crédito de mi monedero digital

para retirar las tarjetas que ya no uso y controlar mejor la seguridad de mis datos financieros

Dado que tengo varias tarjetas de crédito agregadas a mi billetera digital

Cuando hago clic en el botón "Eliminar" para una tarjeta específica

Entonces, la tarjeta seleccionada debe eliminarse de mi billetera digital

 

Como usuario,

Quiero poder realizar pagos con mi monedero digital

para no tener que llevar mi tarjeta física conmigo.

Dado que tengo una tarjeta de crédito agregada a mi billetera digital

Cuando elijo la tarjeta en un punto de venta

E ingreso mi número de teléfono o escaneo un código QR

Entonces, el pago debe procesarse utilizando mi billetera digital.

Criterios de aceptación:

1.    El usuario puede seleccionar una tarjeta de crédito de su billetera digital para realizar un pago

2.    El usuario puede ingresar su número de teléfono o escanear un código QR para completar el pago

3.    El pago debe ser procesado con éxito y el usuario debe recibir una confirmación del pago

 

Como usuario,

Quiero poder realizar pagos con mi billetera digital en cualquier lugar que acepte tarjetas de crédito

para que pueda hacer pagos donde quiera que esté.

Dado que tengo una tarjeta de crédito agregada a mi billetera digital

Cuando elijo la tarjeta en un punto de venta

E ingreso mi número de teléfono o escaneo un código QR

Luego, el pago debe procesarse utilizando mi billetera digital.

Criterios de aceptación:

1.   El usuario debe poder realizar pagos en cualquier lugar que acepte tarjetas de crédito (por ejemplo, en la tienda, en línea)

2.   El usuario debe poder seleccionar una tarjeta de crédito de su billetera digital para realizar un pago

3.   El pago debe ser procesado con éxito y el usuario debe recibir una confirmación del pago

 


domingo, octubre 09, 2022

De historias de usuario a historias de persona

 Y una forma más de delimitar y hacer pequeñas las historias de usuario

El problema actual

Dividir historias de usuario se ha convertido en un dolor de cabeza para los practicantes ágiles, principalmente para quienes usan esa técnica como motor para describir las necesidades de los usuarios y las características finales de los productos.

Lo voy a decir de otra forma: en mi trasegar diario con equipos y empresas que acompaño en el uso del enfoque y prácticas y marcos de trabajo ágil, he visto que dividir historias de usuario es algo de lo que todos hablan y tratan de practicar, pero les está costando.

Una de las causas de fondo de todo esto es la subvaloración que se le ha dado a la práctica de historias de usuario. Por ser algo tan sencillo, tan liviano, se estudia con poco detalle, de manera superficial y muy rápido. Los practicantes ágiles apenas si le están dedicando algunos minutos con la creencia de que ya conocen todo lo que deben conocer al respecto. Pero no es así. De ser algo tan simple, pasó a ser algo tan poco entendido y muy mal practicado. Quizás pasa lo mismo que con Scrum, liviano y fácil de entender, pero difícil de llegar a dominar.

Voy a ir más a fondo: el problema no es dividir historias de usuario en sí. Es tener historias de usuario lo suficientemente pequeñas, pero de Valor para el negocio y para el usuario, que se puedan elaborar en muy poco tiempo, desde unas pocas horas, hasta dos o tres días máximo, teniendo en cuenta iteraciones cortas de 10 días. Y cuando digo 2 o 3 días como máximo, me refiero a que la historia queda Terminada, cumple con todos los criterios de aceptación y con todas las condiciones de la Definición de Terminado para las historias de usuario individuales.

Entran las historias de persona

Soy Nancy. Ama de casa. Jubilada hace muchos años. Quiero hacer una transferencia de dinero a mi nieta sin tener que ir al banco. No quiero exponerme a un contagio y ya no tengo fuerzas para esperar de pie haciendo largas colas. Y quiero dedicar mi tiempo a otras labores de la casa.

Quiero hacer la transacción desde mi celular o en el PC de la casa.

Debe ser fácil de realizar porque no soy experta en el uso de estos dispositivos.

Quiero hacerlo de manera segura y rápida. Que no me roben mi platica.

 

Miguel es periodista. Viaja continuamente. Quiere saber cuándo le han consignado sus honorarios y sus gastos de viaje para llevar un control estricto de sus ingresos y gastos.

Miguel quiere recibir información de las consignaciones en su celular, quizás a través de mensajes de texto.

El mensaje debe incluir información sobre el valor de la consignación, el concepto por el cual se hizo y la fecha y hora de esta.

Miguel quiere que nadie más pueda tener acceso a esa información en caso de que se le extravíe el celular.

Aquí hay dos historias de usuario, dos historias, 2 relatos desde el punto de vista muy particular y hasta íntimo de dos personas. Tienen nombre propio, atraviesan vicisitudes específicas, necesidades singulares. Requieren que se cumplan algunas condiciones que consideran valiosas. Estas representan el éxito de su experiencia de cliente usando productos de alguna corporación o empresa. Son historias de persona.

Las historias de persona son concretas, en contraposición a las abstracciones naturales de una historia de usuario que señalan o lidian con, por ejemplo, Amas de Casa, Empleados, Clientes, Jubilados, trabajador autónomo o free lance, entre muchos otros. La misma historia permite conocer qué hace la persona, cómo lo hace, con quien lo hace, qué información intercambia y con quién la intercambia o quién es el receptor de esta. De alguna manera también deja ver sus principales problemas o inconvenientes al hacer lo que hacen. Es como si el equipo de trabajo, incluso los interesados y el mismo Product Owner o Product Manager, lo estuvieran viendo en acción, algo que se ha perdido en las últimas décadas en pro de prácticas que, de distintas manera, impiden el contacto o el acercamiento de quienes hacen productos con los consumidores o usuarios de estos.

Las historias de persona comienzan con la “persona” que originó la necesidad, con nombre y características demográficas únicas. Viene de la práctica User Persona. Esta persona tiene una identidad única y esto delimita el ámbito o el alcance de la historia y, por consiguiente, de la característica del producto que un equipo está forjando. He usado esta técnica en los últimos años y he comprobado que, en general, las historias resultantes son pequeñas, siguen siendo de valor y, efectivamente, se pueden labrar en muy pocas horas o, a lo sumo, en muy pocos días, junto a otras historias en una iteración breve.

Esta es una regla general, por supuesto. Es posible que algunas de estas historias todavía tengan que dividirse aún más para que se puedan trabajar en un sprint corto sin el riesgo visible de que no se puedan terminar junto a las demás.

No es la primera vez que uso el concepto de persona relacionado con las historias de usuario. El primer bloque o nodo de mi User Story Conversation Canvas es sobre las personas. Sobre esto explico que “el equipo debe conocer muy bien el perfil de estas personas, los aspectos personales y profesionales que los identifican, la educación, datos demográficos, sus hábitos e incluso sus motivaciones y comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos productos y servicios para seres humanos. El equipo debe sentir que conoce al usuario”.

El enigma del “usuario” en la historia de “usuario” y cómo resolverlo

Imagen de OpenClipart-Vectors en Pixabay
No me malentiendan. He escrito lo suficiente sobre historias de usuario, incluso he publicado un libro con mi gran amigo Jorge Abad sobre estos menesteres cuya edición en inglés recientemente fue referenciada por la Agile Alliance. No hay un problema de fondo con el usuario en la historia de usuario. Pero conocer más al usuario sí ayuda.

En general, un “usuario” es un concepto abstracto con cierto nivel de vaguedad que se puede automatizar o categorizar para trabajar con él, pero su uso ha mostrado ser de mucha valía en los negocios y en la industria. Un “usuario” describe actividades y responsabilidades de un grupo de individuos. Escribí ampliamente sobre eso en mi libro Asuntos de la Ingeniería de Software, cuando hacía referencia a los Casos de Uso de Ivar Jacobson y a un elemento fundamental de los casos de uso: el Actor. Y un usuario es precisamente eso, un actor. De hecho, decía en una de mis Lecturas Fundamentales, en noviembre de 2006 que “Debemos indagar por las costumbres del actor, su perfil, su experiencia, su conocimiento, el entorno donde se mueve”, nada diferente de lo que estoy diciendo hoy nuevamente, 16 años después.

Un usuario es un rol que se define a través de una tarea o acción concreta o un grupo de funciones con mucha afinidad, que son ejecutadas por personas durante el consumo de un producto o el uso de un sistema. Sin embargo, los usuarios no son algo tan simple como pueden parecer para el practicante ágil inexperto y aún para muchos expertos. Los usuarios pueden llegar a gozar de una ambigüedad tal que vuelven problemática la obtención de historias de usuario pequeñas y de valor. He revisado conjuntos de historias de usuario donde los usuarios exhiben incompatibilidades entre ellos o donde unos tienen sobrecarga de responsabilidades o donde se presenta cierta tensión entre unos usuarios y otros, además de algunas otras tramas inesperadas.

En particular, la ambigüedad es un aspecto destacado para el diseño de productos porque nos muestra una fotografía de la ausencia de precisión que una persona, sus colegas e incluso todos en la empresa pueden llegar a tener sobre los roles y sus responsabilidades. He dedicado más de dos décadas a estudiar este fenómeno y he tenido experiencia de primera mano cuando de usuarios o consumidores y sus responsabilidades o acciones se trata. Por ejemplo, he leído, debatido y ayudado a mejorar decenas de historias de usuario con usuarios como “cliente”, “visitante”, “abonado”, “cliente potencial”, “interesado” o “solicitante” que dicen muy poco o nada sobre el contexto de uso de la historia de usuario y que obstaculizan de distintas formas la división de una épica en historias más pequeñas y trabajables.

Una de las pocas formas que me ha funcionado para resolver todo esto es que todos los interesados en el producto, es decir, el equipo de producto y el equipo de trabajo en pleno vean al usuario en acción. Hay disponer de la logística necesaria, a lo Ojo del Gran Hermano, para que todas estas personas tengan la oportunidad de ver a sus potenciales usuarios o consumidores trabajando. ¿Qué hacen? ¿Cómo lo hacen? ¿Cuándo? ¿Con quién lo hacen? ¿Qué información intercambian unos con otros y quienes de estos también son usuarios y quienes no? ¿Cuáles son sus principales problemas o las dificultades más frecuentes que impactan su desempeño? ¿Cuáles son los criterios de éxito que tienen en cuenta en su accionar habitual?

Resolver estas cuestiones es de suma importancia antes de pensar en la solución que necesitan estos clientes o consumidores.

De vuelta a las historias de persona

Imagen de Gerd Altmann en Pixabay

Hola, soy Mabel, Gerente de Crédito Hipotecario. Quiero un informe de solicitudes de crédito para realizar proyección de aprovisionamiento y trabajar en las próximas campañas con el área de Marketing.

El informe debe ser diario y debo poder clasificarlo por tipo de crédito, pero también quiero tener un resumen por tipo de crédito y la tendencia respecto a los últimos 5 días.

También quiero clasificarlo por tipo de solicitante y tener un subtotal de lo solicitado por tipo de solicitante.

De manera predeterminada quiero ver el informe del día inmediatamente anterior, pero también quiero tener la posibilidad de ver el informe de una fecha anterior.

He estado usando una ligera variación de la forma Davies-Cohn para representar las historias de persona:

Como [usuario] Quiero [esta característica] Para [lograr este beneficio u objetivo]

que puede llegar a ser innecesariamente prolija y repetitiva, aunque muy fácil de entender y de usar en muchos entornos dada la gran difusión y documentación que ha tenido en las últimas dos décadas.

Pero bien podría usar muchas otras grafías para representar historias de usuario. Por ejemplo, puedo usar las historias de usuario estilo BDD, como en:

Registrar datos personales.

Dado que Ibeth, asesora de prensa de la alcaldía, solicitante de crédito de libre inversión, se mantiene muy ocupada en su día a día y tiene poco tiempo para hacer gestiones de manera presencial, ingresó los datos solicitados y existe al menos un dato sin diligenciar. Cuando ella intente enviar los datos, entonces recibirá un mensaje informándole de los datos sin diligenciar y estos datos aparecerán marcados en rojo y no se podrán almacenar los datos, aunque se le permitirá almacenar los datos de manera temporal si ella así lo prefiere.

En conclusión, hay tantas o más formas para representar historias de persona que para representar historias de usuario. Y una vez más, noten amigos lectores que uso el término “representar” como lo he hecho desde hace años, para alejarme y alejarlos de la limitante y problemática expresión “escribir historias de usuario”. Aquel es más abierto, indica que se pueden usar no solo palabras sino también figuras y simbología de distinto tipo que la mente y la imaginación sean capaces de retener. No sobra decir aquí que lo más importante de las historias de persona también es la conversación que se mantenga alrededor de cada una de ellas.

Las personas son instancias de los usuarios. Son ejemplos. Y los ejemplos te ayudan a encontrar inconsistencias en las historias y porque te delimitan un contexto. Pero sobre todo, los ejemplos son buenos porque te ayudan a iniciar conversaciones.

Y bueno, además del innegable beneficio del tamaño (sucinto, en el sentido de pequeño) de las historias de persona, de su contexto concreto e individualizado, otras ventajas de este instrumento derivado son los siguientes:

·       Ayudan a definir un mejor y más aproximado Producto Mínimo Viable, ya que, por naturaleza, estas historias de persona son mínimas y minimalistas, en el sentido de que son esenciales y eliminan o ayudan a eliminar lo que puede llegar a ser superfluo en el producto, es decir, nos ayudan a eliminar desperdicio, a elaborar el producto correcto desde el comienzo.

·       Las personas son, por naturaleza, colaborativas. Cada una usa o consume un producto de una manera diferente, pero entre todas colaboran para que el consumo o utilización del producto se maximice.

·       Ayudan a que quienes se encargan de exponer los productos a sus usuarios, es decir, aquellos que tienen la difícil pero fascinante labor de brindar la mejor experiencia de usuario y de cliente posible, tengan éxito, dado que las personas se conocen mejor, son más concretas, generan más empatía y puedes imaginarlas con una sonrisa cuando el producto las esté ayudando a lograr sus propios objetivos. Las personas nos permiten conectarnos emocionalmente con ellas, los usuarios abstractos quizás no.

·       Las historias de persona ayudan a iniciar y a mantener conversaciones más fluidas y verosímiles que las historias de usuario. Incluso nos permiten crear otras personas (personajes de la historia) para los eventos alternativos de la historia o para los procesos de manejo de excepciones en esta.

·       Las personas son más imaginables o creíbles o comprensibles que los usuarios porque tienen un rostro y un nombre y una identidad.

Llamado a la acción

Finalmente, te invito a que uses este modelo de historia, de historia de persona. Eso sí, cuéntame y cuéntanos cómo lo podemos extender y practicar mejor. Y no dejes de contactarme con cualquier inquietud que tengas respecto a este o a cualquiera otra inquietud sobre las historias, sean de usuario o de persona.