为什么总是延期:三个被系统性低估的环节
先说诊断。AI 项目延期,十次里有八九次不是工程师摸鱼,而是三个环节被低估。第一个,数据环节。排期表里数据准备经常就写一行"两周",实际做起来:口径对不齐、历史数据质量差、要补标几千条、标注员理解不一致返工——两周变六周是常态。第二个,效果迭代次数。传统功能开发,工作量 ≈ 功能点数 × 单点成本;AI 项目的工作量 ≈ 实验次数 × 单次实验成本,而实验次数在开始前没人知道,运气好几次就通,运气不好二十次还在原地。第三个,依赖方。GPU 资源排队、数据要别的部门给、法务安全评审、工程侧接推理服务,每个依赖方延一周,串起来就是一个月。这三个环节,传统项目管理经验全都覆盖不到,所以按传统方法排的 AI 项目计划,从第一天起就是错的。
排期原则:按阶段估,不按功能估
我的排期方法是把项目拆成确定性不同的三段,用不同的估算逻辑。数据准备和工程化这两段,确定性高,可以按传统方式排:任务拆解、估人日、加 20%-30% buffer,基本靠谱。中间的效果打磨段,绝对不排"第几周到第几周做到 90%",而是排时间盒:比如六周,每周跑多少组实验、评测集什么时候冻结、第几周做一次 Go/No-Go 评审。时间盒的意思是把不确定的"什么时候能到目标"转换成确定的"到这个时间点我们做一次有依据的决策"。
这么排还有个隐藏好处:它逼着团队在第六周必须面对现实,而不是无限期"再优化一下"。无限优化是 AI 项目延期的最大黑洞,时间盒就是堵这个洞的。
里程碑要定义可验证的退出条件
"数据准备完成""模型初版完成"这种里程碑毫无意义——怎么算完成?我要求每个里程碑带一条可验证的退出条件,而且验证方式要提前约定。比如:"数据就绪"的退出条件是 5000 条标注完成、双人标注一致率 ≥ 85%、场景覆盖率清单打勾;"POC 通过"的条件是在冻结的 300 条评测集上核心指标 ≥ 80%;"可上线"的条件是连续两周线上灰度数据达标、badcase 率低于阈值、运营侧验收签字。
带退出条件的里程碑有个附带价值:延期时你知道延在哪。没有退出条件的项目,延期是以"整体感觉慢了"的形式出现的,谁也说不清差多少;有了退出条件,你能精确地说"POC 这一门差了 6 个点,预计还需要两轮实验",这在跟老板汇报时是完全不同的可信度。
向上管理:承诺区间,管理期望
老板要日期,你给个区间再加一个降级方案,这比硬顶或者硬接都好:"工程化上线 10 月 15 号,这个能承诺;效果达标有两条路径——顺利的话 9 月底,不顺的话 10 月底但先带人工兜底上线。"关键是把"延期"从意外变成剧本里写好的一条分支。AI 项目延期最伤的不是时间,是信任:第一次延期老板理解,第二次怀疑,第三次项目就没了。把不确定性前置讲清楚,延期就变成"走了 plan B",信任就保住了。
还有一个笨办法但有效:每个里程碑达成后,发一封简短的进展同步,附上评测数据截图。平时持续刷存在感,真到需要延期的那天,你面对的是一个知情的老板,而不是一个被惊喜砸中的老板。