25 PDCA执行法：怎么推动落地才能“步步为赢”？
你好，我是华仔。
在事中执行阶段，最核心的方法当然就是PDCA执行法了。毕竟一开始工作规划得再好，如果没有落地执行，那么也产出不了任何价值。
PDCA执行法
所谓PDCA执行法，就是把事情的执行过程分成四个环节：计划（Plan）、执行（Do）、检查（Check）和行动（Act），从而把控执行过程，保证具体事项高效高质地落地。
具体流程如下图所示：
这个方法来源于美国质量管理专家休哈特在1930年提出的PDCA循环。
20世纪中后期，美国另一位质量管理专家戴明利用这个理论指导日本企业进行质量管理，极大地提高了日本企业的市场竞争力，也让PDCA循环得以在世界范围内推广。
这也反映出PDCA执行法是一个普适性的方法，适用于各行各业。不过它的实际效果如何，还要取决于使用者有没有掌握各个环节的具体技能。
因为PDCA执行法在不同行业的最佳实践有很大的差异，这一讲我就分享它在互联网行业的使用技巧。
先说明一点，使用PDCA执行法，意味着你要完成制定计划、拆解任务、协调资源、安排责任人和检查结果等工作，所以它比较适合“负责人”这个角色，比如Team Leader、虚拟团队负责人和领域负责人等。
而如果你平时只是执行具体的事项，现阶段还不需要用到PDCA执行法。比如你是刚刚毕业的P5，承担某个项目的某个功能的开发或者测试工作，那么只要遵循项目计划就行了。
不过就算是这样，为了能更快地晋升，你最好也能先掌握这个方法。接下来我就分环节一一讲解使用技巧。
计划（Plan）
第一个环节是计划（Plan），确定具体任务、阶段目标、时间节点和具体责任人。
OKR、3C方案设计与PDCA
看到这里，你可能会有疑问：OKR规划，3C方案设计和PDCA，它们好像都和规划有关，那么它们之间的区别和联系是什么呢？
如果你看过日本人写的关于PDCA的书，比如《高效PDCA工作术》，就会发现他们既用PDCA来规划，也用它来推动落地。
但是我在实践中发现，这样做可能会把长远规划和短期任务混在一起，把长远目标和短期结果混在一起，从而导致你在和团队成员讲解计划和目标的时候，很难准确地区分和平滑地切换。
所以，我把OKR定位成专门用来做规划的方法，把PDCA定位成专门用来做执行的方法。它们的对比如下表所示：
至于3C和OKR的关系，我在上一讲已经提到过：3C方案设计法最典型的应用场景就是基于上一级的OKR来制定自己的OKR。
比如业务规划的1条KR是“新用户增长100万”，运营团队TL分解出“买量60万”的KR。针对这一条买量的KR，从什么渠道去买，抖音、快手还是微信，就可以用3C方案设计法来挑选。
等确定是从抖音买量60万之后，这60万要分几个阶段去买，每个阶段要做什么事，具体责任人是谁，就是PDCA的计划环节要确定的。
所以它们之间的关系是：OKR制定整体规划，3C选择实现方案，PDCA落实具体任务。
业务案例：用户增长
我用一个最简单的业务例子，用户增长，来为你说明它们之间的关系吧。
Step 1：OKR
业务负责人制定了业务OKR，如下图所示：
运营TL对照KR1“6个月内新用户增长100万”，基于自己的专业分析和判断，认为“买量”是一个有效的手段，于是为团队初步分解出一条KR，“买量60万”。
Step 2：3C
买量的具体渠道有很多，运营TL对比不同渠道买量方案的优缺点、投入成本和买量效果，最后确定把“抖音买量60万”作为团队的1条KR，汇报上级后获得批准。
Step 3：PDCA（计划环节）
运营TL拆解“抖音买量60万”这条KR的具体任务，明确时间点、阶段目标和责任人，如下表所示：
注：
- 表格信息仅为示例，你不用关注具体含义。
- Plan中的结果数据之和是超出KR描述的，你可以想想背后的原因。
- 你可以根据自己的需求自由定制表格中的列，比如可以加上“预算”“风险”和“依赖”等，让计划更全面。
计划环节技巧
这个环节的技巧，主要有3条。
1. 处理紧急的事情要长短结合
很多负责人在处理紧急事情的时候会陷入一个两难的境地：
如果采取临时措施，虽然能够快速处理，但没有从根本上解决，后面还可能出现其他问题。
如果采取长远措施，虽然能够从根本上解决，但是投入很大，短期内无法快速落地。
正确的做法是长短结合，先快速解决表面的问题，避免损失，然后规划长期的方法，从根本上解决问题。
比如Redis出现未授权访问漏洞（通过公网可以访问Redis），你可以先通过防火墙或者访问控制来应对，然后通过升级Redis到最新版本来彻底解决。
2. 重要但不紧急的事情拆分多个小项目
很多人负责人都有这样的经历：
对于重要但不紧急的事情，团队都知道，也都想做；可是一旦准备要做，就发现投入太大，没有足够的时间和人员投入。
于是团队每天都忙于处理各种紧急的事情，这些重要但不紧急的事情就一直拖着。
我遇到过这样一个存储系统，因为设计的缺陷（没有采用分库分表，未归档海量历史数据，缓存设计不合理等），线上经常出现性能问题。每次系统一出问题，都是“DBA + 测试 + 开发”团队一顿操作猛如虎，结果一看，还是会影响业务几十分钟甚至几个小时。
团队也知道要优化存储系统设计，但是一看投入这么大，业务版本又那么紧，就一拖再拖，导致各种性能问题反复出现。
正确的做法是拆分为多个小项目来落地，可以按照事情类别来拆分，也可以按照时间迭代来拆分。
我在接手这个存储系统之后，就开始进行优化。我先把措施按照类别拆分为分库分表、大表归档和缓存优化等几个类别；然后发现，分库分表也是大工程，所以就进一步采用时间迭代的方式来拆分，5月份完成A表，6月份完成B表……
经过这样的拆分，原本预计要投入5个人一直做3个月的工作，分散到各个业务版本中逐步落地。虽然前后花费了6个月时间，但不需要从团队抽5个人专门来做优化，业务开发基本不受影响。
3. 学会利用上级的力量来协调资源
对于某些项目，一开始并不能明确需要投入的人力。作为负责人，你很可能在分析之后发现，需要的人力投入比最初预估的要多。
如果你是TL，并且你自己团队的人就可以满足需要，那么你就自己安排就可以了。
比较麻烦的情况是，你发现需要借调其他团队的人才能完成。你可以先尝试自己去跟对方的TL协调，如果你们之间的关系不错，还比较好商量；但如果没什么交情的话，可能就会碰钉子了。
这个时候要怎么办呢？正确的做法是，找上级来协调，然后成立正式的工作组。
首先，上级人脉多，面子大，可以协调和安排的资源更多。
其次，有上级出面，对方团队也更乐意接受安排，因为他们知道这件事情做好了，上级会清楚他们团队的贡献。
另外，如果对方团队真的有困难安排不了，上级也帮你会想其他办法，就算实在想不到办法，至少他也知道了事情的困难。
协调到具体的参与人员后，你需要成立虚拟的工作组，让参与的人员工作有名有份，取得进展和成果之后，也要向上级进行汇报。
执行（Do）
第二个环节是执行（Do），按照计划落地各项具体的活动，比如技术人员完成方案设计、编码和测试等工作。
这个环节的技巧，主要有2条。
1. 根据情况采取相应的管理风格
在指导团队成员执行的时候，负责人经常犯两种错误，一是管得太多，一种是管得太少。
管得太多体现在因为担心团队成员出错，事无巨细都要亲自参与，结果一方面导致自己很累，另一方面让团队成员没有发挥空间，很难得到成长。
管的太少体现在只做任务分配，不做具体指导，万一出问题就找个人背锅，这样虽然自己很轻松，但团队成员仍然得不到成长；而且团队的成果会有很大的不确定性，成员如果能力一般，很可能得不到好的结果。
正确的做法是，根据情况采取相应的管理风格，包括独裁式、民主式、专家式、教练式和授权式等，这方面的内容我会在后面的专项提升部分详细介绍。
2. 做好信息同步
很多人都有的一个坏毛病就是，收到了上级的任务后就只知道埋头干活，只要上级不来问，自己就不说，甚至出了问题都不上报，期望自己搞定，不要打扰上级。
这是一个非常严重的错误做法，特别是出了问题如果你不跟上级说，一旦他通过其他渠道得知，对你的印象都不会好。
一方面他会觉得尴尬，自己团队的问题都不知道，还要等别人来告诉自己；另一方面他会觉得你故意隐瞒问题。
正确的做法是，及时同步信息。根据信息的不同，同步的方式也有差异：
- 对于问题相关的信息，必须立即同步，在问题发生的第一时间、问题取得进展和得到解决的时候都要及时汇报，不要等到解决完了再汇报，更不要以为自己把问题搞定了就可以当作什么事情都没发生。
- 对于任务相关的信息，可以定期同步，比如通过周报、双周报或月报的形式来汇报就可以了。
- 如果有里程碑的事件，也需要及时同步。
检查（Check）
第三个环节是检查（Check），对照计划来检查实际执行结果，明确哪些符合预期、哪些不达预期、哪些超出预期以及存在什么问题等。
这个环节的技巧，主要就是1条。
使用5W分析问题根因
大部分人在分析问题原因的时候，都倾向于归结为表面的外部原因或者客观原因，而不愿意归结为深层的内部原因，尤其是自己的原因。
所以在分析问题原因的时候，存在一种常见的现象，只要某个人说了一个外部原因或者客观原因，感觉团队成员都长舒一口气，然后分析也就到此为止了。
比如团队A负责的某个项目延迟了，团队成员分析原因是负责某外部关联系统X的团队B没有人力支撑进行联调。
表面上看起来，的确是因为团队B人力不足。但实际情况是，X系统是一个中台系统，所有项目都应该提前申请和排期。但是团队A的人员在分析联调配合关系的时候，遗漏了X系统的关联关系，没有预先向B团队申请联调支持，结果临时去申请正好遇到B团队没人支撑，导致联调暂停。
正确的做法是，采用5W根因分析法，不断追问更深一层的根本原因。具体做法我会在下一讲为你详细介绍。
行动（Act）
第四个环节是行动（Act），基于检查的结果，总结经验和教训，明确下一步需要采取的措施。
如果Check的结果是目标已经实现，那么当前PDCA循环结束。
示意图中行动（Act）和计划（Plan）之间用虚线连接，就是因为并不是每次行动都一定要回到计划。
如果Check的结果是目标没有实现，那么就需要调整计划，把经验和教训作为输入，开始新一轮的PDCA循环，如此重复直到目标达成或者取消。
这个环节的技巧，主要有2条。
1. 做好总结汇报
你可能会问：“执行环节不是已经同步了各种信息吗，这里还要总结汇报什么呢？”
其实这两个环节的汇报有很大的区别：
执行环节是同步信息，主要是问题、进展和重要的里程碑事件。
行动阶段是总结汇报，主要是结果是否符合计划的预期，能总结什么经验教训，后续是否需要采取什么措施。
总结汇报不一定要写个PPT来汇报，很多时候写个邮件就差不多了。
2. 每次最多挑选3个改进点落实到流程
行动环节最重要的产出就是经验和教训了。
一个常见的误区是，认为经验和教训越多越好。有些负责人会收集团队全体成员的意见，甚至根据意见的数量来判断团队成员的主动性，于是得到的经验和教训的数量非常多。
我曾经遇到这样的情况，某个团队总结的经验教训有将近100条，项目成员40个人针对经验教训讨论了3个小时都没有讨论完。
事实上大部分经验和教训都是无价值的。
首先，全员收集就会存在凑数的问题，团队成员会拼凑几个没有实际意义的经验教训来证明自己的主动性。
其次，很多经验教训都是偶发的，并不是普遍现象，比如某个成员因生病导致自己负责的部分延迟。
最后，如果来一条经验就落入流程，来一个教训就出一个改进措施，结果只会导致流程越来越臃肿，改进措施越来越多，最后谁都记不清到底有多少。
即使经过筛选和讨论，最后认定有价值的经验和教训，也不是一股脑地固化到流程就可以了。因为任何措施都是有实施成本的，如果成本太高，最终的效果可能大打折扣，甚至会带来新的问题。
比如为了规避某个成员生病导致项目延迟，某团队规定，任何任务都必须有备份人员一起参与，而且备份人员能够随时接手任务。
但是这样做却让原本人力就吃紧的开发团队雪上加霜，整个团队同时支撑的开发项目数量大大下降，严重影响了业务的上线速度，经常被业务方吐槽。
正确的做法是，不要想解决所有问题，而是关注可能重复发生的、影响很大的问题。我建议每次总结的时候，最多挑选3条经验教训相关的改进点落实到流程。（其实3条都已经比较多了，如果每年做10次类似的总结，就可能有30条改进措施了。）
小结
现在，我们回顾一下这一讲的重点内容。
- PDCA执行法就是把事情的执行过程分成四个环节：计划（Plan）、执行（Do）、检查（Check）和行动（Act），从而把控执行过程，保证具体事项高效高质地落地。
- 计划环节确定具体任务、阶段目标、时间节点和具体责任人；执行环节落地各项具体的活动，检查环节检查实际执行结果，行动环节明确下一步需要采取的措施。
- OKR规划法、3C方案设计法和PDCA的计划环节的关系是：OKR制定目标，3C选择方案，PDCA落实任务。
思考题
这就是今天的全部内容，留一道课后思考题给你吧。对照一下PDCA的方法和技巧，你觉得自己平时做事主要是哪些地方做的不够好？看完这一讲后有什么改进或者提升的想法？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
- jss 👍（19） 💬（1）
信息同步, 这一点很有感触; 在之前的公司中, 我总是自己埋头苦干, 遇到问题, 就想着自己解决; 不知道及时寻求帮助; 自己工作的进度, 也是到了完成的时候才汇报; 缺乏, 阶段性的汇报; 这导致我工作有时候会感觉很痛苦; 之后, 来到新公司, 在同事和领导的影响下, 开始主动汇报工作的进度, 遇到问题及时反馈; 工作起来, 顺畅很多; 其实, 主动汇报工作, 花费的时间很少; 可能就是几句话; 但是, 会给领导, 同事留下靠谱的印象; 而且, 在一个团队, 我的进度往往会影响到其它人, 及时同步信息是非常重要的!
2021-02-21 - Sisyphus235 👍（11） 💬（1）
反思自身日常 PDCA 的问题： 1.Plan 容易过多或过少，针对重要任务，尤其是和 KPI/OKR 有关的任务，容易过度规划，陷入实施细节的陷阱中；针对日常任务，尤其是看起来简单的任务，比如跨团队实现一个业务功能，容易规划不足，忽略非技术原因带来的挑战； 2.Do 在任务安排上，容易出现重要性倒挂，状态比较差的时候倾向于完成容易的任务，忽略优先级； 3.Check 容易被挤占，遇到了很多问题，但急于解决突发的或者计划的其他任务，而挤占了回溯分析的时间； 4.Act 没有在后续工作中和之前的改进方式建立关联机制，这样很容易停留表面，改进方法只是提出了，但没有切实的落地。
2021-01-27 - 起而行 👍（5） 💬（1）
华仔，1.如果项目有延期风险第一时间同步给leader，然后怎么处理呢。一般leader会让自己加班 或者另外去找人手帮我? 2.我有时会想自己加加班用周末时间把问题处理了，这样不会被leader知道需要延期，而被认为能力不足 3.为了比较好的技术提升和绩效，在自身排期已经很紧张的情况，又临危受命接了团队的一个紧急又重要的需求，做了2天后发现可能会有很大延期风险，这时应该如何与leader说?
2021-04-04 - 一个帅哥 👍（3） 💬（1）
1 每次做完事情之后都不会进行总结。从不思考做的超出预期的、符合预期的、不符合预期的部分。自然也不会有改进措施，导致下一次的行事风格没有变化。改进措施：每完成一件事，就总结出超出预期的部分、符合预期的部分、不符合预期的部分，然后根据这三个部分提炼出下一次的行动指南（好的部分继续保持，不好的地方按照改进意见在下一次行动中试行。 2 做事情不分重要性和紧急性，总是会高优处理临时接到的事情，每当进行绩效总结的时候就会发现和最初的目标相差甚远，而且做的事情还很散，及其不满意这种结果！改进意见：把事情按照重要和紧急维度进行划分，当临时事情来的时候将其归类，然后决定处理的顺序和具体时间点，甚至可以不处理或者给别人处理。尽量做复杂的、困难的、有价值的事情，少做简单的事情。 3 总是想着去执行，及精力都放在了pdca里面的d，而不会主动规划可以做的事情、不需要做的事情，导致规划能力非常差。改进措施：日常记录做的不好的点；时不时地看看竞品、其它团队在做什么事情，已经做了什么事情，计划要做什么事情，以便找到接下来可以做的事情。
2023-06-11 - 花儿少年 👍（3） 💬（1）
可能更多人在向上管理的时候不积极，就像你说的 老板不问 就吭哧吭哧干，啥也不说，导致老板不知道进度，不知道结果，没有功劳，白干一场！
2021-08-04 - 大魔王汪汪 👍（3） 💬（1）
同上面其他同学所讲，同样没有在汇报上做的更好，特别是负责横向工作之后，需要考虑到不同团队老板风格，不同任务环境的不同，汇报内容与方式都不同，后续需要改进。
2021-02-27 - Geek_a2e439 👍（3） 💬（1）
p d c a 每个环节提到的每个技巧策略，正好就是我缺乏的做事套路。（老被上级说做事没章法）
2021-02-15 - 毛成方 👍（1） 💬（1）
要及时向上汇报风险点 寻求上级的资源 不能埋头苦干 闭门造车 否则被干掉都是一脸懵逼
2023-01-04 - 怀揣梦想的学渣 👍（1） 💬（1）
各位是如何处理备份人员问题的呢，目前我接触过的团队，除了技术很强的同事，鲜有可以随时顶上的人，大多需要交接一段时间才能融入。
2022-07-06 - Geek_pingan_zc 👍（1） 💬（1）
反思日常pdca的问题: 1.Plan:每个版本都会评估需求，拆分任务，安排每项任务的提测时间，但是遇到重要不紧急的事，因为有更紧急的业务需求，一直往后拖，没有拆分成细项去完成 2. Do:没有向上级汇报的习惯，属于那种埋头干的人 3.Check&Act:check的时候经常分析的是表面原因，没有去分析根因，之前开版本回顾会议，拉上产品测试一起，一开就是2个小时，大家都提出版本过程中遇到的问题，针对每个问题没有去区分哪些是偶发的，哪些是每个版本都会出现的，会议过程中提出的改进意见也很少固化到流程里。
2021-01-29 - 悦 👍（0） 💬（1）
我有一个疑惑， 进行3c的时候。我们要把每个c都进行pdca方式都具体排期弄好吗？ 这样会不会时间太多。 一个完整的技术方案是要有排期的。
2023-07-18 - 毛成方 👍（0） 💬（1）
看第二遍 也有收获
2023-02-02 - 苍茫大地 👍（0） 💬（1）
推动需求具体落地，坚持PDCA。我们之前所有的需求都是业务时间节点跟客户定好后倒推，设计与开发时间被压缩太多，最终结果必然不好，不过还好我们的总体架构设计没有马虎。后来通过向上管理，协调了业务、产品、开发，使得沟通更加透明，同步也更加到位，聚焦更有价值，各子任务P的定位更加清晰，则每个迭代的安排都差不多刚刚好，有挑战又不太累人，再加上我们一直注意Check和Act，最终在用户那边的交付，满足周期，又保证了高质量。
2021-12-07 - 阔别 👍（0） 💬（1）
CA是不是我们阿里人经常说的复盘
2021-05-23 - 牛非刘 👍（0） 💬（1）
看到PDCA想起来在华为玩的QCC 被基层玩坏了
2021-05-02