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