第2章 原型范围筛选场景识别

原型范围筛选并非在所有项目中都需要执行，只有当特定触发条件出现时，才需要启动该流程。本章帮助团队建立统一的场景判断标准，明确何时必须做、谁来做、决策如何流转，避免在原型阶段出现范围蔓延或资源错配。

2.1 适用场景

以下5类典型业务场景会触发原型范围筛选流程。团队在任意一类场景出现时，应立即启动RICE评分驱动的范围筛选。

2.2 前置条件

启动原型范围筛选前，必须完成以下4项准备工作。缺少任何一项都可能导致筛选结果不可执行。

• 条件1：需求收集与初步分析已完成 —— 所有候选需求已录入产品待办列表，包含简要描述和验收标准草稿。
• 条件2：至少一轮完整的RICE评分数据已产出 —— 每个需求均已计算 Reach、Impact、Confidence、Effort 四项分数，并汇总为 RICE 总分。
• 条件3：跨职能产品团队已正式组建 —— 至少包含 PO、设计师、开发代表各1人，且已明确各自在筛选中的角色。
• 条件4：项目资源约束已书面明确 —— 可用人力（人/天）、时间窗口（截止日期）、预算上限（如有）已由项目经理书面确认。

2.3 操作步骤

原型范围筛选共分5个步骤，执行顺序不可逆。每个步骤均需输出对应产物，方可进入下一步。

1. 识别触发信号 —— 对照2.1节中的5类场景，确认当前触发信号属于哪一类或多类组合。记录触发时间、场景编号和紧急程度。
2. 拉取RICE评分数据 —— 从产品待办列表中导出所有候选需求的RICE评分，按总分降序排列。剔除评分缺失项。
3. 召开范围筛选会议 —— 由PO主持，设计师与开发代表参加。会议时长控制在45分钟内，按RICE排序从高到低逐项讨论。
4. 匹配典型场景与资源约束 —— 将RICE排序结果与当前资源约束对齐，标记出「必须保留」「可谈判」「建议移除」三类需求。
5. 形成范围决议并书面签发 —— PO签署《原型范围筛选决议表》，明确本次原型制作的范围、排除项及理由。决议同步至所有干系人。

2.4 输入输出物

2.5 责任边界

原型范围筛选涉及4个核心角色，决策链路为：PO发起 → 设计师&开发代表提供评估 → PO裁决 → 产品委员会（如有争议）终裁。具体职责如下：

2.6 记录材料

每次范围筛选必须留存以下3份记录材料，存档至项目知识库，保存周期至少至项目结项后6个月。

• 《范围筛选会议纪要》 —— 包含会议时间、参会人、每项需求的RICE评分、讨论结论（保留/谈判/移除）、争议点及仲裁结果。
• 《原型范围筛选决议表》 —— 包含筛选后的原型范围清单、排除项清单、PO签字及日期。
• 《RICE评分-范围映射表》 —— 展示每个需求从RICE评分到范围决策的对应关系，用于事后回溯。

下方为会议纪要模板示例：

【范围筛选会议纪要模板】
日期：2025-XX-XX
参会人：PO：张三 / 设计：李四 / 开发：王五 / 记录：赵六
触发场景：S1（需求池膨胀）+ S2（资源受限）

| 需求ID | 名称 | RICE总分 | 工作量(人/天) | 决策结果 | 理由 | 争议备注 |
|--------|------|---------|-------------|---------|------|---------|
| US-001 | 用户登录优化 | 82 | 3 | 保留 | 高影响+高信心 | — |
| US-002 | 数据看板导出 | 45 | 8 | 移除 | Effort过高 | — |
| US-003 | 消息推送设置 | 61 | 5 | 谈判 | 缩减至MVP版本 | 设计建议拆分 |

PO签字：____________    日期：____________

2.7 异常处理

以下3类异常情况在原型范围筛选中最常出现，团队需提前制定应对方案。

2.8 验收标准

本章节的流程与知识是否被团队正确掌握，通过以下5条验收标准衡量。全部达标后方可进入第3章学习。

• 标准1： 团队成员能准确识别5类触发场景，并能在实际项目中正确匹配触发信号。
• 标准2： 每次启动筛选前，前置条件清单逐项自查率达到100%，无遗漏。
• 标准3： 操作步骤执行顺序正确，会议产出物（决议表、纪要、映射表）齐全且格式规范。
• 标准4： 角色职责与决策链路清晰，无越级决策或职责交叉导致的流程阻塞。
• 标准5： 异常处理方案被团队熟知，至少通过一次模拟演练验证方案可执行性。