呱呱 其他
写 Job Story、拆解 JTBD…
当需要把功能拆成关注用户情境、动机与结果的 Job Story，并为每条故事编写可验证的验收标准时使用。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 48/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 55/100 ×0.15
适用场景
写 Job Story、拆解 JTBD 通用
解决思路
- 收集输入：$PRODUCT（产品或系统名）、$FEATURE（要拆解成 job stories 的新功能）、$DESIGN（设计文件链接，如 Figma、Miro 等）、$CONTEXT（用户情境或 job 场景）。
- 识别触发需求的用户情境（situation）。
- 定义用户行为背后的动机（motivation）。
- 明确用户想要达成的结果（outcome）。
- 应用 JTBD 框架：关注要完成的任务（job），而不是用户角色（role）。
- 创建验收标准，用来验证目标结果是否已达成。
- 使用可观察、可衡量的语言描述情境、动机、结果与验收标准。
- 链接到设计稿或原型（mockups/prototypes）。
- 按故事模板输出：Title 为 [任务结果或结果]，Description 为 When [situation], I want to [motivation], so I can [outcome]，Design 为 [设计文件链接]。
- 为每条故事编写 Acceptance Criteria，至少覆盖：1）情境被正确识别；2）系统支持期望的动机；3）进度或反馈可见；4）结果被高效达成；5）边界情况被优雅处理；6）集成和通知正常工作。
- 最终交付为功能生成完整的一组 job stories。
- 确保每条 story 都遵循“When...I want...so I can”格式。
- 为每条 story 配置 6-8 条以结果为中心的验收标准。
- 让 stories 强调用户情境和动机，而非角色。
- 在 stories 中提供清晰的设计与原型链接。
适用边界 · 注意事项
- 不适用于必须围绕用户角色或职能进行拆分的需求，因为该方法刻意弱化角色，聚焦 job。
- 不适用于缺少用户情境与动机信息且无法补充调研的早期模糊需求。
- 不适用于需要技术实现细节或非功能规格的场景，它产出的是结果导向的 Job Story 与验收标准。