PDCA循环

PDCA循环（Plan-Do-Check-Act，戴明环）把改进从一次性的项目事件变成周而复始的制度：每轮循环检验一个假设、沉淀一份标准，方法因此沿螺旋上升，而不是在原地画圆。

一次性改进为何总会退化

多数改进死于成功之后：专项小组立项、冲刺、验收结项，结项的瞬间注意力撤离、人员轮换、旧习惯回流，系统在几周内滑回原稳态。改进没有输给反对者，只是没能在系统里留下任何东西——方案留在了结项报告里，而没有留在每天的工作方式里。失败的根源不在执行力，而在改进的组织方式：它被当成事件，而非制度。事件有始有终，制度没有终点；要让改进不随项目结束而蒸发，需要的是一个强制系统周期性回到问题本身的结构。PDCA 就是这个结构的最简形式。

四阶段：把改进变成制度

这个结构出自质量管理传统：统计学家 Walter Shewhart 提出雏形，W. Edwards Deming 1950 年代将其带入日本，与 Kaizen（改善）实践结合后定型为四阶段，成为 TQM（全面质量管理）的引擎——这段脉络是管理思想演进中过程管理取代结果检验的关键一环，也是管理学概述四大职能中「控制」职能的方法化展开。四个阶段各自回答一个不可跳过的问题：

• Plan（计划）：分析现状、定位根因、设定目标与行动方案。目标怎么写才经得起检验，SMART原则是现成的语法。
• Do（执行）：小范围实施方案并记录过程数据。小是为了压低试错成本，不是缺乏魄力。
• Check（检查）：用数据对照目标，判断效果是否真由方案带来。实践中最薄弱的一环——它要求直面「方案没用」的证据，而组织与人都倾向于宣布成功后跳过验证。
• Act（处理）：验证有效的做法固化为新标准，无效的废弃并修正假设，未解决的问题带入下一轮 Plan。

下表把四阶段的验收要点与常见断点并列——多数「转不起来的 PDCA」都能在最后一列找到病因：

阶段	回答的问题	典型产出	常见断点
Plan	根因是什么	根因分析、目标、方案	把症状当根因，直接开药方
Do	方案跑起来什么样	试点运行、过程数据	跳过试点全面铺开
Check	效果从哪里来	对照数据、归因结论	只报结果不归因，或干脆不验证
Act	什么值得留下	新标准、遗留问题清单	经验不落标准，人走即散

顺序本身是设计的一部分：Check 必须先于 Act——没有验证的标准化，只是把侥幸固化为教条。

螺旋而非圆环：知识如何沉淀

闭环若只是回到起点，转多少圈都在原地。PDCA 画的是螺旋：Act 阶段充当棘轮，标准只在通过验证后更新，于是每轮 Plan 都从新基线出发，而不是重复解决同一个问题。知识沉淀的载体是标准、清单与流程文档——它们构成组织记忆，让人员流动不再等于经验清零。这也是 PDCA 与「坚持」的区别：坚持消耗意志力，棘轮结构则让每轮循环的产出自动成为下一轮的输入。

这套结构在软件工程里有著名的变体：Scrum 把 PDCA 压进固定节奏——sprint 计划是 Plan，迭代交付是 Do，review 是 Check，retrospective 产出的改进行动是 Act。敏捷迭代与 PDCA 不是替代关系而是粒度不同：PDCA 给出逻辑骨架，time-box 提供执行节拍。Deming 晚年本人更推崇 PDSA（以 Study 替代 Check），意在强调检查的目的是学习而非判定合格——与 retrospective 的精神一致。

与 SMART、OKR、KPI 的分工

PDCA 只回答「方法如何迭代」；循环要转起来，Plan 与 Check 两端都需要目标与度量工具补位，各自辖区如下：

• SMART原则服务于 Plan：目标具体、可度量，Check 才有对照基准——不可检验的目标让循环从源头断裂。
• OKR提供复盘节奏：季度周期天然是放大版的 PDCA——周期初的 O 与 KR 是 Plan，季末打分复盘是 Check，据此调整下季度目标是 Act。分工上 OKR 决定「做对的事」，PDCA 迭代「把事做对」。
• KPI与绩效管理提供 Check 的度量基础设施；更高阶的用法是反过来用 PDCA 迭代考核体系本身——绩效评估从年度考核演进为持续绩效管理，正是一轮组织级的 Act。

个人版：周复盘是一个人的 PDCA

组织靠制度跑循环，个人靠节律。最小实现以周为单位：周初计划（Plan）、执行中随手记录（Do）、周末复盘（Check）、把验证有效的做法改成默认规则（Act）。GTD 的 Weekly Review 恰好覆盖后两个阶段——清空收集箱、检视项目清单、更新下一步行动，本质是把个人工作系统本身当作持续改进的对象。个人版 Act 的产出不是组织标准，而是默认选项与环境设计：把有效的做法变成无需每次重新决策的惯例，比依赖意志力可靠得多。