职场工具箱之 PDCA：高手做事，都有一个"闭环"

——为什么领导最怕"做着做着就没下文"

职场里有两种人： 一种是"做了"，一种是"做成了"。 区别往往就在于——有没有闭环。

开篇：一个让领导血压升高的场景

周一例会，领导随口问了一句：

"上次那个客户投诉的问题，后来怎么样了？"

你愣了两秒："呃……我当时改了代码……应该没问题了吧？"

领导皱眉："应该？你没跟进吗？"

你心虚地回想：好像……确实没跟进。

当时改完代码就觉得"搞定了"，转头就去忙下一个需求了。至于改完之后有没有效果？有没有新问题？——压根没想过。

这种"做着做着就没下文"的情况，是职场新人的通病。

更扎心的是，你觉得自己"很努力"——每天写代码、开会、回消息，忙得要死。

但在领导眼里，你只是"做了"，而不是"做成了"。

区别在哪？

高手做事有一个特点：闭环。

不只是"执行"，还会"检查"和"复盘"。不只是"开头"，还有"收尾"。

今天这篇文章，我要介绍一个帮你建立闭环思维的经典框架：PDCA 循环。

一、PDCA 是什么？

1.1 来源：质量管理之父的智慧

PDCA 由美国统计学家威廉·爱德华兹·戴明（W. Edwards Deming）在 1950 年代推广，所以也叫"戴明环"（Deming Cycle）。

最早用于工业质量管理，后来被发现——这套方法论适用于几乎所有需要"持续改进"的场景。

无论是生产流水线、软件开发、项目管理，还是个人成长，PDCA 都能用。

1.2 四个字母，四个阶段

PDCA 是四个单词的首字母：

四个阶段形成一个循环，结束后进入下一个循环，螺旋上升：

    ┌─────────────────────────────────┐
    │                                 │
    │    P (Plan)  →  D (Do)         │
    │       ↑              ↓         │
    │    A (Act)   ←  C (Check)      │
    │                                 │
    └─────────────────────────────────┘
              ↓ 改进后
    ┌─────────────────────────────────┐
    │    P' → D' → C' → A' → ...     │
    └─────────────────────────────────┘

关键点：这不是"做一次就完了"，而是不断循环、持续改进。

二、为什么高手都有"闭环"？

2.1 有闭环 vs 没闭环

来看两个场景：

场景 A：没闭环的新人

接到需求 → 写代码 → 提交 → 去做下一个需求

问题来了： - 这个需求上线后效果怎么样？不知道。 - 有没有 bug？等用户投诉才知道。 - 下次类似需求能不能做得更好？没想过。

场景 B：有闭环的高手

接到需求 → 明确验收标准（P）
        → 写代码、提交（D）
        → 上线后跟进指标（C）
        → 复盘：哪里做得好/可以改进（A）
        → 下次需求应用改进（P'）

区别显而易见：高手多了检查和复盘两步。

2.2 领导眼中的"靠谱"

领导判断一个人靠不靠谱，有三个标准：

1. 凡事有交代：交给你的事，不用追着问进展
2. 件件有着落：不会"做着做着就没下文"
3. 事事有回音：做完了会主动汇报结果

这三条，本质上都是闭环。

而 PDCA 正是建立闭环思维的最佳框架。

三、新人最容易漏掉的 C 和 A

3.1 只有 PD，没有 CA

大多数人做事是这样的：

P (计划) ✅  →  D (执行) ✅  →  C (检查) ❌  →  A (处理) ❌

为什么？

• C（检查）需要主动跟进：没人催你去看结果，你就不会去看
• A（处理）需要额外思考：很累，而且"好像也没什么用"

于是，大部分人的工作模式变成了：

计划 → 执行 → 计划 → 执行 → 计划 → 执行……

每次都在"从头开始"，永远没有积累。

3.2 C（Check）：不检查 = 白干

检查是验证"做得对不对"的关键一步。

不检查会发生什么？

• 改了 bug，不知道改好没有
• 做了优化，不知道性能提升了多少
• 上线了功能，不知道用户用不用

正确的做法：

Check 的黄金问题：

"我怎么知道这件事做好了？"

如果你答不上来，说明你漏了 C。

3.3 A（Act）：不复盘 = 白走弯路

处理是把经验沉淀下来的关键一步。

不复盘会发生什么？

• 同样的坑，踩第二遍、第三遍
• 同样的问题，下次还是不会处理
• 做了三年，还是三年前的水平

正确的做法：

Act 有两种结果：

Act 的黄金问题：

"如果让我再做一遍，会有什么不同？"

四、PDCA 实战：四个场景

4.1 场景一：改一个 Bug

P（计划）

• 目标：修复用户反馈的登录失败问题
• 方案：定位到是 token 过期逻辑有问题，改用自动刷新
• 验收标准：测试环境复现 → 修复后不再出现

D（执行）

• 修改代码，本地测试通过
• 提交 MR，code review
• 合并，部署测试环境

C（检查）

• 测试环境复现问题：❌ 已修复
• 让 QA 帮忙回归：✅ 通过
• 上线后监控告警：无新增报错

A（处理）

• 做得好：修复方案清晰，一次改好
• 可改进：之前没有 token 刷新的单元测试，补上
• 沉淀：写一篇 wiki 记录 token 刷新的最佳实践

4.2 场景二：组织一次技术分享

P（计划）

• 目标：让团队了解新上线的监控系统
• 方案：PPT + Demo，30 分钟
• 验收标准：80% 参会者反馈"有收获"

D（执行）

• 准备 PPT 和 Demo 环境
• 发会议邀请，提前发预习材料
• 完成分享

C（检查）

• 发放反馈问卷：85% 反馈"有收获"✅
• 发现问题：Demo 环节时间不够，很多人想上手试

A（处理）

• 做得好：提前发材料，大家带着问题来，讨论更深入
• 可改进：下次 Demo 时间留长一点，或者安排 Hands-on Workshop
• 沉淀：把 PPT 和 Demo 脚本整理成文档，放到 wiki

4.3 场景三：学习一门新技术

P（计划）

• 目标：掌握 Kubernetes 基础，能部署简单应用
• 方案：每天学习 30 分钟，用 minikube 实操
• 时间：2 周
• 验收标准：能独立部署一个 web 应用到 K8s

D（执行）

• 第 1 周：看官方教程，跑通 Hello World
• 第 2 周：部署一个 Go web 应用 + MySQL

C（检查）

• 能部署简单应用：✅
• 发现盲区：对 Service 和 Ingress 的区别还不太清楚

A（处理）

• 做得好：实操驱动，边学边练
• 可改进：下次先看架构全貌，再深入单个概念
• 下一轮 PDCA：专门学习 K8s 网络（Service / Ingress / NetworkPolicy）

4.4 场景四：个人周总结

P（计划）

每周一早上 10 分钟： - 列出本周 Top 3 目标 - 每个目标定义"做好的标准"

D（执行）

• 按优先级推进
• 遇到阻塞及时调整

C（检查）

每周五下班前 10 分钟： - Top 3 完成了几个？ - 没完成的原因是什么？

A（处理）

• 哪些做法奏效？保持
• 哪些做法低效？改进
• 下周 Top 3 是什么？

五、PDCA 与软件工程：从敏捷到 CI/CD

作为程序员，你可能觉得 PDCA 是"管理方法论"，跟写代码没关系。

大错特错。

实际上，现代软件工程的核心实践——敏捷开发、Scrum、CI/CD、DevOps——本质上都是 PDCA 的变体。

5.1 PDCA 与敏捷开发：同根同源

敏捷宣言的核心理念之一是：

"Responding to change over following a plan." （响应变化重于遵循计划）

这不是说"不要计划"，而是说——计划要小步快跑、持续迭代。

这正是 PDCA 的精髓。

对比一下：

敏捷的本质：把一个大 PDCA 拆成无数个小 PDCA，快速循环。

5.2 Scrum 中的 PDCA

如果你用过 Scrum，你会发现每个 Sprint 就是一个完整的 PDCA：

Scrum 里最容易被忽视的两个会议：

• Sprint Review（对应 C）：很多团队把它当成"演示会"，走个过场。实际应该是验证目标是否达成。
• Sprint Retrospective（对应 A）：很多团队觉得"浪费时间"，能省就省。实际上这是持续改进的关键环节。

没有 Retro 的 Scrum = 没有 CA 的 PDCA = 没有闭环

5.3 CI/CD：PDCA 的自动化

CI/CD（持续集成/持续交付）本质上是把 PDCA 自动化、加速化：

Code Commit (P: 我认为这段代码是正确的)
    ↓
CI Build & Test (D: 执行构建和测试)
    ↓
Test Results (C: 检查是否通过)
    ↓
Fix or Merge (A: 失败就修，成功就合并)
    ↓
下一次 Commit (新一轮 PDCA)

CI/CD 的 PDCA 周期有多快？

周期越短，反馈越快，改进越及时。

5.4 TDD：极致的小 PDCA

测试驱动开发（TDD）是 PDCA 的极致形态：

Red-Green-Refactor 循环：

1. P: 写一个失败的测试（定义期望行为）
2. D: 写最少的代码让测试通过
3. C: 运行测试，检查是否通过
4. A: 重构代码，改进设计
   ↓
重复（下一个测试）

TDD 的 PDCA 周期是以"秒"计算的——这就是为什么 TDD 能帮你快速收敛到正确方案。

5.5 代码评审中的 PDCA

Code Review 不只是"找 bug"，它也是一个 PDCA：

高效 Code Review 的关键：A 阶段不只是"改完这次的代码"，而是沉淀经验——

• 发现的问题能否加到 linter 规则里？
• 好的设计模式能否整理成模板？
• 反复出现的坑能否写成团队 Wiki？

5.6 DevOps 与 PDCA：度量驱动的改进

DevOps 强调"度量一切"（Measure Everything），这正是 PDCA 中 Check 环节的核心。

DevOps 的典型度量指标：

有了度量，A 阶段才有依据：

• 部署频率低 → 改进 CI/CD pipeline
• MTTR 高 → 改进监控和告警
• 变更失败率高 → 加强测试覆盖

"没有度量，就没有改进"——这句话换成 PDCA 的语言就是：没有 C，就没有有效的 A。

5.7 迭代式增量开发：多层 PDCA 嵌套

在大型软件项目中，PDCA 是嵌套的：

项目级 PDCA（季度）
  └── 里程碑级 PDCA（月）
        └── Sprint 级 PDCA（周）
              └── Daily 级 PDCA（天）
                    └── CI/CD 级 PDCA（小时）
                          └── TDD 级 PDCA（分钟）

每一层都在循环，每一层都在改进。

这就是"迭代式增量开发"的精髓：

• 增量：每次交付一部分价值（D）
• 迭代：每次循环都反馈和改进（CA）
• 持续：循环永不停止

5.8 软件工程 PDCA 最佳实践清单

一句话总结：

现代软件工程 = PDCA × 自动化 × 高频迭代

六、PDCA vs 其他方法

PDCA 的独特价值：它不是"做一次"，而是"循环做"。

PDCA 与敏捷/DevOps 的关系：

把 PDCA 和其他方法组合：

• SMART + PDCA：用 SMART 定目标（P），用 PDCA 持续推进
• 艾森豪威尔 + PDCA：用艾森豪威尔定优先级，用 PDCA 逐个执行
• 复盘 = CA：复盘其实就是 PDCA 的后半段
• Scrum = PDCA × Sprint：每个 Sprint 都是一个完整的 PDCA

七、常见误区

误区 1：Plan 过度，迟迟不 Do

有些人喜欢"完美计划"，方案改了又改，迟迟不动手。

真相：计划只需要 60% 完善就可以开始执行，剩下的在 CA 中调整。

误区 2：Do 很多，但没有 Check

"我很忙"——忙着执行，但从不检查效果。

真相：没有检查的执行，可能是在错误的方向上努力。

误区 3：Check 了，但不 Act

发现问题了，但没有改进，下次还是一样。

真相：检查的目的是为了改进，不改进等于没检查。

误区 4：把 PDCA 当"一次性流程"

做完一轮就结束了，没有循环。

真相：PDCA 的精髓是持续循环，每一轮都比上一轮更好。

八、一个简单的 PDCA 模板

每次做事时，可以用这个模板问自己四个问题：

## P（计划）
- 这件事的目标是什么？
- 怎么做？
- 怎么算"做好了"？

## D（执行）
- 按计划执行
- 记录过程中的问题

## C（检查）
- 目标达成了吗？
- 有什么偏差？
- 数据/反馈是什么？

## A（处理）
- 哪些做得好？（标准化/复用）
- 哪些可以改进？（进入下一轮 PDCA）
- 有什么经验可以沉淀？

总结

软件工程视角：

一句话总结：

高手做事的闭环 = P → D → C → A → 再来一轮

现代软件工程 = PDCA × 自动化 × 高频迭代

Checklist：PDCA 自检

通用自检：

• [ ] P：我有没有明确的目标和验收标准？
• [ ] D：我在按计划执行吗？
• [ ] C：我有没有检查结果？（不要等别人来问）
• [ ] A：我有没有总结经验？（哪些保持，哪些改进）
• [ ] 循环：这件事结束后，下一轮 PDCA 是什么？

软件工程自检：

• [ ] Sprint 有 Planning + Review + Retro 完整闭环吗？
• [ ] CI/CD 能及时反馈构建/测试结果吗？
• [ ] Code Review 的改进有沉淀成规范吗？
• [ ] 故障有 Post-mortem 和 Action Items 吗？
• [ ] 有监控指标来 Check 系统健康吗？

写在最后

回到开头那个场景——

领导问："上次那个问题，后来怎么样了？"

如果你有 PDCA 的习惯，你会这样回答：

"改完之后我跟进了一周，线上没有再出现类似报错（C）。 我发现之前测试覆盖不够，已经补了单元测试（A）。 下次类似问题应该能更快定位（下一轮 P）。"

这就是闭环。

领导听完，点点头，心想：这小子，靠谱。

下次你做完一件事，准备"去做下一件"的时候，停下来问自己：

「这件事，我闭环了吗？」

如果没有——先把 C 和 A 补上。

做完 ≠ 做好。 有始有终，才叫靠谱。

扩展阅读

PDCA 基础：

• PDCA - Wikipedia
• The Deming Cycle
• 丰田生产方式与 PDCA

软件工程与敏捷：

• Scrum Guide — Scrum 官方指南
• 持续交付 — CI/CD 圣经
• DevOps 实践指南 — 度量驱动的改进
• 重构 — 代码级的持续改进

系列回顾

这是"职场工具箱"系列关于做事方法的文章：

• SMART 原则：把目标定清楚
• 艾森豪威尔矩阵：把优先级排对
• PDCA 循环（本篇）：把过程闭环

记住这个组合：

SMART 定目标 → 艾森豪威尔排优先级 → PDCA 保证闭环

这三个工具组合起来，基本可以覆盖"做事"的全流程。

@startmindmap
* PDCA 循环
** P - Plan 计划
*** 定目标
*** 想方案
*** 定验收标准
** D - Do 执行
*** 按计划干活
*** 记录过程问题
** C - Check 检查
*** 对比结果和目标
*** 收集数据反馈
*** 最容易漏
** A - Act 处理
*** 做得好则标准化
*** 做得不好则改进
*** 进入下一轮
** 软件工程应用
*** Scrum Sprint
*** CI/CD Pipeline
*** TDD 红绿重构
*** Code Review
*** Post-mortem
@endmindmap

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。