2. 功能边界划分的前置条件
在开始划分功能边界之前，必须完成三项基础对齐工作，它们共同构成边界划分的决策底盘。任何跳过或缩减都会导致后续原型评审中出现大量重复返工与范围拉锯。
核心原则：边界划分不是技术推导，而是业务与系统约束的交汇决策。前置条件完成度决定了边界的稳定性。
2.1 适用场景
本章前置条件适用于以下项目阶段或决策节点：
- 产品立项后的初期范围界定阶段；
- 大型需求跨迭代、跨团队拆分前；
- 新系统建设或核心模块重构的规划阶段；
- 涉及多部门协作、外部系统对接的集成场景。
2.2 三项前置条件详解
| 前置条件 | 核心目的 | 潜在问题（若不执行） |
|---|---|---|
| 业务目标对齐 | 确保所有参与者理解产品存在的商业理由 | 功能范围失去优先级锚点，出现“什么都要做”或“什么都砍” |
| 利益相关方识别 | 明确决策权、审批流与信息输入者 | 评审时反复临时拉人，边界被非正式渠道推翻 |
| 现有系统约束 | 评估技术债务、API 限制、数据依赖 | 边界划分结果在研发阶段被判定不可实现 |
2.3 操作步骤（前置条件确认流程）
- 步骤一：发起业务目标对齐会。产品经理组织核心团队（含业务方、项目管理、技术负责人），使用「产品定位画布」或「OKR 拆解表」统一目标。
关键产出：一句话产品价值主张 + 本阶段 1-3 个关键结果指标。 - 步骤二：绘制利益相关方地图。使用 RACI 矩阵或影响力/兴趣矩阵，列出影响边界决策的所有角色。
角色 | 决策权限 | 信息输入 | 审批节点 -------------------------------------------- 产品经理 | 执行决策 | 高 | 终审 业务负责人 | 战略方向 | 中 | 二审 研发主管 | 技术可行性 | 高 | 技术初审 运营/客服 | 用户体验 | 中 | 咨询建议 - 步骤三：进行系统约束扫描。技术负责人提供当前系统的模块依赖图、核心 API 清单及已知技术债务清单。
常见遗漏：忽略第三方服务的并发限制、数据迁移成本、未治理的历史遗留字段。这些会在边界划分时被当作“隐形强约束”。 - 步骤四：三方对齐确认。将业务目标、利益相关方清单、系统约束清单打包为“前置条件基线文档”，并进行一轮逐项确认会议。确认通过后方可进入边界划分环节。
2.4 输入输出物（Input / Output）
| 类型 | 物料名称 | 格式与承载 |
|---|---|---|
| 输入 | 产品立项文档 / 业务需求说明书 | 文档或协作平台页面 |
| 输入 | 组织架构或项目干系人列表 | 在线表格或 HR 系统导出 |
| 输入 | 现有系统架构图与 API 文档 | Wiki、Swagger 或图模版 |
| 输出 | 前置条件基线文档（含三方确认签字） | 知识库永久链接 + PDF 存档 |
| 输出 | 利益相关方 RACI 矩阵 | 表格或协作图 |
2.5 责任边界（RACI）
- 产品经理（R/A）：负责发起对齐、整理基线、完成最终签字闭环；
- 业务方 / 需求提出部门（C）：提供业务目标并确认优先级；
- 研发负责人（R）：提供系统约束扫描结果，并标注技术风险等级；
- 项目经理（I）：记录会议决议，跟踪未解决项。
2.6 记录材料
以下三类物料必须作为本轮前置条件的正式记录归档：
- 物料①：业务目标对齐会议的会议纪要（含表决结果）；
- 物料②：利益相关方地图（RACI 或影响力矩阵）；
- 物料③：系统约束清单，按“不可突破 / 可协商 / 可通过改造规避”三级分类标注。
2.7 异常处理
| 异常场景 | 处理策略 |
|---|---|
| 业务目标与公司高层战略冲突 | 必须上升至项目发起人或高层产品线负责人仲裁，不可自行妥协 |
| 利益相关方列表存在遗漏 | 设立“利益相关方发现期”（通常 2 天），在边界划分前补全并确认 |
| 系统约束信息严重不足或过时 | 启动 1-2 天技术探针（Spike），澄清后再进入边界划分 |
| 多方对业务目标优先级分歧 | 使用 WSJF（加权最短作业优先）或影响/努力矩阵进行量化排序 |
强制暂停原则：如果三方（业务、产品、研发）中任意一方明确表示“当前目标或约束不清晰”，则不允许启动功能边界划分。必须暂停直到该方确认。
2.8 验收标准
确认前置条件阶段完成的标准如下：
- 已完成至少 1 轮正式的业务目标对齐会议，并有书面记录（完成 / 未完成）；
- 利益相关方识别清单已覆盖所有可能对边界产生直接影响的角色（通过 RACI 矩阵可追溯）；
- 现有系统约束清单已按三级分类标注，并经过研发负责人签字确认（不可突破项列表已锁定）；
- 前置条件基线文档已上传至知识库，且获得产品经理 + 核心业务方 + 研发负责人的三方数字签名或确认回复。