想象你请了一支装修队来改造新家。设计师交给你一份精美的效果图和施工方案，评审会上大家都点头说“挺好，开工吧”。可是，如果你只是对工头喊一句“按图纸装”，会发生什么？水电工不知道第几天进场，瓷砖和线管谁先谁后没人管，木工等了一个月才发现柜子尺寸和插座位置冲突，最后验收时你才发现“开灯不亮、下水不通”。方案的每个字都写得清清楚楚，可现实还是一团糟。 问题出在哪？缺的不是方案，而是一份“落地计划”。装修队需要的是一张施工总表：把“装修”这个大目标拆成拆墙、改水电、贴砖、刷漆这些小事；每件事指定唯一责任人；排好开工完工日期；标清谁依赖谁；写死“空鼓率低于 5%”的验收标准；再约定每周六的工地巡检。这六件事，正是落地计划的全部内核。本文就用这场装修之旅，带你从 AI 项目经理的视角，把“方案到生产”的桥一步步搭起来。这扇门打开后，你会发现：方案落地不是玄学，而是一套可以被反复复制的方法。

岗位关联

对 AI 从业者的价值：落地计划是方案设计文档走向生产交付的关键一环。掌握任务拆解、排期、依赖与验收的设计方法，是从“会写方案”进阶到“能带项目”的必修课，直接决定你的 AI 方案是停留在 PPT 上，还是真正跑在线上。

目录
  1. 可视化演示
  2. 落地计划概览
  3. 任务拆解
  4. 责任人指派
  5. 时间节点规划
  6. 依赖关系管理
  7. 验收标准制定
  8. 里程碑评审
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示任务拆解WBS、依赖关系关键路径、里程碑时间节点及验收标准量化定义，步进式切换深入理解方案落地执行的核心方法论。

本节配有交互动效（进入视口后自动加载，约 3KB）。

WBS任务拆解：层级化分解复杂项目 100%规则：每层分解完整覆盖上层全部工作 分解到可估算、可分配、可追踪的工作单元 WBS遵循MECE原则：互斥且完全穷尽 任务拆解是落地计划的基石。

落地计划概览

装修队开工前，工头会在墙上贴一张“施工总计划”：先拆墙，再改水电，然后瓦工贴砖、木工吊顶、油漆收尾，每一项后面写着师傅名字和大致日期。这张纸不解决“怎么装得好看”，只解决“活儿怎么一件件干完”。落地计划之于技术方案，就是这张纸：方案回答“做什么、为什么这么做”，落地计划回答“谁、何时、以什么顺序、干到什么程度算完”。

在 AI 项目里，方案评审通过后最大的风险往往不是设计缺陷，而是执行走样——算法团队埋头训练，数据团队还在手工清洗，测试团队不知道验收线在哪。落地计划把技术方案映射为一张可执行的任务总表，包含六大要素：任务清单、责任人、时间节点、依赖关系、验收标准、里程碑评审。六者缺一，计划就像少了一条腿的板凳，坐上去就晃。

从文档体系看，落地计划是方案设计文档的“执行镜像”：方案每一章都应对应一组落地动作，方案里承诺的指标都应在验收标准中再现。它不是另起炉灶，而是把“纸上承诺”翻译成“施工动作”。评审通过的方案只说明方向正确，落地计划才保证步伐不乱。

回到装修的比喻：这张施工总计划贴得越清楚，工人越不需要天天跑来问“下一步干啥”。对 AI 团队也一样——方案评审完毕，先别急着写代码，把这张“总表”挂出来，项目就成功了一半。

Plan={ T, R, Sch, Dep, Acc, Ms }\displaystyle Plan = \{\, T,\, R,\, Sch,\, Dep,\, Acc,\, Ms \,\}
这个公式把落地计划“装”进一个集合：六种要素齐备，计划才算完整。
  1. 整体记号 $Plan$表示整份落地计划文档，它是六大要素的集合。
    Plan={⋯ }Plan = \{ \cdots \}
  2. 任务清单 $T$把技术方案拆成的可执行任务集合，是计划的最小单元。
    T={t1,t2,…,tn}T = \{t_1, t_2, \ldots, t_n\}
  3. 责任人 $R$每个任务绑定的唯一负责人，解决“活儿由谁干、找谁问责”。
    R(ti)=某位成员R(t_i) = \text{某位成员}
  4. 排期 $Sch$每项任务的起止时间安排，回答“什么时候干”。
    Sch(ti)=[Si,Ei]Sch(t_i) = [S_i, E_i]
  5. 依赖与验收 $Dep, Acc$任务间的先后约束和完成标准，回答“按什么顺序、干到什么程度”。
    Dep⊆T×T,Acc⊆T×标准Dep \subseteq T \times T, \quad Acc \subseteq T \times \text{标准}
  6. 里程碑 $Ms$计划中的阶段性评审点，用来周期性校正方向。
    Ms={m1,m2,m3}Ms = \{m_1, m_2, m_3\}

任务拆解

装修队不会把“装修”当成一个任务派给工人，因为没人能一口吃掉整栋房子。工头会拆成拆墙、水电改造、贴砖、吊顶、刷漆，再往下拆，贴砖又分为瓷砖到货、地面找平、铺贴、勾缝。这种像剥洋葱一样逐层切分的过程，在项目管理里叫 WBS（工作分解结构）。拆到哪一层才算完？答案是拆到“一个责任人在一个合理周期内能独立交付”为止。

对 AI 项目来说，任务是计划的基本颗粒。一个“做一个推荐系统”的任务注定无法落地，它必须先拆成数据清洗、特征工程、模型训练、离线评测、服务上线等子任务。每个子任务都要有清晰的边界——交付物是什么、范围到哪为止、和相邻任务不重叠、不遗漏。这样任务清单本身就是方案的“清单化复述”，评审时能一眼看出方案承诺的每个能力是否都有对应任务承接。

拆解的粒度是门手艺。太粗，任务两周都完不成，进度失去感知；太细，光管理任务就耗尽心力。业界常用“人日”作为衡量单位：一个任务落在 2 到 16 人日之间比较理想，相当于一个人一周左右能交付的可验证成果。这个区间既保证颗粒可追踪，又不至于碎成粉末。

装修师傅常说“活要干得顺手”，顺手的前提是每一铲都有明确目标。任务拆解就是给团队发一把把“小铲子”，每把铲子都能在几天内挖出一个看得见的坑。拆得清楚，计划就有了血肉。

T总=∑i=1nti,ti∈[2, 16] 人日\displaystyle T_{\text{总}} = \sum_{i=1}^{n} t_i, \qquad t_i \in [2,\,16]\ \text{人日}
总工作量等于所有任务之和，而每个任务应控制在 2 到 16 人日的“一口能吃下”的尺度。
  1. 总工作量 $T_{\text{总}}$方案涉及的全部工作量，用“人日”（一个人一天）计量。
    T总=t1+t2+⋯+tnT_{\text{总}} = t_1 + t_2 + \cdots + t_n
  2. 求和符号 $\sum$把拆出来的所有任务的工作量累加，检查是否覆盖方案的每个模块。
    ∑i=1nti\sum_{i=1}^{n} t_i
  3. 任务单元 $t_i$第 $i$ 个可执行任务的估算工作量。
    ti=工作量it_i = \text{工作量}_i
  4. 粒度区间 $[2,16]$每个任务应落在 2 到 16 人日之间，低于下限说明拆得过碎。
    2≤ti≤162 \le t_i \le 16
  5. 单位“人日”一个人工作一天的工作量，是 AI 项目排期和估人的通用标尺。
    人日=1人×1天\text{人日} = 1\text{人} \times 1\text{天}

责任人指派

装修最怕一个插座三个师傅管：电工说归瓦工，瓦工说归木工，最后谁都没装。所以工头会在任务旁边写死一个名字——“改水电：老王”。这背后是一条朴素原则：一个任务只有一个唯一负责人。若还要备一个监督人，那也只是“问责人”，执行责任永远只有一个人扛。AI 项目里，任务负责人通常就是能对这个任务的交付物签字的人。

光有人还不够，还要对得上号。让一个只写规则引擎的工程师去负责大模型训练，就像让木工去改水路，不是不努力，是技能不匹配。落地计划里应该让负责人与任务能力要求对齐，并在计划中显式标注每个成员的 RACI 角色。RACI 是一张权责分工表：R 是执行者（Responsible），A 是最终问责人（Accountable），C 是被咨询者（Consulted），I 是被告知者（Informed）。其中 A 有且只有一个，而 R 可以多个但必须有主次。

大模型项目还有一招“双人备份”：每个关键任务除了主负责人，再指定一名熟悉上下文的备份人。备份人平时不抢活，但主负责人请假或离职时能无缝顶上。这就像装修队里两个师傅都会贴砖工艺，谁家里有事都不耽误工期。单点依赖是计划里最隐蔽的雷，双人备份就是排雷器。

装修师傅说“我负责的墙，我负责到底”，这种ownership的确定性，正是计划能推进的心理基础。没有唯一负责人，任务清单再漂亮也只是墙上的一张画。

∀ti∈T: ∃! R(ti)∈Team,Backup(ti)≥0\displaystyle \forall t_i \in T:\ \exists!\, R(t_i) \in \text{Team}, \qquad \text{Backup}(t_i) \ge 0
每个任务存在且仅存在一位负责人；备份人可多可少、不可取代唯一负责人。
  1. 全称量词 $\forall$表示“对于每一个任务”，强调规则没有例外。
    ∀ti∈T\forall t_i \in T
  2. 存在唯一 $\exists!$表示“有且只有一个”——任务的主负责人必须唯一。
    ∃! R(ti)\exists!\ R(t_i)
  3. 负责人映射 $R(t_i)$把任务 $t_i$ 映射到团队中的某个成员。
    R:T→TeamR: T \to \text{Team}
  4. 备份约束 $\text{Backup}(t_i) \ge 0$每个任务可以配置零个或多个备份人，但备份不改变唯一负责人。
    Backup(ti)∈{0,1,2}\text{Backup}(t_i) \in \{0, 1, 2\}

时间节点规划

装修的工期表是这么排的：先估算每道工序要几天，再按依赖顺序贴到日历上，最后在“关键路线”上留出缓冲。项目管理的排期逻辑如出一辙：给每个任务估算工期，确定最早可开工时间，把依赖关系映射成时间轴，再用甘特图——也就是横轴时间、竖轴任务的条形图——直观呈现。 AI 项目里，数据准备、模型训练、联调测试这些任务的起止日期一旦排定，团队就有了共同的节拍。

排期最容易踩的坑是“乐观偏差”：大家总是按最顺利的情况估算，忘了 GPU 排队、数据格式返工、接口联调延期。成熟的计划会在关键路径上主动加 10% 到 20% 的缓冲。缓冲放在哪里？放在关键路径的末尾，而不是每个任务都加，否则就失去了排期的意义，成了层层注水的“橡皮筋计划”。

这里必须引入“关键路径”的概念：在所有任务组成的链路中，从起点到终点最长的那条路径决定了总工期。链上的每个任务松弛时间为零——晚一天，全盘晚一天。就像装修里水电改造拖延，贴砖、油漆、家具进场全部顺延。识别出关键路径，管理者才知道眼睛该盯哪几个任务。

工头每天都去关键路径上的工序转一圈，因为那里一堵，全楼停工。排期规划的本质，就是把团队的注意力引向真正决定成败的那几个任务上。

ESi=max⁡j∈Pred(i)(ESj+dj),SLi=LSi−ESi\displaystyle ES_i = \max_{j \in \text{Pred}(i)} \left( ES_j + d_j \right), \qquad SL_i = LS_i - ES_i
一个任务最早何时开工，取决于所有前置任务里“最晚结束”的那个；松弛时间为零的任务构成关键路径。
  1. 最早开始时间 $ES_i$任务 $i$ 在不违反依赖的前提下最早第几天开工。
    ESi=max⁡(⋯ )ES_i = \max(\cdots)
  2. 取最大值 $\max$对任务 $i$ 的所有前置任务 $j$，分别计算“前置开工加前置工期”，取最大。
    ESj+djES_j + d_j
  3. 前置集合 $\text{Pred}(i)$任务 $i$ 的所有前置任务，它是依赖关系在排期中的体现。
    j∈Pred(i)j \in \text{Pred}(i)
  4. 松弛时间 $SL_i$任务 $i$ 能拖延而不影响总工期的余量。
    SLi=LSi−ESiSL_i = LS_i - ES_i
  5. 关键路径判定 $SL_i = 0$松弛时间为零的任务串联起来，就是决定总工期的关键路径。
    LSi−ESi=0LS_i - ES_i = 0

依赖关系管理

装修有铁一般的顺序：水电改造没做完，贴砖就不能开工，因为瓷砖一铺，水管电线就再也够不着了。这种“必须先做完 A 才能做 B”的关系就是依赖。AI 项目同样充满依赖：没有清洗好的数据就没法训练模型，没有模型接口就没法联调，没有联调通过就不能上线。落地计划必须把每对前后关系显式写出来，让执行的人不靠猜。

依赖分几种：硬依赖是物理规律，比如服务上线必须先有代码部署；软依赖是资源约束，比如同一个 GPU 集群不能同时跑两个大训练任务；外部依赖则是团队控制不了的部分，比如第三方数据平台的授权、云厂商的资源配额。对每种依赖，计划里都要标注清楚，并给外部依赖设置风险预案——比如授权迟迟不下来时，先用公开数据集跑通流程。

把所有任务和依赖画出来，会得到一张有向无环图（DAG）：每个任务是一个节点，箭头从前置指向后置，箭头只朝一个方向走、不绕圈。这张图的价值在于让人一眼看出“哪些任务可以并行，哪些必须串行”。能并行的任务排在一起，工期就缩短；必须串行的任务排错了，整个计划就崩了。

装修工头在墙上贴一张“工序地图”，谁先谁后一目了然。依赖管理就是项目里的工序地图——它把“混乱的并行”变成“有序的协同”，是计划从静态清单变成动态系统的关键。

Dep={ (tj,tk)∣tj≺tk }\displaystyle Dep = \{\, (t_j, t_k) \mid t_j \prec t_k \,\}
依赖关系是一个有序对集合：$t_j$ 完成后 $t_k$ 才能开始。箭头只向前，不形成环。
  1. 依赖集合 $Dep$所有依赖关系的汇总，是计划中“顺序”的形式化表达。
    Dep={(tj,tk),…}Dep = \{(t_j, t_k), \ldots\}
  2. 有序对 $(t_j, t_k)$括号内左项在前、右项在后，表示 $t_j$ 是 $t_k$ 的前置。
    (tj,tk)(t_j, t_k)
  3. 偏序符号 $\prec$读作“先于”，是“完成后才能开始”的数学写法。
    tj≺tkt_j \prec t_k
  4. 无环约束依赖箭头不能形成闭环，否则没有任何任务能先开工。
    t1≺t2≺⋯⊀t1t_1 \prec t_2 \prec \cdots \not\prec t_1

验收标准制定

装修验收最怕听到“差不多”“看着行”。专业的做法是拿靠尺量墙面平整度、拿小锤敲瓷砖听空鼓。每一项都有硬指标：空鼓率低于 5%，平整度误差不超过 2 毫米。AI 项目也是一样，任务的完成不能靠感觉，要把“完成定义（Definition of Done）”写进计划：数据清洗任务的交付物是一份无重复、无空值、格式统一的数据集；模型训练任务的交付物是评估指标达到阈值、可复现训练过程的模型文件。

验收标准要满足 SMART 原则：S 具体（具体到指标名），M 可测量（有数值或可观察的结果），A 可达成（跳一跳够得着），R 相关（与方案目标对齐），T 有时限（在某个节点前完成）。一个典型的 AI 验收条目是“离线评测 AUC ≥ 0.85，p99 时延 ≤ 200ms，且灰度 3 天无 P0 告警”——每一条都能被机器或评审人客观判定。

验收标准不只是为了“最后盖章”，它还是执行者的行动指南。当一个训练任务写完代码后，工程师照着验收清单跑一遍，就知道自己算不算真正干完。这就像装修师傅贴完砖，自己先拿小锤敲一遍，不合格的当场返工。标准写进计划，验收就变成了“照单核对”而不是“看人脸色”。

瓷砖贴完不到半天就验收，发现空鼓立刻返工，成本最低。验收标准的本质是把“返工成本”压到最低：越早发现问题，返工的代价越小。把完成定义写死，团队心里那杆秤就校准了。

Accepti=Si∧Mi∧Ai∧Ri∧Ti\displaystyle \text{Accept}_i = S_i \land M_i \land A_i \land R_i \land T_i
一个任务的验收结论，是五项 SMART 特性的逻辑与：任何一项为假，验收就不通过。
  1. 验收结论 $\text{Accept}_i$任务 $i$ 是否通过验收的结果，取值为真或假。
    Accepti∈{真,假}\text{Accept}_i \in \{\text{真}, \text{假}\}
  2. 逻辑与 $\land$五项条件必须同时成立，类似“并且”。
    Si∧Mi∧Ai∧Ri∧TiS_i \land M_i \land A_i \land R_i \land T_i
  3. 具体 $S_i$标准说“什么指标、什么对象”，而不是“性能要变好”。
    Si:明确指标准则S_i: \text{明确指标准则}
  4. 可测量 $M_i$标准能用数值或可观察事实判断，数值从哪来要约定清楚。
    Mi:采集评测结果M_i: \text{采集评测结果}
  5. 可达成 $R_i$ 与时限 $T_i$目标在团队能力范围内，且在指定时间节点前验证。
    Ai∧Ri∧TiA_i \land R_i \land T_i

里程碑评审

装修工头每周六下午带业主巡检：这周水电做完了吗？瓷砖铺到哪了？预算超了没？这种定期巡检，对应到项目里就是里程碑评审。里程碑是计划中人为设置的检查点，一般选在关键路径的交汇处，比如“数据就绪”“模型基线达标”“灰度完成”。它不是日常汇报，而是带着验收标准、对着计划做“体检”。

评审的核心动作是度量偏差：把实际完成的工作量与计划应完成的工作量对比，算出偏差值。偏差在容忍区间内，继续走；偏差超限，就要启动纠偏——加人、调序、砍范围还是延后里程碑，必须当场决策并更新计划。评审最忌讳“报喜不报忧”，所以好的评审机制会预设一个显性的偏差阈值，谁也不能用“快了快了”糊弄过去。

变更控制是评审的另一半。真正的项目没有不变更的，但变更必须走流程：提出变更、评估影响（工期、成本、范围）、评审批准、更新计划。否则就会出现“方案早就改了，计划还是老样子”的脱节。每次里程碑结束，还要做一次复盘：哪些估算准、哪些依赖没看清，沉淀成下一份计划的输入。计划越用越准，团队越来越强，这正是落地计划作为组织资产的复利效应。

每周巡检时，业主问的不是“干得累不累”，而是“和计划比，差在哪”。里程碑评审就是项目版的工地巡检：它让计划不是写一次就扔进抽屉，而是一路被校准、被激活、被传承的活文档。

Δ=EV−PV,通过  ⟺  ∣Δ∣≤ε\displaystyle \Delta = EV - PV, \qquad \text{通过} \iff |\Delta| \le \varepsilon
偏差等于实际完成价值减去计划应完成价值；偏差绝对值在容忍阈值内，评审才放行。
  1. 实际完成价值 $EV$到检查点为止，真正完成的任务量换算出的进度价值。
    EV=∑已达标tiEV = \sum_{\text{已达标}} t_i
  2. 计划完成价值 $PV$按原计划此刻应当完成的任务量。
    PV=∑应达标tiPV = \sum_{\text{应达标}} t_i
  3. 偏差 $\Delta$两者之差，正数表示超前、负数表示落后。
    Δ=EV−PV\Delta = EV - PV
  4. 通过判定 $\iff$当且仅当偏差绝对值不超过设定阈值 $\varepsilon$ 时评审通过。
    ∣Δ∣≤ε|\Delta| \le \varepsilon
  5. 纠偏触发 $|\Delta| > \varepsilon$偏差超限则进入纠偏流程，更新后续排期。
    纠偏:更新 Sch′\text{纠偏}: \text{更新} \ Sch'

AI 应用场景

大模型微调项目落地

阶段：项目实施与交付

解决的问题：传统做法是评审通过后各角色各自开工，数据组不知道交付标准，训练组干等两周才发现数据格式不对，最后验收互相扯皮。落地计划把数据准备、指令标注、微调训练、评测验收拆成任务，每项写清负责人与验收线，让并行团队各守其位。

具体案例：某团队落地法律问答大模型微调，在计划中给“数据清洗”标定“标注一致率 ≥ 95%”的验收标准，并设定“数据就绪”里程碑。第一次评审发现标注进度落后 20%，按预案临时抽调双人备份支援，按时赶上训练窗口。

推荐系统算法重构

阶段：技术方案实施

解决的问题：存量推荐代码重构牵涉特征平台、模型切换、服务上线多个子系统，靠口头沟通经常互相等待：特征没重构完就动模型，上线时才炸锅。用依赖关系图和关键路径排期后，谁先谁后清清楚楚。

具体案例：算法团队把“特征平台重构”排在“模型切换”之前，在关键路径末尾预留两天缓冲，并为核心骨干配置备份人。重构期间骨干请假，备份人无缝接手，总工期反而提前一天完成。

跨团队模型灰度发布评审

阶段：里程碑评审与上线

解决的问题：模型上线前，算法、开发、运维、业务对“能不能发”标准不一，口头验收各说各话。统一完成定义和里程碑评审机制后，每个团队对照验收清单逐项签字，杜绝“我觉得没问题”。

具体案例：某平台每月一次模型灰度发布评审会，对照“离线指标达标、p99 时延、告警率、回滚预案”四张清单逐项确认，任一项不通过即触发变更控制流程，历史上成功拦截过三次带病上线。

Python 演示

python68 行
# -*- coding: utf-8 -*-"""落地计划排期器：根据任务依赖关系计算最早开工时间与关键路径"""  class PlanScheduler:    """核心算法：把任务和依赖建成有向无环图，求排期"""     def __init__(self, name):        self.name = name        self.durations = {}   # 任务 -> 工期(天)        self.prereqs = {}     # 任务 -> 前置任务列表     def add_task(self, task, duration, prereq=None):        self.durations[task] = duration        self.prereqs[task] = prereq or []     def compute_schedule(self):        # 1. 拓扑排序：保证每个任务的前置先被处理        visited, order = set(), []         def dfs(task):            if task in visited:                return            visited.add(task)            for p in self.prereqs[task]:                dfs(p)            order.append(task)         for task in self.durations:            dfs(task)         # 2. 最早开始时间 ES：取所有前置中最大的完成时间        es = {t: 0 for t in self.durations}        for t in order:            for p in self.prereqs[t]:                es[t] = max(es[t], es[p] + self.durations[p])         # 3. 总工期与最晚开始时间 LS：从后往前倒推        finish = {t: es[t] + self.durations[t] for t in self.durations}        total = max(finish.values())        ls = {t: total - self.durations[t] for t in self.durations}        for t in reversed(order):            for nxt in self.durations:                if t in self.prereqs[nxt]:                    ls[t] = min(ls[t], ls[nxt] - self.durations[t])         # 4. 关键路径：最早等于最晚，一天都不能拖延        critical = [t for t in self.durations if ls[t] == es[t]]        return critical, total, es     def show(self):        critical, total, es = self.compute_schedule()        print("项目:", self.name)        print("总工期:", total, "天")        print("关键路径:", " -> ".join(critical))        for t in self.durations:            print(f"  {t}: 最早第{es[t]}天开工, 工期{self.durations[t]}天")  if __name__ == "__main__":    plan = PlanScheduler("AI 推荐系统上线")    plan.add_task("需求确认", 3)    plan.add_task("数据准备", 5, prereq=["需求确认"])    plan.add_task("模型训练", 8, prereq=["数据准备"])    plan.add_task("接口开发", 4, prereq=["需求确认"])    plan.add_task("联调测试", 3, prereq=["模型训练", "接口开发"])    plan.add_task("上线发布", 2, prereq=["联调测试"])    plan.show()
目的：把一个 AI 项目的任务和依赖关系喂给调度器，自动排出最早开工时间、总工期和关键路径，是落地计划中“时间节点规划”和“依赖关系管理”的代码化实现。
  1. plan.add_task("模型训练", 8, prereq=["数据准备"])注册一个任务：模型训练要 8 天，且必须等数据准备完成才能开工。
  2. def dfs(task):递归深度优先的拓扑排序，先把前置任务排进顺序，再排自己，确保依赖永远在前。
  3. es[t] = max(es[t], es[p] + self.durations[p])最早开工时间 = 所有前置任务中“最晚结束”的那个时刻，这是关键路径算法的基石。
  4. ls[t] = min(ls[t], ls[nxt] - self.durations[t])从后往前倒推最晚开始时间，要求自己的结束不能拖累任何后置任务。
  5. critical = [t for t in self.durations if ls[t] == es[t]]最早等于最晚的任务没有任何回旋余地，它们串联起来就是关键路径。
  6. plan.show()程序入口：打印总工期、关键路径和每个任务的最早开工时间，直接复用为计划的排期草稿。

常见误区

误区反正需求天天变，写计划也是白写，还不如边做边看，走一步算一步来得灵活。

正解计划的目的不是预测未来，而是建立“变化的基准线”。没有计划，你连“变了多少”都说不出来，更谈不上纠偏。就像装修没有施工总表，工头永远不知道延期了多少天、该找谁问责。落地计划恰恰是应对变化的最佳工具：变化发生时，对照计划评估影响、走变更控制，而不是一团乱麻地重新摸索。

为何常见：人们把“计划”误解为“预言”，一旦预言不准就全盘否定，却忽略了计划作为对照基准和沟通契约的价值。

误区把任务拆成半天一个，颗粒越小越清楚，最好每两小时就能看到一个产出。

正解过细的拆解会让管理成本盖过执行效率。每个任务都要配负责人、排期、验收标准，拆成 200 个小任务意味着 200 次跟踪，团队光填状态就耗光了精力。合理的粒度是 2 到 16 人日：一个任务一周内能交付、能验证，既保持可见性又不过度管理。拆解的目标是“可管理”，不是“最细”。

为何常见：初学者容易把“细致”等同于“专业”，却没有意识到任务清单也是要维护的成本中心，过度工程化是执行的大敌。

误区验收嘛，跑起来不报错就是好了，写那么多指标纯属浪费时间，反正是自己团队看。

正解“功能正常”是无法验证的主观描述。你说正常，测试说有问题，到最后只能比嗓门。验收标准必须可测量：模型用 AUC、时延用 p99、数据用一致率、告警用 P0 数量。可测量的标准让验收从“口头博弈”变成“照单核对”，也让执行者提前知道靶心在哪，干活时自动对齐。无法量化的条目，要么写成可观察的检查项，要么从标准里拿掉。

为何常见：写具体数值需要动脑、需要评估，而“正常”两个字最省力；等出了问题才想起标准太模糊，返工成本已经付出去了。

误区每个里程碑开个会，各人讲讲“最近在忙什么”“进展还行”，记个纪要就算评审过了。

正解里程碑评审是带着验收标准做的“体检”，核心动作是度量和决策：对照计划算偏差，偏差超阈值就当场定纠偏方案，需要变更加资源就当场评估影响。没有偏差量级的评审只是聊天，没有决策输出的评审只是通知。评审结束时必须有一句明确的话：“计划通过 / 需要调整 / 项目暂停”。

为何常见：人天生回避冲突，报喜不报忧比直面偏差舒服得多，于是评审退化成例会，失去了把关和纠偏的功能。

误区前期各做各的，等联调时再把接口对一对，反正有测试兜底，到时候拉个群解决。

正解依赖关系必须在计划阶段就画清楚，因为它是排期的基础：数据准备晚一周，模型训练、联调、上线全部顺延。等联调才暴露依赖问题，往往意味着大范围返工和排期推倒重来。在计划里提前标识硬依赖、软依赖和外部依赖，给外部依赖设风险预案，才是把不确定性挡在项目早期。

为何常见：前期每个人都觉得自己那摊事能按时完成，依赖问题被“到时候再说”的心态掩盖；直到联调成了卡点，才意识到依赖才是项目真正的骨架。

面试题

Q1. 落地计划的首要作用是什么？

单选题 · easy

  • A.把方案变成执行指南← 正确答案
  • B.替代方案设计文档
  • C.仅供领导审批签字
  • D.记录项目失败经验

答案：A。落地计划是“方案到生产”的桥梁，核心是把设计方案拆成可执行的任务清单，明确谁来做、何时做、怎样算完成。它不替代方案文档，也不只是审批道具，更不是失败记录。选 B 混淆了计划与设计的定位，选 C 和 D 则完全偏离了计划的驱动执行价值。

Q2. WBS 任务拆解的合理粒度一般是多少？

单选题 · easy

  • A.通常在 2 到 16 人日← 正确答案
  • B.通常在 2 到 16 人时
  • C.通常为 1 个人年以上
  • D.通常要求小于 1 小时

答案：A。任务粒度以“人日”计，2 到 16 人日意味着一个人一周左右能交付，既保证进度可感知，又不会碎到难以管理。人时和小时级拆解过度增加管理成本，人年级则粗到无法跟踪。就像装修不能把“贴砖”拆成“每块砖一个任务”，也不能整个屋算一个任务。

Q3. RACI 矩阵中的 R 代表什么？

单选题 · easy

  • A.Responsible 唯一执行人← 正确答案
  • B.Accountable 最终问责人
  • C.Consulted 被咨询角色
  • D.Informed 被告知对象

答案：A。R 是 Responsible，指任务的执行者；A 是 Accountable，指最终问责人，且每个任务只有一个 A。C 是被咨询者，I 是被告知者。容易混淆的是 R 和 A：R 负责干活，A 为结果负责，二者可以不同人，但 A 必须唯一，像装修里“贴砖师傅是 R，工头是 A”。

Q4. 关键路径上的任务松弛时间为？

单选题 · mid

  • A.零，晚一天全盘晚← 正确答案
  • B.半天到一天的余量
  • C.等于任务自身工期
  • D.由项目经理自由定

答案：A。关键路径是决定总工期的最长链路，链上任务的最晚开始时间等于最早开始时间，松弛时间为零。任何一个关键任务延期，总工期必然顺延。这就像装修中水电改造拖延，后续贴砖、刷漆、家具进场全部推迟。松弛时间大于零的任务不在关键路径上。

Q5. 下列属于验收标准应满足特性的是？

多选题 · mid

  • A.指标可量化可测量← 正确答案
  • B.描述主观感受即可
  • C.与实现手段强绑定
  • D.有明确完成时限← 正确答案

答案：AD。验收标准要满足 SMART：可测量（M）和有时限（T），所以 A、D 正确。B 的“主观感受”不可验证，违反可测量原则；C 与实现手段强绑定反而压死技术选型，验收标准应该关注结果而非实现方式，像“空鼓率低于 5%”不规定用什么锤子敲。

Q6. 任务 A 是任务 B 的前置，意味着什么？

单选题 · mid

  • A.A 完成后 B 才能开工← 正确答案
  • B.B 完成后 A 才能开工
  • C.A 和 B 必须同时开工
  • D.A 可以随时调整工期

答案：A。前置关系表达的是“先序后启”：A 完成是 B 开工的必要条件。B 颠倒了先后，C 把串行变成并行，D 忽视了 A 的延期会传导给 B。就像水电改造没完成，贴砖不能开工；A 的工期变动直接影响 B 的最早开始时间，这是依赖管理的基本语义。

Q7. 里程碑评审发现进度偏差-15%，正确做法是？

单选题 · hard

  • A.先定位根因再纠偏← 正确答案
  • B.立即压缩全部工期
  • C.假装没看见继续走
  • D.直接更换项目成员

答案：A。偏差超阈值先做根因分析：是估算乐观、依赖阻塞还是资源不足？再针对根因选择纠偏动作——加人、调序、砍范围或延里程碑。B 的“全部压缩”不区分关键与非关键路径，容易击穿质量；C 回避问题让偏差滚雪球；D 更换成员是最重的动作，不能当作首选，就像工地巡检发现进度慢，先查是材料没到还是师傅偷懒，而不是直接换掉整个班组。

Q8. 落地计划必须包含的要素有？

多选题 · hard

  • A.任务清单与负责人← 正确答案
  • B.时间节点和依赖← 正确答案
  • C.验收标准与里程碑← 正确答案
  • D.每位员工的绩效

答案：ABC。落地计划六大要素是任务清单、责任人、时间节点、依赖关系、验收标准、里程碑评审，A、B、C 分别覆盖其中四项。D 的员工绩效属于人力管理制度，不属于落地计划范畴。计划回答“做什么、谁做、何时做、按什么顺序、做成什么样、何时检查”，绩效评价是另一个管理议题。

Q9. 双人备份的主要作用是？

单选题 · easy

  • A.降低单点风险← 正确答案
  • B.增加团队人数
  • C.提高任务复杂度
  • D.延长项目工期

答案：A。双人备份指关键任务除主负责人外，再指定一名熟悉上下文的备份人，主负责人请假或离职时可无缝接管，本质是降低单点依赖风险。它的目的不是扩充编制、增加复杂度或拖长工期，而是用最小的成本给关键路径上保险。备份人平时不抢活，关键时能顶上。

Q10. 关于里程碑评审机制，正确的是？

多选题 · mid

  • A.评审要对照验收标准← 正确答案
  • B.有偏差就触发纠偏← 正确答案
  • C.评审只是走个过场
  • D.复盘沉淀到文档← 正确答案

答案：ABD。里程碑评审是带标准做体检：对照验收标准核对完成度（A），偏差超阈值就启动纠偏和变更控制流程（B），结束后复盘沉淀成组织资产（D）。C 把评审等同于形式主义例会，恰恰是评审最需要避免的退化。评审的产出必须是明确的决策：通过、调整或暂停，而不是一句“辛苦了”。