Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Producto. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Producto. Mostrar todas las entradas

domingo, mayo 28, 2023

Inspirado: como crear productos de tecnología que tus clientes amen

Esta es la presentación de mi charla en el Lean Agile Summit, en Medellín este 27 de mayo de 2023. En ella brindé información sobre las prácticas y, sobre todo, los principios del enfoque exitoso de productos en empresas de tecnología y en otras con las que he trabajado a lo largo de mis 35 años de carrera profesional.

En particular, hablé de las Las causas fundamentales de los esfuerzos fallidos de producto, cómo nos pueden ayudar los enfoques Lean y Ágil en este proceso de Las 4D, descubrir, diseñar, desarrollar y distribuir productos que resuelvan la paradoja de las compañías que quieren tener éxito en el mundo convulsionado de hoy: quieren que sus clientes amen sus productos, pero no sabrán si esto es posible hasta tanto no pongan esos productos en manos de ellos.

También hablé de los principios de Lean Product Discovery y entrega frecuente y de mi tema favorito: personas. Detrás de cada gran producto hay una gran persona y, por extrapolación, un gran equipo. Principios de equipos de producto sólidos, sobre el líder de producto y el papel del liderazgo y, finalmente sobre la cultura sólida de producto que tienen las organizaciones brillantes. Por supuesto, fue tiempo para hablar de las Organizaciones B (Brillantes) y la triple restricción: estas son las empresas que no solo buscan el necesario y “sine qua non” beneficio financiero, sino también el beneficio social y ambiental. No podemos tener empresas sanas y, por consiguiente, productos sanos, en un planeta enfermo. Perentorio.

Al final, de mi libro Cultura ágil: ese oscuro objeto del deseo, mis tres leyes de la cultura:

1.    La ley del cambio

2.    La ley del lenguaje

3.    La ley del liderazgo cultural

No faltaron los consejos sobre cómo trabajar con equipos de diseño e ingeniería.

Fue un momento de compartir con amigos y colegas y un gran público que me acompañó atento durante la sesión. ¡Muchas gracias a todos!

Puedes descargar la presentación aquí: 👇

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 priorizar 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. Prioriza 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í:

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.

viernes, enero 21, 2022

Plantilla en Mural para el User Story Conversation Canvas


Las buenas historias de usuario estimulan, en el buen sentido, la conversación entre los involucrados (por ejemplo, Dueño de Producto y miembros del equipo). Además, las historias de usuario ven, o dejan ver, la funcionalidad desde la perspectiva del negocio, específicamente desde el Valor que la historia proporciona al negocio.

Como su nombre lo indica, este User Story Conversation Canvas es un medio de comunicación, un instrumento para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. En el fondo, es una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.

Con este lienzo cualquier persona involucrada, el Dueño de Producto, el equipo en pleno o solo un miembro de este, el Scrum Master, incluso un usuario, puede encontrar la ayuda que necesita para describir adecuadamente los aspectos más relevantes de una historia de usuario, desde las personas que están o se verán involucradas durante la definición, evolución, desarrollo y puesta en marcha de la historia, hasta el resultado esperado y las métricas asociadas a la historia, pasando por el contexto de la misma. Pero, sobre todo, podrá encontrar el soporte que necesita para preparar conversaciones fantásticas sobre los elementos que componen el producto.

Las sesiones de refinamiento, la planificación y la revisión son tres de los escenarios principales donde podemos usar este Lienzo para Conversar Sobre Historias de Usuario. Pero se puede usar en muchas otras circunstancias: el dueño de producto hablando con los usuarios y otros interesados, los miembros del equipo de desarrollo, para acordar y sincronizar el trabajo a realizar, el Scrum Master y el Dueño de Producto, en conversaciones alrededor del producto, del backlog, al aplicar patrones para dividir las historias, entre otros escenarios.

¡Cuando se trata de historias de usuario, el énfasis es en la Conversación!

Para saber más sobre Historias de Usuario, los criterios INVEST de las historias y otros aspectos no menos relevantes sobre el tema, puedes visitar mi serie de artículos “Historias de usuario altamente efectivas” en mi Gazafatonariohttp://bit.ly/lashistoriasdelucho.

Descarga el lienzo y la guía completa en alta definición aquí:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

Y para estos tiempos de trabajo virtual he desarrollado esta plantilla en Mural para que puedas trabajar de manera colaborativa con historias de usuario y con el lienzo para conversar sobre historias de usuario. Para ir a la plantilla, ve a la parte superior de la siguiente imagen y toca en "start from template" o en el icono de Mural.

domingo, julio 25, 2021

Qué hay de "usuario" en las historias de usuario



Estamos en la era de la hiperpersonalización de productos y servicios, cada usuario, cada consumidor quiere tener su propia experiencia de consumo, de uso, de aplicación y eso ocurre a cualquier nivel, en cualquier escenario.

Entonces nos toca proporcionar productos y servicios altamente direccionados, envolventes y únicos para nuestros usuarios. Y esto comienza con cada componente del producto haciendo resonancia con los demás, para que el producto en pleno pueda ser percibido como único por sus consumidores. Esta es la manera cómo construyes relaciones más fuertes con tus clientes y usuarios.

En mi primer curso de ingeniería de software en la universidad, hace ya varias décadas aprendí algo que todavía hoy sigue vigente, pero cuya práctica se extravió en pro del seguimiento rígido a los procesos y metodologías que vinieron después: “mira al usuario en acción”. Qué hace, cómo lo hace, con quién intercambia información, qué información intercambia, a quién beneficia, qué problemas resuelve, cuáles son sus principales vicisitudes, entre otras, son algunas de las cuestiones que debes indagar para conocerlo mejor.

El apellido “de usuario” no es gratuito en las historias de usuario. Para empezar, concentrarte primero en el usuario, antes de en cualquier otra cosa de su historia, te permitirá trabajar en una estrategia de producto hacia esa hiperpersonalización exigida por los consumidores actuales para que tengan su experiencia diferenciada.

Para lograrlo tienes que practicar y fomentar una cultura de “el cliente sentado en la mesa”, pero también de ir a verlo actuando en el gemba*, el suyo, para que puedas entender a fondo sus necesidades y los escenarios en los que se desenvuelve día tras día. Es de esta forma cómo podrás:

·       Conocer su problema, incluso el problema detrás del problema, la causa raíz;

·       Identificar sus canales de comunicación preferidos;

·       Emplear un lenguaje más apropiado a sus características;

·       Generar las hipótesis de cómo el producto puede favorecerlo en la resolución de problemas;

·       De qué forma se podría arruinar su experiencia como usuario o consumidor.

Entre muchos otros aspectos de su cotidianidad.

En mi User Story Conversation Canvas ya mencionaba que el primer paso en la construcción de productos grandiosos es identificar y entender a los consumidores y usuarios. Son actividades basadas en entrevistas, observación e investigación. Hay personas que son primarias al producto o a la historia de usuario en particular, otras son secundarias e incluso otras son suplementarias.

Figura 1: Un ejemplo de User Story Conversation Canvas para la historia de usuario “acceder primero a los libros de mi interés”. Clic en la figura para ampliar.

Entre las primeras encontramos a los usuarios finales de la historia de usuario o a los consumidores del producto. Encargados como un Product Owner o un Product Manager primero, y luego el equipo de trabajo, deben conocer muy bien el perfil de estas personas, los matices 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 para seres humanos. Quienes estamos comprometidos en esta tarea debemos sentir que conocemos al usuario, tener empatía con el usuario.

Las personas “secundarias” son quienes tienen algo que decir acerca de la historia de usuario (o del producto o servicio) pero que no lo usan. Pueden ser quienes lo adquieren, quienes imponen una restricción o una regulación, quienes harán la instalación o el mantenimiento, quienes venderán o distribuirán el producto a los usuarios, entre otras. Y las personas “suplementarias” son todas aquellas que de una u otra forma están o se sienten involucradas con la historia de usuario, como patrocinadores del proyecto, la dirección de la organización, representantes de los usuarios y otros interesados.

En resumen, algunos tipos de personas para tener en cuenta en y para la conversación son:

1.     Personas

2.     Usuarios o Consumidores finales

3.     Interesados

4.     Patrocinadores

5.     Equipo de desarrollo

6.     Otros (Legales, externos, etcétera)

7.     Equipo de soporte, Mercadeo, Distribución, Logística, etcétera.

Cuando observamos, entendemos y acordamos entre todos cómo las personas usan o usarán el producto, estaremos en capacidad de:

·      Planificar la accesibilidad al producto desde el principio

·      Desarrollar más rápidamente soluciones de accesibilidad

·      Tomar decisiones informadas entre diferentes opciones y evitar perder el tiempo adivinando o suponiendo o lanzando hipótesis que solo serán eso, hipótesis, hasta tanto el producto no esté en manos de quienes lo van a consumir o a usar

·      Limitar el tener que volver atrás y solucionar problemas, es decir, elaborar el producto correcto desde el principio, no generar desperdicio. Esto es más de pensamiento Lean.

·      Evitar tener que hacer concesiones más tarde porque esperamos demasiado para para conocer mejor al usuario y para abordar las características relevantes del producto.

·      Tener una mejor perspectiva sobre los estándares de uso, las pautas y otros requisitos, que es posible que deba cumplir ahora o más adelante, por ejemplo, si el producto será de uso gubernamental o debe cumplir con ciertas regulaciones.

Todo esto beneficia al equipo de trabajo, incluyendo Product Owner si lo hay, a la media y alta dirección de las organizaciones y a cualquier otro interesado en el desarrollo y puesta en marcha del producto.

User Personas

No en vano, Personas es el primer componente del lienzo para conversar sobre la historia de usuario. Ya desde antes existía este otro instrumento en el que podemos registrar lo que observemos y aprendamos del usuario en acción: se trata del User Persona o simplemente Persona.

Figura 2: un ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

En este, podemos registrar aspectos como los de la figura 2:

·      Objetivos del usuario, esto es, las metas que quiere alcanzar o que queremos que alcance en el mediano y largo plazo con el producto

·      Barreras o problemas actuales y posibles problemas futuros

·      Puntos de dolor o necesidades

·      Comportamientos o hábitos del usuario

Y no está demás conocer algunos detalles demográficos y hasta personales del usuario en cuestión, además de ciertos aspectos biográficos que ayuden a conocerlo y, sobre todo, a entenderlo mejor, a ser más empático con esa persona. Incluso, si es alguien conocido, un colaborador de la empresa, bien podemos traer su fotografía y usar sus datos reales, y hasta un lema o declaración de vida, su distintivo o consigna.

Figura 3: otro ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

Otros aspectos que bien podrían servir son:

·      Su experiencia ideal

·      La tecnología que usa o las fuentes de información a las que accede habitualmente

·      Por qué quiere usar nuestro producto, de hecho, este aspecto es crucial, deberíamos empezar por allí.

·      Respuestas a la pregunta: ¿qué arruinaría su experiencia usando el producto?

Recomendación final

No me andaré por las ramas: nunca intentes, ni lo sueñes siquiera, empezar a implementar o a desarrollar una historia de usuario de un producto si no conoces quien la usará y por qué. Perentorio.

Conclusión

Involucrar y conocer a los usuarios en las primerísimas etapas del descubrimiento del producto y más tarde, durante el propio desarrollo de este, da como resultado mejores productos para los consumidores, un desarrollo más eficiente y otros beneficios para los interesados y, por supuesto, para los mismos usuarios o clientes.

Y tú, qué haces para conocer a tu usuario. Por favor, déjamelo saber en el foro.

 

Quieres saber más

* Gemba |現場|' es un término japonés que significa "en el sitio de acción" o en la “escena del crimen". En negocios, Gemba se refiere al lugar donde se crea "valor"; en fabricación Gemba es el piso de la fábrica y en ventas es el área de ventas o el lugar donde el proveedor de servicios interactúa directamente con el cliente.1

Más sobre el User Story Canvas en:

El libro Historias de usuario: una visión pragmática:

https://luchosalazar.com/portfolio/historias-de-usuario-una-vision-pragmatica/

O en:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

Más sobre historias de usuario en:

bit.ly/lashistoriasdelucho

Y en octubre, una nueva edición del curso User Stories FoundationCertificatedonde te contaré de mis experiencias en este y otros asuntos sobre lo esencial de las historias de usuario.

Encuentras más información en:

https://luchosalazar.com/portfolio/nuevo-curso-historias-de-usuario/

¡Te espero!


Créditos

Imagen de la portada por Gerd Altmann en Pixabay.



domingo, noviembre 22, 2020

Ágiles 2020: o del menguado interés por el desarrollo de software en los eventos ágiles

Temas de interés en Ágiles 2020
Imagen tomada de las redes sociales.

Hace poco se llevó a cabo la más reciente edición de Ágiles Latinoamérica, Ágiles 2020. Iba a ser en Uruguay, quizás en Montevideo. Pero, por razones ampliamente conocidas o imaginadas por todos, se realizó de manera virtual. Como siempre, un evento que convoca a toda la Comunidad ágil de la región, incluso de Europa. Por ejemplo, en la charla que facilitara con mi gran amigo Jorge Abad sobre “de qué hablamos cuando hablamos de historias de usuario” había personas de España. La sorpresa es que allá eran las 2 de la madrugada del día siguiente.

A estas alturas del año, con quizás algunos miles de horas más “frente a la pantalla” que en años anteriores debido a la situación mundial, el entusiasmo de algunos no era el mismo. Sin embargo, hicimos lo posible por llegar a la cita y por cumplir con quienes apoyan el evento, con quienes lo organizaron con corazón y con pasión. A todos ellos, muchas gracias.

Pero no quiero referirme a la organización, a las vicisitudes del evento o a las sesiones, sino a su contenido. Específicamente a las categorías de contenido que hubo en el encuentro. El llamado de trabajos a presentar se hizo clasificado en cinco temas o “tracks”:

  • Producto y clientes
  • Liderazgo y cultura
  • Equipos y coaching
  • Software crafters
  • Organizaciones ágiles

Y durante la apertura se hizo una encuesta rápida sobre cuáles eran los intereses de los asistentes. Los resultados están en la imagen superior (lo siento, no pude conseguir una mejor resolución). El hecho es que desde ese mismo momento y aún después del evento llamó a muchos la atención de que el tema “técnico” no fuera del interés general (hablo de la categoría de Software crafters). El resultado muestra un interés de menos del 25 %, con una muestra representativa de 209 personas que seleccionaban sus preferencias de manera ordenada, de mayor a menor predilección. Y una primera cosa que debo aclarar es que esta es la preferencia de los asistentes, de hecho, así nos gusta hacer las cosas, con lo que les interesa a las personas “hoy”, no con lo que alguien más piensa o presume que le puede servir o concernir.

Pues bien, para aquellos que piensan y sienten que esto es un contrasentido, que se está perdiendo el interés por lo “técnico”, que las personas que tenemos responsabilidades o roles como Scrum Master, coaches o mentores ágiles, facilitadores o habilitadores, no estamos interesados o, peor aún, no sabemos de lo técnico, y que todo esto es una consecuencia de lo que ha venido pasando en los últimos no solo en el Ágiles Latinoamérica sino en otros eventos de esa misma índole, los invito a reflexionar un poco sobre lo siguiente:

Yo creo que tenemos que mirar el contexto. Desde mi punto de vista esto quiere decir que el pensamiento ágil se está llevando a todos los rincones de la organización y que ha salido de una vez por todas y para siempre de las áreas de tecnología, sobre todo de las de desarrollo de software.

Es que pensar que los Scrum Masters deben saber de software es decir que solo podemos usar Scrum para hacer desarrollo de software, cuando, de hecho, hace muchos años hemos pasado esa frontera. Scrum se usa hoy en muchos contextos fuera del desarrollo de software y fuera de lo “técnico” (considerando “técnico” el software), porque cada área tiene su “técnico”. Por ejemplo, si son equipos de Talento Humano, de Operaciones, de Logística, de Mercadeo, de Ventas, incluso de la alta gerencia de la empresa, los Scrum Masters no tienen porqué saber de desarrollo de software.

Si uso Scrum o cualquier otra práctica ágil para crear un hospital, para desarrollar un producto o servicio que no tenga nada que ver con software, para investigación y desarrollo, para enseñar (incluso para aprender), para una empresa de preparación de matrimonios, para abrir y gestionar una cafetería o un restaurante o un bar, para llevar a la cúspide a un equipo deportivo, en fin, para cualquier otra cosa que no sea software, entonces necesitamos otro tipo de agentes de cambio, de facilitadores o habilitadores ágiles, de Scrum Masters, de personas que hagan el trabajo a “lo ágil”.

Quizás eso es lo que quieren decir esos números. Ya abordaremos el tema de si, cuando se trata de desarrollo de software, los Scrum Masters deben saber de software o no, yo pienso que sí. Pero eso es algo muy distinto a lo que estamos hablando aquí.

Debemos entender de una vez por todas y para siempre que la agilidad y Scrum y Kanban y todas las demás prácticas que usamos hoy, no las usamos solo para hacer software. ¿Tú que piensas? Por favor, déjamelo saber en el foro.

¡Aunque sea cuales fueren tus pensamientos, espero verte en #Agiles2021 en Panamá!


Coletilla:

Hace algunos días se publicó la nueva versión de la guía de Scrum, asunto que generó mucho interés entre la comunidad de practicantes ágiles en todo el mundo. Sobre el tema que abordé en este artículo, tengo que referirme a la declaración inicial que hacen los autores de la guía y cocreadores de Scrum, Sutherland y Schwaber. Explícitamente dicen al inicio:

Nos sentimos honrados de ver que Scrum está siendo adoptado en muchos dominios que tienen un trabajo esencialmente complejo, más allá del desarrollo de productos de software donde Scrum tiene sus raíces”.

Es definitivo, hace mucho dejamos de usar Scrum solo para desarrollo de software y las áreas de la empresa fuera de Tecnología son muchas más. Quizás a ello se deba el interés creciente en otros temas ágiles.