pm-skills 的 Job Stories 技能用When…I want to…so I can框架拆解用户情境与动机的 JTBD 式需求实践指南【免费下载链接】pm-skillsPM Skills Marketplace: 100 agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills本指南以 pm-skills 仓库中pm-execution插件的 job-stories 技能为核心系统讲解如何将一项新功能拆解为一组聚焦用户情境—动机—结果的 Job Stories并配以完整可用的故事模板、验收标准清单与实战示例。读完本文你将掌握 JTBDJobs-to-be-Done式需求表达的完整方法能够在 Claude Code、Claude Cowork 等 AI 编程助手中直接调用该技能或经/write-stories命令触发产出带详细验收标准的可交付需求条目并与用户故事User Stories、WWA 格式互为补充。一、Job Stories 是什么从角色转向情境Job Stories 是一种以用户正在试图完成的任务job为中心的需求表达方式其核心句式是When [situation], I want to [motivation], so I can [outcome]When [situation]触发需求的情境描述用户在什么场景、什么条件下产生了这个需求I want to [motivation]用户行为背后的动机即他此刻真正想做什么so I can [outcome]用户期望达成的结果即完成之后能带来什么收益。与传统的用户故事As a [role], I want to [action], so that [benefit]相比Job Stories 刻意弱化用户角色标签把重心放在**情境situation与动机motivation**上。这一点在技能 frontmatter 的 description 中写得非常明确适用于writing job stories, creating JTBD-style backlog items, or expressing user situations and motivations以及focusing on user context rather than roles见 pm-execution/skills/job-stories/SKILL.md。从仓库结构看job-stories 是 pm-execution 插件 16 个技能之一与 user-stories3C INVEST 的用户故事、wwasWhy-What-Acceptance 格式共同构成三种可选的 backlog 条目写法详见 pm-execution/README.md。二、技能定位与输入参数该技能以 YAML frontmatter 声明元信息遵循仓库统一规范技能的name必须与目录名一致description用于让 AI 在合适的对话时机自动加载该技能详见 CLAUDE.md 中的 Key Design Rules 与 Whats Visible Where 表格。技能调用时需要提供四个参数参数含义说明$PRODUCT产品名或系统名限定需求所属的产品上下文$FEATURE要拆解的新功能技能将以该功能为单位产出整组 Job Stories$DESIGN设计文件链接Figma、Miro 等设计稿链接用于关联视觉原型$CONTEXT用户情境或任务场景研究观察到的真实使用情境是情境优先写法的素材来源需要说明的是按 CLAUDE.md 的约定技能本身不需要占位符Skills need no placeholders它们直接从对话上下文中读取信息这里的参数是给使用者准备的内容清单实际调用时 AI 会从对话中提取相应信息。三、八步工作流程从情境到可验收的故事技能的 Step-by-Step Process 定义了从输入到输出的完整链路识别触发需求的用户情境Identify user situations——先回答用户在什么时刻需要这个功能定义动机Define motivations——澄清用户行为背后的真实意图澄清结果Clarify outcomes——明确用户最终想达成什么应用 JTBD 框架Apply JTBD framework——聚焦要完成的任务job而非用户角色role编写验收标准Create acceptance criteria——用可验证的标准确认结果达成使用可观察、可度量的语言Use observable, measurable language——避免含糊的主观描述关联设计稿或原型Link to design mockups or prototypes——让视觉参考与文字需求对应输出带详细验收标准的 Job StoriesOutput job stories with detailed acceptance criteria。这八步的内核可以概括为先情境、后动机、再结果最后用验收标准闭环。第 4 步是整个方法的分水岭传统需求先问谁要用Job Stories 先问在什么情况下、为什么。四、故事模板可直接套用的结构技能给出了标准的 Job Stories 输出模板**Title:** [Job outcome or result] **Description:** When [situation], I want to [motivation], so I can [outcome]. **Design:** [Link to design files] **Acceptance Criteria:** 1. [Situation is properly recognized] 2. [System enables the desired motivation] 3. [Progress or feedback is visible] 4. [Outcome is achieved efficiently] 5. [Edge cases are handled gracefully] 6. [Integration and notifications work]模板包含四个要素Title以任务结果命名而不是以功能名命名让整条故事一眼可读Description完整套用 When/I want to/so I can 三段式Design挂接设计文件链接Figma、Miro 等Acceptance Criteria默认给出 6 条通用验收维度覆盖情境识别、动机达成、进度反馈、效率、边界情况与集成通知。六条通用验收维度逐一解读情境被正确识别系统能准确判断触发条件对应模板中的[Situation is properly recognized]系统支持用户的动机功能实现确实服务于用户想做的事[System enables the desired motivation]进度或反馈可见用户在操作过程中能看到明确的进展或反馈[Progress or feedback is visible]结果高效达成用户能以合理的成本、步骤达成结果[Outcome is achieved efficiently]边界情况优雅处理异常输入、临界状态不会导致流程崩溃[Edge cases are handled gracefully]集成与通知正常与其他模块的联动、消息通知按预期工作[Integration and notifications work]。这六条是通用骨架实际使用时按功能特点细化成具体、可观察、可度量的验收点。五、完整示例精讲Track Weekly Snack Spending技能文档给出了一个完整的示例故事这里逐条拆解其写法Title:Track Weekly Snack SpendingDescription:When Im preparing my weekly allowance for snacks (situation), I want to quickly see how much Ive spent so far (motivation), so I can make sure I dont run out of money before the weekend (outcome).注意这个例子的精妙之处它没有说作为用户我想要一个记账功能而是先给出真实情境每周准备零食预算时再给出动机快速看到已花费金额最后落到结果确保周末前钱够用。角色被完全隐藏情境与动机成为主角——这正是 JTBD 式表达与角色式表达的本质差异。Design:[Figma link]Acceptance Criteria:显示消费汇总包含 Weekly Spending Overview 区块记录支出后实时更新进度指示器进度条展示周预算已用 0-100%剩余预算以醒目的颜色高亮详细消费日志按类别细分达到 80% 预算阈值时发送通知周四晚达到 90% 时发送周末专属提醒Weekend-Specific Reminder便捷访问与导航到明细页。这条示例演示了可观察、可度量的验收标准写法实时性Real-Time Update、量化阈值80%、90%、可视化组件进度条、高亮色、数据组织按类别细分、主动触达通知与提醒都有明确的可验证描述而不是体验要好性能要快这类无法测试的表述。示例中的 8 条验收标准也印证了技能在 Output Deliverables 中的要求每条故事给出 6-8 条面向结果的验收标准。六、输出交付物一组完整可进入 backlog 的故事技能要求最终产出如下交付物该功能的一组完整 Job Stories每条故事严格遵循 When…I want to…so I can 句式每条故事包含 6-8 条面向结果的验收标准故事整体突出用户情境与动机每条故事清晰关联设计稿与原型链接。这组交付物可以直接进入产品 backlog。在 pm-execution 插件中与之配套的后续动作包括用 pm-execution/skills/test-scenarios/SKILL.md 技能将验收标准转化为 QA 可直接执行的测试场景含测试目标、起始条件、用户角色、分步操作与预期结果用 pm-execution/skills/wwas/SKILL.md 为跨职能团队补充战略上下文。七、在 /write-stories 命令中的实际调用Job Stories 技能不是孤立存在的。pm-execution 插件提供/write-stories命令将功能拆解为三种格式用户故事 / Job Stories / WWA其中 Job Stories 分支正是调用本技能实现的见 pm-execution/commands/write-stories.md。命令用法/write-stories user Allow users to export reports as PDF and CSV /write-stories job Notification system for task deadlines /write-stories wwa Dark mode for the mobile app /write-stories [upload a PRD or feature spec] # 询问格式偏好 /write-stories # 询问功能与格式命令中关于 Job Stories 的约束命令文档明确了 Job Stories 分支的执行要点与技能本身互为印证格式When [situation], I want to [motivation], so I can [outcome]聚焦情境与上下文而非用户角色基于研究观察到的真实用户场景Ground in real user scenarios observed in research适合 JTBD 导向的团队Ideal for JTBD-oriented teams。命令层面的拆解纪律此外命令文档还给出了生成整个 backlog 的工程纪律同样适用于 Job Stories将功能拆成5-15 条独立故事小到能在一个 Sprint 内完成每条故事独立交付价值deliver user value on its own按依赖与优先级排序每条写 3-5 条验收标准标注需要设计输入或技术 spike 的故事一条故事 一个可独立部署的价值单元——如果它依赖另一条故事才可用就应合并验收标准应能让 QA 无需二次解读即可测试错误处理与边界情况应作为独立故事而不是塞在 happy path 故事的要点里。这些纪律解释了为什么技能的验收标准要写得可观察、可度量它们向下直接决定 QA 能否执行、Sprint 能否估算。八、与用户故事、WWA 的横向对比在 pm-execution 插件中三种格式针对不同团队偏好维度User Stories用户故事Job StoriesWWAWhy-What-Acceptance核心句式As a [role], I want to [action], so that [benefit]When [situation], I want to [motivation], so I can [outcome]Why [战略背景] → What [交付物] → Acceptance [标准]关注重心用户角色与行为情境、动机与结果战略意图与交付物适用场景大多数团队默认选择JTBD 导向团队需要业务上下文对齐的跨职能团队技能文件pm-execution/skills/user-stories/SKILL.mdpm-execution/skills/job-stories/SKILL.mdpm-execution/skills/wwas/SKILL.md用户故事技能强调 3CCard/Conversation/Confirmation与 INVESTIndependent, Negotiable, Valuable, Estimable, Small, TestableWWA 则把战略推理为什么做这件事作为显式组成部分。Job Stories 处于二者之间既有用户故事式的细粒度验收又把情境与动机放在句式的最前端。三种格式在/write-stories命令中可随时互相转换命令的 Next Steps 明确提供 convert to a different format (user stories ↔ job stories ↔ WWA)。九、仓库中的实现规范与校验支撑该技能在仓库中遵循一套统一的工程规范理解这些有助于在自建技能时复刻同样的质量Frontmatter 必需字段技能必须声明name与description且name必须与目录名一致——job-stories 技能的name: job-stories与其目录pm-execution/skills/job-stories/完全对应渐进式披露Progressive disclosurefrontmatter 保持精简始终加载详细内容放在 SKILL.md 正文触发时才加载——本文所讲解的模板、八步流程、示例都在正文中正体现了这一设计description 中的触发短语技能 description 中的 Use when... 短语就是给 AI 的自动加载触发条件也是 validate_plugins.py 中trigger_keywordstrigger / use when / use for所检查的内容见 validate_skill 函数中对 description 的质量检查统一校验仓库根目录的 validate_plugins.py 会检查每个技能是否包含 YAML frontmatter、必需字段、name 与目录名是否匹配、字数是否在合理区间低于 50 词会告警内容过少、高于 3000 词建议渐进式披露以及命令对同插件技能的内部引用是否存在validate_cross_references。这意味着 job-stories 技能与/write-stories命令之间的引用关系是被脚本显式校验的。十、实战使用建议综合技能文档与命令文档给出以下使用建议素材先于格式编写 Job Stories 前先积累研究中的真实用户情境访谈、观察、反馈避免凭想象编造情境角色退后情境上前写作时反复检查——如果句子删掉角色名依然成立且更聚焦说明方向正确验收标准坚持可观察、可度量把体验好改写成进度条显示已用 80% 时触发通知这类可验证描述边界情况单独成故事不要把一个 happy path 故事写成顺便处理异常的巨无霸保持一条故事一个价值单元若两条故事必须同时上线才有价值就合并善用命令串联在 Claude Code / Cowork 中可用/write-stories job 功能描述直接触发产出后可继续用/test-scenarios生成测试场景、用generate-data生成测试数据形成拆需求 → 验需求 → 测需求的闭环各命令详见 pm-execution/README.md。十一、延伸阅读原技能文档的 Further Reading 部分推荐了 Tony Ulwick 与 Sabeen Sattar 主讲的 Jobs-to-be-Done 大师课视频课程Masterclass可作为理解 JTBD 理论体系成果驱动创新、情境访谈法等的延伸学习资料同仓库的 pm-execution/skills/user-stories/SKILL.md 与 pm-execution/skills/wwas/SKILL.md 提供了另外两种 backlog 写法可与本文对照阅读若想了解技能与命令在仓库中的组织规范可阅读 CLAUDE.md 与根目录 README.md。【免费下载链接】pm-skillsPM Skills Marketplace: 100 agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考