网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
第二个原因是，这两个阶段的任务并不一定是强制要求的。
比如有些团队的 Team Leader 是问题驱动型的，要么完成项目任务，要么处理问题，而不会主动去规划什么东西，因为规划有时候是一件很费脑筋的事情。
也有的人完成任务就万事大吉，接着去做下一个任务，而不会对当前任务进行总结，不会去想哪些做得好可以传承，做得不好可以改进。
但是如果你有了闭环思维，那么就算不是你自己负责的事情，或者不是强制要求的事情，你也会想方设法地去了解更多信息，思考下次怎么做得更好，这就是晋升原则中的主动原则和成长原则所讲的内容。
以开发人员为例，虽然你只负责开发环节，但是如果按照闭环思维来做事，在做之前你除了理解需求之外，还应该去了解“为什么做这个需求”“需求的价值是什么”（事前规划），需求上线之后，你还应该去了解“需求上线后的结果怎么样？”“具体的业务数据是多少？”“我通过做这件事情收获了什么”（事后总结）等等。
而如果你本来就是端到端地负责某件事情的话，那就更加需要学会事后复盘、给领导汇报等技巧了，而不是做完事情之后被动地等着别人来问结果。
标准二：有方法论指导
有了闭环思维，做事就已经比较靠谱了。但是事情能不能做得漂亮，光有闭环思维是不够的，还需要看你的做事有没有方法论，也就是说，你做事的时候不只是靠经验教训的历史积累，还有一套系统的流程或者模板。
方法论的第一个优势在于，无论遇到什么情况，你都能取得比较好的结果，能够保证交付质量的下限。否则如果只凭经验，那么下次情况稍微发生一些变化，你就不适应了。
方法论的第二个优势在于，你的行为背后是有一套逻辑支撑的，而不是拍脑袋随便拍出来的，这样会更有说服力。
比如你说“我觉得 XX 业务功能可以改一改”，但是又给不出充分的理由，那么别人很可能认为你是在瞎指挥；但如果你采用了 AARRR 漏斗模型来分析业务数据，在这个模型的基础上提出改进建议，那么别人接受的可能性就大多了。
标准三：能拿到好的结果
有了方法论是不是就一定很厉害呢？其实还不一定。
首先，你可能虽然有方法论，但其实你的方法论是错误的。
其次，你之前形成的方法论可能很厉害，但并不适合当前公司或者业务。
所以最后，判断你的方法论好不好，其实还是要看最后的结果好不好，给公司带来了多少价值，这也是晋升原则中的价值原则讲的内容。
虽然我们说是否能够拿到好的结果会有运气的成分，但剔除掉运气的因素，方法论的影响也很大。这也是很多从大公司出来的高 P 人员拿着原来的方法论到了中小公司或者创业公司，生搬硬套导致水土不服的原因。
做事方法
经过多年的实践检验和筛选，我逐步形成了一套系统的做事方法论，它按照闭环思维的三个阶段展开，整体结构如下：
事前规划
OKR 规划法：英特尔提出、谷歌发扬光大的方法，通过合理地设定目标和分解关键成果来弥补 KPI 的缺陷，用于制定工作规划。OKR 规划不同于传统 KPI 规划，更加注重聚焦和逻辑，你可以理解为“OKR 方法教你如何制定牛逼的 KPI”。
事中执行
3C 方案设计法：我原创的方法，通过制定多个备选方案来系统地分析事情相关的方方面面，避免思维狭隘，用于设计合理的落地方案。
PDCA 执行法：美国人提出、日本人发扬光大的方法，通过四个环节的循环来把控执行过程，保证具体事项高效高质地落地，用于推进事情的执行。
5W 根因分析法：丰田集团提出的方法，又叫“丰田五问法”，通过五个为什么来深挖问题本质，用于分析根本原因。
5S 问题处理法：我原创的方法，通过五个步骤来解决问题，化“危”为“机”，用于系统地处理问题。
事后总结
4D 总结法：我原创的方法，通过四个维度来整理做事的收获，能够帮助你在完成任务后进一步全方位地提升自己的能力，用于事后总结。
金字塔汇报法：我参考麦肯锡的金字塔原理所提出的方法，通过遵循四个原则来展示工作成果，从而更容易获得高级别管理人员的认可，用于事后汇报。
四线复盘法：我原创的方法，通过四个角度来复盘重大问题，达到公平公正的处理效果，避免背锅和甩锅，用于重大问题发生后的复盘改进。
小结
以上这些做事方法是我个人经验的归纳总结，希望能给你一些启发。当你不熟悉的时候，可以先照搬这些方法；而当你积累了一定的经验后，就不用再局限于我讲的内容了，可以自己去尝试和总结一些新的方法，不过一定要记得按照我在之前介绍的三条标准来检验。
现在，我们总结一下这一讲的重点内容：
关于做事能力，有三条业界达成共识的判断标准，分别是闭环思维、方法论和结果。
我总结的做事方法分为事前规划、事中执行和事后总结三个阶段，包括 OKR 规划法、3C 方案设计法、PDCA 执行法、5W 根因分析法、5S 问题处理法、4D 总结法、金字塔汇报法和四线复盘法等 8 种方法。
OKR的优势：为什么要用OKR来取代KPI做团队规划？
你好，我是华仔。
如果让 Team Leader（以下简称 TL）选出自己工作中最头疼的几件事，那么团队规划一定是其中之一，因为这件事情很难有确定的标准，感觉怎么做都有一定的道理，但又不太确定什么样的规划才能拿到好结果。
那么是不是说，如果你不是 TL，就不用掌握团队规划的方法了呢？其实并不是这样的。
首先，作为团队成员，你需要理解 TL 的规划，并且根据他的规划分解出自己的规划；当你自己学会了团队规划，就更容易发现潜在的机会，然后跟 TL 争取这些机会。
其次，现在到了 P6+ 级别就可能带人了，如果你想晋升到 P7 的话，必须具备一定的管理能力，而无论你是带实体团队还是虚拟团队，都要掌握团队规划的方法。
KPI：关键绩效指标
团队规划到底要怎么做呢？大家耳熟能详的就是 KPI 了。
KPI 的英文全称是 Key Performance Indicator，意思是关键绩效指标。它把公司的目标自上而下地分解，并且通过相关的关键绩效指标来衡量实际的执行效果。
KPI 的问题
虽然 KPI 规划法曾经的确是比较先进的管理方法，但是到了今天，它的缺点也暴露得很明显。
首先，它只适合标准化的、目标稳定的工作。
比如在一家生产洗衣液的工厂，生产线是标准化的流水线，KPI 可以设定为产量、停机时间和良品率等，产品销售是目标稳定的活动，KPI 可以设定为销售量和市场占有率等。
但是，工厂的技术创新就不适合用 KPI 来衡量了，因为创新有很大的不确定性，既不可能标准化，也不可能稳定产出。
其次，它也会给团队带来不好的风气。
索尼公司前常务董事天外伺朗就写过一篇名为《绩效主义毁了索尼》的文章，痛批 KPI 规划法带来的问题。这篇文章在业界流传很广，其激起的广泛讨论现在都没有停止。
如果我们先抛开文章结论对不对、观点是不是太偏激、索尼对 KPI 的理解是不是准确这些争议不谈，只看其中描述的现象，就会发现很多公司都存在同样的问题，比如：
故意定低指标：几乎所有人都把指标定得比较低，因为这样容易实现。
只顾短期效益：追求眼前利益的风气蔓延，短期内难见效益的工作都受到轻视，比如质量检验和老化处理等。
一切只看指标：上司不把部下当有感情的人来对待，一切都用指标来衡量。
工作和考核本末倒置：绩效考核需要把各种工作量化，但是很多工作无法简单地量化，所以公司在绩效考核上花费了大量的精力和时间，而在真正的工作上却敷衍了事，本末倒置。
KPI 的困惑
KPI 规划法的这些缺点，在互联网公司的技术团队往往会进一步放大，很多 TL 在使用这种方法的时候都遇到过问题，比如：
第一，程序员的工作要怎么量化？
代码行数？版本数？bug 数？这些指标都是不可行的！
比如某通信大厂考核程序员的关键指标是 bug 的数量和等级，而考核测试员的关键指标是发现的 bug 数量和等级。
结果呢？程序员和测试员为了一个问题是 bug 还是需求遗漏、bug 的等级是严重还是一般，能够吵上 2 个小时；2 个小时吵不出结果，就拉上双方主管再吵 2 小时；还吵不出结果，就拉上经理继续吵 2 个小时。
于是最后就看谁会吵，谁官大，搞得程序员和测试员身心俱疲，关系很紧张。
第二，技术团队怎么体现工作贡献呢？
既然代码量、版本数、需求数、bug 数这些指标不可行，那么如何体现技术团队对业务的贡献呢？
有的公司喜欢用“技术团队背 30% 的业务指标”这样的方式来定技术团队的 KPI。比如公司业务的整体目标是“新增用户 100 万”，技术团队直接按照 30% 的比例定自己的 KPI 为“新增用户 30 万”。
但实际上这种 KPI 没有什么意义，因为技术团队的工作并不能直观的转换为业务数据，最后只能是看运气，业务目标达到了技术团队就跟着吃肉，业务目标没达到技术团队就跟着挨罚。
第三，有风险的工作谁愿意做？
很多前瞻性和拓展性的工作也伴随着风险，比如引入 ElasticSearch，理论上是可以提升搜索性能的，但在引入的这一年可能会带来很多问题，之后能带来多少收益还不确定。
在 KPI 的机制下，这种有风险的工作很可能没有人愿意去做，因为大家都不想犯错。
技术团队规划的常见角度
考虑到这些问题，使用 KPI 规划法的时候，很多技术团队的 TL 会从以下 3 个角度来做团队规划：
\1. 解决问题
比如解决版本延迟、线上 Bug 和团队成员士气不高等问题。
这是最容易找的角度，因为没有完美的团队，只要去找，一定能找到问题；而且这个角度看上去就很有价值，因为出问题肯定是不好的，解决掉总归是有好处的。
\2. 优化性能
既包括团队优化，比如提升开发效率和质量，提升团队成员战斗力；也包括技术优化，比如将 App 的崩溃率从 0.5% 优化到 0.3%，将后台接口响应时间从 50ms 优化到 30ms。
这也是很多人喜欢用的一个角度，因为它也非常简单明确，不需要太多的思考，毕竟没有哪个产品和系统是完美的，每年都可以找到各种优化点，并且这些优化点还可以用指标衡量出来，看起来就是一个完美的 KPI。
\3. 引入新技术
比如引入 Flutter 来实现双端统一开发，引入机器学习来实现系统的某个功能。
业界各种新技术不断涌现，新技术有可能让生产效率或者生产质量大幅提升，所以引入新技术看起来既可以提升团队技术水平，又可以提升产品竞争力。
但是，从这些角度来做 KPI 规划，往往拿不到很好的绩效结果。主要原因在于，这些都是团队和技术的角度，没有结合业务目标，所以就算你做得很好，价值也不一定能体现出来。
我曾经多次遇到过这样的场景：
某个技术团队的 TL 兴致高昂地介绍了自己的团队规划。技术领导问了一句：“为什么要现在做这个事情，这个事情给业务带来什么价值？”
结果这位 TL 就答不上来了，因为在整个规划的过程中，他都没有这样思考过。最后，他的规划汇报没通过，被领导要求重新规划。
你可能会认为：这些事情本身都是有价值的呀，为什么不可以作为规划内容呢？比如 App 崩溃率从 0.5% 优化到 0.3%，用户体验肯定是提升了的呀！
我不否认这个事情本身的价值，但是团队规划需要考虑的是如何做才能创造最大的价值。因为团队的资源和时间是有限的，需要让投入产出比最大化。
同样以 App 崩溃率为例，如果你的 App 是在东南亚市场推出，受当地市场的手机档次比较低端的限制，崩溃率 0.5% 跟国内市场比感觉很高了，但其实在当地已经算很好的了。
你花了很大力气，将崩溃率从 0.5% 提升到 0.3%，确实有利于用户体验，但是这部分提升带来的价值对用户来说感知不明显。
相比之下，如果你花同样的资源按照当地用户的操作习惯将 UI 改版，可能效果会非常明显。
OKR：目标与关键成果
为了解决 KPI 规划法的问题，英特尔公司创始人安迪·格鲁夫（Andy Grove）提出了另一种团队规划法，后来由约翰·杜尔（John Doerr）引入谷歌发扬光大。
目前硅谷的知名企业都在使用这种方法，比如微软（Microsoft）、领英（LinkedIn）、推特（Twitter）、亚马逊（Amazon）、脸书（Facebook）和雅虎（Yahoo）等，它就是 OKR 规划法。
OKR 的英文全称是 Objectives and Key Results，意思是目标与关键成果。它的实施步骤是：
首先，设定业务目标（Objectives），比如提升市场占有率。
然后，为每个目标设定关键结果（Key Results），也就是为了实现目标具体要做的事情，以及具体的标准，比如为了实现“提升市场占有率”这个目标，准备“请 XX 明星做代言人”“投入 100 亿做用户补贴”等。
OKR 与 KPI 的区别是什么？
大部分人第一次接触 OKR 的时候都很疑惑：OKR 和 KPI 看上去好像没什么区别，OKR 的一个关键结果（KR）如果用数据来描述，似乎就是 KPI 的一项指标。
既然如此，那么我们为什么要强调用 OKR，而不用 KPI 呢？其实它们的本质区别就藏在名字里。
KPI 的关键词是 Indicators，而 OKR 的关键词是 Objectives。
换句话说，KPI 关注的是数据指标，而 OKR 关注的是业务目标。
我举几个例子来说明吧：
假如你是程序员，如果关注指标，你想到的是代码行数、bug 数和单元测试覆盖率；而如果关注目标，你想到的是解决产品的卡顿问题和实现精准推荐。
假如你是足球运动员，如果关注指标，你想到的是进球数、助攻数、跑动距离和比赛场次；而如果关注目标，你想到的是夺冠、四强和保级。
假如你是曹操专车的业务负责人，如果关注指标，你想到的是司机数量、订单数和乘客数；而如果关注目标，你想到的可能是让曹操专车成为网约车行业第二。
所以，不要小看指标和目标这两个词的力量，它们代表的是两种思维方式。
当你使用 KPI 规划法，更关注数据指标的时候，第一反应是“我要履行什么职责”，思维就会受到限制，只会关注当前已有的工作，不太可能去思考接下来应该做的事情是什么。
而当你使用 OKR 规划法，更关注业务目标的时候，第一反应是“我要做成什么事情”，思维就会更加开阔，而不会局限于当前正在做的事情，可以根据实际情况判断和选择接下来应该要做的事情。
方向对了，就不怕路途遥远；方向不对，数据再漂亮也没有意义。在快速发展的行业，比如互联网行业，我们需要拥抱变化、不断调整，显然 OKR 规划法更加适用。
《绩效主义毁了索尼》这篇文章里有这么一句话：“具有讽刺意味的是，因单枪三束彩色显像管电视机获得成功而沾沾自喜的索尼，却在液晶和等离子薄型电视机的开发方面落后了。”
怎么理解呢？按照 KPI 的思维，彩色显像管电视机是已经在做的产品，自然要把销量数据做得越高越好；但是按照 OKR 的思维，整个行业都在转向液晶和等离子电视，必须尽快切换产品方向。
彼得·德鲁克在《管理的实践》这本书中说道：“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”
这句话非常好地诠释了 KPI 和 OKR 的区别，提炼一下就是：KPI 让我们正确地做事，OKR 让我们做正确的事。
你知道大部分的人的 KPI 是怎么制定的吗？先看有哪几个指标，然后每个指标做一些提升，就当成 KPI 提交。
我就亲身经历过这样的 KPI 讨论场景：
某手游交易网站的产品经理列出了 5 个指标，用户量、成交额、用户安全、发货速度和收入，然后给每个指标设定了一个增长量。
团队内部讨论的时候，我提了一个问题：“为什么要制定这些 KPI？”
产品经理的回答是：“这些指标每个都很重要啊，你说哪个不重要呢？”
事实上，这些指标在不同的时期重要程度是不一样的，有的指标甚至是互相冲突的。
如果业务目标是做到市场份额行业第一，那么用户量作为核心指标必须增长，你需要到百度买流量、补贴新用户和免交易手续费等，但这样做肯定会增加支出、减少收入。
如果集团要求创新业务必须实现盈亏平衡，那么收入作为核心目标必须增长，你就不能免除交易手续费，而是要实现交易阶梯收费，但这样又会影响用户量和成交额，因为会有一部分用户会因为手续费的原因而转移到其他交易平台。
当你用 OKR 规划法的话，需要先根据环境变化和业务发展进行判断和取舍，明确业务目标，然后才能基于目标分解出合理的 KPI。
所以有一种说法是这样的：OKR 其实就是一种牛逼的 KPI 制定方法。
OKR 与 KPI 的联系是什么？
虽然 OKR 和 KPI 有着本质区别，但这并不意味着它们截然相反、水火不容。
前面我也提到过，OKR 的 KR 和 KPI 的表现形式基本一致。比如下面这个例子中的 KR，我们说是它是 KPI 也没什么问题。
某 App 业务负责人的 OKR
O：App 注册用户数达到 5000 万
KR1：2021 全年新增用户 1500 万
KR2：月活用户达到 2500 万
KR3：新用户月留存率达到 40%
所以，OKR 和 KPI 其实有着内在的联系，我觉得它们的关系用下面这张图来形象地表示：
如上图所示，OKR 的 KR 有两种表现形式，一种是 KPI，一种是里程碑。
因为 KPI 的要求是可以量化，而 OKR 的要求是可以衡量，有着微妙的不同。你可以用量化的数据来衡量，也可以用里程碑式的关键节点来衡量。
量化的 KR 很常见，比如前面提到的“2021 全年新增用户 1500 万”。
里程碑式的 KR，指的是关键事项的落地，难以量化但可以衡量。以索尼公司为例，彩色显像管电视的开发项目立项时的 KR 应该是“19XX 年开发出彩色显像管电视”，这就是一个无法量化但可以衡量的结果。
互联网行业常见的里程碑 KR 有“某某业务上线”“完成推荐系统从 0 到 1 开发”“落地敏捷开发流程”这些。
小结
现在，我们回顾一下这一讲的重点内容。
OKR规划法：Team Leader 怎么做团队规划？
你好，我是华仔。
上一讲我介绍了 KPI 的问题和 OKR 的优势，你一定很想知道：OKR 到底要怎么用呢？
其实，用 OKR 做规划可以分为两个阶段。
第一个阶段是，P9/P10 级别的业务负责人针对整条业务线做业务规划。
第二个阶段是，P7/P8 级别的 Team Leader 针对专业团队做团队规划。
你可能会想，做团队规划，是不是只要了解第二阶段就行了呢？然而并不是这样，P7/P8 的 TL 同样要了解第一阶段。
因为你只有理解业务规划背后的逻辑，才能做出与之匹配的团队规划。
这也是为什么在很多公司，当你的级别到了 P7+，就有机会参与业务规划的讨论的原因。
这一讲我就会为你介绍，在这两个阶段怎么使用 OKR 规划法来做规划。
阶段一：业务规划
我们先来看第一个阶段，业务规划。
第一步：聚焦业务目标（O）
业务规划的第一步是聚焦业务目标，也就是 O。
聚焦是 OKR 规划法的第一核心理念，也是 OKR 和 KPI 在做法上的核心区别之一。
业务负责人（有可能不是一个人，而是一个决策团队）使用 OKR 进行规划的时候，要在众多可以选择的方向中，挑出最重要的几个，一般不超过 3 个。
而如果使用 KPI，很多人的进行规划的时候，就是简单地把一些指标的数值分别增加一点。
这就是使用 OKR 规划的优势：聚焦于最重要的事情，争取形成合力和突破。因为目标太多会导致资源投入分散，难以形成突破，形象点说，10 个 60 分的目标不如一个 100 分的目标。
这一步看上去很简单，但其实它是整个 OKR 规划过程中最难的一步。
我参加过很多次业务目标通晒大会，在介绍业务规划的 P9/P10 级别的负责人中，几乎每次都有人被挑战，甚至被批评得很惨。
而业务线内部讨论业务目标时候，也会经常发生激烈的争执，如果争执不下，就只能更高级别的老板来拍板做决定，但其实老板也是凭感觉和经验来拍板的。
为什么会出现这种情况呢？因为做业务规划有两个很大的难点：
一是你面对的环境和处理的信息本身就有很大的不确定性。比如竞品的策略、行业的动态和用户的心理，这些都没法通过数据确切地体现，不管是谁，都只能靠推断甚至是猜测，不可能百分之百保证准确性。
二是就算在条件和信息上达成一致，但不同的人制定规划的时候判断和选择的标准也是不同的。比如说你知道了竞品的策略，那么现在要跟它贴身短打、正面硬刚呢，还是要避其锋芒、错位竞争呢？其实各有各的道理，谁对谁错，可能只有事后诸葛亮才知道。
因为业务规划存在这么大的困难，所以你千万不要觉得 OKR 规划法是包治百病、一用就见效的灵丹妙药。
毕竟方法本身不能取代经验，你还是得在工作中摸爬滚打，慢慢积累经验，加深对业务的理解才行。
不过，聚焦业务目标过程中的互怼和争执，本身也是一个澄清和完善的过程。总的来说，OKR 规划法还是比其他方法（比如 KPI 规划法）更有逻辑，更有说服力。
聚焦的目标可以是定性描述的，比如“提升用户满意度”，也可以是可衡量的，比如“市场占有率排名前三”，通常情况下不要求量化。因为 KR 中会有具体的数据描述，在目标中你只要把数据的意义提炼出来就行了。
如果你一定要在目标中体现数据，也是可以的，具体来说有两种方式。
第一种是在 KR 中直接拆解目标中的数据，KR 的数据总和大于或者等于目标中的数据，比如：
O：新增用户数 2000 万
KR1：短视频平台买量拉新 1000 万
KR2：开发新业务拉新 600 万
KR3：通过与其它平台换量拉新 500 万
第二种是在 KR 中添加辅助的指标，比如：
O：新增用户数 2000 万
KR1：新增用户数 2000 万
KR2：投入资金不超过 1 亿
KR3：新用户月留存率不低于 40%
第二步：分解关键结果（KR）
聚焦业务目标之后，第二步是分解关键结果，也就是 KR。对于每个目标，业务负责人都要提出 3～5 个 KR。
这些 KR 一方面是用来评判目标有没有实现的衡量标准，另一方面也体现了为了实现目标，可能要做的具体事情的范围。
比如业务 KR 说“新增用户数 2000 万”，那么下面的团队可能就会进一步分解出“短视频平台买量 xx 万”“开发新业务拉新 xx 万”之类的工作。
所以 KR 太多不行，比如你列了 10 条，对应的事情太多，会导致精力和资源分散，难以形成突破。
而且 KR 太少也不行，比如你只列 1 条，这既说明没有全面地考虑到各种实现目标的方法，也会导致衡量标准太单一，最后可能会为了追求短期的单个数据指标而忽视业务长远的发展。
比如曾经有业务把“新增用户数 xx 万”作为唯一的 KR，于是下面的 P7/P8 执行的时候只管砸钱买量，不管用户质量。
结果到了年底一看，新增用户数是达标了，但是支出远远超出预算，用户留存率也很差；第二年严格控制预算之后，新增用户数立马被打回原形，用户活跃率更是远远不达标。
所以，业务目标有没有实现，我们需要综合 3～5 个 KR 一起来判断。
上一讲我提到过，KR 有两种表现形式，一种是可以量化的 KPI，比如“用户量增长 100 万”；另一种是虽然不能量化但是可以衡量的里程碑，比如“2021 年 6 月实现千人千面功能”。
所以 KR 不能采取定性的描述，像“用户量大幅增长”这样肯定是不合格的，因为不可衡量。
对于可以量化的 KR，关键在于具体的数值应该定多少，太低了看起来没有挑战，太高了看起来没有希望，但具体定多少并没有明确的标准。一般来说，可以参考历史数据、竞品数据或行业数据，也可以举全公司之力来定一个非常有挑战的目标值。
阶段二：团队规划
现在，我们再来看第二个阶段，团队规划。
第一步：对齐业务 OKR
团队规划的第一步是对齐业务规划的 OKR。
对齐是 OKR 规划的第二核心理念，也是 OKR 和 KPI 在做法上的另一个核心区别。
下一级的 Team Leader 要对照上一级业务 OKR，看看自己的团队能够贡献什么价值和力量，从而让整个公司“心往一处想，劲往一处使”。
假设现在业务规划的 OKR 是：
O：总用户数达到行业第一
KR1：新增用户数 2000 万
KR2：投入资金不超过 1 亿
KR3：新用户月留存率不低于 40%
那么如果你是技术团队的 TL，要怎么对齐呢？
首先，针对 KR1，技术团队能做的包括“降低 App 包大小”“SEO 优化”“开发某某新业务”和“开发小程序”等。
其次，针对 KR2，技术团队能做的不多，除非运营明确说“某个大渠道的 ROI 偏低，主要原因是包太大影响转化”，这时你就可以直接把解决问题作为团队的目标。
最后，针对 KR3，技术团队能做的包括“优化用户体验”“新用户连续签到奖励”和“新用户引导”等。
你可以看到，光是对照业务规划的一个 OKR，我们就能够想到很多关联的事情。按照同样的思路，再对照其他的 OKR 继续分析，把想到的事情分类整合排序形成自己团队的 OKR，对齐业务 OKR 的工作就完成了。
当然，对齐的过程同样需要“聚焦”，你的判断和选择同样得是有逻辑的，不能把所有关联的事情全部都罗列出来去做。
比如刚才这个例子中，针对 KR3“新用户月留存率不低于 40%”，你想到了可以通过“优化用户体验”这个技术手段来提升新用户留存率。
但是，“用户体验”真的是影响新用户留存的关键因素吗？这就需要论证了。你不能简单地摆出“提升用户体验肯定可以提升用户留存”这样的大道理，而是应该通过数据分析或者用户调研的结果来证明它们的逻辑关系。
第二步：补充专业 OKR
对齐业务 OKR 之后，团队规划的第二步是补充专业 OKR。
如果说对齐业务 OKR 是自上而下的传导，那么补充专业 OKR 就是自下而上的提炼。TL 要结合业务目标和团队情况，提出专业上的 OKR，和业务上的 OKR 共同组成团队完整的 OKR。
以技术团队为例，假设现在的业务系统问题比较多，团队成员要花很多时间来处理各种线上问题。
虽然因为团队成员的能力很强，所以最终这些问题没有对业务直接产生什么影响，但是站在整个团队角度来看，这会降低团队成员的工作效率和质量，长期这样就会影响正常的版本开发进度。
针对这种情况，TL 可能需要提炼一个专业目标：季度线上问题平均数量从 XX 减少到 YY。
这样的目标很难通过对齐得到，只能由技术团队自己提出来。
自上而下的传导需要很强的业务理解能力，而自下而上的提炼需要有很强的专业能力，这两种能力相辅相成，用 OKR 做团队规划的时候缺一不可。
所以，OKR 规划法对于 TL 来说，也是一个不小的考验。
举例：技术团队的 OKR 是怎么诞生的
假设某个技术团队负责一款电商 App 的技术工作，现在，我们通过一个完整的例子看看这个团队的 OKR 是怎么诞生的。
第一，业务负责人确定 2021 上半年的业务目标，其中之一是用户量增长（具体来说是增长到行业第三）。
第二，业务负责人分解 KR，比如针对用户量增长这个目标，业务负责人分解出了 3 个 KR，具体如下：
第三，技术团队 TL 拿到业务规划的 OKR 之后，进行对齐。
KR1 是“用户量增长 4000 万”，乍一看好像和技术团队没有太大关系，但实际上这就是技术团队需要基于业务来思考技术的一个典型 KR。
TL 从技术的角度来分析业务的目标：哪些技术指标和用户增长量有关，它们跟哪些技术有关，团队现在具备这些技术吗，还有没有优化的空间？
比如影响用户增长量的一些技术指标，就包括“安装包大小”“App 启动时间”“App 崩溃率”和“App 耗电情况”等。
经过分析，TL 认为目前的安装包太大，并且 App 启动时间较长，于是提出了 2 条对应的 KR：
\1. App 安装包从 20M 缩减到 8M
\2. App 启动时间从 2s 优化到 500ms
KR2 是“买量支出不超过 10 亿”，一般来说这跟技术团队的关系不大，不需要关注。
但是 TL 了解到，现在运营的系统无法评估每个渠道买量效果，所以他增加了 1 条对应的 KR：
\3. 新增渠道质量监测功能
这也反映出，技术团队 TL 如果能了解更多的业务信息，就可以为业务做出更大的贡献。
KR3 是“推出新业务 A”，TL 把它直接变成了自己团队的 1 条 KR：
\4. 推出新业务 A
TL 再继续对齐业务规划的其他 OKR，又得到了 2 条对应的 KR：
\5. 改版 B 业务
\6. 后端服务器接口平均响应时间从 60ms 提升到 30ms
然后，他对这 6 条 KR 进行分类整合排序，归纳出了 2 个目标：
O1：优化技术指标，提升用户体验
O2：保证关键业务和功能上线
所以，TL 通过对齐业务 OKR 得到的结果如下图所示：
第四，技术团队 TL 结合业务目标和团队情况，补充专业 OKR。
当前阶段在技术上有没有重点要做的事情呢？TL 经过思考发现，要实现用户增长，就需要做很多新的尝试性的功能，但是团队目前的版本节奏比较慢，原因是因为版本多而测试环境不足。
为了解决测试环境不足导致版本等待等问题，他得出了一个目标：
O3：提升测试效率
为此，他也分解出了几个 KR：
\1. 添加 4 台测试环境机器
\2. 引入 Docker，支持一台机器搭建 20 套环境
\3. 一键生成全套测试环境
于是，他补充了一个专业上的 OKR，如下图所示：
TL 将业务上的 OKR 和专业上的 OKR 结合起来，就得到了团队完整的 OKR，团队规划也就做好了。
看完这个例子，我想你已经对 OKR 规划法的使用建立了整体的认知。不过你对 OKR 可能还有一些疑问，接下来，我就针对两个常见的问题进行解答。
常见问题
问题一：如果用 OKR 规划法，要怎么做绩效考核呢？
美国硅谷的很多科技公司都用 OKR 取得了很好的效果，但介绍 OKR 的文章往往都会说 OKR 和绩效考核无关。
比如 Facebook 的绩效考核方式是 360 度环评，也就是通过多人打分的方式来对员工进行绩效考核。
目前来看，中国公司推广这种考核方式的可能性似乎不大。那么如果推行 OKR，绩效考核要怎么做呢，难道还要引入另外一套机制吗？
其实我之前提到过，KR 的两种形式，KPI 和里程碑，都要求是可以衡量的。所以，根据 OKR 本身来做绩效考核并没有什么问题，我们可以像考核 KPI 一样来考核 KR。
如果是 KPI 形式的 KR，就是看数值有没有达标，跟原定目标相差多少；
如果是里程碑形式的 KR，就是看事情有没有在规定的时间节点高质量地完成。
为了方便考核，我们甚至可以在制定 KR 的时候，就直接将结果的等级包含进去，比如：
KR1：用户量增长 1000 万（合格）；用户量增长 2000 万（良好）；用户量增长 3000 万（优秀）
不过在做 OKR 绩效考核的时候，还有可能出现两种比较特殊的情况：
第一种情况是，KR 都做到了，但是目标没有实现。
比如我们假设曹操专车的业务目标是“超越滴滴”，KR 是订单数增长 200%，但到了年底盘点一看，订单数增长 300%，超额完成，但行业第一还是滴滴。
那么这种情况怎么处理呢？OKR 的关键是实现目标，从这个角度来看，团队人员的绩效不会太高。
第二张情况是，KR 没有做到，但是目标实现了。
比如某电商 App 的业务目标是“成为行业第三”，年底盘点一看，发现 KR 没达成，但是确实成为了行业第三。
这种情况怎么处理呢？我们就要继续分情况讨论，看看目标到底是怎么实现的。
如果是因为竞争对手都不给力，全靠同行衬托得好，那么这种情况下团队人员的绩效也不会特别高。
但是如果是因为一开始的 KR 确实定得太高，团队为了实现目标，没有把有限的资源浪费在盲目地追求数据指标上，那么这其实是值得肯定的。
而如果是因为外部的不可抗力，比如突发疫情或国际政策变化，团队及时放弃年初制定的 KR，探索出了新的路径来实现目标，那么这就更加值得激励了。
问题二：OKR 规划法可以用来做个人规划吗？
虽然宣传 OKR 的文章一般都会声明 OKR 同样适合个人做规划，但从实践的效果来看，如果是 P7/P8/P9 级别且带了团队的技术主管，个人的规划就是团队的规划，使用 OKR 来做个人规划其实就是团队规划。
对于 P5/P6/P7 级别没有带团队的技术人员来说，使用 OKR 来做个人规划比较别扭，原因在于这个级别的技术人员更多的是执行团队主管安排的任务，自己能掌控的规划内容并不多。
小结
现在，我们回顾一下这一讲的重点。
3C方案设计法：怎么让你的方案有理有据？
你好，我是华仔。
上一讲我介绍了用来制定工作规划的 OKR 规划法。在完成事前规划之后，我们就到了事中执行阶段。
在执行阶段，你可能经常遇到这样的情况，领导审批或者跨部门同事协作的时候，别人对你的想法提出挑战。
比如你提出了一个方案，其他人针对你的方案提了很多疑问，而这些疑问确实是你在做方案时没有考虑到的；或者有人提出了其它的方案，你一时也无法明确地证明你的方案优于别人的方案。
所以在一开始的时候，你就要设计出有理有据的方案，这样才能让别人更加理解、支持和配合你。
3C 方案设计法
要怎么设计呢？我总结出了一个 3C 方案设计法，也就是每次做事的时候都至少设计 3 个方案，然后选择最优的 1 个或者几个方案去执行。
这里的 C 代表 Choice，选择。
3C 方案设计法最典型的应用场景就是基于上一级的 OKR 来制定自己的 OKR。
比如你是负责买量的运营人员，你的 Team Leader 基于上一级业务 OKR，分解出运营团队的某个 KR 是“新用户买量 60 万”，现在交给你来负责执行。
你会发现买量的渠道有很多种，包括抖音、快手、头条、百度、QQ 和微信等。不同的渠道用户特性不同，方式不同，投入产出也不同，你不能每个渠道都买一点，而应该聚焦几个效果好的渠道。
但到底哪几个渠道才是好的呢？你不能简单地凭感觉拍脑袋，而应该有理有据地推导出来。
具体来说，就是提出不同渠道买量的方案，对比这些方案的优缺点、投入成本和买量效果等。如果最后你判断“抖音买量 50 万”和“百度买量 20 万”这两个方案比较好，那么就把这两个方案作为自己的 KR。
向上汇报的时候，你一定会遇到很多挑战，比如“为什么是抖音而不是快手？”“百度的优势在哪里？”
但是这些问题你都有答案，因为你使用 3C 方案设计法的过程，其实就是在不断澄清各种可能的问题。
当然，3C 方案设计法不局限于业务规划和业务方案设计，它也可以用来做技术方案，也可以用来做管理方案；既适合比较重大的事项，也适合日常的判断选择。
下面是几个应用的实例：
三个阶段选出最终方案
3C 方案设计法的使用过程可以分为三个阶段，每个阶段都能够从不同的角度帮助你完善思考，提升方案的说服力。
第一个阶段是预研阶段，你需要设计出 3～5 个备选方案。
这个过程会促使你思考多种可能性，避免思维狭隘错过了更好的方案；而研究不同方案的优缺点可以帮助你系统理解某个领域的知识和技能。
你可能并不一定能很快想出 3 个备选方案，这恰恰说明你对当前的领域或者事情还没有全面的理解和思考，你需要强迫自己一定要想出 3 个备选方案，这个探索的过程就是一个自我提升的过程。
第二个阶段是讨论阶段，你需要把备选方案向上级汇报，或者给其他人评审。
这个过程会让其他人的信息、观点和疑问输入到你的大脑中，进一步全面完善你对每个方案的优缺点、依赖条件和所需资源的理解。
第三个阶段是决策阶段，你需要挑选出最终的方案。
一般来说，如果是互斥的方案，那么选出 1 个最优的落地就行了。
比如新招聘的员工表现不太理想，方案 1 是“立即辞退”，方案 2 是“不辞退，加大培养力度”，方案 3 是“延长试用期 1 个月”，你最终只能挑选 1 个方案落地。
如果是可以并行的方案，那么“3 选 2”或“5 选 3”也是可以的，但是不建议“3 选 3”或“5 选 4”，因为这样执行的时候会没有重点。
列出一些备选方案，只能说明你对领域有一定了解；选出合适的最终方案，才能说明你已经掌握了这个领域，能做到理论和实践相结合。
决策的过程会让你重新审视自己原来提出的方案，尤其是最初倾向的方案，帮助你发现方案的问题、理解的问题、乃至自己决策标准的问题。
3C 方案设计法会耽误效率吗？
你可能会担心，每次都要做 3 个方案，要花不少时间吧，这个 3C 方案设计法会不会耽误做事效率啊？
其实这是一种片面的理解。
首先，虽然前期准备的时间变长了，但是做一件事的整体效率变高了。
“前期匆匆忙忙赶工，后期急急忙忙返工”，这样的情况你肯定遇到过吧？
如果你在前期预研的时候先选出更好的方案，那么更有可能一次就拿到好的结果。一次就把事情做好，肯定比重复好几次效率更高。
其次，虽然负责人投入的精力变多了，但是整个团队的效率变高了。
“方案潦潦草草，讨论轰轰烈烈”，这种情况你肯定也深有体会吧？
如果负责人在设计方案的时候投入更多的精力，那么后续整个团队讨论决策和执行的效率都会提高。
正是因为考虑到效率，3C 方案设计法才提倡准备 3～5 个备选方案。
如果超过 5 个，讨论和决策时需要投入的时间和精力太多。但是少于 3 个也不好，1 个方案容易出现思维狭隘的问题，2 个方案容易出现选择困难的问题，所以说：
1 个方案是陷阱，2 个方案是困境，3 个方案是选择。
对晋升的帮助
我指导团队成员晋升或者自己担任晋升评委的时候，经常遇到这样的场景：
申请者在自述环节自信满满地介绍他做过的某个漂亮的项目，列出了 3～5 个闪光点，并且贴出了详细的数据来证明效果。
然而到了答辩环节，评委只是简单地问了一句“你为什么采取这个方案”，他就卡住了，要么支支吾吾，要么就说一些比较虚的内容，比如这个方案性能高、可靠性高之类的。
然后评委再问一句“性能有多高，跟谁比性能高”，他就彻底答不上来了。
有时候我甚至能从申请者的眼中看出不可思议的表情，仿佛在说：“采取这个方案不是自然而然的吗？还有什么为什么啊？我都列出了这么多优点，选这个方案还用说吗？”
他们当中的大部分人在晋升失败后，都不会认为是自己专业能力不行，而会觉得是自己的口才不行，临场反应不好，甚至有人真的开始去买本书来尝试提升自己的口才。
其实这样的理解是错误的。明明是自己做得很漂亮的事情，结果却在晋升的时候答得不好，根本原因不是口才问题，而是在做事的时候没有深入思考和真正理解。
我也见过所谓口才好的申请者，临场反应能力很强，随便问个问题都能说上 2～3 分钟。但是在评委听来，他说的内容完全是临时拼凑，甚至是瞎扯淡。
有时候评委实在受不了了，还会直接打断正在滔滔不绝地讲废话的申请者。
与其这样回答，还不如直接说不知道。
站在评委视角看，他们在判断申请者能力的时候，需要甄别把事情做好的真正原因：
是因为他自己掌握了相关能力？
还是因为有个厉害的主管直接告诉他怎么做？
又或者是他直接照搬了其他项目的经验？
甚至只是因为他这次运气好？
……
而最常见的甄别方法，就是问“为什么”：
为什么你采取这个方案？
为什么你觉得这个方案好？
为什么不采用另外一种方案？
为什么有某某缺点你还是选择这个方案？
……
所以，如果你想提高自己的晋升成功率，首先要认识到回答问题不能光靠临场反应，更重要的是在平时做事情的时候就要逐步积累，正所谓“台上一分钟，台下十年功”。
晋升答辩的时候，在评委看来：
你能够想出 3 个以上的方案，说明你对领域有系统和全面的理解，或者做事考虑非常周全；
能够详细的分析多个备选方案的优缺点，说明你对领域有深入的理解；
而能够从多个方案中选出落地的方案并最终拿到结果，说明你有一套成熟的评价标准或者原则，展现了你的决策能力。
有的主管可能只是简单地跟你提出“你要加深理解”“全面思考”“深入思考”“明白背后的原因”等比较虚的要求，你听完后还是一脸懵逼。
但是学完这一讲，我想你就知道应该怎么做。只要按照 3C 方案设计法来做事，就自然就能满足这些要求。
我曾经带过一个团队成员，他之前 3 次晋升 P7 都失败了，自己总结的原因都是“太紧张了，口才不好”（他确实比较腼腆内向一些）。
我跟他指出，口才不是关键原因，关键是平时的思考和积累太少，然后在接下来的一年里严格要求他按照“3C 方案设计法”来实践：
重大技术方案设计要做 3 个备选方案
团队管理相关的措施想三个可选方案
每年的团队规划方向也要求想 3 个
一年之后，他再次申请晋升，答辩结束后他就跟我说：“我不怎么紧张了，因为大部分评委的问题，我平时自己都已经想过了。”最后果然顺利地通过了。
小结
现在，我们回顾一下这一讲的重点内容。
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 条改进措施了。）
小结
现在，我们回顾一下这一讲的重点内容。
5W根因分析法：怎么找准问题源头才能治标又治本？
你好，我是华仔。
上一讲我介绍了 PDCA 执行法，它把执行过程分为四个环节。其中在检查（Check）环节，最容易出现的问题就是，分析原因的时候，只看到表层的原因，而没有去深挖深层的根本原因。
这就会导致我们给出的解决方案治标不治本，虽然短时间内做了应急处理，但是按下葫芦浮起瓢，相关的问题之后还会接连不断地冒出来。
5W 根因分析法
怎么解决呢？这就要靠 5W 根因分析法了。它又叫 5Why 分析法或者丰田五问法，最初是由丰田集团创始人丰田佐吉提出的，后来成为丰田汽车公司获得成功的重要方法。（老板提出来的，应用也是自然的 _）
那么，5W 根因分析法到底是什么做的呢？根据丰田汽车公司前副社长大野耐一的描述，就是重复问五次“为什么”，问题的本质和解决办法就会变得显而易见。
大野耐一曾经举过这样一个例子：
问题 1：为什么机器停了？
答：因为机器超载，保险丝烧断了。
问题 2：为什么机器会超载？
答：因为轴承的润滑不足。
问题 3：为什么轴承会润滑不足？
答：因为润滑泵失灵了。
问题 4：为什么润滑泵会失灵？
答：因为它的轮轴耗损了。
问题 5：为什么润滑泵的轮轴会耗损？
答：因为杂质跑到里面去了。
如果到了问题 1 就停止追问，那么工人的措施就是更换保险丝，一段时间后保险丝肯定还会烧断。
如果到了问题 4 就停止追问，那么工人的措施就是更换轮轴，一段时间后轮轴又会很快坏了。
只有当追问到了问题 5，才能找出停机的根本原因，这时工人的措施就是给润滑泵加上防杂质的滤网，从而彻底解决问题。
现在，5W 根因分析法在其他很多企业已经得到了广泛应用，并且融入到了各种管理方法中，比如持续改善法（日本持续改善之父今井正明提出）、精益生产法（美国学者研究丰田后提出的管理哲学）和六西格玛法（摩托罗拉提出的管理策略，杰克·韦尔奇推广到通用公司）等。
虽然它起源于生产过程中问题分析，但是作为一种思维方式，可以应用到很多场景，比如业务分析、技术学习和管理改进等。
接下来，我就针对这三类应用场景分别举例说明，这些都是我亲身经历的例子。
业务分析
第一个场景是业务分析。
在某交易平台的业务规划目标讨论会上，我通过 3 个为什么，了解到了业务目标背后的深层考虑。
问题 1：为什么今年的业务目标是成交金额翻番？
答：因为只有成交金额翻番我们才能达到盈亏平衡点。
问题 2：为什么今年要求达到盈亏平衡点？
答：因为集团要求我们的业务能够自负盈亏。
问题 3：我们本质上还属于创新业务，为什么集团要求我们的业务能够自负盈亏？
答：因为疫情的影响，集团需要开源节流，减少非盈利业务的持续投入。
你可能觉得有些奇怪：怎么这个例子只问了 3 个为什么就结束了呢？
因为 5 个为什么只是一个形象的说法，实际操作中可以是 3 个，也可以是 7 个，关键在于通过追问找到根本原因。
虽然在这个例子中，我们还可以继续问下去，比如：“集团为什么要开源节流，创新业务难道不重要吗？”
但这样的问题，业务团队很难得到确切答案，因为集团的决策背景和讨论信息只有高层才知道，而且就算知道答案，也不会对业务规划目标的理解有更多的帮助。
技术学习
第二个场景是技术学习。
在某次 Netty 培训课上，我通过 5 个为什么，来验证大家是否真的深入理解了 Netty 网络高性能的核心原理。
问题 1：为什么 Netty 网络处理性能高？
答：因为 Netty 采用了 Reactor 模式
问题 2：为什么用了 Reactor 模式性能就高？
答：因为 Reactor 模式是基于 IO 多路复用的事件驱动模式。
问题 3：为什么 IO 多路复用性能高？
答：因为 IO 多路复用既不会像阻塞 IO 那样没有数据的时候挂起工作线程，也不需要像非阻塞 IO 那样轮询判断是否有数据。
问题 4：为什么 IO 多路复用既不需要挂起工作线程，也不需要轮询？
答：因为 IO 多路复用可以在一个监控线程里面监控很多的连接，没有 IO 操作的时候只要挂起监控线程；只要其中有连接可以进行 IO 操作的时候，操作系统就会唤起监控线程进行处理。
问题 5：那还是会挂起监控线程啊，为什么这样做就性能高呢？
答：首先，如果采取阻塞工作线程的方式，对于 Web 这样的系统，并发的连接可能几万十几万，如果每个连接开一个线程的话，系统性能支撑不了；而如果用线程池的话，因为线程被阻塞的时候是不能用来处理其他连接，会出现等待线程的问题。
其次，线上单个系统的工作线程数配置可以达到几百上千，这样数量的线程频繁切换会有性能问题，而单个监控线程切换的性能影响可以忽略不计。
第三，工作线程没有 IO 操作的时候可以做其他事情，能够大大提升系统的整体性能。
这种场景在晋升答辩的时候也会经常发生。评委在考察申请者能力的时候，很喜欢用“夺命连环问”，连续追问为什么。如果平时没有训练和积累，你很可能被问到哑口无言的地步。
这样在晋升答辩的时候，你就能从容应对，不用再害怕评委针对技术深度展开“夺命连环问”了。
管理改进
在某次项目延迟问题的讨论会上，我通过 6 个为什么，把项目延迟的核心原因找了出来。
问题 1：为什么项目延迟了？
答：因为要等测试环境进行测试。
问题 2：为什么要等测试环境？
答：我们只有 2 套测试环境，2 套都已经用于另外两个项目了。
问题 3：为什么只有 2 套测试环境，不能搭建多套吗？
答：现在没有机器用来搭测试环境了，而且我们有将近 20 个子系统，搭建一套可用的测试环境耗时可能要一周。
问题 4：为什么会没有机器，直接申请机器不就可以了？
答：运维今年的预算用完了，不能购买新机器了。
问题 5：为什么一定要用新机器，测试环境对机器性能要求高吗？
答：测试环境对机器性能要求不高，基本能跑就行。
问题 6：那为什么不找运维申请过保机器（使用超过 3 年的机器，即使没坏也要换掉）用来搭建测试环境？
答：之前没想过这个方案。
所以解决方案很简单，直接找运维借几台过保的机器用来搭建测试环境。
不过这还只是短期的解决方案，实际上在问题 3 的回答中，我们还可以发现另外一个问题：搭建一套环境太耗时了。
于是测试开发部启动了一个基于 Docker 的快速搭建环境的项目，项目完成后，任何一个开发或者测试同学花 5 分钟就能生成一套全新可用的环境。
注意事项
通过这 3 个例子，我想你已经理解了 5W 根因分析法的使用技巧。在实际应用的时候，我们还需要注意以下 3 点：
\1. 问题数量不是关键，找到根本原因才是关键
在介绍业务分析这个例子的时候，我已经提到，5W 或者说 5 个为什么只是一个形象的说法，3 个也可以，7 个也可以，关键在于找到根本原因。
所以一个最简单的提问方法就是：下一个问题是对上一个回答的进一步深入。
虽然数量可多可少，但我建议不要少于 3 个，因为凭借 3 个以下的为什么，大概率找不出根本原因；但是也不要多于 7 个，因为如果问了 7 个以上的为什么还没找到根本原因，那就要审视一下问题本身是不是有问题了，比如关注的焦点偏移，前面问的是 A，后面变成了问 B 了。
\2. 首先要明确问题本身
5W 根因分析法起源于生产过程，通常情况下问题都是比较明显的，比如机器停机了或者次品率升高了。但是，还有很多情况下问题本身其实是不明确的，每个人的理解可能都不太一样。
如果没有明确问题就开始问为什么，无论问题多么精彩都没有意义，甚至越精彩离题越远。
比如“成交量大幅下降”，这个问题就不明确，到底下降 10%、30% 还是 50% 才算“大幅”？是同比下降还是环比下降？是某一个子业务下降很多，还是所有子业务都在下降？
如果这些问题都不明确就开始进行根因分析，就很可能得出一大堆似是而非的原因和改进措施。
\3. 避免变成大型“撕逼”现场
在连续追问“为什么”的时候，如果双方没有对这个方法充分达成认识，被问的人很可能觉得你在挑战和质疑他，讨论的现场就会变成大型“撕逼”现场，最后闹得不欢而散。
所以在一开始的时候，就要先解释清楚，待会儿将采用 5W 根因分析法来探讨根本原因，避免挑起情绪对立，引发“撕逼”。
小结
现在，我们回顾一下这一讲的重点内容。
5S问题处理法：怎么应对问题才能转危为机？
你好，我是华仔。
上一讲我介绍了 5W 根因分析法，教你通过追问 5 个为什么来找到问题的根本原因。不过，找到原因不等于解决问题。
这就好比大夫看病，光是看出来患者的病根在心脏还不够，还要明确心脏到底出了什么毛病，是只用服药还是需要做手术，如果要安排手术，具体要怎么操刀。
处理问题也是这样，它是一个复杂的系统工程，既能够反映你的专业能力，又能够反映出你的综合能力。所以问题既有可能成为拖垮你绩效的陷阱，也有可能成为你晋升的机遇，关键在于你如何有效地去处理。
那么问题到底要怎么处理呢？我总结了一个 5S 问题处理法，也就是把处理问题的过程分为 5 个步骤：明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。
接下来，我会为你逐一讲解这 5 个步骤。
第一步：明确问题（Specify）
第一个步骤是，明确问题。
我有个朋友曾经遇到过这样的情况：
领导跟他说，最近团队士气好像不高。他立刻分析了 8 点原因，并提出了针对性的改进意见，还觉得自己反应很快，能力很强。
然后领导就让他负责提升士气，于是他组织培训和团队活动，搞各种评奖，推出各种新制度……干了一大堆事儿。
结果半年后，老板说，感觉士气还是没什么变化。
这其实是很多人都会犯的第一个错误：问题本身都没有明确定义，就直接开始采取行动。结果很可能就是，你做了很多事情，但无法衡量。
所以你一定要提醒自己，在解决问题之前，先要明确问题。（这本来是不言而喻的道理，但是在实际工作中我们往往容易忘记。）
怎么明确呢？根据问题有没有用数据量化，可以分为两种情况。
量化了的问题
首先，对于已经用数据量化的问题，关键在于确认数据是否准确。
通过数据来展现问题是比较直观的，而且很多人认为“数据不会撒谎”，所以他们看到数据之后就直接开始处理。
但其实这种情况也是需要明确问题的。因为数据可能出错，出错的原因有很多种，可能是源数据出错，也可能是计算时出错。
我就多次遇到过报表系统出问题导致业务数据异常的情况；也遇到过统计部门调整算法但是引入 bug，从而导致数据错误的情况。
怎么确认数据是否准确呢？最方便的方法当然是让数据部门去核对，但是可能耗时比较长；而最快速的方法则是通过多个关联数据互相验证。
以互联网电商业务为例，如果月销售收入下降了 20%，但是月订单量和月活用户（MAU，Monthly Active User）都在增长，那么很可能是销售收入的数据统计出了问题。
没有量化的问题
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
散。
所以在一开始的时候，就要先解释清楚，待会儿将采用 5W 根因分析法来探讨根本原因，避免挑起情绪对立，引发“撕逼”。
小结
现在，我们回顾一下这一讲的重点内容。
5S问题处理法：怎么应对问题才能转危为机？
你好，我是华仔。
上一讲我介绍了 5W 根因分析法，教你通过追问 5 个为什么来找到问题的根本原因。不过，找到原因不等于解决问题。
这就好比大夫看病，光是看出来患者的病根在心脏还不够，还要明确心脏到底出了什么毛病，是只用服药还是需要做手术，如果要安排手术，具体要怎么操刀。
处理问题也是这样，它是一个复杂的系统工程，既能够反映你的专业能力，又能够反映出你的综合能力。所以问题既有可能成为拖垮你绩效的陷阱，也有可能成为你晋升的机遇，关键在于你如何有效地去处理。
那么问题到底要怎么处理呢？我总结了一个 5S 问题处理法，也就是把处理问题的过程分为 5 个步骤：明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。
接下来，我会为你逐一讲解这 5 个步骤。
第一步：明确问题（Specify）
第一个步骤是，明确问题。
我有个朋友曾经遇到过这样的情况：
领导跟他说，最近团队士气好像不高。他立刻分析了 8 点原因，并提出了针对性的改进意见，还觉得自己反应很快，能力很强。
然后领导就让他负责提升士气，于是他组织培训和团队活动，搞各种评奖，推出各种新制度……干了一大堆事儿。
结果半年后，老板说，感觉士气还是没什么变化。
这其实是很多人都会犯的第一个错误：问题本身都没有明确定义，就直接开始采取行动。结果很可能就是，你做了很多事情，但无法衡量。
所以你一定要提醒自己，在解决问题之前，先要明确问题。（这本来是不言而喻的道理，但是在实际工作中我们往往容易忘记。）
怎么明确呢？根据问题有没有用数据量化，可以分为两种情况。
量化了的问题
首先，对于已经用数据量化的问题，关键在于确认数据是否准确。
通过数据来展现问题是比较直观的，而且很多人认为“数据不会撒谎”，所以他们看到数据之后就直接开始处理。
但其实这种情况也是需要明确问题的。因为数据可能出错，出错的原因有很多种，可能是源数据出错，也可能是计算时出错。
我就多次遇到过报表系统出问题导致业务数据异常的情况；也遇到过统计部门调整算法但是引入 bug，从而导致数据错误的情况。
怎么确认数据是否准确呢？最方便的方法当然是让数据部门去核对，但是可能耗时比较长；而最快速的方法则是通过多个关联数据互相验证。
以互联网电商业务为例，如果月销售收入下降了 20%，但是月订单量和月活用户（MAU，Monthly Active User）都在增长，那么很可能是销售收入的数据统计出了问题。
没有量化的问题
[外链图片转存中…(img-K3abhiFR-1715796047990)]
[外链图片转存中…(img-egQ0nDa1-1715796047990)]
[外链图片转存中…(img-m5dpB9Ok-1715796047991)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
扫一扫
887
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
