job-stories

工作故事专家

概述

使用 Jobs-to-Be-Done（JTBD）框架编写工作故事。与关注角色（“作为一名用户……”）的传统用户故事不同，工作故事关注情境、动机和期望结果。这种转变能让需求更贴合真实的用户情境，也更不容易预设用户的身份。

格式为 When [situation], I want to [motivation], so I can [outcome]. 去掉角色并描述情境很重要，因为同一个人在不同情境下有不同需求，处于相同情境的不同人会有共同需求，而且情境可观察、可测试，而角色只是抽象标签。

核心能力

• JTBD 探索画布 — 梳理功能性／社交性／情感性工作、痛点和收益，然后将每项映射到工作故事的组成部分。
• 故事编写 — 撰写具体、与解决方案无关且聚焦收益的情境、动机和结果。
• 质量把关 — 应用六项 INVEST 标准，并为每个故事编写 6-8 条以结果为导向的验收标准。
• 转换与引导 — 将传统用户故事转换为工作故事，并组织故事编写工作坊。

适用场景

• 功能定义 -- 需要结合用户情境说明要构建什么以及为什么时。
• 待办事项列表创建 -- 需要填充始终聚焦用户结果的工作项时。
• 需求研讨会 -- 与利益相关者协作，明确“完成”的定义时。
• 设计简报 -- 需要向设计师说明某项功能背后的情境和动机时。

不适用场景

• 需要结合业务背景制定战略性待办事项时——改用 wwas/。
• 团队已经熟悉用户故事格式，只需要轻量级故事时。
• 工作纯属技术性内容，没有直接面向用户的情境时。

先澄清

编写工作故事前，请确认以下信息。如果有任何信息未知或含糊不清，请先询问——不要自行假设：

• 情境／触发因素 — “When”决定了整个故事的基础；情境模糊会导致故事披着情境外衣，实则仍是角色描述
• 底层工作与动机 — “I want to”背后的功能性／社交性／情感性工作；缺少这一点，故事表达的会是解决方案，而非需求
• 期望结果／进展 — 用户希望通过“so I can”实现什么；这决定了以结果为导向的验收标准
• 用户研究来源 — 访谈／观察／支持数据，而非猜测；缺少依据时，情境可能是凭空编造的，也可能无法反映现实

停止规则：只询问对输出影响最大的 2-3 项。如果用户说“直接起草”，就继续，并在文档开头列出假设。

快速开始

When [situation], I want to [motivation], so I can [outcome].

1. 运行 JTBD 探索画布（或从研究中提取信息），找出工作－痛点－收益簇。
2. 为每个簇按 When/Want/So 格式编写一条工作故事。
3. 应用 INVEST 标准；拆分任何未通过“Small”或“Independent”测试的故事。
4. 为每个故事添加 6-8 条可观察、以结果为导向的验收标准。

参考资料

根据任务加载相应的参考资料 — 保持此文件精简，需要时再查阅详细内容：

• references/job-stories-playbook.md — 完整流程：JTBD 探索画布模板 + 画布到故事的映射、格式详情、写作质量表、INVEST 表、故事卡模板、验收标准指南、完整示例、故障排查和成功标准。编写或完善故事时阅读。
• references/jtbd-guide.md — JTBD 理论、工作故事与用户故事的比较、发现情境的技巧，以及故事拆分策略。了解此框架或决定使用哪种故事格式时阅读。
• references/red-flags.md — 工作故事中常见的问题、每个问题的错误/正确示例，以及识别方法。故事进入冲刺规划前阅读。
• assets/job_story_template.md — 可直接使用的工作故事卡模板。起草故事时使用。

范围与限制

范围内： 使用 JTBD「When/Want/So」格式编写工作故事，应用 INVEST 质量标准，编写以结果为导向的验收标准，将现有用户故事转换为工作故事，主持故事编写工作坊，将工作故事整合到 Jira 待办事项中。

范围外： 包含业务背景的战略待办事项（转交给 wwas/），产品创意构思和机会发现（转交给 discovery/brainstorm-ideas/），详细技术规格，UX 研究和用户访谈方法论。

限制： 当团队能够获取真实的用户研究（访谈、观察、支持数据）时，工作故事的效果最佳。缺少用户背景时，团队可能会凭空编造与实际情况不符的情境。对于没有直接用户情境的纯技术或基础设施工作，这种格式不太自然。工作故事与用户故事相辅相成——有些团队会根据不同工作类型使用这两种格式。

集成点

集成	方向	流转内容
wwas/	互补	WWAS 补充战略层面的「Why」背景；工作故事补充情境层面的「When」背景。按需同时使用
summarize-meeting/	会议 -> 故事	探索性对话和细化会议会产出情境，为工作故事提供依据
../jira-expert/	故事 -> Jira	完成的工作故事会成为包含结构化描述的 Jira 工单
discovery/brainstorm-ideas/	创意 -> 故事	经验证的产品创意会拆解为待办事项中的工作故事
execution/brainstorm-okrs/	OKR -> 故事	团队目标定义工作故事应关联的结果
execution/prioritization-frameworks/	故事 -> 优先级排序	使用 RICE 或其他框架对工作故事评分，以便进行冲刺规划