25 | PDCA执行法：怎么推动落地才能“步步为赢”？

Jan 27, 2021

25 | PDCA执行法：怎么推动落地才能“步步为赢”？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

25 | PDCA执行法：怎么推动落地才能“步步为赢”？

2021-01-27 李运华来自北京

《大厂晋升指南》

课程介绍



讲述：安晓辉

时长17:47大小16.24M



你好，我是华仔。
在事中执行阶段，最核心的方法当然就是 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 的方法和技巧，你觉得自己平时做事主要是哪些地方做的不够好？看完这一讲后有什么改进或者提升的想法？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 18

提建议

24 | 3C方案设计法：怎么让你的方案有理有据？

26 | 5W根因分析法：怎么找准问题源头才能治标又治本？

 写留言

精选留言(18)

jss
2021-02-21
信息同步, 这一点很有感触; 在之前的公司中, 我总是自己埋头苦干, 遇到问题, 就想着自己解决; 不知道及时寻求帮助; 自己工作的进度, 也是到了完成的时候才汇报; 缺乏, 阶段性的汇报; 这导致我工作有时候会感觉很痛苦; 之后, 来到新公司, 在同事和领导的影响下, 开始主动汇报工作的进度, 遇到问题及时反馈; 工作起来, 顺畅很多; 其实, 主动汇报工作, 花费的时间很少; 可能就是几句话; 但是, 会给领导, 同事留下靠谱的印象; 而且, 在一个团队, 我的进度往往会影响到其它人, 及时同步信息是非常重要的!
展开
作者回复: 说明你的新公司不错，氛围比较好，恭喜你。
11
Sisyphus235
2021-01-27
反思自身日常 PDCA 的问题： 1.Plan 容易过多或过少，针对重要任务，尤其是和 KPI/OKR 有关的任务，容易过度规划，陷入实施细节的陷阱中；针对日常任务，尤其是看起来简单的任务，比如跨团队实现一个业务功能，容易规划不足，忽略非技术原因带来的挑战； 2.Do 在任务安排上，容易出现重要性倒挂，状态比较差的时候倾向于完成容易的任务，忽略优先级； 3.Check 容易被挤占，遇到了很多问题，但急于解决突发的或者计划的其他任务，而挤占了回溯分析的时间； 4.Act 没有在后续工作中和之前的改进方式建立关联机制，这样很容易停留表面，改进方法只是提出了，但没有切实的落地。
展开
作者回复: 很好的补充。针对第1点的改进建议：Plan从OKR逐步推导过来，因为OKR已经聚焦了，Plan只要不偏离OKR，基本上不用担心太多或者太少。第2点改进建议：感觉你说的第2点和第1点类似，还是计划阶段容易犯的错误。第3点改进建议：养成关键信息给上级汇报的习惯，就不会把这个过程忽略掉了。第4点太常见了，我见过很多团队都是做完总结后，改进就扔到一边去了，这个没有太好的方法，只有负责人或者TL来主动跟进。
9
起而行
2021-04-04
华仔，1.如果项目有延期风险第一时间同步给leader，然后怎么处理呢。一般leader会让自己加班或者另外去找人手帮我? 2.我有时会想自己加加班用周末时间把问题处理了，这样不会被leader知道需要延期，而被认为能力不足 3.为了比较好的技术提升和绩效，在自身排期已经很紧张的情况，又临危受命接了团队的一个紧急又重要的需求，做了2天后发现可能会有很大延期风险，这时应该如何与leader说?
展开
作者回复: 1. leader会有反应，即使他没反应，至少知道了风险，这样后面出问题的时候，不会直接让你全部背锅 2. 这就是做事的技巧了，尽量让leader知道延期不是能力问题，而是进度问题，当然如果自己都认为确实能力不够，那就加班处理吧 3. 实事求是，今早反馈
3
Geek_a2e439
2021-02-15
p d c a 每个环节提到的每个技巧策略，正好就是我缺乏的做事套路。（老被上级说做事没章法）
作者回复: 好好学习😄😄
2
怀揣梦想的学渣
2022-07-06
各位是如何处理备份人员问题的呢，目前我接触过的团队，除了技术很强的同事，鲜有可以随时顶上的人，大多需要交接一段时间才能融入。
作者回复: 平时的工作安排就应该做成AB切换的方式，而不是等到需要顶上的时候再来安排
1
花儿少年
2021-08-04
可能更多人在向上管理的时候不积极，就像你说的老板不问就吭哧吭哧干，啥也不说，导致老板不知道进度，不知道结果，没有功劳，白干一场！
作者回复: 人的惰性吧，知道不好后才能改进。
1
大魔王汪汪
2021-02-27
同上面其他同学所讲，同样没有在汇报上做的更好，特别是负责横向工作之后，需要考虑到不同团队老板风格，不同任务环境的不同，汇报内容与方式都不同，后续需要改进。
作者回复: 横向汇报也不需要那么复杂，不需要每个老板汇报一下，抓住关键内容就可以了
1
毛成方
2023-02-02 来自浙江
看第二遍也有收获
作者回复: 加油，在实际工作中多尝试
毛成方
2023-01-04 来自广东
要及时向上汇报风险点寻求上级的资源不能埋头苦干闭门造车否则被干掉都是一脸懵逼
作者回复: 正解
苍茫大地
2021-12-07
推动需求具体落地，坚持PDCA。我们之前所有的需求都是业务时间节点跟客户定好后倒推，设计与开发时间被压缩太多，最终结果必然不好，不过还好我们的总体架构设计没有马虎。后来通过向上管理，协调了业务、产品、开发，使得沟通更加透明，同步也更加到位，聚焦更有价值，各子任务P的定位更加清晰，则每个迭代的安排都差不多刚刚好，有挑战又不太累人，再加上我们一直注意Check和Act，最终在用户那边的交付，满足周期，又保证了高质量。
展开
作者回复: 做法很好，前提是你的上级不错，愿意听你们的：）
阔别
2021-05-23
CA是不是我们阿里人经常说的复盘
作者回复: 不是，复盘是事后总结
牛非刘
2021-05-02
看到PDCA想起来在华为玩的QCC 被基层玩坏了
作者回复: 先固化后优化，结果最后只有固化，没有优化了
周平
2021-02-25
很多做事的方法，需要好好消化。收获1: 向领导及时同步信息的原则。我一直把握不好，多大的事要找领导，多大的事自己解决。导致我不会经常向领导汇报，一向领导汇报就要整成非常漂亮的文档之类的。这就有可能，我自己工作中的一些问题，领导从其他人口中得知，想想就很尴尬。虽然初心是，我自己能把事情都搞定，让领导省心，并没有故意要隐瞒什么，但却很容易被领导误会成我要隐瞒什么。还有个问题是，领导是什么类型的。比如:我有个习惯是在群里通报进度。后来在一个公司，领导嫌烦，觉得很小的事儿都要告诉他。后来想想，其实是外行领导内行的情况，我汇报了他也不懂，还嫌烦。收获2:处理紧急问题的方法，需要标本兼治。临时方案暂时止损，是治标，下次还会再犯。治本的方案，周期比较长，在业务开发很紧的情况下，很难腾出大块时间来搞这件事。我就是临时方案，一顿操作猛如虎，问题解决，却经常没下文。因为治本方案执行周期长，影响范围大，又没有大块的时间来搞，后来就不再弄了。如果我及时给领导提出出长期解决方案的建议，不管后面我有没有机会实现，也是有益的。
展开
作者回复: 事无巨细都同步确实没必要，一般是有“初步结论、阶段成果、问题、进展”的时候同步，如果不符合这些特征，那么每周汇总一下汇报就差不多了。
共 2 条评论
sugarzhangnotes
2021-02-03
和主管的信息沟通较少，以后多加改进
Geek_pingan_zc
2021-01-29
反思日常pdca的问题: 1.Plan:每个版本都会评估需求，拆分任务，安排每项任务的提测时间，但是遇到重要不紧急的事，因为有更紧急的业务需求，一直往后拖，没有拆分成细项去完成 2. Do:没有向上级汇报的习惯，属于那种埋头干的人 3.Check&Act:check的时候经常分析的是表面原因，没有去分析根因，之前开版本回顾会议，拉上产品测试一起，一开就是2个小时，大家都提出版本过程中遇到的问题，针对每个问题没有去区分哪些是偶发的，哪些是每个版本都会出现的，会议过程中提出的改进意见也很少固化到流程里。
展开
作者回复: 第2点没做好，个人很吃亏啊，一定要注意改正。第1和第3点的问题，可以按照我讲的内容去实践。
王同学
2021-01-27
反思： 1.Plan很多时候只在脑子里想，没有真正的写出来，觉得浪费时间太麻烦。 2.新的项目plan之后不管再怎么仔细的思考，真正到执行的时候还是要不断调整，所以有时直接就不详细制定计划，执行一段时间后再plan。
作者回复: 第1点：学会用工具，并且Plan也不一定要非常正规，我有时候就用todo来记录第2点：计划有调整是正常的，做计划的最大作用不是说一开始就事无巨细想的非常清楚，而是避免自己像无头苍蝇一样乱窜，东抓葫芦西扯瓢
吴科🍀
2021-01-27
PDCA是项目管理常用的方法，teamleader要有关键问题的处理权利，有的时候，往往是需要你去干活，但是有没有相应的授权，难
作者回复: 我在文中强调了“负责人”这个角色用PDCA比较合适，并且讲了几个获取资源和管理的技巧。一般来说“负责人”是有一定的授权的。
Monday
2021-01-27
PDCA感觉A就是D，然后可以理解成PDCDC…
作者回复: 不一样的，A你可以理解为“总结和反应措施”，D就是真正干活

