你好，我是华仔。
在事中执行阶段，最核心的方法当然就是PDCA执行法了。毕竟一开始工作规划得再好，如果没有落地执行，那么也产出不了任何价值。
所谓PDCA执行法，就是把事情的执行过程分成四个环节：计划（Plan）、执行（Do）、检查（Check）和行动（Act），从而把控执行过程，保证具体事项高效高质地落地。
具体流程如下图所示：
这个方法来源于美国质量管理专家休哈特在1930年提出的PDCA循环。
20世纪中后期，美国另一位质量管理专家戴明利用这个理论指导日本企业进行质量管理，极大地提高了日本企业的市场竞争力，也让PDCA循环得以在世界范围内推广。
这也反映出PDCA执行法是一个普适性的方法，适用于各行各业。不过它的实际效果如何，还要取决于使用者有没有掌握各个环节的具体技能。
因为PDCA执行法在不同行业的最佳实践有很大的差异，这一讲我就分享它在互联网行业的使用技巧。
先说明一点，使用PDCA执行法，意味着你要完成制定计划、拆解任务、协调资源、安排责任人和检查结果等工作，所以它比较适合“负责人”这个角色，比如Team Leader、虚拟团队负责人和领域负责人等。
而如果你平时只是执行具体的事项，现阶段还不需要用到PDCA执行法。比如你是刚刚毕业的P5，承担某个项目的某个功能的开发或者测试工作，那么只要遵循项目计划就行了。
不过就算是这样，为了能更快地晋升，你最好也能先掌握这个方法。接下来我就分环节一一讲解使用技巧。
第一个环节是计划（Plan），确定具体任务、阶段目标、时间节点和具体责任人。
看到这里，你可能会有疑问：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的具体任务，明确时间点、阶段目标和责任人，如下表所示：
注：
这个环节的技巧，主要有3条。
1. 处理紧急的事情要长短结合
很多负责人在处理紧急事情的时候会陷入一个两难的境地：
如果采取临时措施，虽然能够快速处理，但没有从根本上解决，后面还可能出现其他问题。
如果采取长远措施，虽然能够从根本上解决，但是投入很大，短期内无法快速落地。
正确的做法是长短结合，先快速解决表面的问题，避免损失，然后规划长期的方法，从根本上解决问题。
比如Redis出现未授权访问漏洞（通过公网可以访问Redis），你可以先通过防火墙或者访问控制来应对，然后通过升级Redis到最新版本来彻底解决。
2. 重要但不紧急的事情拆分多个小项目
很多人负责人都有这样的经历：
对于重要但不紧急的事情，团队都知道，也都想做；可是一旦准备要做，就发现投入太大，没有足够的时间和人员投入。
于是团队每天都忙于处理各种紧急的事情，这些重要但不紧急的事情就一直拖着。
我遇到过这样一个存储系统，因为设计的缺陷（没有采用分库分表，未归档海量历史数据，缓存设计不合理等），线上经常出现性能问题。每次系统一出问题，都是“DBA + 测试 + 开发”团队一顿操作猛如虎，结果一看，还是会影响业务几十分钟甚至几个小时。
团队也知道要优化存储系统设计，但是一看投入这么大，业务版本又那么紧，就一拖再拖，导致各种性能问题反复出现。
正确的做法是拆分为多个小项目来落地，可以按照事情类别来拆分，也可以按照时间迭代来拆分。
我在接手这个存储系统之后，就开始进行优化。我先把措施按照类别拆分为分库分表、大表归档和缓存优化等几个类别；然后发现，分库分表也是大工程，所以就进一步采用时间迭代的方式来拆分，5月份完成A表，6月份完成B表……
经过这样的拆分，原本预计要投入5个人一直做3个月的工作，分散到各个业务版本中逐步落地。虽然前后花费了6个月时间，但不需要从团队抽5个人专门来做优化，业务开发基本不受影响。
3. 学会利用上级的力量来协调资源
对于某些项目，一开始并不能明确需要投入的人力。作为负责人，你很可能在分析之后发现，需要的人力投入比最初预估的要多。
如果你是TL，并且你自己团队的人就可以满足需要，那么你就自己安排就可以了。
比较麻烦的情况是，你发现需要借调其他团队的人才能完成。你可以先尝试自己去跟对方的TL协调，如果你们之间的关系不错，还比较好商量；但如果没什么交情的话，可能就会碰钉子了。
这个时候要怎么办呢？正确的做法是，找上级来协调，然后成立正式的工作组。
首先，上级人脉多，面子大，可以协调和安排的资源更多。
其次，有上级出面，对方团队也更乐意接受安排，因为他们知道这件事情做好了，上级会清楚他们团队的贡献。
另外，如果对方团队真的有困难安排不了，上级也帮你会想其他办法，就算实在想不到办法，至少他也知道了事情的困难。
协调到具体的参与人员后，你需要成立虚拟的工作组，让参与的人员工作有名有份，取得进展和成果之后，也要向上级进行汇报。
第二个环节是执行（Do），按照计划落地各项具体的活动，比如技术人员完成方案设计、编码和测试等工作。
这个环节的技巧，主要有2条。
1. 根据情况采取相应的管理风格
在指导团队成员执行的时候，负责人经常犯两种错误，一是管得太多，一种是管得太少。
管得太多体现在因为担心团队成员出错，事无巨细都要亲自参与，结果一方面导致自己很累，另一方面让团队成员没有发挥空间，很难得到成长。
管的太少体现在只做任务分配，不做具体指导，万一出问题就找个人背锅，这样虽然自己很轻松，但团队成员仍然得不到成长；而且团队的成果会有很大的不确定性，成员如果能力一般，很可能得不到好的结果。
正确的做法是，根据情况采取相应的管理风格，包括独裁式、民主式、专家式、教练式和授权式等，这方面的内容我会在后面的专项提升部分详细介绍。
2. 做好信息同步
很多人都有的一个坏毛病就是，收到了上级的任务后就只知道埋头干活，只要上级不来问，自己就不说，甚至出了问题都不上报，期望自己搞定，不要打扰上级。
这是一个非常严重的错误做法，特别是出了问题如果你不跟上级说，一旦他通过其他渠道得知，对你的印象都不会好。
一方面他会觉得尴尬，自己团队的问题都不知道，还要等别人来告诉自己；另一方面他会觉得你故意隐瞒问题。
正确的做法是，及时同步信息。根据信息的不同，同步的方式也有差异：
第三个环节是检查（Check），对照计划来检查实际执行结果，明确哪些符合预期、哪些不达预期、哪些超出预期以及存在什么问题等。
这个环节的技巧，主要就是1条。
使用5W分析问题根因
大部分人在分析问题原因的时候，都倾向于归结为表面的外部原因或者客观原因，而不愿意归结为深层的内部原因，尤其是自己的原因。
所以在分析问题原因的时候，存在一种常见的现象，只要某个人说了一个外部原因或者客观原因，感觉团队成员都长舒一口气，然后分析也就到此为止了。
比如团队A负责的某个项目延迟了，团队成员分析原因是负责某外部关联系统X的团队B没有人力支撑进行联调。
表面上看起来，的确是因为团队B人力不足。但实际情况是，X系统是一个中台系统，所有项目都应该提前申请和排期。但是团队A的人员在分析联调配合关系的时候，遗漏了X系统的关联关系，没有预先向B团队申请联调支持，结果临时去申请正好遇到B团队没人支撑，导致联调暂停。
正确的做法是，采用5W根因分析法，不断追问更深一层的根本原因。具体做法我会在下一讲为你详细介绍。
第四个环节是行动（Act），基于检查的结果，总结经验和教训，明确下一步需要采取的措施。
如果Check的结果是目标已经实现，那么当前PDCA循环结束。
示意图中行动（Act）和计划（Plan）之间用虚线连接，就是因为并不是每次行动都一定要回到计划。
如果Check的结果是目标没有实现，那么就需要调整计划，把经验和教训作为输入，开始新一轮的PDCA循环，如此重复直到目标达成或者取消。
这个环节的技巧，主要有2条。
1. 做好总结汇报
你可能会问：“执行环节不是已经同步了各种信息吗，这里还要总结汇报什么呢？”
其实这两个环节的汇报有很大的区别：
执行环节是同步信息，主要是问题、进展和重要的里程碑事件。
行动阶段是总结汇报，主要是结果是否符合计划的预期，能总结什么经验教训，后续是否需要采取什么措施。
总结汇报不一定要写个PPT来汇报，很多时候写个邮件就差不多了。
2. 每次最多挑选3个改进点落实到流程
行动环节最重要的产出就是经验和教训了。
一个常见的误区是，认为经验和教训越多越好。有些负责人会收集团队全体成员的意见，甚至根据意见的数量来判断团队成员的主动性，于是得到的经验和教训的数量非常多。
我曾经遇到这样的情况，某个团队总结的经验教训有将近100条，项目成员40个人针对经验教训讨论了3个小时都没有讨论完。
事实上大部分经验和教训都是无价值的。
首先，全员收集就会存在凑数的问题，团队成员会拼凑几个没有实际意义的经验教训来证明自己的主动性。
其次，很多经验教训都是偶发的，并不是普遍现象，比如某个成员因生病导致自己负责的部分延迟。
最后，如果来一条经验就落入流程，来一个教训就出一个改进措施，结果只会导致流程越来越臃肿，改进措施越来越多，最后谁都记不清到底有多少。
即使经过筛选和讨论，最后认定有价值的经验和教训，也不是一股脑地固化到流程就可以了。因为任何措施都是有实施成本的，如果成本太高，最终的效果可能大打折扣，甚至会带来新的问题。
比如为了规避某个成员生病导致项目延迟，某团队规定，任何任务都必须有备份人员一起参与，而且备份人员能够随时接手任务。
但是这样做却让原本人力就吃紧的开发团队雪上加霜，整个团队同时支撑的开发项目数量大大下降，严重影响了业务的上线速度，经常被业务方吐槽。
正确的做法是，不要想解决所有问题，而是关注可能重复发生的、影响很大的问题。我建议每次总结的时候，最多挑选3条经验教训相关的改进点落实到流程。（其实3条都已经比较多了，如果每年做10次类似的总结，就可能有30条改进措施了。）
现在，我们回顾一下这一讲的重点内容。
这就是今天的全部内容，留一道课后思考题给你吧。对照一下PDCA的方法和技巧，你觉得自己平时做事主要是哪些地方做的不够好？看完这一讲后有什么改进或者提升的想法？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
评论