Declaración
P01 El progreso del usuario es la unidad de diseño
No diseñes lo que el usuario puede hacer. Diseña el progreso que necesita conseguir.
Tensión
Explicación
Un equipo puede entregar muchas funcionalidades y resolver poco. Cuando el trabajo se organiza por features o por perfiles genéricos, nadie tiene que explicar qué cambia para la persona después de usar el producto.
Profundizar: Tensión
Cuando el trabajo se organiza alrededor de features o perfiles genéricos, el equipo puede entregar mucho y resolver poco. Una Job Story obliga a explicar la causalidad: la circunstancia que activa la necesidad, la tensión que impulsa a actuar y la situación mejor que permitiría reconocer el progreso. Cuando el producto utiliza otra forma, esa misma causalidad debe conservarse en la medida en que resulte aplicable.
Significado
Explicación
Una capacidad importa solo cuando produce un cambio reconocible para alguien: pasar de una situación actual a un resultado buscado. Antes de diseñar una respuesta se describe cuándo surge la necesidad, qué la motiva y qué resultado permitiría reconocer el avance.
Profundizar: Significado
Una funcionalidad solo tiene sentido si ayuda a una persona a pasar de una situación actual a un resultado deseado. El fundamento de producto establece la razón autorizada del desarrollo. Jobs to Be Done puede definir el progreso en un nivel amplio y la Job Story lo vuelve operativo al describir cuándo surge la necesidad, qué motiva a la persona y qué resultado busca, sin anticipar la solución.
Consecuencia
Explicación
Cada decisión tiene que poder rastrearse hasta el fundamento de producto que la justifica. Un pedido de funcionalidad se reformula como circunstancia, motivación y resultado antes de discutir soluciones, y esa formulación admite más de una respuesta, incluida la de no construir.
Profundizar: Consecuencia
Identificar el fundamento de producto y la fuente autorizada que establece el alcance antes de diseñar una respuesta.
Cuando el fundamento se exprese mediante Job Stories, ubicarlas dentro del progreso o propósito de nivel superior que corresponda.
Formular cada Job Story como circunstancia, motivación y resultado, sin nombrar una pantalla, un componente ni una funcionalidad.
Respaldar las decisiones con conducta observada, obstáculo o ansiedad actual y evidencia que permita aceptar el resultado.
Ejemplo
Un pedido llega como «agregar un botón de exportar». Reformulado, dice: cuando alguien tiene que presentar sus datos a otra persona, necesita llevarlos fuera de la herramienta sin rehacer el trabajo. Esa formulación admite un botón, un enlace para compartir o un informe automático, y permite elegir la respuesta que menos carga agrega.
Contraejemplo
Describir un sitio como una colección de páginas o de efectos. La lista de lo que contiene no dice qué comprensión o capacidad obtiene quien lo recorre.
Señal de incumplimiento. Como estudiante quiero recibir pistas para resolver derivadas parece una historia útil, pero comienza por un rol y prescribe una función. No explica cuándo surge el bloqueo, qué necesita comprender la persona ni cómo reconocer que recuperó el avance.
Prueba de decisión
Una decisión está lista cuando estas preguntas tienen respuesta con evidencia, no con intuición.
¿Puede señalarse la fuente autorizada que justifica esta decisión y su relación con el alcance completo?
Cuando existe una Job Story, ¿la circunstancia es específica y observable o solo describe un rol?
¿La motivación y el resultado están respaldados por evidencia o fueron supuestos por el equipo?
¿La formulación admite varias soluciones posibles? Si ya prescribe una interfaz sin que ello sea una decisión de producto, debe revisarse.
Fuente
Núcleo del manifiesto v2.1, sección PRINCIPIO 1 · P01. Descargar el núcleo