第4章：前置条件分析：用户需求分析、市场验证结论、资源约束清单
前置条件分析是MVP功能范围判定的“输入关口”：只有系统化完成用户需求分析、市场验证结论和资源约束清单三项审计，后续的取舍原则才有依据。本章给出该分析的完整SOP，包括每一步的操作指令、交付物模板和常见异常应对。
4.1 适用场景
- 新功能提议的准入评审：每个候选功能在进入MVP Backlog前必须先通过前置条件分析。
- 迭代计划会前准备：在Sprint计划前需更新用户需求、市场验证和资源三份清单。
- 项目节点“Go/No Go”决策：当外部环境（如竞品发布、资金变化）发生突变时需重新分析。
4.2 前置条件
| 编号 | 前置条件 | 说明 |
|---|---|---|
| PC01 | 最新版本的用户画像与场景库 | 至少覆盖目标用户的3个典型使用场景 |
| PC02 | 至少一轮MVP级用户可用性测试或原型验证的数据 | 定性与定量结果均需归档 |
| PC03 | 当前团队资源日历与预算表 | 包含人力、工期、技术储备、外部依赖 |
| PC04 | 已签署的价值/成本评估模板（详见第3章） | 用于快速与前置条件比对 |
4.3 操作步骤
- Step 1：用户需求审计 (User Need Audit)
- 汇总所有未关闭的用户反馈、NPS低分原因、工单高频标签。
- 剔除“伪需求”：通过5 Whys法追问真实动机，去除与业务目标不直接相关的需求。
- 输出：需求真伪判定表（包含需求ID、原始描述、5 Whys链条、保留/拒绝结论）。
- Step 2：市场验证结论核查 (Market Validation Review)
- 核查所有实验（A/B测试、着陆页、预售页面）是否达到最小统计显著性（p<0.05）。
- 标注“已验证”与“待验证”的市场假设，对齐到不同版本路线图。
- 输出：市场假设验证状态矩阵。
- Step 3：资源约束清单构建 (Resource Constraint Inventory)
- 盘查剩余冲刺天、团队可用点数（Story Points）、外部API配额、合规风险等硬性约束。
- 区分“不可妥协约束”（如法规）与“可谈判约束”（如非关键依赖）。
- 输出：约束分类映射表。
- Step 4：交叉验证（Cross-Validation）
- 将需求审计结果与市场验证结论对比：已验证的需求优先保留；待验证但需求紧急的需标记风险。
- 将保留需求对照资源约束，计算最小可行开发包（Minimum Development Package）。
- 输出：前置条件分析总表（见记录材料）。
- Step 5：签署判定依据
- 产品经理、技术负责人、业务方共同签字确认“功能边界判定依据”，进入下一环节（第5章 功能边界优先级排序）。
4.4 输入输出物
| 类型 | 名称 | 格式/模板 | 责任人 |
|---|---|---|---|
| 输入 | 用户需求分析报告 | .md / 飞书文档 | 产品经理 |
| 输入 | 市场验证实验报告 | .xlsx / 数据看板 | 增长/市场负责人 |
| 输入 | 资源约束清单初稿 | .xlsx / 项目管理工具 | 项目经理 + 开发代表 |
| 输出 | 前置条件分析总表 | .xlsx / 在线表格（固定列：需求ID、真伪结论、验证状态、约束等级、风险标记） | 产品经理 |
| 输出 | 功能边界判定依据 | .docx / 协作文档 | 评审委员会 |
4.5 责任边界
| 角色 | 职责 | 签字/确认环节 |
|---|---|---|
| 产品经理 | 主导需求审计、汇总分析总表、组织交叉验证 | 步骤1、4、5 |
| 市场/增长团队 | 提供市场验证数据、标注置信度 | 步骤2 |
| 技术负责人 | 评估资源约束准确度、提供技术可行性意见 | 步骤3 |
| 业务方/客户代表 | 对保留需求给出业务价值排序建议 | 步骤4（列席） |
| 项目/交付经理 | 记录约束项更新时间、监控风险 | 全程存档 |
4.6 记录材料
请使用以下标准化模板生成 前置条件分析总表（示例部分数据）：
| 需求ID | 原始描述 | 5 Whys结论 | 真伪判定 | 市场验证状态 | 约束类型 | 风险标记 |
|--------|-------------------|-------------------|----------|--------------|----------|----------|
| R-012 | 添加“分享到微博” | 用户隐藏动机：传播工作成果 | 真实 | 已验证（CTR+12%） | 低 | 无 |
| R-045 | 增加暗黑模式 | 无深层次需求 | 伪 | 未验证 | 中 | 用户感知低 |
| R-078 | 导出PDF报表 | 合规审计强制要求 | 真实 | 不适用（合规） | 硬约束 | 不可妥协 |4.7 异常处理
异常 1：用户需求与市场验证结论严重冲突（如用户说要“更快”，但A/B测试显示加速功能导致用户放弃率上升）。
- 处理：优先级暂停该需求，发起二次定性访谈（5-8人），必要时回到 Step 1 重建需求描述。
- 记录：在总表中标注
[冲突-需二次验证]。
异常 2：资源约束清单出现“不可预知依赖”（如第三方SDK突然变更收费计划）。
- 处理：立即标记为“高约束风险”，与法务、采购启动48小时快速评估。
- 替代方案：若评估周期超出迭代窗口，将该需求移至“后置观察池”，不放入当前MVP。
提效技巧：建议每两周召开一次30分钟的“前置条件同步会”，固定更新三项输入的版本时间戳，避免一次分析使用过时的市场验证数据。
4.8 验收标准
完成前置条件分析后，需满足以下条件方可进入下一章：
- 所有候选功能需求均经过5 Whys真伪判定，且判定记录可追溯。
- 市场验证结论表中“已验证”项占比 ≥ 60%，否则需补充实验（延期当前迭代计划）。
- 资源约束清单中所有“硬约束”都有明确的满足/规避方案，且获得技术负责人、项目经理书面确认。
- 前置条件分析总表经产品经理、技术负责人、业务方三方签字（电子或纸质）归档。
- 功能边界判定依据文档已生成，包含明确的准入/准出列表（至少包含“强制包含”“可选”“放弃”三类）且不含歧义项。