目录
PDCA 是一种持续改进的管理方法，也叫 PDCA 循环（戴明循环）。
它的核心思想是：做任何一件事情，都不能只是安排任务、执行任务，还要检查结果、总结问题、改进方法，形成管理闭环。
PDCA 由四个英文单词组成：
一、PDCA 的运作逻辑
PDCA 不是执行一次就结束，而是不断循环，让下一轮工作比上一轮更好。
二、结合 DIC IT 项目延期，详细举例
假设 DIC 正在研发一个 CRM 系统，原计划 9 月 30 日上线，但到了 9 月底仍未完成。
如何用 PDCA 管理？
1. P — Plan（计划）
项目开始前需要明确：
- 目标： 9 月 30 日正式上线 CRM 一期。
- 范围： 实现客户档案、线索管理、客户查重、权限管理。
- 责任： 产品经理负责需求，开发经理负责研发，测试人员负责验收。
- 时间： 需求确认、开发、测试、上线分别安排明确的完成日期。
- 风险： 需求频繁变更、开发资源不足、跨系统接口存在依赖。
关键是不能只说“9 月底上线”，还要明确谁做、何时完成、完成标准是什么。
2. D — Do（执行）
根据计划开展工作。
例如：
- 产品经理输出 PRD，并组织需求评审。
- 开发人员按照开发任务推进。
- 测试人员提前编写测试用例。
- 项目负责人每周检查任务完成情况。
执行过程中还要记录实际进度、遇到的障碍和处理情况。
3. C — Check（检查）
假设 9 月 15 日进行检查，发现：
| 检查事项 | 计划 | 实际 | 问题 |
|---|---|---|---|
| 客户档案 | 100% | 100% | 正常 |
| 线索管理 | 100% | 70% | 开发延期 |
| 客户查重 | 100% | 40% | 需求变更 |
| 权限管理 | 100% | 60% | 资源不足 |
此时不能仅仅得出“项目延期”的结论，还应该分析：
为什么延期？
例如进一步分析发现，客户查重功能在开发过程中，业务提出必须支持企业名称模糊匹配，但前期需求评审并未覆盖该场景。
这说明问题可能不只是开发速度慢，也涉及需求识别和评审机制不足。
4. A — Act（处理与改进）
针对检查发现的问题，制定改进措施。
当前项目纠偏：
- 重新评估剩余工作量。
- 调整开发资源和优先级。
- 对新增需求建立变更评估与审批机制。
- 重新明确上线计划及风险。
长期机制改进：
- 需求评审增加真实业务场景验证。
- 开发前明确需求冻结节点。
- 项目进度实行每周检查。
- 对影响上线的风险建立升级处理机制。
最终将有效的改进措施纳入后续项目管理规范。
注意：A 不仅仅是解决眼前问题，更重要的是避免同类问题再次发生。
三、PDCA 与普通工作方式有什么区别？
假设老板安排：“10 月底完成 CRM 客户查重功能。”
| 普通工作方式 | PDCA 管理方式 |
|---|---|
| 收到任务，开始开发 | 明确目标、范围、时间及验收标准 |
| 开发人员自行推进 | 按计划执行并记录进度 |
| 等到月底看是否完成 | 每周检查进度、质量及风险 |
| 延期了，继续开发 | 分析延期原因并采取纠偏措施 |
| 功能上线，任务结束 | 总结经验，完善需求评审和项目管理机制 |
两种方式最大的区别就是：
普通工作重视“有没有做”，PDCA 更重视“有没有达到目标、为什么、以后如何做得更好”。
四、在 DIC 管理中，还可以用在哪些场景？
除了 IT 项目管理，PDCA 也可以用于：
- IT 运维管理： 制定系统可用性目标 → 执行巡检 → 检查故障与告警数据 → 优化监控和故障处理机制。
- SPS 业务调研： 制定调研计划 → 访谈业务人员 → 检查调研覆盖度和问题真实性 → 补充调研、优化产品规划。
- 流程管理： 制定流程规范 → 按流程执行 → 检查执行质量和异常情况 → 优化流程及责任机制。
- 人员绩效管理： 制定绩效目标 → 开展工作 → 检查指标完成情况 → 辅导改进并调整后续行动。
五、一个非常重要的管理认知
PDCA 中的四个阶段，实际上对应四种管理能力：
- P：规划能力——能否把目标转化为可执行的计划？
- D：执行能力——能否把计划真正落地？
- C：检查能力——能否及时发现实际结果与目标的差距？
- A：改进能力——能否分析原因、解决问题并形成机制？
很多团队的问题不是没有 P 和 D，而是 C 做得不够及时，A 做得不够深入。
例如，项目延期后只是要求开发人员加班赶进度，却没有分析需求变更、资源安排、进度预警等问题。即使当前项目最终上线，下一个项目仍然可能重复延期。
一句话总结：PDCA = 有计划地执行、有依据地检查、有针对性地改进，并通过持续循环不断提升工作质量。
对于 DIC 来说，可以把它理解为：从“任务完成型管理”向“目标结果型、持续改进型管理”转变。