3. 前置条件梳理
在启动《MVP验证周期与用户反馈闭环》之前，必须完成四项前置条件检查。若任一条件未达标，验证周期将面临数据失真、资源错配或利益相关方中途否决的风险。本章提供清单式核查方法与对应决策树。
3.1 适用场景
任何计划启动MVP验证的团队，在完成方案设计后、进入开发/招募阶段前，应执行本节前置条件梳理，适用场景包括但不限于：
- 新产品核心功能验证（0→1阶段）
- 现有产品新功能上线前灰度测试
- 跨部门协作的流程型MVP验证
- 需外部资金或高层审批的验证项目
⚠️ 常见误区：团队往往直接进入开发或招募环节，跳过前置条件梳理。当验证途中出现「人手不够」「资金链断裂」「关键干系人反对」时，才倒查前置条件。请务必在启动会前完成本清单。
3.2 前置条件清单
| 条件维度 | 检查项 | 验收标准 |
|---|---|---|
| 团队准备 | 核心角色已到位（产品经理/技术/用研/数据） | 每角色至少1人，且已签署责任承诺 |
| 团队准备 | 团队成员已验证MVP方法与反馈闭环流程 | 已完成1次流程走查（walkthrough） |
| 资源评估 | 开发/设计/运营预算已锁定 | 预算批准文件或邮件存档 |
| 资源评估 | 可用的用户招募渠道与样本量 | ≥50个目标用户联系方式或可触达池 |
| 时间窗口 | 验证周期不与其他重大任务重叠 | 确认日历无并行冲刺/发布/审计 |
| 时间窗口 | 有明确「硬截止日期」 | 有具体日历日（例如：6月15日） |
| 利益相关方确认 | 有权决策者已书面同意验证目标与KPI | 邮件或会议纪要签字确认 |
| 利益相关方确认 | 关键干系人已获知验证时间线与交付物 | 参与过1次同步会或收到书面沟通 |
3.3 操作步骤：前置条件检查流程
💡 建议：将以下步骤固化为「启动会Checklist」模板，每次新验证周期直接复用，节省重复思考时间。
- Step 1 · 召开前置条件核查会
参会人员：产品负责人、技术负责人、用研负责人、财务对接人。时长：≤1小时。 - Step 2 · 逐一打勾前置条件清单
使用上面的表格逐项检查。未达标项标记为「红/黄/绿」。 - Step 3 · 制定补全计划
对于红色或黄色项，明确负责人、完成时间、资源支持。 - Step 4 · 利益相关方签发
将验证目标、资源需求、时间窗口整理为《MVP验证启动备忘》，发送授权人签字。 - Step 5 · 锁定启动日期
所有前置条件为「绿色」后，在项目管理工具中创建里程碑。
3.4 输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 文档 | MVP验证方案草案 | 《验证前置条件检查表》 |
| 沟通 | 干系人名单与联系方式 | 《利益相关方确认函》 |
| 计划 | 团队排班表/预算表 | 更新后的项目日历（含验证周期） |
3.5 责任边界
- 产品负责人：负责召集核查会，确保清单打勾完成，签署最终启动备忘。
- 技术负责人：评估开发资源是否可用，明确并行任务冲突风险。
- 用研/数据负责人：确认用户招募渠道与数据收集工具就绪。
- 财务/PMO：确认预算已预留，无财务冻结或审批排队。
- 利益相关方：仅需「确认知晓并同意」，不参与日常执行。
3.6 记录材料
每次前置条件梳理完成后，需归档以下材料至项目共享文件夹：
- 《验证前置条件检查表》（Excel或在线表格）
- 利益相关方签字截图或邮件回复
- 会议纪要（含未达标项的补全计划）
- 更新后的项目甘特图（高亮验证周期）
3.7 异常处理
🛠 异常场景与应对：
- 异常A · 核心人员离职/请假：立即启动B角替换或调整验证周期至人员到位后。不允许强行启动。
- 异常B · 预算被砍：缩小MVP范围（例如只做核心功能，不做完整UI），重新评估资源后再次核查。
- 异常C · 利益相关方反对：安排1对1沟通，澄清验证目标与KPI，若仍反对，必须获得书面否决理由，并暂停验证。
- 异常D · 时间窗口冲突：推迟验证至无重叠窗口，或拆分为两个子验证周期（例如先做线上问卷，再做线下测试）。
3.8 验收标准
前置条件梳理环节的本章节验收标准如下：
- [ ] 已召开前置条件核查会，并完成《验证前置条件检查表》全项打勾
- [ ] 所有红色项已有补全计划及负责人、截止日期
- [ ] 利益相关方已书面确认验证目标、资源、时间窗口
- [ ] 团队所有成员已知晓自己在本验证周期中的角色与责任
- [ ] 记录材料已同步至指定归档位置
3.9 前置条件流程图
以上即为第3章节“前置条件梳理”的完整内容。本章给出的清单、表格、流程图与异常处理机制可直接用于指导团队启动MVP验证前的准备工作，避免因前置条件遗漏导致验证周期中途中断。