wwas

Why-What-Acceptance 待办事项专家

概述

使用 Why-What-Acceptance（WWAS）格式创建待办事项。此格式可确保每项工作都与战略背景相关联，包含简洁的描述，作为“讨论内容的提醒”而非详细规范，并定义聚焦于可观察结果的高层级验收标准。

适用场景

• 创建待办事项——构建产品待办列表，且战略一致性至关重要时。
• 冲刺规划——完善即将进入冲刺的事项，且团队需要了解每项工作的意义时。
• 利益相关者沟通——高管或跨职能合作伙伴需要了解单项工作与业务目标的关联时。
• 路线图拆解——将路线图主题拆解为可执行的待办事项时。

不适用场景

• 需要以情境为驱动的需求时——请改用 job-stories/。
• 工作是没有战略背景的纯技术任务时（使用简单的任务描述）。
• 团队更喜欢传统的用户故事格式，且战略背景已广为理解时。

WWAS 格式

每个待办事项都包含三个部分：

1. Why（战略背景）

用 1-2 句话将这项工作与团队目标和业务战略联系起来。Why 要回答以下问题：

• 这项工作支持什么业务目标？（例如：“在第二季度将客户流失率降低 10%”）
• 为什么是现在？ 相较于其他工作，这项工作为何适时或重要？

Why 是最重要的部分。 它能避免团队构建与战略脱节的功能。如果你无法清楚阐述 Why，这项工作就不应列入待办列表。

好的 Why 示例：

• “我们的第二季度目标是将新用户的价值实现时间从 14 天缩短至 3 天。入门引导是最重要的杠杆——流失用户中有 60% 从未完成设置。”
• “企业客户表示，缺少 SSO 是他们不升级的首要原因。这直接支持我们在上半年实现 ARR 增长 200 万美元的营收扩张目标。”
• “上个季度，与账单问题相关的支持工单量增加了 40%。解决这些问题可以腾出 2 名支持全职员工，让他们专注于入门引导支持，从而助力我们的激活目标。”

不好的 Why 示例（请避免）：

• “因为客户提出了这个要求。”（没有战略背景）
• “这是最佳实践。”（与团队目标没有关联）
• “发布版本需要这个。”（循环论证）

2. What（描述）

简要描述需要构建或更改的内容。本部分是讨论内容的提醒，而非详细规范。

指南：

• 最多 1-2 段。
• 描述变更时，应足以提醒团队完善待办事项时讨论过的内容。
• 如果有设计文件，请附上链接。
• 不要编写实现细节、技术规范或分步说明。
• 团队阅读 What 后应能说：“对，我记得我们讨论过要构建这个。”

好的 What 示例：

• “添加一个引导式设置向导，引导新用户连接数据源、邀请团队成员并创建第一个仪表板。该向导应支持跳过和恢复操作。[设计：Figma 链接]”
• “将当前的账单常见问题页面替换为交互式故障排查工具，引导用户解决常见账单问题（付款失败、套餐变更、发票申请），并在无需提交支持工单的情况下解决 80% 的问题。”

不好的 What 示例（请避免）：

• 包含线框图、API 契约和数据库架构的多页规范（过于详细——这些内容应放在设计文档中）。
• “构建 SSO。”（过于含糊——团队无法回忆讨论过的内容）。

3. 验收标准

用于定义任务何时完成的高层级、可观察结果。这些不是详细的测试用例，而是任务获通过验收必须满足的最低条件。

指南：

• 每项至少包含 4 条验收标准。
• 每条标准都描述一个可观察的结果，而不是实现步骤。
• 关注用户或系统应该做什么，而不是它是如何构建的。
• 纳入最重要的边缘情况，但详尽的测试用例留给 QA。

优秀的验收标准示例：

1. 完成设置向导的新用户会在 3 天内激活（以创建第一个仪表板为衡量标准）。
2. 用户可以通过移动设备和桌面浏览器访问该向导。
3. 用户可以在任何步骤跳过向导，并在之后从离开处继续。
4. 跳过向导的用户可以从帮助菜单再次访问该向导。

不佳的验收标准示例（请避免）：

• API 返回状态码 200，并带有包含……的 JSON 负载（实现细节）
• React 组件通过所有单元测试（内部质量，不是用户结果）
• 可在 Chrome 上运行（过于笼统；应明确说明“可运行”是什么意思）

INVEST 质量关卡

WWAS 事项进入冲刺前，必须通过 INVEST 标准：

标准	问题	未通过时的处理方式
独立	这项任务能否不依赖其他任务而交付？	重新排列待办事项，或合并存在依赖关系的任务。
可协商	“做什么”是否允许讨论实现方法？	从“做什么”中删除对实现方式的规定。
有价值	“为什么”是否关联到实际业务目标？	重写“为什么”，或降低此任务的优先级。
可估算	团队能否有合理把握地估算工作量？	在“做什么”中补充背景信息，或开展预研。
小型	能否在一个冲刺内完成？	按结果、范围或用户群体拆分任务。
可测试	能否验证验收标准？	将标准重写为可观察且具体的描述。

事项模板

### [Title]

**Why:**
[1-2 sentences connecting to strategic objective and explaining why this matters now.]

**What:**
[1-2 paragraphs describing the change. Reminder of the discussion, not a specification.]

[Design: link or "TBD"]

**Acceptance Criteria:**

1. [ ] [Observable outcome]
2. [ ] [Observable outcome]
3. [ ] [Observable outcome]
4. [ ] [Observable outcome]

完整示例

引导式入门向导

为什么： 我们的 Q2 北极星目标是将用户实现价值所需的时间从 14 天缩短至 3 天。用户研究显示，流失用户中有 60% 从未完成初始设置，最常见的原因是“我不知道接下来该做什么”。引导式入门流程可以通过带领用户完成关键的初始步骤，直接解决这一问题。

做什么： 添加一个分步设置向导，在用户首次登录时显示，并引导新用户完成三个里程碑：连接数据源、邀请队友，以及创建第一个仪表板。向导应允许用户随时跳过（有些用户更愿意自行探索），如果用户未完成就离开，也应支持之后继续。每个步骤都应简要说明其重要性，并提供直接操作按钮。

[设计：figma.com/file/abc123]

验收标准：

1. 新用户首次登录时，向导会自动显示。
2. 用户可以在任何步骤跳过向导，并在之后从帮助菜单返回向导。
3. 每个里程碑（数据源、队友、仪表板）都可以独立完成，且不受顺序限制。
4. 用户完成全部三个里程碑后，会看到完成确认信息及建议的后续步骤。
5. 已完成设置的现有用户不会看到该向导。
6. 向导在桌面和移动浏览器上均可正常使用。

将 Why 与业务目标关联

WWAS 的优势在于明确的战略关联。使用此映射来撰写有力的 Why 陈述：

目标层级	目标示例	Why 表述方式
公司 OKR	将 ARR 提高至 $10M	“这有助于实现 $10M ARR 目标，因为……”
团队 OKR	将每月流失率降至 <5%	“我们团队的 Q2 流失率目标要求……”
产品主题	自助式引导	“作为自助式引导主题的一部分……”
客户反馈	排名前 3 的功能需求	“这是企业客户最常提出的功能需求，目前阻碍了 $500K 的销售管道……”
运营	减轻支持负担	“此问题每月产生 X 张支持工单，耗费 Y 小时……”

与其他技能集成

• 当你需要以情境为驱动、侧重用户背景而非战略一致性的故事时，请使用 job-stories/。
• 使用 brainstorm-okrs/ 定义 WWAS 条目所关联的目标。
• 使用 summarize-meeting/ 记录为 What 提供参考的细化会议讨论。
• 将 WWAS 条目交给 ../jira-expert/，以便使用结构化字段创建工单。

参考资料

• 有关格式对比、INVEST 深入介绍和细化最佳实践，请参阅 references/backlog-management-guide.md。
• 可直接使用的模板请参阅 assets/wwas_template.md。

故障排除

问题	可能原因	解决方案
“Why” 陈述过于笼统（“因为客户提出了要求”）	PM 未将请求与业务目标关联；战略背景不明确	要求每条 Why 都引用具体的 OKR、指标或业务案例；使用此技能中的目标层级映射表
“What” 描述过于含糊或过于详细	团队不清楚“讨论内容摘要”原则；未进行细化会议	编写 What 之前先召开细化会议；严格控制在 1-2 段；详情链接至设计文档
验收标准描述了实现步骤	工程团队编写标准时未从面向用户的角度出发	使用“用户会在意吗？”筛选；将每项标准改写为可观察的结果；删除 API/数据库引用
条目总是无法通过 INVEST-S（小）门槛	细化过程中范围不断扩大；团队不愿拆分条目	练习纵向切分：按用户群体、场景或结果拆分；目标是让条目能在 3-5 天内完成
待办事项逐渐失去与战略的关联	Why 陈述写好后从未重新审视；OKR 变更后未更新待办事项	每季度检查待办事项与战略的一致性；更新或废弃 Why 已不再与当前目标关联的条目
团队认为 WWAS 格式比简单的用户故事更繁琐	格式增加了阻力，却未体现价值；团队本身已有清晰的战略背景	对高优先级条目和功能使用 WWAS；Bug 和技术任务可采用更简单的格式；展示 Why 如何避免无效工作，以体现其价值
验收标准过少或过于浅显	团队匆忙进行细化；把验收标准当作打勾任务	每个条目至少设定 4 条验收标准；至少包含 1 条边缘案例标准和 1 条错误状态标准

成功标准

• 100% 的功能待办项都包含 Why 说明，并引用具体的业务目标或 OKR
• What 描述为 1-2 段，并在适用时链接到设计文档
• 每个事项至少有 4 条验收标准，重点关注可观察的用户结果
• 所有可进入冲刺的事项在进入冲刺前都通过完整的 INVEST 质量门槛
• 利益相关者无需额外背景信息，即可阅读任意待办项的 Why 并确认其与战略保持一致
• 与缺少战略背景的事项相比，采用 WWAS 格式编写的事项在冲刺评审中的拒绝率降低 30% 以上
• 至少每季度进行一次待办项一致性审查，并淘汰或更新过时事项

范围与限制

范围内： 按 Why-What-Acceptance 格式编写待办项，应用 INVEST 质量门槛，将工作项与战略目标关联，主持细化会议以产出 WWAS 事项，将现有待办项转换为 WWAS 格式，以及集成 Jira 以创建工单。

范围外： 由情境驱动的需求（转交给 job-stories/）、产品构思与机会发现（转交给 discovery/brainstorm-ideas/）、OKR 定义（转交给 execution/brainstorm-okrs/）、详细技术规格、冲刺规划与容量管理（转交给 ../scrum-master/）。

限制： 当组织已明确定义目标（OKR、北极星指标）时，WWAS 格式最能发挥价值。缺乏战略背景时，Why 会变成流于形式的练习，收益有限。该格式面向产品/功能工作——纯技术债务或基础设施事项可能不太适用。团队从用户故事转型时，可能需要 2-3 个冲刺才能熟练掌握该格式。

集成点

集成	方向	流转内容
job-stories/	互补	Job stories 补充情境背景（When）；WWAS 补充战略背景（Why）。两者结合使用可形成完整需求
summarize-meeting/	会议 -> WWAS	细化会议的讨论产出 What；决策产出验收标准
../jira-expert/	WWAS -> Jira	WWAS 事项转换为包含结构化描述字段的 Jira 工单
execution/brainstorm-okrs/	OKR -> WWAS	团队 OKR 提供 Why 说明所引用的战略目标
execution/prioritization-frameworks/	WWAS -> 优先级排序	使用 RICE 或其他框架为 WWAS 事项评分，以确定待办项顺序
discovery/brainstorm-ideas/	创意 -> WWAS	经过验证的创意拆解为 WWAS 待办项，并保留战略可追溯性