Buscar en Gazafatonario IT

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

martes, noviembre 28, 2023

Los artefactos Scrum: un enfoque unificado para el éxito del producto

 

Fuente: https://www.linkedin.com/feed/update/urn:li:activity:7132793258551726080/

He tenido el privilegio de guiar a numerosos equipos y empresas a través de implementaciones exitosas de Scrum. Una de las preguntas más comunes que encuentro es: "¿Cuál es el artefacto principal en Scrum: el Product Backlog, el Sprint Backlog o el Incremento?"

En una encuesta reciente en LinkedIn realizada por Scrum Inc., a manera de trivia, el 74 % de los encuestados, incluyéndome, indicaron que los tres artefactos son igualmente críticos para el éxito de Scrum. Esto se alinea con mi propia experiencia, donde he sido testigo de cómo cada artefacto desempeña un papel distinto pero complementario a la hora de impulsar el desarrollo de productos.

Pero qué pasa con quienes dieron respuestas diversas: el 13% estaba a favor del Product Backlog, el 6% optó por el Sprint Backlog y otro 6% creía que el Incremento era el más crucial. Este último parece tener sentido, después de todo, se trata del objeto final de la iniciativa de producto, ir creándolo en pequeñas partes, pero ni siquiera tuvo una mayoría favorecedora dentro de los artefactos individuales.

La ilusión de la separación: un nombre inapropiado

Si bien cada artefacto posee sus propios méritos disímiles, la verdadera magia de Scrum radica en su interacción sinérgica. El Product Backlog proporciona una visión general, el Sprint Backlog traduce esa visión en tareas procesables y el Increment manifiesta esas tareas en valor tangible.

Es definitivo: la noción de que un artefacto reina sobre los demás es un error. Es como afirmar que los cimientos, las paredes o el techo de una casa son más importantes que los demás. Cada componente juega un papel crucial en la integridad de la estructura. De manera similar, cada artefacto Scrum contribuye al éxito general del proceso de desarrollo del producto.

El Product Backlog: la brújula visionaria

El Product Backlog sirve como base de Scrum y representa la visión en constante evolución del producto. Es una lista ordenada de características, requisitos y mejoras que definen el estado deseado del producto. Continuamente refinado y actualizado, el Product Backlog guía los esfuerzos del equipo, asegurando que estén alineados con la dirección estratégica del producto.

El Sprint Backlog: la hoja de ruta táctica

El Sprint Backlog, derivado del Product Backlog, traduce la visión del producto en tareas procesables para un solo sprint. Es una lista dinámica de historias de usuario, errores, tareas y otros elementos de trabajo que el equipo se compromete a completar durante el sprint. El Sprint Backlog proporciona enfoque y claridad, lo que permite al equipo ofrecer valor tangible al final de cada sprint.

El Incremento: la expresión concreta del progreso

El Incremento, la culminación de cada sprint, representa el producto funcional que está potencialmente disponible para los clientes. Es la manifestación tangible de los esfuerzos del equipo, que muestra las capacidades en evolución del producto y permite que se proporcione retroalimentación temprana para una mejora continua. El Incremento sirve como un faro de progreso, motivando al equipo y validando la dirección del producto.

Adoptando la naturaleza entrelazada de Scrum

El verdadero dominio de Scrum radica en reconocer la interconexión de estos artefactos. No son entidades aisladas sino más bien elementos interdependientes que se entrelazan para formar el tejido del éxito de Scrum. Descuidar un artefacto inevitablemente afecta a los demás, lo que dificulta la capacidad del equipo para entregar valor de manera consistente.

Cuando aceptamos el significado colectivo de los artefactos Scrum, liberamos el verdadero potencial del framework. Normalmente, capacito a los equipos para que naveguen por las complejidades del desarrollo de productos con agilidad, enfoque y mejora continua. Juntos, el Product Backlog, el Sprint Backlog y el Increment forman la piedra angular del éxito de Scrum, lo que permite a los equipos ofrecer productos que deleitan a los clientes e impulsan el crecimiento y la innovación en las empresas.

En mi experiencia, los intentos de aislar un artefacto como el más crucial a menudo conducen a una comprensión incompleta del enfoque holístico de Scrum. Cada artefacto juega un papel indispensable y su integración armoniosa forma la base del éxito de las iniciativas Scrum.

Estos instrumentos no son meras herramientas; son el alma de Scrum, son las expresiones tangibles de una mentalidad ágil. Encarnan los principios de mejora continua, colaboración y adaptabilidad, transformando el proceso de desarrollo de productos en un viaje de experiencias y evolución continuas.

Entonces, la próxima vez que reflexiones sobre la importancia relativa de los artefactos Scrum, recuerda que no son entidades aisladas sino hilos interconectados que tejen el tapiz del éxito de Scrum.

viernes, agosto 04, 2023

El poder de las historias de usuario: sembrando narrativas para cosechar productos disruptivos

 

Esta es algo así como la transcripción de mi charla relámpago en Ágiles Colombia 2023 en Barranquilla. Y al final, está la charla para su descarga.

El poder de las historias de usuario:
sembrando narrativas para cosechar productos disruptivos

Las historias de usuario son un instrumento muy muy poderoso. Escuchen esto, queremos hacer las cosas “the Agile way”, y muchas veces nos preguntamos “¿eso cómo se hace?” “¿Eso con qué se come?”. Pues bien, las historias de usuario son ese utensilio que necesitamos para ello.

Veamos cómo en esta sesión relámpago…

Ninguna charla, mucho menos relámpago, sobre historias de usuario estaría completa si no comenzamos por aquí.

“Con historias y contando historias es como las culturas se hacen más fuertes y sobreviven”.

Con historias es como hemos llegado a este momento del tiempo, algunos científicos ya dicen que estamos en la era del Antropoceno, la nuestra. Imagen así el poder que tienen las historias si son ellas las que nos han permitido evolucionar durante los últimos 2 millones de años.

¡Y las historias de usuario son eso: historias!

Las historias de usuario son un protocolo de comunicación social, y la comunicación es condición requerida, indispensable, sine qua non dicen los intelectuales, para que haya verdadero trabajo colaborativo que, a su vez, es esencial para que la hagamos las cosas de la manera ágil.

Así es que lo más, con énfasis en “más”, importante de las historias de usuario son las conversaciones que se gestan alrededor de ellas. En su entorno.

Son conversaciones que se dan entre las personas involucradas, pero sobre todo comprometidas con el desarrollo de productos o la ejecución de actividades con enfoque Ágil y Lean.

Vamos a ver más en detalle esto porque es el mensaje principal de esta sesión.

Miren. Muchos todavía ven las historias de usuario, en el mejor de los casos, en este ámbito. Alguien tipo Product Manager/Product Owner “escribe” las historias de usuario y se las entrega a un equipo. En ocasiones hay una charla breve, muchas veces más relámpago que esta y ¡zas, ya está! Ahí les dejo sus historias.

Pero no, así no es. Es más bien de esta otra forma.

Esas conversaciones poderosas se dan, de un lado, entre esta persona tipo PM/PO y su entorno, incluyendo no solo a los usuarios o clientes finales, sino también a los interesados y más allá, gente del Mercado, de la Competencia, del Gobierno, de la Sociedad y del Medio Ambiente. Importantísimo estos dos últimos, volveremos a ello sobre el final de la charla.

Y de otro lado, entre esta PM/PO y el equipo de desarrollo de productos. Conversaciones abiertas, francas, en confianza, con transparencia.

Este es el ámbito donde las historias de usuario tienen mucho poder.

Pero eso no es todo… Las historias de usuario son poderosas si su práctica y el comportamiento que exhibimos quienes las usamos tiene como soporte la esencia de la agilidad. HU para colaborar, ya lo dijimos, pero también, HU para entregar en pequeño y frecuentemente, y una vez entregadas, para reflexionar con datos, no con supuestos. Y en el proceso, siempre siempre, mejora implacable.

Esto es absolutamente necesario, si no, son cualquier otra cosa menos historias de usuario a la usanza ágil.

Así que es definitivo. Si por lo menos ya las estamos usando, cambiemos nuestra forma de pensar acerca de las HU. Vamos de un mindset “especificacional” a uno conversacional. Las HU no son para escribir documentos repletos con características del producto. Para nada.

Dicho esto, empecemos también a pensar en las HU como experimentos. Como hipótesis que son realmente. Una HU siempre será una hipótesis hasta tanto el producto o el incremento de producto del que hace parte no está en manos del usuario final, del consumidor.

Así que empecemos a tratarlas como tal desde el principio.

Esto además ayuda a cambiar el mindset que necesitamos para tener éxito con ellas.

Y miren esto: ese apellido “de usuario” no está allí gratuitamente, por su linda cara como decimos. Las HU, o la práctica de estas, deben permitirnos conocer al usuario más que cualquier otra persona en nuestro entorno. ¿Quién es el usuario? ¿Qué hace?

¿Con quién lo hace? ¿Qué información intercambia? ¿Como lo hace? ¿Cuáles son sus dolencias y quejas? ¿Qué lo hará exitoso?

Responder a todas estas cuestiones solo se logra si el enfoque que usamos con HU está centrado en el usuario final y nadie más. En la persona.

De la misma manera, las historias de usuario deben permitirnos conocer más el producto, sus características esenciales, las que hacen feliz al consumidor, las importantes, las que lo dejan satisfecho, y las buenas bonitas, pero no baratas, las que lo dejan presuntuoso, más que cualquier otra persona a nuestro alrededor.

Ahora bien, Las HU poderosas, las que nos permiten crear productos disruptivos que nuestros clientes amen y que causen en ellos impactos a tal grado de modificar su modus vivendi, son pequeñas y aun así proporcionan valor a esos usuarios.

Pequeña es un término relativo, pero en general significa que se pueda construir en una iteración corta junto a otras HU.

También, las HU poderosas tienen unos criterios de aceptación bien definidos: tamaños, colores, matices, sabores, ángulos, vistas. Gozan de precisión, son colaborativos también. Quizás en una sesión hoy hablemos de mi modelo de las 7 C de los criterios de aceptación.

Y en el fondo, las HU poderosas se enfocan en el objetivo del usuario final. Son pequeños peldaños hacia el logro de una meta aún mayor: el objetivo del producto.

Aquí tenemos un ejemplo de una HU que no está basada en el objetivo, sino en la solución, un botón para exportar datos a un plano, ni más faltaba, se le tiene, pero esto no es del contexto de las HU, es algo de la solución.

En cambio, en este otro ejemplo, vemos con claridad una HU enfocada en el objetivo de un usuario final: elegir un método de envío, sin ninguna preferencia en particular ni ningún detalle que restrinja la solución final. Esta será un asunto del equipo de desarrollo del producto.

Y no podemos cerrar tampoco sin hablar de priorización por valor. Las HU poderosas se priorizan por algún aspecto de valor.

Técnicas como MoSCoW, WSJF, modelo de Kano, El costo de la demora y la Matriz de Impacto Motivado, conocida también como el modelo de Lucho.

Entre otras que se pueden usar para ordenar y reordenar un backlog constantemente.

¿Y todo esto para qué? Para hacer que germinen productos asombrosos. Aquí les dejamos un modelo simple pero efectivo para ello.

Ojo al paso 5: No es posible que construyamos productos asombrosos, que impacten a nuestros clientes, es una sociedad y en un planeta enfermos. Perentorio. Así que siempre pensemos en estos 2 factores además del financiero que es absolutamente necesario.

Esto era todo, mis amigos. Aquí 5 ideas claves de esta sesión relampagueante:

1.    Mindset conversacional para las HU,

2.    Colabora,

3.    Enfoque centrado en el usuario,

4.    Priorización eficaz con diferentes métodos, y

5.    desarrollo iterativo e incremental. ¡Lo nuestro!

Muchas gracias. Les dejo información de donde pueden conseguir muchísima más información, por si apenas llegan a nuestra sintonía. En bit.ly/lashistoriasdelucho y, por supuesto, el libro que se originó en esa página precisamente.

Puedes descargar la presentación aquí: 👇


miércoles, octubre 19, 2022

9 + 1 acciones que debes empezar a realizar para ser un Scrum Master extraordinario

Photo by Parabol on Unsplash

Nivel
: principiante. Para todo público.

Presentación

Como coach y consultor ágil, y antes Scrum Master, durante más de una década he acompañado y colaborado con muchos equipos en diferentes industrias. Hace poco publiqué con mi gran amigo Jorge Abad el libro Scrum:epítome de experiencias, que resume en 338 páginas muchos de los experimentos que realizamos y de las lecciones que aprendimos durante todo este tiempo. Espero que el libro llegue a tus manos en algún momento. Mientras tanto, en mi Gazafatonario seguiré compartiendo más de todo esto, incluyendo algunas de las cosas que me han sorprendido en el camino.

1.    Entender el rol y las responsabilidades de Scrum Master

Como Scrum Master, eres responsable del proceso Scrum. También eres responsable de brindar retroalimentación de calidad al equipo y eliminar impedimentos.

Una forma efectiva de pensar en esto es que tu trabajo como Scrum Master no es solo asegurarse de que todos estén haciendo su propio trabajo correctamente, sino también asegurarse de que sepan cómo hacerlo mejor, para que ya no te necesiten. O, al menos, dar esa impresión. En la práctica, un equipo, por muy maduro que sea, siempre necesitará de un Scrum Master extraordinario.

2.   El enfoque principal del Scrum Master es el empoderamiento del equipo, no la gestión de proyectos

     No eres un director de proyectos. Un Scrum Master no es un administrador de proyectos; eres el coach del equipo. Como tal, tu enfoque principal debe ser ayudar al equipo a ser autoorganizado y multifuncional, eliminando los impedimentos para el progreso (en lugar de resolverlos todos).

     Tu trabajo no es solo desarrollo. De hecho, si bien la organización para la que trabajas puede tener un rol de Product Owner establecido que administra los requisitos y libera valor en cada Sprint, no solo lo estarás acompañando durante toda la gesta como Scrum Master. Además, pasarás la mayor parte de tu tiempo trabajando directamente con todos los miembros del equipo de trabajo, empoderándolos, para ayudarlos a comprender lo que significa hacer el trabajo con un marco de desarrollo serializado de productos como Scrum (y por qué es importante) para que se sientan capacitados para tomar decisiones sobre la mejor manera de lograr los objetivos propuestos.

     Necesitas que todos participen para que este enfoque funcione bien para todos los involucrados. Hay muchos beneficios asociados con mantener equipos lo suficientemente pequeños, por ejemplo, que todos sus miembros puedan tener cierta superposición en las habilidades propias de cada uno, es decir, que el equipo se convierta en uno multifuncional. También, cuando alguien que carece de experiencia necesita la ayuda de otra persona pero no sabe qué preguntas debe hacer primero antes de iniciar cualquier tipo de comunicación entre ellos, la sinergia existente en un equipo pequeño hace que esa comunicación comience a ser más fluida. Además, un Scrum Master extraordinario puede ayudar a que las personas del equipo se relacionen mejor entre sí sin necesidad de forzar algún tipo de conversación artificial.

3.   El Scrum Master guía al equipo para que se organice a sí mismo

Eres el verdadero líder del equipo, el guardián del proceso y el que ayuda a tu equipo a autoorganizarse y autogestionarse. También facilitas la colaboración en equipo, la comunicación clara y el progreso hacia los objetivos del sprint con la ayuda de los artefactos de Scrum.

El Scrum Master sirve como coach para el equipo al garantizar que sus miembros trabajen de acuerdo con la teoría Scrum (por ejemplo, sin multitarea), ayudándolos a prevenir y resolver impedimentos (por ejemplo, deuda técnica) y manteniéndolos enfocados en sus objetivos a través de revisiones periódicas y retrospectivas.

4.   El trabajo del Scrum Master es eliminar los impedimentos, no resolverlos todos

Un Scrum Master extraordinario es un solucionador de problemas y, en general, es una persona analítica. Los mejores pueden ayudar a los equipos a eliminar sus propios impedimentos y a autoorganizarse para que puedan proporcionar valor continuamente. Es importante no confundir el rol del Scrum Master con el de un gerente de proyecto, quien es responsable del resultado de un proyecto en lugar de simplemente facilitarlo. Un Scrum Master extraordinario debe ser hábil para eliminar impedimentos, ¡no para resolverlos todos!

5.   El Scrum Master entiende que no existe tal cosa como "la mejor manera"

El Scrum Master entiende que no existe tal cosa como "la mejor manera". El proceso debe adaptarse al equipo y su entorno. Para adaptarse, él o ella debe ser capaz de aprender cosas nuevas.

Esto significa que no todos los Scrum Masters son iguales. Algunos son mejores en ciertas cosas que en otras. ¡Está bien! Es parte de lo que nos hace a todos tazas de café especiales.

En cualquier caso, el Scrum Master se aleja y aleja a su equipo de quienes vienen con “la mejor manera de hacer esto es…”.

6.   El Scrum Master entiende que cada organización es diferente y necesita un enfoque diferente

El Scrum Master entiende que cada organización es diferente y, por lo tanto, requiere un enfoque distinto. Por ejemplo, si una organización es muy jerárquica y burocrática, la Scrum Master deberá trabajar con la gerencia de la organización para hacerla más ágil. Esto significa ayudarlos a comprender cómo pueden ser más efectivos mediante la adopción de prácticas de Scrum y otras prácticas ágiles, como la eliminación de impedimentos y la mejora de procesos para que el equipo pueda organizarse por sí mismo. Si la organización no tiene demasiadas reglas o regulaciones, entonces podría ser más fácil para el Equipo Scrum autoorganizarse sin necesidad de mucha ayuda de su Scrum Master.

7.   El Scrum Master entiende la importancia de sumergirse en la cultura Ágil a través de aprendizaje, capacitación y experimentación

La cultura ágil es una mentalidad, no solo un conjunto de procesos. Es importante comprender que la cultura ágil no es algo que se pueda aprender en un día. Se necesita tiempo, capacitación y experimentación para convertirse en parte de esta nueva forma de trabajar.

El Scrum Master entiende que la cultura ágil se trata de la mejora continua y no de seguir reglas.

8.   El Scrum Master sabe adaptarse rápidamente a las nuevas circunstancias y cambios en el entorno

El Scrum Master sabe que es un líder servicial y se esfuerza constantemente por crear un entorno en el que el equipo pueda volverse más productivo. El Scrum Master entiende que el éxito depende de tener un equipo motivado y de alto rendimiento, por lo que es responsable de eliminar todo lo que se interponga en el camino del éxito de su equipo.

El papel de un líder servicial es permitir que otros crezcan y tengan éxito. Cuando tu trabajo como Scrum Master está bien hecho, será difícil para ti identificar exactamente cuál ha sido tu contribución porque has estado trabajando entre bastidores para asegurarte de que todos los demás tengan lo que necesitan para hacer su trabajo de manera efectiva.

Como parte de esta dedicación para capacitar a otros, es importante no solo saber cómo, sino también cuándo es el momento de recibir alguna retroalimentación u orientación de asesoramiento o tutoría relacionados con el cumplimiento de los principios o procesos ágiles (también conocido como facilitación).

9.   El Scrum Master entiende que el objetivo de cualquier equipo maduro debe ser la mejora continua

     Como Scrum Master, debes comprender que el objetivo de cualquier equipo maduro debe ser la mejora continua. El marco de trabajo Scrum está diseñado para ayudar a las organizaciones a lograr este objetivo al alentar a las personas y los equipos a mejorar constantemente sus prácticas de trabajo a través de ciclos de retroalimentación rápidos y cambios pequeños e incrementales.

     Este concepto se llama Kaizen en la comunidad Lean y Mejora Continua en Ágil. También se conoce como "aprendizaje organizacional" en algunos círculos, porque requiere lecciones regulares de experiencias pasadas, tanto buenas como malas, para que puedan aplicarse para mejorar los resultados futuros o evitar problemas similares en el futuro (en lugar de simplemente arreglar las cosas cuando se rompen).

9 + 1. No tengas miedo de salir de tu zona. ¡Una nueva aventura podría estar a la vuelta de la esquina!

Entonces, eres un Scrum Master y asistes al curso de capacitación para obtener la tan anhelada certificación. Aprendes muchas cosas nuevas sobre Scrum y cómo puedes ayudar a las organizaciones de todo el mundo. El entrenamiento es divertido, pero notas que falta una cosa en tu vida: ¡emoción!

Empiezas a pensar en cómo podrías conseguir algo de aventura en tu vida. ¿Irás a una aventura al aire libre con amigos o familiares y les enseñarás cómo hacer cosas como escalar rocas, saltar de un puente elevado o navegar en kayak? Esto se sentirá como estar de vacaciones porque estás fuera del trabajo por un par de días, pero luego, cuando regreses a casa, ¡podrías tener más energía que antes! ¿Y si esta nueva forma de vivir puede traer alegría a tu vida? ¡Nunca se sabe hasta que se prueba!

Estoy seguro de que sabes que esto es lo que quieres hacer, pero tal vez haya cosas que te detengan. Tal vez has estado trabajando en ti mismo durante años y parece que no puedes progresar. O tal vez eres nuevo en todo esto de "ser un gran líder ágil" y no sabes por dónde empezar. 

Seamos realistas por un segundo: nadie es perfecto. Y el perfeccionismo puede ser paralizante cuando se trata de hacer cualquier cosa, especialmente cuando se trata de ser alguien extraordinario como un Scrum Master o un líder ágil que está listo para asumir cualquier desafío que se presente a continuación.

Inténtalo. Todo gran triunfo empieza con un primer paso. Y dentro de algunas semanas, incluso meses, habrás querido dar ese primer paso hoy mismo.

Conclusión

El Scrum Master es un rol esencial en cualquier organización moderna. El trabajo del Scrum Master es guiar y acompañar a los equipos para que puedan entregar sus productos de manera más efectiva, eficiente y con alta calidad. Eres un líder y los mejores líderes siempre están aprendiendo. Saben que la única forma de liderar verdaderamente es refinando constantemente sus habilidades y ven a su equipo como una plataforma para el crecimiento y el desarrollo.

Como líder, siempre debes trabajar para mejorarte a ti mismo. Nunca debes quedarte quieto y pensar que lo tienes todo resuelto. Siempre habrá más para aprender, así que aprovecha cada oportunidad para ampliar tu base de conocimientos leyendo libros sobre liderazgo, asistiendo a conferencias y seminarios, o realizando programas de capacitación diseñados específicamente para tu función como líder ágil.

Como el próximo curso que facilitaré con Jorge Abad a partir de este 22 de octubre. Encuentras toda la información en:

https://luchosalazar.com/portfolio/nuevo-curso-scrum-master/

También te invito a descargar este póster en alta definición con diez cualidades que te pueden ayudar a convertirte en la mejor versión de Scrum Master que puedas llegar a ser:

http://www.gazafatonarioit.com/2017/05/cualidades-de-un-scrum-master.html





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.



miércoles, mayo 05, 2021

Buenas y “malas” historias de usuario


Los criterios INVEST* no son los únicos que hacen a una historia de usuario una “buena” historia de usuario. Pero son un buen comienzo. Además, decir o pensar que una historia de usuario es buena o mala quizás no sea la mejor idea. En cualquier caso, lo más importante es si la historia está preparada o no para implementarse o desarrollarse. Si no lo está, entonces hace falta conversación, ojalá cara a cara, para ponerla a punto: conversación entre los usuarios o interesados clave y un dueño de producto o gerente de producto; y también, conversación entre estos y el equipo de personas que finalmente hará el trabajo de implementación de esas historias.

Nota mental: en realidad, lo más más importante de la historia de usuario es que genere Valor, en cualquiera de sus modos, por ejemplo: más ingresos, mayor felicidad a los usuarios o consumidores, menores gastos, mejora en la marca organizacional, más clientes, mayor aprendizaje, entre muchas otras formas de valor.

Y como son un buen comienzo, veamos algunos ejemplos de cómo se cumplen o no esos criterios en las historias de usuario. Usaremos la forma Connextra para escribir las historias de usuario, pero recordemos que hay muchísimas formas, cuando no infinitas, de representar las historias. Los ejemplos corresponden a una plataforma de compra y venta en línea de productos y en algunos de ellos obviaré la parte del “para” qué se quiere la historia, solo con la intención de concentrarnos en lo fundamental.

Independiente

En la medida de lo posible, las historias se pueden implementar en cualquier orden.

La historia del Comprador no se podrá implementar hasta tanto no estén establecidas todas las condiciones de venta que el Vendedor requiera. Y esta historia solo es verificable en cuanto a instituir y preservar las condiciones de venta, pero no en cuanto a hacerlas cumplir por el comprador. Las cosas así, es posible eliminar la dependencia, dividiendo las historias de usuario usando como criterio las distintas condiciones de venta del producto, desde el punto de vista del Vendedor, además de combinar el establecimiento de los términos de venta con algunas condiciones para hacerlos cumplir en cada historia.

Negociable

Se deja abierta la forma de lograr el objetivo, sin sugerencia de implementación.


La historia de usuario original no deja ningún margen al diálogo en cuanto a las posibilidades de implementación de las formas de pago, es la indicada y nada más. En cambio, la historia derivada abre las posibilidades y permitirá que se tomen las mejores decisiones para su confección mediante conversaciones sucesivas.

Valiosa para el usuario

Algo que el usuario realmente pueda usar, no solo una tarea técnica.

Hasta tanto las imágenes del producto puedan usarse, no tienen ningún valor y, por consiguiente, la historia de usuario en sí carece de trascendencia, de peso (alias de valor). No proporciona ningún beneficio. El impacto de su contraparte, sin embargo, es a todas luces evidente. El valor de la historia salta a la vista.

Estimable

No se requiere investigación, bien entendida.


¿Cuántos informes son? ¿Cuáles? ¿Con qué información o datos? ¿En qué momento se producirán? Estas y algunas otras cuestiones sin respuesta aparente no permitirán que la historia de usuario pueda estimarse en complejidad o tamaño, mucho menos en tiempo. La historia contigua, en cambio, goza de mayor precisión: es una única lista, un informe solo de productos entregados; estas condiciones reducen las posibilidades y aumentan los detalles necesarios para realizar una predicción más o menos confiable sobre cuándo podrá estar terminada.

Pequeña

Se puede pasar del concepto a estar preparada para su lanzamiento en un par de semanas y preferiblemente dentro de un par de días.


Como con el caso de la historia no estimable, no conocemos la cantidad ni la calidad de los informes a los que se refiere esta historia. El informe resumido por categoría de producto, por su parte, es algo mucho más acotado: es uno solo, su carácter de “resumido” ya deja entrever que los datos que incluirá son pocos. Tiene visos de ser una historia que se pueda implementar en dos o tres días de una iteración.

Comprobable

Es posible medir algo específico para verificar que la historia está terminada.


¿Qué si
gnifica “rápidas”? ¿45 segundos? ¿27? ¿Un milisegundo? No hay forma de verificarlo, no será posible probar los términos de esta historia, ni siquiera con los mejores robots de prueba existentes hoy. En general, “rápido” es una expresión ambigua, imprecisa. Si decimos “2 segundos”, la ambigüedad desaparece de inmediato. Unos pocos casos de prueba nos permitirán comprobar la completitud de la historia.

 

¿Quieres saber más sobre historias de usuario?

En octubre estaré facilitando un curso donde 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!