第3章 前置条件准备：用户问题清晰度、资源约束、时间窗口

1. 适用场景

本章适用于以下三种典型项目启动阶段：

• 产品从0到1：尚未形成明确产品方向，需要从用户反馈中筛选首个MVP范围。
• 存量业务创新：已有成熟产品线，需在限定资源内验证新功能假设。
• B端定制交付：客户需求模糊且交付周期紧迫，须快速锁定最小可行交付物。

2. 前置条件

编号	条件	验收标准
PC-1	已收集不少于5份真实用户原始反馈记录	记录可追溯至具体用户角色和场景
PC-2	已完成干系人识别并明确决策链	产品负责人、技术负责人、业务方代表已确认
PC-3	项目预算与人力池已初步确定	预算上限和可用人天已书面确认

3. 核心操作步骤

前置条件准备需依次完成三个维度的评估与校准，顺序不可逆。

步骤一：用户问题清晰度评估

1. 提取原始问题关键词：从用户反馈中筛选高频动词和名词。
2. 归类问题类型：将问题归入“功能缺失”“体验障碍”“性能瓶颈”“认知鸿沟”四类。
3. 计算清晰度分数：使用以下公式量化每个问题：

   清晰度分数 = (明确场景数 × 0.4) + (影响用户数 × 0.3) + (可复现性 × 0.3)

4. 标记阈值：分数 < 3.0 的问题标记为“模糊问题”，需退回补充调研。

步骤二：资源约束盘点

1. 统计可用人天：按角色类别汇总预算人天。

   可用人天 = 开发人天 + 设计人天 + 测试人天 + 产品人天

2. 折算成本上限：根据平均人天单价估算最大可消耗工时。
3. 识别硬约束：标记不可变更的条件，如“必须复用现有API”“前端仅配置1人”。
4. 绘制资源气泡图：将人天按功能模块分配，气泡大小代表资源占比。

步骤三：时间窗口对齐

1. 锁定关键里程碑：记录市场活动日、客户交付日、内部演示日等硬性截止点。
2. 倒推开发周期：从最紧的里程碑向前推算，预留20%缓冲期。

   最晚开工日 = 里程碑日期 - (开发天数 × 1.2)

3. 冲突检测：若多个里程碑重叠，标记为“窗口冲突”并上报产品委员会。

4. 输入输出物

方向	物项	格式/载体	责任人
输入	用户原始反馈记录集	石墨文档 / Confluence	用户研究员
输入	项目资源预算单	Excel 或飞书表格	项目经理
输入	项目关键里程碑日历	甘特图 / 日历视图	项目经理
输出	问题清晰度评估矩阵	评估表（含分数和分类）	产品经理
输出	资源约束清单	结构化清单（含硬约束标记）	产品经理 + 技术负责人
输出	时间窗口对齐报告	冲突检测结果 + 倒推排期表	项目经理

5. 责任边界

角色	职责	决策权限
产品经理	主导清晰度评估，输出评估矩阵	可判定问题是否退回补充
技术负责人	提供资源约束的可行性判断	可否决超出技术储备的约束
项目经理	管理时间窗口对齐与冲突上报	可触发跨项目协调会议
产品委员会	仲裁资源冲突与窗口重叠	可调整项目优先级或延期决策

6. 记录材料

本章执行过程中必须同步维护以下三份记录，作为后续章节的输入依据：

• RW-01 用户问题清晰度评估表：包含问题ID、原始描述、分类、分数、是否退回标记。
• RW-02 资源约束登记册：分角色记录预算人天、已使用人天、硬约束说明。
• RW-03 时间窗口对齐日志：记录里程碑日期、倒推开工日、冲突标记与仲裁结论。

7. 异常处理

异常场景	判定条件	处理措施
用户问题清晰度分数普遍偏低	超过60%的问题分数 < 3.0	暂停流程，启动补充用户访谈，至少新增3份有效记录后再重新评估
预算人天与倒推需求人天缺口 > 30%	可用人天 < 倒推人天 × 70%	发起资源变更请求，或由产品委员会裁剪非核心功能假设
两个里程碑重叠且均不可调整	窗口冲突检测结果为红色	上报产品委员会，指定其中一个里程碑为“硬截止”，另一个协商延期
关键干系人未在2个工作日内确认约束	约束清单待签字时长 > 48h	项目经理升级至产品委员会，由委员会指派决策代行人

8. 验收标准

本章流程完成后，必须满足以下全部标准方可进入下一章：

• AC-1：问题清晰度评估矩阵中，模糊问题占比 ≤ 20%。
• AC-2：资源约束清单已完成所有硬约束标记，且经技术负责人签字确认。
• AC-3：时间窗口对齐报告无红色冲突标记，或冲突已形成仲裁结论。
• AC-4：三份记录材料（RW-01、RW-02、RW-03）均已归档至项目知识库。
• AC-5：产品经理与技术负责人、项目经理三方已签署《前置条件准备确认单》。

9. 流程结构总览

下方SVG展示了前置条件准备阶段三个维度的评估顺序与决策门，帮助团队快速定位当前所在步骤及可能的分支路径。