第2章 评估前置条件与输入文档准备
适用场景
前置条件与输入文档准备适用于以下具体场景:
- 新产品/新项目立项 — 在启动技术可行性评估前,需要确认业务目标、需求文档和用户场景已就绪;
- 现有产品AI能力升级 — 评估新增AI功能前,需要补全当前版本的需求变更说明和用户场景更新;
- 技术方案选型对比 — 在多个候选技术路线中做可行性判断前,必须先对齐统一的评估输入基线;
- 投资/资源审批决策 — 需要向决策委员会提交技术可行性评估时,前置条件与输入文档的完备性是审批通过的前提。
前置条件
启动技术可行性评估前,必须同时满足以下五项前置条件,缺一不可:
- 组织承诺 — 项目发起人已书面确认评估目标,并授权成立评估小组;
- 人员到位 — 至少配备1名技术负责人、1名产品经理、1名领域专家;
- 时间窗口 — 评估周期已排入项目计划,且不少于3个工作日;
- 信息基线 — 需求文档、业务目标文档、用户场景说明已获得相关方初审;
- 工具与数据 — 评估所需的技术调研环境、测试数据集、指标模板已准备。
💡 经验提示
实际项目中,前置条件中最容易被忽略的是“信息基线”中的用户场景说明。建议产品经理在评估启动前至少完成一次用户访谈,并输出结构化的场景描述(含主流程、异常流程与边界条件),否则后续技术指标评估将缺乏判断依据。
实际项目中,前置条件中最容易被忽略的是“信息基线”中的用户场景说明。建议产品经理在评估启动前至少完成一次用户访谈,并输出结构化的场景描述(含主流程、异常流程与边界条件),否则后续技术指标评估将缺乏判断依据。
输入输出物
| 类别 | 物名 | 版本/格式要求 | 责任方 |
|---|---|---|---|
| 输入 | 需求文档 | ≥ V0.5,包含功能列表、性能指标、数据约束 | 产品经理 |
| 业务目标文档 | 含核心指标(如准确率、响应时间、覆盖率) | 产品经理 / 项目发起人 | |
| 用户场景说明 | 至少包含1个主场景 + 1个异常场景 | 产品经理 / UX 设计师 | |
| 输出 | 评估输入确认清单(Checklist) | 签章版,作为评估启动的正式依据 | 技术负责人 |
操作步骤
前置条件与输入文档准备共分为6个标准步骤,执行顺序不可逆:
- 步骤1:组建评估小组 — 明确技术负责人、产品经理、领域专家,并发布任命通知;
- 步骤2:收集原始文档 — 从产品经理处获取需求文档、业务目标文档、用户场景说明;
- 步骤3:文档完整性审查 — 对照《评估输入检查表》逐项核对,标注缺失或模糊项;
- 步骤4:文档补充与确认 — 将审查意见反馈给产品经理,在1个工作日内完成补充;
- 步骤5:前置条件自检 — 评估小组对照5项前置条件逐条签字确认;
- 步骤6:签发评估启动通知 — 技术负责人签发书面通知,评估正式进入技术指标打分阶段。
责任边界
| 角色 | 主要职责 | 交付物 / 签字点 | 协作方 |
|---|---|---|---|
| 产品经理 | 提供需求文档、业务目标文档、用户场景说明,并对其完整性和准确性负责 | 三份输入文档 + 文档补充记录 | 技术负责人、UX 设计师 |
| 技术负责人 | 组织前置条件自检,签发评估启动通知 | 评估输入确认清单 + 启动通知 | 产品经理、项目发起人 |
| 项目发起人 | 书面确认评估目标,授权评估小组 | 项目授权书 | 技术负责人 |
| 领域专家 | 协助审查用户场景的技术合理性,补充技术约束 | 场景技术约束说明 | 产品经理 |
记录材料
本章执行过程中必须归档以下记录材料,作为评估可追溯性的依据:
- 《评估输入检查表》 — 逐项记录需求文档、业务目标、用户场景的完整性检查结果;
- 《文档补充沟通记录》 — 记录与产品经理的沟通日期、补充内容及确认人;
- 《前置条件自检表》 — 五项前置条件的签字确认记录;
- 《评估启动通知》 — 技术负责人签发的正式启动文件(含评估时间窗口)。
异常处理
| 异常情形 | 处理措施 | 升级路径 |
|---|---|---|
| 需求文档版本低于 V0.5 或关键指标缺失 | 退回产品经理补充,限 1 个工作日内补交 | 超时 → 升级至项目发起人协调 |
| 用户场景未包含异常流程 | 要求产品经理补充至少 1 个异常场景 | 补充后仍不完整 → 召开场景评审会 |
| 评估小组人员未到位(如领域专家空缺) | 从技术团队或业务方临时借调 | 借调失败 → 调整评估时间窗口 |
| 前置条件自检未通过(如缺少测试数据集) | 记录缺口,启动数据准备子任务 | 影响关键路径 → 同步通知决策层 |
| 评估时间窗口不足 3 个工作日 | 与项目发起人协商延长,或缩小评估范围 | 协商不一致 → 按最小可行评估范围执行 |
验收标准
本章执行完毕的验收条件如下(全部满足方可通过):
- 文档完备 — 需求文档、业务目标文档、用户场景说明均已归档,且通过完整性审查;
- 签字齐全 — 《评估输入确认清单》已由产品经理和技术负责人双方签字;
- 自检通过 — 五项前置条件自检结果全部为“是”,并记录在《前置条件自检表》中;
- 通知签发 — 《评估启动通知》已正式发布至项目组及相关部门;
- 材料归档 — 所有记录材料已存入项目共享文件夹,路径结构符合《评估文档目录规范》。
⚠️ 常见返工风险
实际项目中最常见的返工原因是“用户场景未覆盖边界条件”。例如,在语音识别产品的可行性评估中,如果用户场景只写了安静环境下的交互,没有写嘈杂环境或多人说话场景,技术指标评估将严重偏离真实部署条件。建议在步骤3(文档完整性审查)中增加“场景边界检查”子项,作为强制检查点。
实际项目中最常见的返工原因是“用户场景未覆盖边界条件”。例如,在语音识别产品的可行性评估中,如果用户场景只写了安静环境下的交互,没有写嘈杂环境或多人说话场景,技术指标评估将严重偏离真实部署条件。建议在步骤3(文档完整性审查)中增加“场景边界检查”子项,作为强制检查点。