WBS 与项目进度计划

是什么

WBS（工作分解结构）回答"要交付的东西由哪些部分组成"，进度计划回答"这些部分按什么顺序、用多少时间、由谁完成"。两者不能混：先有交付物结构，才有时间安排。直接拉一张任务清单当计划，是最常见的错误。

一句话链路：

交付物 → 工作包 → 活动排序 → 资源与工期 → 关键路径 → 基线 → 滚动更新

WBS 的分解原则

1. 按交付物分解，不按部门分解。按部门分解的 WBS 看起来整齐，但没人对最终交付负责。
2. 拆到"可管理粒度"：能被一个人或一个小组在 1–2 周内完成并验收。太粗无法估，太细管理成本高于收益。
3. 100% 原则：下级所有工作包之和必须完整覆盖上级交付物，不多不少。
4. 每个工作包有唯一负责人，责任人名字写在 WBS 上，而不是写在会议纪要里。
5. 项目具体要求（非产品需求）写进项目手册，不要混进技术规格里。

进度计划的必备要素

一张能用的项目进度计划，必须显式包含以下节点与关系：

要素	为什么必须体现
项目启动会	计划真正开始的时间锚点
质量评审与评审回顾	门径是硬节点，不是软里程碑
客户节点	客户样件、审核、SOP 认可
开始生产（SOP）/ 提前批量	交付承诺的基准
跨项目依赖同步点	与其他项目或外部活动的接口
已批准的变更	计划变更必须可追溯
关键路径	决定项目最短工期的那条链
关键路径风险的应对措施	风险应对要落到具体时间段

分计划联动：产品开发、试验、供应商开发、过程开发各有分计划，由各部门固化后分发，再汇总进主计划。主计划与分计划不同步，是"计划永远在变"的根源。

工期估算怎么做

1. 基于资源估工期：不是"理论上几天能干完"，而是"给这个人、这台设备、这个优先级，实际要几天"。
2. 区分工作类型：设计、试验、采购、制造、验证的周期结构完全不同；试验还要排队和失效重做。
3. 加上真实等待时间：供应商报价、模具制造、客户反馈、审批流转，这些等待常占总周期一半以上。
4. 估不确定性：新技术、新供应商、新工艺要加缓冲，但缓冲要放在项目层而不是每个任务里。
5. 滚动式规划：远期只做粗排，近期做得细；每两周或每月细化下一段。一次排到 SOP 的详细计划，通常一个月后就失真。

关键路径管理

• 关键路径上任何一天延误，项目就延误一天；非关键路径的延误只要不超过浮动时间，不影响交付。
• 资源冲突时优先保关键路径，这是资源调配的第一原则。
• 关键路径会随变更移动，每月重算一次，别拿立项时的关键路径管到量产。
• 关键路径上的风险应对要前置：不能等风险发生了再想办法，那时已经没有浮动时间。

怎么做 / 关键点

1. 先画交付物树，再排时间，两件事分开做、分开评审。
2. 里程碑用"可验证状态"命名（如"B 样冻结"而非"B 样阶段"），避免歧义。
3. 每个工作包写清输入、输出、验收标准、负责人，否则执行时必然扯皮。
4. 基线化：批准后的计划作为基线，变更走变更流程并记录原因。
5. 周更新、月重排：每周更新完成率与阻碍，每月重算关键路径与资源。
6. 用一张纸看全貌：一页主计划（阶段 + 门径 + 客户节点）+ 分计划明细，别让人翻八张表。
7. 计划里体现"谁在等谁"，接口等待是项目最常见的隐性延误。

常见坑

• 任务清单当计划：只有事情没有依赖关系和责任人，谁都能说"我在等别人"。
• WBS 按部门拆：最后交付物没人认领。
• 工期拍脑袋：按"最理想情况"估算，没有缓冲，第一个问题就把计划打穿。
• 忽略等待时间：供应商、客户、审批的周期不进计划，实际进度永远落后。
• 计划不更新：基线成摆设，实际进度靠口头汇报。
• 只盯关键路径不调资源：识别出关键路径却不给人不给设备，等于没识别。
• 粒度失控：拆到几百行任务，更新成本高于管理收益。