第4章 原型范围定义文档结构
4.1 本章交付物
完成本章学习后，你将掌握如何输出一份标准化的原型范围定义文档。该文档是产品需求阶段的核心交付物，用于对齐项目干系人对“做多少、做到什么程度”的预期。文档包含五个核心模块：
- 目标 – 本轮原型要验证的核心假设或业务指标
- 用户群 – 明确的目标用户画像与使用场景
- 功能列表 – 按优先级排列的功能清单（含边界说明）
- 验收标准 – 每个功能通过/不通过的量化条件
- RICE评分 – 用RICE模型为功能打分，支撑取舍决策
关键认知：原型范围定义文档不是PRD，它更轻量、更聚焦于验证性交付。RICE评分直接决定功能去留，避免“什么都想做”的陷阱。
4.2 RICE模型在原型范围定义中的嵌入方式
RICE模型的四个维度（Reach、Impact、Confidence、Effort）需要与文档的“功能列表”和“验收标准”联动。操作步骤如下：
- 拆解需求 – 从用户访谈和场景故事中提取独立功能项，写入功能列表。
- 定义验收标准 – 每个功能必须附有可量化的通过条件（如：在5秒内加载完成）。
- 逐项RICE打分 – 对每个功能估算R、I、C、E值，计算优先级分数 = (R×I×C)/E。
- 划定及格线 – 定义最低优先级分数阈值（例如≥50），低于阈值的功能划入“暂不实现”。
- 形成范围基线 – 将选中功能写入原型范围定义文档，作为开发团队和测试团队的工作边界。
常见误区：不要先写功能列表再补RICE评分。应该先做快速打分迭代，用分数驱动功能列表的增删，避免后期返工。
4.3 原型范围定义文档模板（核心字段）
下表是标准模板的简化版，实际使用时可根据项目复杂度扩展“优先级”列。
| 模块 | 字段 | 填写说明 / 示例 |
|---|---|---|
| 目标 | 业务目标 | 提升用户次日留存率5% |
| 验证假设 | 消息推送提醒能促使70%用户次日回访 | |
| 用户群 | 目标用户画像 | 活跃度≥3天/周的新注册用户（注册后1-14天） |
| 功能列表 | 功能名称 | 消息推送开关 |
| 边界说明 | 仅支持iOS推送，Android暂不纳入原型 | |
| 验收标准 | 量化条件 | 推送到达率≥95%；点击率≥20% |
| RICE评分 | Reach（用户数） | 5000人/月 |
| Impact（影响程度） | 0.5（中等提升） | |
| Confidence（信心） | 80% | |
| Effort（人天） | 12人天 |
实践技巧：RICE评分中的Confidence一项最容易被主观放大。建议每个功能至少由产品、开发、测试三方共同估算，取中位数作为最终值。
4.4 文档结构全景图（RICE驱动原型范围定义）
4.5 交付物检查清单
在输出原型范围定义文档前，请逐项确认以下要点：
- ☐ 目标是否明确描述了“验证什么”而非“做什么”？
- ☐ 用户群是否精确到可筛选的维度（如活跃天数、注册时长）？
- ☐ 功能列表是否按RICE分数从高到低排序，并标注了“原型必做/可选/暂不”三类标签？
- ☐ 验收标准是否每条都是可测的（时间、数量、比例）？
- ☐ RICE评分是否经过至少3人校准，Confidence是否低于100%？
- ☐ 是否有“RICE评分≤30”的功能被保留在范围内？如果是，附件中需给出保留理由。