第一章 Effort估算的适用场景与前置条件
章节定位:本章是《Effort估算:AI项目资源投入评估表》的起点,明确在什么情况下可以使用Effort估算、团队需要达到怎样的规模匹配度、以及数据基础必须满足哪些条件。只有通过本章的“场景-规模-数据”三重检查后,后续的估算模板和计算流程才能生效。
1.1 适用场景
Effort估算主要适用于以下三类AI项目场景,每类场景的估算粒度与复用策略不同:
| 场景类型 | 典型特征 | 估算粒度 | 模板复用策略 |
|---|---|---|---|
| 新项目启动 | 无历史基线,需求模糊,PoC阶段 | 故事点/人天(±40%) | 基于功能点与领域复杂度推算 |
| 迭代版本规划 | 有1~2个版本数据,需求相对稳定 | 人天(±20%) | 修正历史估算因子(CF) |
| 跨团队资源调度 | 多项目并行,依赖共享GPU/标注池 | 人周(±15%) | 资源冲突系数加权 |
提示:Effort估算不适合用于纯研究型探索(如论文复现)或一次性硬件选型评估,这类活动应使用工期估算(Duration Estimation)而非投入估算。
1.2 前置条件
1.2.1 项目类型识别
必须先根据AI项目的主要工作负载确定项目类型,因为不同类型的数据准备、模型训练、评估调优的工时分配比例差异显著。
- 纯模型训练型:训练工时占比 ≥ 60%,数据准备 ≤ 20%,评估调优 ≤ 20%。
- 数据处理型:数据清洗/标注/特征工程工时占比 ≥ 50%,训练 ≤ 30%,评估 ≤ 20%。
- 系统集成型:模型部署、API封装、监控运维工时占比 ≥ 40%,训练 ≤ 30%,数据 ≤ 30%。
- 混合型:上述三类中任意两类占比介于 30%~50% 之间。
1.2.2 团队规模匹配
Effort估算模板的可靠性依赖于团队规模的稳定性。以下为团队规模匹配检查清单:
- 核心角色(PM、数据工程师、算法工程师、MLOps工程师)是否已到位?
- 团队总人数是否在 3~15 人范围内?
注:3人以下估算误差偏大(±60%),15人以上需拆分为多个子团队独立估算。 - 是否有专职的估算复核角色(通常由技术Lead担任)?
1.2.3 数据基础要求
以下数据至少需满足一项,否则应优先进行数据采集而非Estimating:
- 基线数据:至少3个已完成的同类任务的实际人天记录
- 标定数据:使用已有的工时记录对估算因子(CF)进行标定,标定误差 ≤ 20%
- 参数化数据:已知模型参数量、数据规模、GPU型号与数量,可代入公式预估
异常情况:如果团队无任何历史基线,且无法提供参数化数据,则必须先执行“探索性Spike(2~5天)”获取基础数据,再进入Effort估算流程。
1.3 操作步骤
- 识别项目类型:使用“项目类型识别表”(输入物1),选择最匹配的类型。
- 确认团队规模:核对当前团队人员配置,填写“团队角色矩阵”(输入物2),确保关键角色齐全。
- 检查数据基础:从历史项目、工时系统或实验记录中提取基线数据,判断是否满足最低要求。
- 记录决策:在“场景-规模-数据检查表”(记录材料)中标记通过/不通过,并由PM签字。
1.4 输入输出物
| 类别 | 名称 | 说明 |
|---|---|---|
| 输入 | 项目类型识别表 | 包含四类AI项目的工作量分配模板 |
| 输入 | 团队角色矩阵 | 列出当前项目中各角色的实际人员名单 |
| 输入 | 历史基线记录(可选) | 至少3条已完成任务的工时记录 |
| 输出 | 场景-规模-数据检查表 | 签字确认后的检查结果,作为第2章估算的入口凭证 |
| 输出 | 前置条件通过/不通过结论 | 若未通过,返回步骤1或进入异常处理 |
1.5 责任边界
- 项目经理(PM):组织识别会议,确认项目类型和团队规模,检查数据基础,签署检查表。
- 技术负责人(Tech Lead):提供历史基线数据,判断参数化数据是否可用。
- 估算员(Estimator):填写检查表,记录未通过原因及补救建议。
1.6 记录材料
以下为“场景-规模-数据检查表”的核心字段模板:
前置条件检查表(章节1)
项目名称: _________________
检查日期: _________________
1. 项目类型识别
[ ] 纯模型训练型 [ ] 数据处理型 [ ] 系统集成型 [ ] 混合型
确认人: _________
2. 团队规模匹配
[ ] 核心角色齐备 [ ] 人数3~15人 [ ] 有专职估算复核角色
当前人数: ____ 确认人: _________
3. 数据基础要求
[ ] 基线数据≥3条 [ ] 标定误差≤20% [ ] 参数化数据可用
确认人: _________
结论: [ ] 通过 [ ] 不通过
PM签字: _________
1.7 异常处理
| 异常情况 | 处理措施 | 责任方 |
|---|---|---|
| 项目类型无法确定 | 启动3天Spike,输出项目工作负载拆解报告 | Tech Lead + PM |
| 团队规模<3人 | 合并到上级团队统一估算,或增加兼职角色 | PM |
| 团队规模>15人 | 拆分为子团队,每个子团队独立完成本章检查 | PM |
| 无任何数据基础 | 执行探索性Spike(不超过5天),收集至少一条基线 | Tech Lead |
| 数据基础不满足最低要求 | 记录缺失项,延后估算至数据补齐 | Estimator |
1.8 验收标准
- 已明确项目类型,并记录在检查表中。
- 团队规模符合3~15人,且关键角色确认到位。
- 数据基础任意一项达标,或已规划Spike填补数据缺口。
- 检查表经PM签字,作为下阶段估算的正式入口。
SVG导览:上图展示了本章核心检查流程——从项目启动开始,依次通过“项目类型识别”、“团队规模匹配”、“数据基础检查”三道闸门,全部通过后进入下一章估算。若任一步不通过,则进入右侧的异常处理分支(Spike并补齐数据后重新检查)。蓝、绿、橙、红、紫分别对应不同步骤和异常分支,便于快速识别。