第二章 前置条件与数据准备：项目范围定义、历史数据收集、团队角色清单
任何基于模型的成本估算（如COCOMO、功能点分析或参数化类比）的准确性，都高度依赖“前置条件与数据准备”阶段的质量。本章将详细拆解在正式执行Effort估算之前，必须完成的三个核心准备工作：项目范围定义、历史数据收集与团队角色清单。这是确保估算结果可信、可复现的基石。
2.1 适用场景
强大的估算基础准备工作，并非所有估算场景都必须严格执行全部步骤，但在以下场景中，前置条件与数据准备的完善程度直接影响估算置信度：
- 项目启动估算： 需要从零到一建立预算基线，必须有明确的范围定义和团队假设。
- 里程碑/迭代计划： 依赖历史Sprint速率和团队当前产能进行短期排期。
- 变更请求评估： 需要对比“当前范围”与“变更后范围”对成本的影响。
- 外部投标/甲方报价： 必须依据清晰的功能列表和历史生产率进行竞标。
2.2 前置条件
在执行本章节操作前，组织与项目需要具备以下基本要素：
- 项目章程（Project Charter）： 已获正式批准，包含高层级目标、预算约束和关键里程碑。
- 初始产品待办列表（Product Backlog）： 至少包含已排序的Epic级别功能描述。
- 组织过程资产授权： 获得访问历史项目数据仓库、工时管理系统的权限。
- 核心估算团队确认： 已指定技术负责人、估算协调员和业务方代表。
2.3 操作步骤
本章节的核心操作步骤分为三个并行推进的子活动，最终汇聚为估算基线。具体步骤如下：
步骤 1：项目范围定义（Scope Definition）
将高层级需求分解为可估算的工作单元（Work Items）。对于AI项目，切忌使用标准化的功能点，而应采用AI加权功能点或故事点。
| 模块名称 | 功能描述 | 估算复杂度 | 关联历史参考 |
|---|---|---|---|
| 数据管道 | 多源数据接入、清洗、特征工程 | 高 (L3) | Project Alpha - 数据层 |
| 模型训练 | 基准模型选型、超参调优 | 高 (L3) | Project Beta - NLP模型 |
| 推理接口 | RESTful API 封装、并发优化 | 中 (L2) | Gamma 微服务骨架 |
步骤 2：历史数据收集（Historical Data collection）
从组织过程资产中提取与待估算项目类似的历史项目数据。重点关注单位产出工时和缺陷返工率。如果缺乏历史数据，需要参考行业基准（如IDC或Gartner AI开发指标）进行校准。
| 历史项目 | 总工作量(人月) | 功能点数 | 速率(人时/FP) | 缺陷率(%) |
|---|---|---|---|---|
| Alpha 推荐系统 | 24 | 1500 | 7.8 | 12 |
| Beta 客服NLP | 45 | 2800 | 8.2 | 15 |
| Gamma 视觉检测 | 18 | 900 | 10.1 | 8 |
数据收集完成后建议使用YAML结构化存储，便于工具读取与动态调整，示例如下：
historical_effort:
- project_code: "PRJ-ALPHA"
system_type: "recommendation"
total_function_points: 1500
total_person_hours: 2800
defect_rate: 0.12
team_experience_level: "intermediate"步骤 3：团队角色清单（Team Role Inventory）
明确可用的人力资源及其技能等级（Junior / Intermediate / Senior）。AI项目的关键角色通常包括：AI架构师、数据工程师、ML工程师、MLOps工程师、测试工程师（AI）及业务分析师。
| 角色 | 拟投入人员 | 技能级别 | 可用率(FTE) | 小时费率($) |
|---|---|---|---|---|
| AI架构师 | 张三 | Senior (L5) | 0.5 | 120 |
| 数据工程师 | 李四 | Intermediate (L3) | 1.0 | 80 |
| ML工程师 | 王五 | Junior (L2) | 1.0 | 55 |
| MLOps工程师 | 赵六 | Intermediate (L4) | 0.25 | 95 |
2.4 输入输出物
| 类型 | 名称 | 说明/来源 |
|---|---|---|
| 输入 | 项目章程 / 产品路线图 | 来源于项目发起人或产品经理。 |
| 输入 | 组织过程资产(OPA) | 来源于项目管理信息系统(PMIS)或问题追踪系统。 |
| 输出 | 分解后的范围说明书(WBS) | 包含已估算复杂度的功能模块树。 |
| 输出 | 历史数据基准记录 | 清洗和归一化后的速率/缺陷率数据库。 |
| 输出 | 团队能力矩阵表 | 明确角色、技能级别、可用率和费率。 |
2.5 责任边界
- 估算协调员（Estimator/SME）： 负责主持分解会议，引导历史数据调取，编制角色清单初稿，对数据质量和一致性负责。
- 技术负责人（Tech Lead/Architect）： 负责范围定义中的技术拆解，确认功能复杂度的技术合理性，纠正历史数据偏差。
- 项目经理/PO： 负责提供范围输入，确认业务优先级，协调资源清单中的角色确认，对最终的输入基线和假设负责。
- 职能经理（Line Manager）： 负责确认团队角色清单中人员的技能等级和实际可用率。
2.6 记录材料
在完成数据准备后，需归档以下过程记录材料：
- 范围定义会议纪要： 记录范围边界、假设条件和排除的功能需求。
- 历史数据采集日志： 记录数据的来源项目、时间戳、清洗方法和异常标记。
- 团队技能确认函（邮件或系统签核）： 由对应职能经理或负责人签字确认的技能水平和可用率。
- 输入数据包版本记录： 确保所有输入材料都有唯一版本号和变更记录。
2.7 异常处理
异常 1：范围边界模糊，无法有效分解。
处理策略：与PO协商中止估算，或采用快速三点估算（最乐观/最可能/最悲观），并记录为预算缓冲储备。
异常 2：无历史数据可用。
处理策略：启动为期1-2周的Sprint 0进行技术原型验证，收集初始速率；或采用市场公开数据库（如Software Improvement Group benchmark）。
异常 3：关键AI角色（如架构师）产能冲突。
处理策略：假设基准估算基于“标准团队配置”。若实际人员不匹配，通过技能折扣因子调整总工作量（如缺失高级人员需增加20%工时）。
异常 4：历史数据口径不一致（如工时统计口径差异）。
处理策略：进行数据清洗与归一化，将粗估工时调整为详细级工时。若清洗后仍偏差超过15%，则标记为低置信度数据，并在基线中增加额外风险储备。
2.8 验收标准
前置条件与数据准备阶段完成的标志，必须满足以下全部检查项：
- 范围已冻结： 范围说明书已完成，并经过技术负责人和PO的签字确认。
- 数据已验证： 历史数据至少包含1-2个相似项目的完整工时记录，且已通过三方核验（估算员、技术负责人、PM）。
- 资源已确认： 团队角色清单中的每一个人力资源的状态为“已分配”或“可用待命”，费率已确认。
- 假设完全暴露： 所有在数据准备过程中的假设（如“假设GPU资源充足”、“假设预训练模型可用”）均已记录在估算假设日志中。