Reemplazar historia de usuario con historia de trabajo

Hola a todos Tradujo otro material interesante para los estudiantes del curso "Product Manager IT-projects" . Disfruta leyendo

---

Anteriormente, ya escribí sobre problemas con la historia del usuario ( historias de usuarios). En esos días, pensé que era mejor pedirle al equipo que discutiera los cambios propuestos al producto. La estrategia era buena si el equipo brindaba asistencia y el producto ya estaba maduro. Sin embargo, ahora estoy trabajando con un nuevo equipo y creando un producto desde cero. En este caso, tenemos una hoja en blanco y no nos resulta fácil llegar a un acuerdo en lo que respecta a la motivación, los eventos y las expectativas del cliente. Hoy todo ha cambiado. Encontré una excelente manera de utilizar la filosofía de Jobs To Be Done para definir la funcionalidad del producto. Hoy hablaremos de Job Stories.

De donde vino ella

Esta idea vino de muchachos muy inteligentes de Intercom . Esto es lo que dicen sobre este tema:

Llamamos a cada tarea de arquitectura Trabajo, nos enfocamos en la situación o evento que lo inicia, la motivación o el propósito, y obtenemos lo siguiente:

Cuando _____, quiero ______ a _______.

Por ejemplo, cuando se registra un nuevo cliente importante, quiero recibir alertas para poder comenzar una conversación con él.

En este artículo, no hago referencias a esta construcción en cuanto a Job Story, pero lo nombraré de tal manera que pueda referirme fácilmente a él en el futuro.

Hoy no pasaremos mucho tiempo explicando el concepto, solo hablaré sobre por qué me gusta y por qué es mejor que User Story.

Sobre el problema de la historia del usuario [nuevamente]

En general, el problema con las historias de usuarios es que contienen demasiados supuestos y poca causalidad. Cuando una tarea se configura en el formato de una historia de usuario ( Al igual que [tipo de usuario], quiero que [acción] obtenga [resultado] ), no hay lugar para la pregunta “¿por qué?”, De hecho, simplemente está limitado a una determinada secuencia fuera de contexto.

Así es como veo este formato:


Suposiciones y falta de comunicación entre una persona y su acción.

El primer problema es que comenzamos con una personalidad, que no es una buena idea , luego viene la acción, que, en nuestra opinión, debe tomarse para lograr el resultado deseado. Como ya señalé en la figura anterior, de hecho, la brecha es entre acción y personalidad.

Veamos algunas historias de usuarios existentes:


Un ejemplo de cómo escribir historias de usuarios

Mirando la tabla anterior, ¿podemos decir que los tipos de usuarios "moderador" y "evaluador" agregan color a la imagen general? En cualquier caso, esto agrega ambigüedad. Podemos ofrecer nuestra propia interpretación de estos conceptos y por qué el contexto se ve así.

Aquí, pruébalo. Elimine toda la parte "como [tipo de usuario]" y vea si realmente está perdiendo algo. Compare las siguientes declaraciones:

Como moderador, quiero crear un nuevo juego ingresando un nombre y una descripción opcional.

O si no:
Quiero crear un nuevo juego ingresando un nombre y una descripción opcional.
¿Se ha derrumbado el cielo?

Job Story: All About Context and Causation


Job Story Format

Basado en aún más experiencia y comentarios, ahora uso una explicación ligeramente diferente. Ahora lo veo de la siguiente manera .

¡Miremos la imagen nuevamente y finalmente comencemos!

Toda la información anterior es muy importante e informativa, ya que nos centramos en la causalidad. Cada Job Story debe contener la mayor cantidad de contexto posible y centrarse en la motivación, no solo en la implementación.

Después de trabajar con Job Story por un tiempo, cambié Motivaciones a Motivaciones y Fuerzas Actuantes. Eche un vistazo al artículo "5 consejos para escribir una historia de trabajo", donde este tema se aborda directamente. Puede obtener más información sobre las fuerzas actuantes en este podcast y este breve artículo .

Reescribamos algunos ejemplos de la tabla de Job Story anterior en Job Story, agregando motivación y contexto a cada uno.

Historia de usuario:
Como moderador, quiero crear un nuevo juego ingresando un nombre y una descripción opcional.
Historia de trabajo:
Cuando esté listo, para que los evaluadores apuesten por mi juego, quiero crear el juego en un formato que entiendan, para que los evaluadores puedan encontrar mi juego y entender que pueden apostar.

Historia de usuario:
Como tasador, quiero ver que se valore el artículo para saber a qué apuesto.
Historia de trabajo:
Cuando encuentro un artículo que quiero evaluar, quiero poder mirarlo para comprender que realmente necesito el artículo en el que estoy apostando.

Historia de usuario:
Como moderador, quiero seleccionar un elemento para evaluación o reevaluación, el equipo lo ve y puede evaluarlo.
Historia de trabajo:
Cuando un elemento no tiene calificación o no me gusta la calificación, deseo poder reiniciar el proceso de evaluación y notificar a todos para que el equipo sepa que un determinado tema debe ser calificado.

¿Qué pasa con múltiples roles y eventos?

Como recibo varias reseñas sobre Job Story y sigo trabajando con ellas, considero apropiado incluir algunas veces roles o personajes en la parte When _____ .

Productos de roles múltiples

Los roles y los caracteres son más útiles cuando el producto en sí tiene varios roles, por ejemplo, un producto de TI (administrador, gerente, participante) o un producto de mercado abierto (comprador, vendedor). La razón es que uno siempre debe entender de quién estamos hablando.

Tome eBay como ejemplo:

Cuando el comprador ya ha apostado por el producto, le preocupa que alguien haga una gran oferta y quiere recibir notificaciones para tener tiempo suficiente para evaluar y actualizar su propia oferta.

Roles y causalidad

A veces surgen situaciones cuando Job Story describe la interacción de varios roles a la vez, creando un escenario causal.

Y de nuevo, tome eBay como ejemplo:

Cuando el vendedor no está satisfecho con las ofertas recibidas y retira su producto del mercado, los compradores que ya han presentado ofertas desean recibir de inmediato una notificación de que el producto ha sido retirado de la subasta para que ya no sigan su dinámica de precios y busquen otro producto similar.

Usar eventos en lugar de roles

En ocasiones, puede surgir una situación cuando un evento afecta a todos los roles o grupos de personas: por ejemplo, debe recibir un recordatorio de contraseña. En este caso, no hay razón para introducir un rol específico, sino que debe dejarse a nivel de conceptos generales, por ejemplo, "cliente" o algo similar (pero no "usuario"):

Cuando un cliente usa su dispositivo móvil y olvida la contraseña, quiere tener una contraseña que pueda restaurarse fácilmente usando su dispositivo móvil para que el cliente pueda continuar iniciando sesión y acceder a su fuente de noticias.

¿Por qué no un usuario ? Un "usuario" suena muy sin vida e infructuoso, mientras que un "cliente" le recuerda que hay personas a las que debe brindar un servicio y que deben ser respetadas.

Definir motivación, no implementación

Las historias de trabajo son buenas porque nos hacen pensar en la motivación y el contexto, y también eliminan el énfasis de agregar cualquier implementación en particular. A menudo, debido al hecho de que las personas se centran en las preguntas "quién" y "cómo", olvidando por completo el "por qué". Cuando empiezas a pensar en el "por qué", tu mente se abre a formas creativas y originales para resolver el problema.

Aprende más

Su historia de trabajo necesita un momento de lucha (https://jtbd.info/your-job-story-needs-a-struggling-moment-c03de87c6026), 5 consejos para escribir una historia de trabajo.
También puede aprender sobre JTBD y Job Story de mi libro When Coffee and Kale Compet.
Puedes decirlo gratis en PDF o comprar una versión en papel aquí . Y aquí puedes pedirlo en línea.