📚 课程目录第3章前置条件

3. 前置条件：业务目标清晰度、技术可行性评估、数据基础检查

AI 产品 Roadmap 的迭代节奏必须建立在三个刚性条件之上。任何一条未达标，后续的版本规划都会因方向摇摆、技术卡点或数据断供而频繁返工。本章提供一个可逐项核验的“门禁检查模型”，帮助团队在启动节奏规划前完成系统自检。

适用场景

团队准备启动 AI 产品 Roadmap 正式规划，需要确认是否具备进入迭代节奏设计的条件。
季度/半年度 Roadmap 刷新前，需要重新核验业务、技术与数据三个维度的基线是否变化。
新立项的 AI 产品在进入版本规划 Gate 前，必须通过本门禁检查。

前置条件

在执行本章检查前，团队应已具备以下初步材料（不要求最终版本，但需可被客观评审）：

业务方向文档：包含至少一个核心业务场景描述、预期商业价值、关键干系人列表。
技术栈清单：已确定主要技术选型（框架、推理引擎、部署平台）及核心依赖的第三方服务。
数据资产目录：已盘点可用数据集来源、存储位置、标注状态、访问权限及基本质量报告。

最佳实践：建议在项目立项（Kick-off）前 1-2 周将上述三份文档发给评审组提前阅读，避免检查会上因信息缺失而无法做出判断。

操作步骤

按三个子流程依次执行，每个子流程包含 3 项检查。全部通过后方可进入下一子流程。

子流程A：业务目标清晰度检查

量化验证：要求业务方给出至少 1 个可量化的核心 KPI（如“用户推荐点击率提升 15%”），目标值偏差需小于 ±20%。
共识验证：组织业务方、产品、技术三方评审会，确认关键干系人对目标理解一致，并签署《业务目标确认书》。
价值验证：检查是否完成 ROI 预估（包含隐性成本——标注成本、运维成本、迭代调优成本）。

子流程B：技术可行性评估

方案成熟度：确认所选技术方案（模型架构、推理框架、部署方式）至少有 1 个来自同行业的成功案例或内部 POC 验证报告。
团队能力匹配：对照技术栈清单，逐项核验团队当前技能覆盖度是否 ≥ 80%。覆盖度不足的项必须注明补齐计划。
外部依赖可控：检查第三方 API、SDK、云服务是否具备 SLA 保障，是否存在单点授权风险或合规壁垒。

子流程C：数据基础检查

数据可用性：确认训练/评估数据集已采集完毕，存储路径可访问，数据读取权限已开通。
数据质量达标：执行数据质量扫描，字段缺失率 < 5%，异常值占比 < 3%，标签一致性 ≥ 95%。
标注/特征就绪：标注任务完成率 ≥ 90%，特征工程管线已通过单元测试验证。

  操作要点：每项检查完成后，由对应负责人在检查表上填写“通过 / 不通过”及证据链接。三个子流程全部通过后，汇总至决策节点进行终审。

输入输出物

类型	名称	格式/载体	提供方
输入	业务愿景文档	PDF / 在线文档	PM
输入	技术栈清单	Excel / 在线表格	Tech Lead
输入	数据资产目录	Excel / 数据地图	数据工程师
输出	前置条件检查清单（已签署版）	PDF / 签名文档	三方会签
输出	前置条件门禁评估报告	PDF / 看板截图	PM

责任边界

角色	职责范围	不负责的边界
PM	组织业务目标对齐会；量化 KPI 并取得干系人签署；输出检查总报告	不承担技术选型验证、数据质量扫描的具体执行
Tech Lead	完成技术可行性评估；识别外部依赖风险；填写技术检查子表	不负责业务目标的商业价值计算、数据采集权限申请
数据工程师	执行数据质量扫描；确认数据可用性与标注进度；填写数据检查子表	不负责技术方案选型、干系人沟通与签署
决策评审组	终审三条件是否全部达标；签署门禁检查清单	不介入具体执行细节

记录材料

使用以下 YAML 模板记录每次前置条件检查的结果，建议存放在项目 Git 仓库的 docs/roadmap/ 目录下，版本号随检查日期更新。

# preconditions_checklist.yaml
version: "1.0"
check_date: "2025-07-10"
product_name: "智能客服推荐系统"

preconditions:
  business_goal_clarity:
    status: pending
    items:
      - name: KPI 可量化
        result: "pass"
        evidence_url: "https://wiki.xx.com/goal/quantify"
        owner: "PM-张三"
      - name: 干系人共识
        result: "pass"
        evidence_url: "https://wiki.xx.com/goal/consensus"
        owner: "PM-张三"
      - name: ROI 预估完成
        result: "fail"
        comment: "隐性运维成本未估算，需补充"
        owner: "PM-张三"

  technical_feasibility:
    status: pass
    items:
      - name: 方案成熟度
        result: "pass"
        evidence_url: "https://poc-report.xx.com/llm-serving"
        owner: "Tech-李四"
      - name: 团队能力匹配
        result: "pass"
        coverage: 0.85
        owner: "Tech-李四"
      - name: 外部依赖可控
        result: "pass"
        sla_level: "99.9%"
        owner: "Tech-李四"

  data_availability:
    status: pass
    items:
      - name: 数据可用性
        result: "pass"
        owner: "DE-王五"
      - name: 数据质量达标
        result: "pass"
        missing_rate: 2.1
        anomaly_rate: 0.8
        owner: "DE-王五"
      - name: 标注/特征就绪
        result: "pass"
        annotation_completion: 0.95
        owner: "DE-王五"

decision:
  all_conditions_met: false
  blocker: "业务目标清晰度 - ROI预估未完成"
  reviewer: "评审组-赵六"
  sign_date: "2025-07-11"

异常处理

当某一项检查结果为“不通过”时，按以下规则处理，不得跳过或合并门禁：

异常类型	典型表现	处理措施	最多重检次数
业务目标不清晰	KPI 无法量化、干系人未达成一致、ROI 缺失	停止 Roadmap 规划；由 PM 组织目标拆解工作坊，重写业务愿景文档	2 次
技术方案不可行	无成功案例、团队技能覆盖度 < 50%、外部依赖无 SLA	启动技术 Spike 或替代方案 POC；制定技能补齐计划（含外部招聘/培训）	2 次
数据基础不达标	数据集未采集、缺失率 > 10%、标注完成率 < 60%	启动数据治理专项；调整 Roadmap 时间线，将数据准备作为独立一期发布	3 次
多条件同时不达标	两个及以上维度同时为 fail	立即冻结 Roadmap 规划，退回至项目立项阶段重新评估	—

硬性规则：三条件中任何一项未达标，不得进入后续的迭代节奏设计环节。禁止以“边做边补”的心态在门禁未通过的情况下启动版本规划——AI 产品的技术债务和数据债务一旦累积，后期修复成本远超传统软件。

验收标准

以下条件全部满足时，本章工作视为完成：

《前置条件检查清单》已签署并归档，三个子流程状态均为 pass。
门禁评估报告中不包含未关闭的异常项（若存在异常，必须附上重检通过的证据链）。
决策评审组在清单上签字确认，并注明“同意进入迭代节奏规划”。
YAML 检查记录已提交至项目仓库的 docs/roadmap/ 目录，版本号可追溯。