第2章：功能边界定义的前置条件
在正式划定PRD功能边界之前，必须完成以下四项前置分析。如果跳过这些步骤直接定义边界，将导致范围蔓延、需求冲突或技术不可行的风险。
2.1 适用场景
本章所述前置条件适用于以下场景：
- 全新产品立项：从零开始定义产品功能范围前，必须完成四项输入确认。
- 重大版本迭代：涉及核心功能重构或新增模块时，需重新对齐前置条件。
- 跨团队协作项目：当产品功能涉及多个业务部门或技术团队时，避免需求失真。
- 系统整合与替换：将多个遗留系统功能合并到新平台前，必须梳理约束。
🚫 不建议跳过的场景：若需求来源不明确、干系人未达成一致、业务目标模糊或技术约束未知，则功能边界定义将被视为无效输入，后续变更成本将成倍增加。
2.2 前置条件
执行本章操作之前，团队必须已经具备以下条件：
- 已获得至少一份经初步审阅的需求收集列表（原始需求条目）。
- 已确定决策委员会与产品负责人的角色。
- 已明确本轮迭代的核心业务指标（如转化率提升、用户留存、合规通过率等）。
- 已获取现有系统架构图或技术债务清单（至少为文本描述）。
2.3 操作步骤
| 步骤 | 操作内容 | 参与角色 | 输出物 |
|---|---|---|---|
| 1 | 需求来源归类与优先级初筛 | 产品经理 / 需求分析师 | 《需求来源分类表》 |
| 2 | 干系人矩阵生成（权力/利益维度） | 产品经理 + 项目经理 | 《干系人登记册》 |
| 3 | 业务目标逐条映射至需求条目 | 业务方 + 产品经理 | 《需求-目标映射矩阵》 |
| 4 | 系统约束清单编写（性能、安全、合规、接口） | 技术架构师 + 产品经理 | 《系统约束清单》 |
2.4 输入输出物
- 输入物：原始需求列表、版本规划文档、技术可行性初评报告、用户反馈/投诉记录。
- 输出物：
- 《需求来源分类表》
- 《干系人登记册》
- 《需求-目标映射矩阵》
- 《系统约束清单》
2.5 责任边界
| 角色 | 职责 | 关键产出 |
|---|---|---|
| 产品经理 | 牵头组织前置分析、输出全部文档、协调干系人确认 | 分类表、登记册、映射矩阵、约束清单 |
| 业务方 | 提供业务目标、确认需求优先级、接受约束 | 目标确认签字、优先级标记 |
| 技术架构师 | 分析现有系统约束、评估技术可行性 | 约束清单、技术评估报告 |
| 项目经理 | 确保流程节点按时完成、记录风险 | 会议纪要、风险日志 |
2.6 记录材料
以下模板或清单需要作为过程记录留存：
- 需求来源分类表：列明需求ID、来源渠道（用户调研/竞品分析/商业需求/法务合规）、提出日期、紧急程度。
- 干系人登记册：干系人名称、所属部门、权力等级（高/中/低）、利益等级（高/中/低）、沟通策略。
- 需求-目标映射矩阵：需求条目对业务指标的贡献度（直接/间接/不相关）。
- 系统约束清单：约束描述、类别（性能/安全/合规/集成）、影响范围、对应需求条目编号。
📌 最佳实践：建议在项目管理工具（如Jira、Confluence、飞书文档）中为每份记录材料创建独立页面，并关联至Epic或用户故事，便于后续追溯。
2.7 异常处理
| 异常情况 | 影响 | 处理措施 |
|---|---|---|
| 需求来源中约50%以上为口头诉求，无书面记录 | 边界定义失去基准 | 暂停边界定义，先完成正式需求采集与书面化 |
| 干系人存在重大利益分歧（如销售与研发目标冲突） | 边界容易反复调整 | 召开专题干系人协调会，由决策委员会裁决优先级 |
| 业务目标与本轮迭代需求匹配度低于30% | 范围极有可能偏离航向 | 重新审视版本定位，必要时放弃本轮定义进行战略对齐 |
| 现有系统约束清单信息缺失（如数据库并发瓶颈未知） | 技术可行性不可控 | 要求技术团队补充压测或排查，给出明确限制数值 |
2.8 验收标准
- 完整性检查：四份输出物均已生成并存入版本管理库，且每份文档均完成一次同行评审。
- 一致性检查：任一需求条目在《需求来源分类表》《需求-目标映射矩阵》《系统约束清单》中至少出现一次，且状态一致。
- 可追溯性检查：从任意输出物出发，均可向上追溯到原始需求来源，向下可关联到后续功能边界条目。
- 签收确认：业务方与技术代表已在干系人登记册及约束清单上签字（或电子确认），表示知悉并接受当前条件。
💡 高效检查：召集30分钟前置条件评审会，逐项对验收标准打勾，任何一项不通过即不能进入第3章“功能边界定义”环节。