3. 功能边界概念与重要性：定义功能边界、避免范围蔓延、保障交付节奏

功能边界是MVP规划中第一道“护栏”。没有清晰的功能边界，团队会不断在“再加一个小功能”的诱惑中流失交付节奏，最终陷入范围蔓延的陷阱。本章通过SOP操作步骤，帮助你为每个MVP划定物理级的功能边界，并建立防止范围蔓延的流程控制机制。

3.1 适用场景

3.2 前置条件

• 已输出经过优先级排序的《需求候选清单》（见第2章）。
• 已确定MVP的验证目标与关键假设（如：用户留存率需达到30%才继续）。
• 团队已就当前迭代的可用人天/工时达成共识。
• 存在已批准的《产品愿景文档》可作为边界决策的依据。

3.3 操作步骤

功能边界判定遵循“5步法”，每一步都有明确的输入、动作与输出。

1. 步骤一：定义“功能边界帧”
   ——为MVP创建一个虚拟的“容器”，明确什么可以进、什么必须排除。容器由3个维度构成：功能列表（哪些US）、交互深度（极限状态、空状态、错误文案是否必须）、质量标准（性能阈值、兼容性要求）。
   动作：PM在《功能边界判定手册》中填写“边界帧”表格。
2. 步骤二：单向门测试（One-Way Door Test）
   对每个候选功能提问：“如果本次不做，后续能否低成本补上？如果做了，后面能否撤销？”
   ——可反向的功能：可以之后再加，本次排除。
   ——不可反向的功能：必须先包含或做原型验证，否则后续无法修复或成本极高。
   动作：PM用红/绿标签标记每个US的“门属性”。
3. 步骤三：依赖矩阵检查
   将核心功能的依赖关系可视化为矩阵，识别“必须一同交付”的功能簇和“可单独交付”的功能孤岛。
   动作：技术负责人使用关联依赖图（见SVG），标注阻塞型依赖。
4. 步骤四：边界确认会议
   召集PM、开发代表、QA代表、业务方，对照边界帧逐项确认。每项确认后双方签字。
   动作：形成签核版《MVP功能边界确认单》。
5. 步骤五：锁定边界并发布基线
   将确认后的边界帧发布为迭代基线，并建立“超出边界变更流程”（见3.7异常处理）。
   动作：更新项目管理工具中的Sprint范围，设置“冻结”日期。

3.4 输入输出物

3.5 责任边界

• 产品经理：主持边界判定流程，维护《功能边界判定手册》，发起边界确认会议，确保变更流程被遵守。
• 技术负责人：提供依赖矩阵分析，评估不可反向功能的技术实现成本，为单向门测试提供技术意见。
• QA代表：评估边界内功能的测试覆盖率，识别因边界缩小导致的质量风险区域。
• 业务方/产品总监：在边界确认单上签字，对超出边界的需求变更承担节奏延误的告知义务。

3.6 记录材料

3.7 异常处理

功能边界在以下情况下允许被调整，但必须走严格管控流程：

3.8 验收标准

• 边界完整性：《功能边界判定手册》100%覆盖MVP全部候选US，无遗漏项。
• 签核完整性：边界确认单包含PM、技术负责人、业务方三方签字，缺一不可。
• 依赖矩阵正确性：依赖矩阵未遗漏任何真实的阻塞型依赖（通过测试阶段回溯检查，遗漏数=0）。
• 变更管控有效性：从锁定基线到交付之日，发生的边界变更次数 < 2次，且所有变更都有完整的变更记录和签核。
• 交付节奏偏差：实际交付日期与基线计划日期的偏差在±15%以内（不含因边界变更导致的主动延期）。