需求分析与 PRD
需求分析把「用户想要什么」翻译成「团队要做什么」，PRD 则把这份共识写下来、能验收、可追溯。好 PRD 不是越长越好，而是让研发、设计、测试与运营看完后对「做什么、为什么、怎么算完成」没有分歧。
需求分析的完整链路
用户声音 → 需求卡 → 用户故事 → 验收标准 → PRD → 评审 → 排期 → 变更管理用户声音的收集见用户研究与需求洞察。需求分析阶段要回答三个问题：
用户故事：把需求说成人话
标准格式
作为 〔角色〕，我想要 〔能力〕，以便 〔价值/目标〕。
示例：
- 作为团队负责人，我想要自动汇总各成员进度，以便省下每周手工整理的时间并在例会前得到汇报视图。
高质量用户故事的三条标准（INVEST 的精简版）
| 标准 | 含义 | 反例 |
|---|---|---|
| 独立（Independent） | 可独立开发与验收，避免依赖纠缠 | 「做一个汇总并顺便改掉统计口径」 |
| 可协商（Negotiable） | 写意图不写死方案，实现细节留白 | 「提供一个导出 Excel 的按钮」（直接锁死方案） |
| 可验收（Testable） | 有明确的完成定义 | 「体验更流畅」（无法验收） |
从「一句话」到「可排期」：Epic → Story → Task
| 层级 | 粒度 | 示例 |
|---|---|---|
| Epic（主题） | 大目标，跨多个迭代 | 团队协作效率提升 |
| Story（故事） | 一个可交付价值，1 个迭代内可完成 | 进度自动汇总 |
| Task（任务） | 研发拆分的最小工作单元 | 接入 IM 机器人定时推送 |
拆分 Story 时若它仍要「1 周以上」，继续拆：一个 Story 应能在 2~3 天内做完并验收。
验收标准：让「完成」可判定
推荐的格式：Given-When-Then
Given（给定前置条件）→ When（当执行动作）→ Then（那么期望结果）
示例（进度自动汇总）：
- Given 团队成员已更新各自状态，且当前时间到达每日 17:00；
- When 系统触发自动汇总；
- Then 负责人收到汇总通知，包含各成员最新状态与未更新成员名单。
验收标准要覆盖的维度
- 正常路径：主流程走通；
- 边界：空数据、超长文本、首次使用；
- 异常：失败、超时、权限不足、重复提交；
- 一致性：与历史数据、其他页面口径一致（口径问题见数据分析的指标口径互链）。
PRD 写作
最小可用结构
markdown
# PRD：进度自动汇总
## 1. 背景与目标
- 背景：手工汇总耗时（调研证据一句话）
- 目标与度量：把「每周手工汇总时长」降为 0；北极星指标见[指标页](./metrics-growth)
- 非目标：不做跨团队权限体系（本期范围外）
## 2. 用户与场景
- 目标用户：团队负责人画像
- 核心场景：周一例会前生成汇报视图
## 3. 范围
- 本期包含 / 不包含（清单）
## 4. 功能需求
### 4.1 自动汇总
- 触发规则：每日 17:00
- 数据来源：成员状态表
### 4.2 通知
- 渠道 / 频率 / 失败重试
## 5. 用户故事与验收标准（节选）
| 故事 | 验收标准（Given-When-Then） |
| --- | --- |
| … | … |
## 6. 交互与视觉要求
- 入口位置 / 关键状态 / 与[设计方向](../design/)对齐的交互规范（链接到设计稿）
## 7. 数据与埋点
- 需要埋的点（进入率 / 完成率），与[数据分析](../data/)对齐口径
## 8. 兼容与边界
- 浏览器/端、权限、异常降级
## 9. 上线计划与回滚
- 灰度范围、上线窗口、回滚方案
## 10. 风险与开放问题
- 依赖 / 待确认问题清单PRD 写作要点
| 要点 | 说明 | 反例 |
|---|---|---|
| 先写背景与目标 | 让读者理解「为什么」，而非直接跳功能 | 一上来就是功能列表 |
| 非目标与范围要写清 | 防止评审时被「顺手加上」蔓延 | 只写「本期包含」，不提边界 |
| 验收标准跟功能走 | 每条需求自带可验收标准，不要集中堆在文末 | 「详见测试用例」（把责任甩给测试） |
| 版本与变更记录 | 顶部记录修订历史：日期 / 变更人 / 变更点 | 悄悄改掉没人知道 |
| 图文结合 | 关键流程配流程图/线框，避免纯文字歧义 | 大段文字描述复杂交互 |
PRD 评审检查清单（评审前自查）
- [ ] 背景 / 目标 / 非目标是否清晰
- [ ] 每条需求都有可执行、可验收的验收标准
- [ ] 边界条件（空、异常、权限）覆盖完整
- [ ] 涉及埋点/数据的需求是否与数据分析口径对齐
- [ ] 依赖与风险（技术依赖、外部系统、开放问题）是否列出
- [ ] 范围外的东西明确写了「不包含」，防止评审蔓延
- [ ] 是否有设计方向需要的交互与视觉信息
版本范围与变更管理
版本范围三问
- 这个版本要解决的核心问题是什么（对齐目标）；
- 哪些需求是必须的（Must）、哪些可以等（Later）——用 MoSCoW 分级：
- Must：不做版本目标无法达成；
- Should：重要但可暂缓；
- Could：锦上添花；
- Won't：本期明确不做。
- 砍需求的标准是什么：影响目标达成度最低的优先砍。
变更管理流程
收到变更请求 → 评估（影响范围 / 成本 / 风险）→ 变更评审会决策 → 更新 PRD 与排期 → 通知相关方- 小变更（文案、样式微调）：记录在变更日志，无需单独评审；
- 中变更（新增小功能、调整逻辑）：走变更评审，重新估算排期；
- 大变更（范围扩展、目标调整）：重新开需求分析，必要时开新 PRD。
变更管理的坑
- 只改 PRD 不通知研发/测试 → 上线前才发现「做的不是最新版」；
- 任何变更都无条件接受 → 版本无限拖延；用「变更的成本要有人买单」原则挡不必要需求；
- 变更不留记录 → 复盘时无法追溯「为什么这版变成这样」。
常见坑速查
| 坑 | 现象 | 解法 |
|---|---|---|
| 需求翻译错误 | 用户说 A，PRD 写成 B | 用户故事 + 原话引用，评审时请需求来源方确认 |
| 验收标准缺失 | 上线后扯皮「这不算 bug」 | 每个 Story 都写 Given-When-Then |
| 范围蔓延 | 评审会越开越大 | PRD 写清「本期不包含」，变更走流程 |
| 只写功能不提目标 | 做完发现跟用户要的不一致 | PRD 头部必须有「背景与目标」 |
| 抄竞品功能 | 别人有所以我们也做 | 需求都回到目标与用户故事验证 |