job-stories

Job Stories - 创建以用户为中心的产品需求

技能概述

Job Stories 技能帮助产品团队使用 "When [情境]，I want to [动机]，so I can [结果]" 的格式创建结构化的用户需求，并附带详细的验收标准，让产品开发聚焦于真实的用户情境而非抽象的角色定义。

适用场景

1. 产品需求写作与 Backlog 管理

当产品经理需要将用户研究结果、客户反馈或业务目标转化为清晰的可执行需求时，Job Stories 提供了标准化的格式。通过明确用户情境、动机和期望结果，团队可以避免模糊的需求描述，创建更有针对性的产品 Backlog。特别适合敏捷开发和 Scrum 团队在 Sprint 规划时使用。

2. 用户研究转化为功能需求

UX 研究师和设计师完成用户访谈、可用性测试或田野调查后，常常面临如何将研究发现转化为工程团队可执行的需求的问题。Job Stories 框架直接连接用户研究的洞察与产品功能规划，确保每个功能都有明确的用户价值和情境支撑，避免"为了功能而功能"的开发陷阱。

3. 从传统用户故事迁移到 JTBD 方法

许多团队发现传统用户故事（"As a [角色]，I want [功能]..."）过于关注角色而非真实的使用情境，导致需求与用户实际需求脱节。Job Stories 基于 Jobs-to-be-Done 理论，帮助团队从"用户是谁"转向"用户在什么情境下想要完成什么任务"，提升需求的准确性和产品的用户价值。

核心功能

1. 结构化 Job Stories 生成

根据输入的产品名称、功能描述和用户情境，自动生成符合 "When-I want-So I can" 标准格式的 Job Stories。每个故事都包含清晰的标题、详细的描述以及 6-8 条可观测、可测量的验收标准，确保开发团队明确知道"做成什么样才算完成"。支持链接 Figma、Miro 等设计文件，让需求与设计保持同步。

2. 基于用户情境的需求分析

超越传统的角色定义，深入分析用户在特定情境下的真实动机和期望结果。通过识别触发需求的用户情境、定义驱动用户行为的潜在动机、明确用户想要实现的结果，帮助产品团队理解"为什么用户需要这个功能"，而不仅仅是"用户需要什么功能"。这种情境驱动的分析方法能够发现更深层次的用户需求和机会点。

3. 可执行的验收标准创建

为每个 Job Story 生成详细的验收标准，覆盖情境识别、系统行为、用户反馈、结果达成、边界处理和集成通知等维度。验收标准使用可观测、可测量的语言，避免模糊表述如"用户友好"、"响应快速"，而是明确具体的指标和行为，如"在 2 秒内加载完成"、"显示进度条"、"达到 80% 预算时发送通知"，确保测试和验收时有明确的判断依据。

常见问题

Job Stories 和传统用户故事有什么区别？

传统用户故事使用 "As a [角色]，I want [功能]，so that [价值]" 的格式，关注用户的角色身份和功能需求，容易导致需求与实际使用场景脱节。Job Stories 使用 "When [情境]，I want [动机]，so I can [结果]" 的格式，关注用户在特定情境下的真实动机和期望结果，基于 Jobs-to-be-Done 理论，更准确地反映用户的真实需求和行为驱动因素。例如，传统故事可能说"作为管理员，我想要导出数据"，而 Job Stories 则说"当我需要准备每周报告时（情境），我想要快速导出上周的数据（动机），以便在周五会议前完成分析（结果）"——后者包含了具体的使用情境和时间压力，更有助于设计符合用户真实工作流程的功能。

如何编写有效的 Job Stories 验收标准？

有效的验收标准应该是可观测、可测量的，避免模糊表述。从六个维度考虑：（1）情境识别：系统如何识别用户处于该情境？（2）系统行为：系统需要提供什么能力或支持？（3）用户反馈：用户如何知道操作正在处理？（4）结果达成：用户如何确认目标已实现？（5）边界处理：异常情况如何处理？（6）集成通知：与其他系统或通知如何配合？使用具体指标替代模糊描述，如"2秒内加载完成"而非"快速加载"，"显示进度条和剩余时间"而非"提供反馈"。参考技能中的示例："Track Weekly Snack Spending" 的验收标准包括"显示每周支出概览"、"进度条显示 0-100% 预算"、"达到 80% 时发送通知"等具体、可测量的标准。

Job Stories 适合哪些类型的产品开发？

Job Stories 特别适合以下场景：（1）B2B SaaS 产品：用户在具体工作情境下完成任务，如"当我准备季度报告时，我想要导出数据..."；（2）消费者应用：用户在生活场景中使用产品，如"当我通勤时，我想要离线阅读..."；（3）功能优化和迭代：明确用户在什么情境下遇到问题，如"当我网络不稳定时，我想要自动重试..."；（4）新功能探索：从用户研究中提炼情境和动机，如"当我需要快速协作时，我想要实时编辑..."。对于底层技术组件或纯内部系统（如数据库迁移脚本），Job Stories 可能不如传统技术规格文档适用。如果团队在需求评审时经常争论"这个功能是给谁用的"，或者开发完成后发现"用户场景和预期不符"，Job Stories 框架可以帮助提升需求质量和产品用户价值。