详解做事方法

转载于： https://time.geekbang.org/column/article/341937

导学：你应该掌握哪些做事方法？

你好，我是华仔。

从今天开始，我们进入到课程的第五部分，做事方法。

你在工作中肯定听到过这样的评价，“这个人做事很靠谱”或者“这个人做事很厉害”。

但是你有没有想过：同一个部门的人，级别一样，岗位职责一样，参与的项目也差不多，为什么你会觉得其中某些人做事就是比大部分人更靠谱、更厉害呢？

你可能会认为，这是因为他们态度更积极，更加会表现。

但是如果你带过团队就会知道，做事的态度和做事的能力不是等价的。

尤其是在部门绩效拉通和晋升预审这些场合，如果你向其他部门的负责人介绍的时候，说自己团队的某个成员“做事积极主动，很认真，很拼”，那么多半会被“怼”得很惨。

比如有人可能会说：“晚上 9 点下班就算拼了？我们团队的 xxx 做项目的时候都是 11 点才准备下班。”

那么，高级别的管理者是怎么判断你的做事能力强不强的呢？

我自己带过很多人，也经常跟其他的 P8、P9 和 P10 这个级别的管理者交流学习。我发现，有三条判断标准是能够达成共识的。

做事能力的判断标准

标准一：具备闭环思维

闭环思维是最基本的能力要素，也就是说，做事的时候不能只是完成任务了事，而是要从端到端的角度去思考和落地。

无论什么事情，端到端的过程都可以分为事前规划、事中执行和事后总结三个阶段，但是大部分人都只关注“事中执行”的阶段，而对事前和事后两个阶段并不在意。

第一个原因是，这两个阶段不是自己负责的。

比如对技术人员来说，需求是产品经理提的，需求上线后也是产品经理来做业务分析，这些都不是你的本职工作。

第二个原因是，这两个阶段的任务并不一定是强制要求的。

比如有些团队的 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）都在增长，那么很可能是销售收入的数据统计出了问题。

没有量化的问题

其次，对于没有用数据量化的问题，又可以分为两类。

一类是可以量化但是还没量化的，比如“业务增长放缓”，其中的“放缓”到底是什么意思，是增长速度从 100% 下降到 60%，还是增长速度从 10% 下降到 6%？不同的人理解可能千差万别。

对于这一类问题，你把量化的环节补上就行了。比如老板说：“我对当前的利润增长速度不满意，希望更快一点。”你就要明确，老板关注的指标是季度增长率还是月增长率？更快一些具体是多快，20% 还是 50% 还是 200%？

另一类是无法简单量化的，比如“团队士气不高”，其中的“士气”只是一种主观感受，很难量化。

所以这类问题是最棘手的，一是士气不高也许只是领导自己的感受有问题，并不是真的存在这个现象；二是就算真的士气不高，改善的效果也很难衡量。

你怎么证明你提高了士气，又怎么证明士气到底提高了多少呢？

直接用数据来衡量肯定是不现实的。经过实践摸索，我发现调查问卷是一种比较有效的方法。既然是主观感受，那我们就综合大多数人的主观感受来得到一个相对客观的评价。

这就像一部电影好不好，虽然不能用片长、投资金额或明星数量来衡量，但是如果看过的观众都来打分，最后综合算出一个分数，还是有一定参考意义的。而且评价的人越多，越能客观地反映影片的质量，这也是豆瓣等平台的价值。

调查问卷的设计技巧总结如下：

问题数量在 10～15 个左右，太少会导致问题分析不全面，太多会导致被调查的人不想答。

问卷数量至少 10 份以上，太少会导致单个样本对整体结果影响太大。

尽量用选择题，开放性问题不要超过 3 个，因为没几个人会认真回答开放性问题。

评分用 1～5 分，不要用 1～10 分，用 10 分制的话，区别度不大，平均分基本都是 7～8 分。

如果你的 P8 或 P9 级别的领导让你帮他分析一下团队的士气，那么你可以这样设计调查问卷：

注：仅为示例，实际的问卷内容要更多一些。

基于多份问卷的结果，就能在一定程度上分析出团队士气情况和整体成员的认知情况，从而避免个人主观判断的偏差。

不过，如果团队的人数很少，就不要用调查问卷了。比如你是 P7 的 Team Leader，手底下带了 5 个人，现在你觉得团队士气不高，可以直接找他们一个一个聊，这样效果更好。

第二步：拆解问题（Split）

第二个步骤是，拆解问题。

明确问题之后，你是不是就准备急着去分析原因了呢？毕竟你是负责人，领导还等着你的答案呢。

这就是很多人都会犯的第二个错误：把自己当成拯救世界的超级英雄，以为可以一个人搞定所有的事情。

如果问题很简单，那么确实可以这样做。但大部分问题其实是比较复杂的，甚至有的问题看起来很简单，实际上可能涉及很多方面，如果你只靠自己一个人去分析，也许花了很长时间都搞不定。

所以为了能够更高效地分析问题和更快地给出解决方案，你要学会拆解问题。

具体的做法是，对问题进行初步的分析，将大问题拆解为几个独立的子问题，然后再根据子问题的数量和规模，看看是否需要申请更多人力资源来一起参与问题处理。

简单来说，就是不要单打独斗，要学会利用团队力量。

至于按照什么维度拆解，这就和问题本身有关了。业务类的问题，可以按照业务类型来拆解，也可以按照客户群体来拆解；管理类的问题可以按照流程来拆解，也可以按照事项分类来拆解。

拆解问题有几个常见的小技巧：

拆解出来的子问题数量 2～5 个，拆太多了就很难保证互相独立。

拆解出来的子问题尽量互相独立。

明确子问题负责人，组成工作组，定期向上汇报进展。

比如电商业务的“订单数下降 30%”，你可以按照业务类型来拆解，看看不同品类各自下降了多少。

经过分析，你可能会发现，“男装下降了 20%”、“鞋类下降了 30%”、“食品下降了 20%”，其它品类的数据还是增长的。

于是，“订单数下降 30%”这个大问题拆解成了 3 个子问题，你可以分别协调对应的运营负责人来一起处理。

又比如“团队研发效率不高”，经过调研发现，团队反馈最多的前 4 个问题是“会议太多”“测试环境不足”“发布太麻烦了”和“需求变更太频繁”。

如果你一个人搞不定这 4 个子问题，你可以分别协调项目经理、测试负责人、运维负责人和产品负责人来一起处理。

第三步：定位问题（Seek）

第三个步骤是，定位问题。

我曾听过这样的案例：

半年的业务买量数据不升反降，老板让运营负责人赶紧想办法。于是他连夜构思解决方案，提出了几个大展拳脚的方案，比如 SEO 优化、增加更多渠道等。

老板大手一挥批准其中 3 个方案，半年后一看，投入多了几千万，买量的数据却没有多大起色，老板脸色很难看。

这就是很多人都会犯第三个错误：没有找到根本原因的情况下，就急于给出解决方案。

如果你只找到了表层原因，那么后续提出的方案就是无法从根本上解决问题，只能白白浪费时间和资源。

定位问题的技巧就是 5W 根因分析法，我在 26 讲已经介绍过了。需要注意的是，根本原因可能不止一个，不同的追问线索可能找到不同的根本原因。

比如“加班太多导致士气不高”，我们也许可以得到两个根本原因：“市面上的 Go 程序员较少” 和 “没有项目经理”。

问题 1：为什么士气不高？

答：因为加班太多。

问题 2：为什么加班太多？

答：因为人力不够。

问题 3：为什么人力不够？

答：因为招聘困难。

问题 4：为什么招聘困难？

答：因为市面上的 Go 程序员太少。

针对“市面上的 Go 程序员太少”这个根本原因，对应的解决方案可以是“招聘 C/C++ 程序员然后培养成 Go 程序员”。

接下来是沿着另一条线索追问的情况：

问题 1：为什么士气不高？

答：因为加班太多。

问题 2：为什么加班太多？

答：因为项目执行混乱。

问题 3：为什么项目执行混乱？

答：因为没有项目经理。

针对“没有项目经理”这个根本原因，对应的解决方案可以是“招聘专职项目经理”。

第四步：解决问题（Solve）

第四个步骤是，解决问题。

定位出问题的根本原因之后，你就需要提出问题的解决方案。

解决方案往往涉及资源的投入（增加广告投入预算）、组织的调整（成立专项小组）和系统的增强（增加配置检查功能防止运营配置出错）等，所以你需要得到上级的认可和支持。

这时很多人都会犯第四个错误：思维比较局限，只做了一个方案提交给上级。

你信心满满地把自己的解决方案提交上去，本来希望得到赞赏，结果却发现上级有更多的想法或不同的方案，反而认为你考虑得不够周全。

那么，怎么做才能很快得到上级的认可和支持呢？

你需要提供多个方案，并且给出你建议的方案和原因，最终让上级来挑选和拍板。这就是我在第 24 讲介绍的 3C 方案设计法。

第五步：落地行动（Sort）

第五个步骤是，落地行动。

方案得到批准后，你就要落地执行，真正解决问题。很多人在这一步容易犯问题处理的第五个错误：做事没有重点和优先级，眉毛胡子一把抓。

在前面的步骤中，你可能拆解出了 3 个子问题，然后每个子问题分析出 2～3 个根因，每个根因分别给出了对应的解决方案，接着每个解决方案又可以分成 3～5 件事情来做。最后你发现，可以做的事情有几十件。

你可能会认为这些事情都是有价值的，所以用一张 Excel 表格全部记录下来，然后从第一件开始一件一件地去做。

但是这样做的结果很可能是，你做了几个月，但是却看不到什么效果。

因为每件事情的价值有大有小，见效时间有快有慢，你的领导并不关心你做了多少件事，他们关心的是，问题有没有真正解决。如果看不到明显的效果，就算你做得很辛苦，也很难得到认可。

正确的做法就是先做优先级排序，然后挑选优先级 TOP N 的事情去做，尽快看到成效，让问题不断地改善。

优先级排序的技巧总结如下：

可以按照阶段来进行优先级排序，并且顺序是可以调整的。比如前 3 个月 TOP 3 的事情是 ABC，后 3 个月 TOP 3 的事情是 XYZ。

如果只有一个团队来做，建议挑选 TOP3 ～ TOP5 的事情来落地；如果多个团队合作，那么可以选 TOP 10，每个团队负责其中 2～3 件事。

短期按照紧急程度来挑选 TOP N，长期按照重要程度来挑选 TOP N。比如“运营配置 URL 出错”这个问题，短期内的 TOP 事项可以是“上线流程优化”，让测试来检查运营配置的内容；长期 TOP 事项可以是“后台管理系统优化”，增加配置 URL 合法性和有效性检查功能。

明确需要落地的 TOP 事项后，就可以用第 25 讲介绍的 PDCA 执行法来执行了。

小结

现在，我们回顾一下这一讲的重点内容：

5S 问题处理法就是把处理问题的过程分为 5 个步骤：明确问题（Specify）、拆解问题（Split）、定位问题（Seek）、解决问题（Solve）和落地行动（Sort），从而化危为机。

处理问题时容易犯的 5 个错误是：（1）问题本身都没有明确定义，就直接开始采取行动；（2）把自己当成拯救世界的超级英雄，期望可以一个人搞定所有的事情；（3）没有找到根本原因的情况下，就急于给出解决方案；（4）思维比较局限，只做了一个方案提交给上级；（5）做事没有重点和优先级，眉毛胡子一把抓。

明确问题可以通过数据量化，也可以靠调研来衡量；拆解问题是为了发挥团队的力量；定位根因、提出方案和落地执行时，可以分别使用 5W 根因分析法、3C 方案设计法和 PDCA 执行法。

---

4D总结法：怎么展示你的工作亮点？

你好，我是华仔。

前几讲我为你介绍了事中执行阶段的 4 种方法，这些方法能够提升你拿到好结果的概率，但是不能保证让你一定拿到好的结果，因为影响最终结果的因素太多了。

首先，就算使用 3C 方案设计法，决策过程仍然有可能有失误。

比如受限于团队整体的技能限制，分析和讨论备选方案的时候漏了一个重要的方案；或者决策时采用的判断标准有问题，对性能要求估计过高，实际上线后业务量远远没有预期那么大等情况。

其次，就算使用 PDCA 执行法，执行过程仍然有可能出现偏差。

虽然 PDCA 方法能够有效地对任务进行规划和跟踪，但是具体执行的时候，可能会受到使用者的水平和投入资源等因素的限制。

最后，就算方法都使用得当，还是有可能受外部因素干扰。

比如某海外钱包团队用 3C 方案设计法设计出了最优的业务方案，但是当地政局不稳定，导致跨境消费剧烈减少，然后又发生疫情，导致本地消费大幅减少，最终结果可能就很不好。

所以，不但做事的方法很重要，而且做事的结果也重要。在晋升答辩的时候，评委除了考察规划和执行相关的“为什么”之外，还会考察和做事结果相关的“为什么”，比如：

你认为这个结果怎么样？你怎么评价这个结果？

为什么你认为这个结果不好？

为什么你的方法挺好但是结果不好？

你从这个结果得到什么经验和教训？

你可能以为，结果好的事情讲起来就很容易了，结果不好才需要包装一下。其实不是这样的，结果不好的事情，你的确需要分析原因，总结经验教训；但是结果好的事情，你也需要讲清楚你对结果的贡献。

大部分人在这个环节的表现都很一般，常见的误区有：

讲的贡献是团队的总贡献，没有讲清楚自己对结果的贡献，或者拔高了自己对结果的贡献。

只讲自己的做事方法多么高大上，却不提最终的效果，比如说自己引入了某某算法，但却不说到底带来了什么好处。

虽然提了一下效果，但都是比较虚的描述，比如高可用、高性能、用户转化率大大提升之类的话，评委听完也不知道到底有多高、有多大提升。

虽然描述效果的时候列出了数据（能列出数据已经超出了 60% 的人了），但仅仅是把从产品经理和运营经理那里要的数据贴过来，对于数据没有自己的理解和判断，评委针对数据问的问题都答不上来。

那么，总结的时候到底要怎么说才能充分展示出自己的工作亮点呢？

这就要用到 4D 总结法了，也就是从结果、数据、技术和成长这 4 个维度（Dimension）来整理自己的做事收获，从而涵盖事情的重点难点核心点，有效地应对晋升答辩时可能遇到的各种问题。

维度一：结果

第一个维度是结果。

结果这个维度重点关注的是事情带来的价值，不同类型的团队在结果价值方面表现会有一些差异。

首先是业务开发团队，不管是业务开发项目，技术优化方案，还是管理措施，我都建议从业务角度进行结果总结：

对于业务开发项目来说，从业务的维度总结是自然而然的，例如某个业务用户日活是多少。

对于技术优化方案来说，主要看技术方案给业务带来的价值是什么，例如高可用方案让业务 P1 故障从 5 次减少到 0 次。

对于管理措施来说，主要看管理措施带来的效率和质量的提升，例如同样的人员支撑了更多业务。

其次是中间件开发团队，结果建议从系统的性能、可用性和成本等方面进行总结；如果中间件系统已经产品化（比如阿里云的 RDS 和 MQ），也可以从销售量或者流量等方面进行总结。

最后是技术支撑团队，也就是运维和测试之类的部门，结果建议从质量、效率和成本方面进行总结。

比如测试做了一个自动化测试平台，可以降低 5000 人日测试工作量，使用了这个自动化测试平台的某业务线上年度故障数量从 20 个降低为 5 个。

维度二：数据

第二个维度是数据。

像“提升了开发效率”这种比较虚的描述，应该改成“开发一个功能从 20 人天提升为 2 人天”这种使用具体数据的描述。

通过数据来描述结果的时候，你不但要列出相关的数据，而且对于这些数据背后的含义也要有自己的理解，尤其是对数据的评价以及评价的标准。通过评价数据的方式，你可以培养自己的业务思维和理解力。

比如，同样是将用户活跃率提升 5%，对于一个像微信这样成熟的业务来说是非常难得的；但对于一个新业务来说还远远不够；同样的道理，从 20% 提升到 25% 和从 90% 提升到 95%，含义也是完全不同的。

很多人在一开始尝试的时候都会遇到一个疑问：感觉这个事情好像没办法用数据来描述啊？

这个时候怎么办呢？其实大部分的情况，不是真的不能用数据来描述，而是你没有去搜集数据，没有养成用数据来说明的习惯。

比如，以前需要写代码才能实现的业务，某个技术优化方案采用 XML 配置就可以完成了，但是之前也没有谁去收集实际上的开发时间，所以无法进行对比，但效率肯定是提升了的。

遇到这种情况，我们可以采取临时补数据的方式，也就是找团队相关人员评估一下之前方案所需的时间。为了避免单个人评估出现严重误差，你可以找多个人进行评估，发挥集体智慧，最后取一个平均值或者中间值。

这样得到的数据虽然没有采用项目管理工具进行收集那样严谨和客观，但实际上也不会偏差太大。

当你平时积累了大量数据总结的内容后，写晋升 PPT 的时候就可以信手拈来，而不用再绞尽脑汁去回想 1 年前做过的一个项目具体的结果是什么了。

维度三：技术

第三个维度是技术。

对于技术人员来说，做完一个项目或者方案之后，技术上有哪些提升、学到了什么新的技术、对哪些技术有了更深或者更全面的理解等，都可以在总结的时候系统地梳理一下。

虽然我们在设计方案的时候已经采用了 3C 方案设计法对领域进行了全面地分析和研究，但并不代表这样就可以完全掌握所有相关的知识和技能，在具体落地的过程中肯定还会遇到很多细节或者之前没有注意的地方。在事情做完后，统一地整理和总结一下经验教训，能够进一步提升技术深度。

我在 2013 年左右使用 Memcache 的时候就遇到过一个比较奇怪的问题：开发语言是 PHP 5，采用 Nginx + php-fpm 来做容器，每天晚上到了 0 点就随机出现 Memcache 连接不上的问题。

最后经过排查，我发现是因为 Memcache 默认连接数只有 1024，而业务上到了 0 点就可以开始新的一天的签到和奖励领取，大量用户卡点操作导致并发量大，连接数超过了 1024 个后 Memcache 就拒绝连接了；而且 PHP 连接的时候采用的是短连接，即使修改连接数，在大量并发连接时也会出现连不上的问题。后来，我们用 C 语言写了一个 PHP 连接池扩展，从而解决了问题。

这件事情要怎么总结呢？

如果某项技术你还没有按照“链式学习法”和“比较学习法”来学习，那么这就是一个很好的学习机会，你可以按照这两种方法画出领域分层图、细节分层图和方案对比的思维导图等。

如果某项技术你之前已经按照“链式学习法”和“比较学习法”学习过，那么你可以结合实践经验，完善领域分层图、细节分层图和方案对比的思维导图。随着你积累的越多，这三个图会越来越完善。

维度四：成长

第四个维度是成长。

除了关注技术上的提升之外，你还需要关注个人综合能力成长，也就是软实力提升，比如对业务的理解能力、项目组织能力、带领团队的能力、沟通能力和做事方法等。

这些能力在 P5/P6 晋升的时候可能没那么重要，但是到了 P7 以后就会变得越来越重要，而且综合能力很难靠突击来提升，只能在平时工作中逐步积累。

以业务理解能力为例，做完一个项目后，你可以从以下角度去总结：

业务的适应场景是什么？

目标用户是谁？

目标用户有什么特点？

解决了目标用户的什么问题？

实际的效果如何？

用户为什么喜欢 / 不喜欢这个功能？

随着做的项目越来越多，你通过总结得到的业务理解信息和能力也越积越多，到了一定阶段就可以量变导致质变，业务理解能力大大提升。

示例

使用 4D 总结法，看起来要整理的内容非常多，但是熟练之后你就会发现，其实并不怎么耗费时间，一个持续 1 个月的项目，可能用 1 个小时来总结就足够了。

总结的时候也不需要很正式，你可以用笔记的方式，把一些想到的关键点列出来。当这样的总结数量积累到一定的程度，你还可以再系统地整理一下，写成文章发表或者拿去给团队做培训，那样效果会更好。

下面是我之前做的一个业务总结示例，对应“成长”部分的总结，供你参考。

游戏衍生内容好坏对用户根本性影响非常弱，这个结论为何到了最后才发现？之前的决策都是基于这个判断来做的。

改进：有想法，然后快速验证，如果一次验证失败可以再尝试，但如果尝试一年还失败，那就要及时调整了。

“没有”和“偶尔”用竞品的竟然占了 90%，这说明几个竞品没有差异化（定位都一样），用户只需要其中一个。

“没时间玩”成为最主要的原因，是否说明用户对 app 的定位就是工具型，需要的时候用一下，不需要的时候根本不会去看。

用户的几个典型弱点：贪婪（礼包、活动、抽奖）、懒惰（信息流）、虚荣（等级、成就）、窥探（笑话、八卦）。

用户的主场景：礼包、下载、找游戏。

消磨零碎时间不是用户玩手游的最主要场景，反而是 63% 的用户在成块的闲暇时间体验手游。

小结

现在，我们回顾一下重点内容。

---

金字塔汇报法：怎么汇报才能让领导认可你的成果？

你好，我是华仔。

上一讲我给你介绍了 4D 总结法，它可以用来做总结，让你在完成工作之后有效地展示亮点和提升自己。

要是你觉得 4D 总结法同样可以用来做汇报，那么我就要提醒你注意了，4D 总结法的确可以提供汇报时需要的一些材料，但是它并不能提供组织这些材料的思路。

如果你汇报的时候，只是把总结得到的内容单纯地罗列出来，是很容易踩坑的。比如我以前就经常遇到这样的汇报场景：

上级直接打断汇报者说：“不要讲这么多细节，挑重点讲！”

总监点评某个团队的汇报时说：“感觉你们团队做了很多事情，团队也很辛苦，但没看到有什么关键结果或者突破！”

P8 汇报完之后，某 P9 大佬问：“能不能用一两句话概括一下这一年的工作？”

为什么在这些场景中，领导都觉得不满意呢？因为汇报的逻辑和总结的逻辑是不同的，总结主要是面向自己做梳理，更强调自己个人的贡献，以及事情的价值和细节；而汇报主要是面向领导做组织提炼，更看重团队整体的结果，以及事情的逻辑和关键。

那么，怎么汇报才能让领导认可你的成果呢？这就要用到金字塔汇报法了。金字塔汇报法来源于金字塔原理，我在第 13 讲分享的 PPT 写作技巧就是金字塔原理的一个应用。这一讲，我先从理论层面再为你深挖一下这个原理。

金字塔原理

它很简单，核心思想是任何事情都可以归纳出一个中心思想，中心思想可由三至七个论点支持，每个论点可以由三至七个论据支撑，这样延伸下去，形状像一个金字塔，所以才叫金字塔原理。它的基本结构如下图所示：

有些人看到金字塔原理之后，认为这个方法名不副实，本质上就是中学作文的总分结构，巴巴拉·明托只不过是取了一个高大上的名字。

从结构上来看，金字塔原理确实是一种总分结构。但它能够风靡全世界 50 年，在各行各业都能取得很好的使用效果，肯定不只是因为采用总分结构化，它背后的 4 条基本原则才是关键。这些原则保证了你的汇报结构是重点突出、逻辑清晰、主次分明的，能够让别人快速地抓住重点，清楚地理解内容，牢固地记住信息。

1. 结论先行

如果你想向别人输出信息（文章、汇报、报告、演讲等），在一开始的时候就应该抛出结论，也就是你想要传达的中心思想。

因为如果你讲的内容比较多，别人找不到重要的结论，可能根本没兴趣认真听完；如果别人听完不明确你的结论或者把结论搞错了，最后你的输出汇报效果也会大打折扣。

所以我们要让结论先行，具体的技巧可以用六句口诀总结：

先重要（结论）后次要（结论）

先全局后细节

先总体（结论）后细分（结论）

先论点后论据

先结论后原因

先结果后过程

注：

1 和 2 针对“不要讲这么多细节，挑重点讲”这样的问题。

3 和 4 针对“能不能用一两句话概括一下这一年的工作”这样的问题。

5 和 6 针对“听下来给我的感觉就是，去年团队很辛苦、很努力、拼劲十足，但是这么辛苦最后拿到来什么结果，我却没怎么看到！”这样的问题。

按照这六句口诀进行汇报，基本上就涵盖了别人关注的内容。如果时间有限，你可以只讲口诀中需要先讲的内容，后讲的内容可以直接不讲，只要做好准备应对提问就行了。

就算时间充足，口诀中后讲的内容也不要花太久，建议按照二八原则来分配时间，80% 的时间给先讲的内容，20% 的时间给后讲的内容。

2. 自顶向下

光有结论是不行的，这个结论还得让别人信服。所以我们采用自顶向下的结构来组织逻辑，用下层的信息来支撑上层的结论。

下图展示了一个简单的金字塔原理案例：

请注意，在这张图中，“手游市场刚刚起步”就可能是一条不那么让人信服的结论，因为它的一个论据“手游厂家只有 XX 家”不足以支撑这条结论。别人听完或许会想，也可能是几个垄断的厂家特别强大，已经挤压到其他厂家没有生存空间，所以数量才比较少。

3. 归类分组

用自顶向下的结构来组织逻辑时会遇到一个问题：下层的数量几个比较合适呢？

如果你在平时的工作中采用了 4D 总结法总结做过的事情，你会发现你可以用的素材很多，尤其是如果你带了团队的话，素材会更多，如果逐一列上去，不要说用 PPT 了，可能用 Excel 表格列几十行才能完整的展示，这样在汇报的时候肯定是不行的。

所以，你需要将类似的论点或者论据抽象、归纳、提炼、总结成一组，最后形成 5 个左右的分组。

一般来说，分组数量尽量不要少于 3 个，如果少于 3 个，你就要检查一下分析是不是全面，有没有遗漏某些要点。

另一方面，极限是 7 个，最好是 5 个以内，因为人类的短期记忆是有局限的，同级别数量太多别人记不住，具体可以参考美国心理学家乔治·A·米勒的论文《神奇的数字：7±2——我们信息加工能力的局限》。

4. 逻辑递进

光通过归类分组来控制数量还是不够的，必须保证同级别的内容具备逻辑关联，主要是一致性和顺序性。

一致性是指，同级别的内容必须属于同一逻辑范围。比如苹果、香蕉、葡萄、菠萝都属于“水果”范围，而牛奶就不属于“水果”。

顺序性是指，同级别的内容是按照某种顺序排列的，比如北上广深四个城市，既可以按照地理位置从北到南排序，也可以按照 GDP 从大到小排序，如下图所示：

金字塔汇报法

标准的汇报内容包括总体结论、具体分析、关键事项、总结改进四部分。接下来，我以一个模拟的某海外移动钱包技术团队负责人的汇报 PPT 作为例子，跟你讲解每个部分的具体内容和技巧。

1. 总体结论

从全局概括整体的工作或者项目情况，得出关键性的结论，让听众整体上知道做得怎么样，形成做得好、做的一般、不达预期或遇到很大困难等直观印象。

这个部分按照金字塔原理来分析和阐述，包括一个总的结论（总体介绍）和几个主要的分论点，PPT 页数一般不超过 3 页，分论点的数量建议 1～3 个，每个分论点再给出 3～5 个论据，如下图所示：

这张图展示了基于金字塔汇报思路写的 PPT，它省略了 PPT 排版格式，只保留了干货信息，实际汇报的时候你可以写得更好看一些，也可以在金字塔方法整理的内容上稍做展开：

注：总体结论的内容可以用定性的描述，也可以是定量的数据。

2. 具体分析

对总体结论中的论据进一步阐述和分析，让别人相信论点的真实性和有效性。

这个部分同样按照金字塔原理来拆解，需要提供具体的数据和证据。

对团队方面的具体分析如下图所示：

这里的团队分析只有结果汇报，没有原因分析，因为前面没有说团队存在明显问题。如果汇报的内容有一条是“团队士气低落”，那就需要做原因分析了。

对业务方面的具体分析如下图所示：

业务结果分析更多的从定量的角度给出详细的数据，如果是技术团队主管，可以找业务负责人拿数据进行汇报。如果有做的不好的地方，需要做原因分析。

比如针对业务结果没有达到预期的原因分析如下图所示：

业务原因分析更多的是从定性的角度对业务结果进行分析。如果是技术团队主管，可以找业务负责人一起分析原因，不建议技术负责人独自分析然后给出结论。

因为高级别的领导可能会从多种途径听到同一个业务的分析结论，如果不同的途径结论差异很大，技术团队给出的业务分析结论很容易被怀疑不专业。

对于分析出来的原因，如果需要进一步论证，可以同样使用金字塔原理来进一步展开，比如“本地用户不习惯这种支付方式”，可以分解为“八达通使用率占比达到 90%”和“信用卡覆盖率达到 60%”等。

3. 关键事项

介绍做过的关键事项的情况，比如某某项目的执行过程或者某某业务的推广行动和效果等。

这部分不需要使用金字塔原理，一般是通过全局大图、演进路径和时间轴等技巧来汇报。

4. 总结改进

总结经验教训和后续改进措施，注意不要随便拍脑袋提出改进措施，改进措施本身也要求有理有据。

要注意，列出来的改进措施，一定是你接下来真的准备去做的，不要为了凑数而加上去，因为下次汇报的时候，领导很可能会想先了解一下你上次汇报时列出的改进措施到底落实得怎么样。

同时，改进措施的数量也不要太多，一般可以分为“业务”“技术”和“管理”这几种类型，每种类型列 3～5 条，如下图所示：

改进措施既可以基于前面的原因分析，比如这里的业务改进措施就是基于业务分析的原因推导出来的；也可以基于前瞻性来进行判断，比如前面虽然没有明确提出团队目前存在问题，但是从中长期来看，这样的团队结构肯定会存在风险的，所以在这里提出团队管理的改进措施也是合理的。

关键事项汇报技巧

刚才我提到，关键事项部分不需要使用金字塔原理，而是通过全局大图、演进路径和时间轴等技巧来汇报。现在我来一一介绍。

全局大图：展示整体情况

首先是全局大图，它是用来展示整体情况的。常见的类型有业务大图、技术大图和组织大图等。

全局大图的核心内容包括两个层面：

整体结构：汇报涉及的领域整体上包含哪些组成部分，各部分的关系或者层级是怎样的，和其他领域的边界和关系是什么。整体结构是领域的完整形态，已经实现的和还没有实现的部分都要展示出来。通常情况下，业务大图和技术大图用分层结构展示，组织大图用组织结构展示。

个体状态：各个组成部分当前的状态，或者取得了什么成就。通常情况下，用不同的颜色来表示不同的状态。

下面是一个业务大图的例子，供你参考。

注：图中信息仅为示例，不代表真实情况。

为了让大部分用户都能看懂，图中的组成部分都是高度抽象的。你在实际汇报的时候可以继续细化，我见过最复杂的业务大图，一张 PPT 中包含的区块有将近 100 个。

当然，也不是说越细化越好，你只要在这张图的基础上再往下分解一层就够了。比如业务中台负责人汇报的时候，可以把商品分解成很多细化的业务，商品收藏、商品快照、商品上下架和商品分类等，但是不需要再对商品收藏做进一步的细化。

同时，不同团队的人使用这张图做汇报的时候，侧重点也不同。比如业务中台的负责人汇报的重点自然是业务中台，数据中台的情况则可以简要带过，但也不能完全不知道；而中台整体负责人汇报的重点就同时包括业务中台和数据中台了。

演进路径：展示个体情况

其次是演进路径，它是用来展示个体的发展路径和当前所处阶段的。这里的个体可以是一个独立的系统，一个业务，或者一个领域。

演进路径的核心内容就是各个演进阶段，每个阶段要能够用一个词加一句话高度概括，让别人一眼就能看出不同阶段的差异。通常情况下，演进路径一般用阶梯式的图来表达，寓意步步提升，越来越好。

下面是一个推荐系统演进路径的例子，供你参考。

时间轴：展示过程

最后是时间轴，又叫时间线，它是来展示事情发生过程的。

时间轴的核心内容是时间维度相关的里程碑以及每个里程碑的关键事项或者进展，换句话说，时间轴中的节点应该都是里程碑式的，不要事无巨细地全部列上去。

通常情况下，如果关键里程碑数量不多，那么时间轴用横向或者纵向的直线就行了；而如果关键里程碑数量比较多，时间轴可以考虑用折线的形式来展示更多的内容。

小结

现在，我们回顾一下这一讲的重点内容。

---

四线复盘法：怎么避免成为背锅侠？

你好，我是华仔。

在事后总结阶段，正常情况下我们主要是做收获总结和成果汇报即可，但是如果发生了明显的问题，就需要做问题复盘。

复盘是一个围棋术语，它指的是对局结束后回顾记录，检查招法的优劣和得失关键，并且根据分析提出更好的招法，提升以后的对局能力。后来，这个思路被引入到了管理工作中。

问题复盘

技术人员主要参与的是线上问题复盘，比如业务或者系统出现了线上问题，在问题解决之后往往就会组织复盘。

不管团队技术多么厉害，也不管公司多么有钱，都不能完全避免业务或者系统出现问题的可能，比如 2015 年 5 月 27 日支付宝发生了大规模宕机的事故，2018 年 10 月 22 日 GitHub 发生了宕机 24 小时的事故等。

虽然无论做什么都不可能完全杜绝问题的发生，但这并不意味着我们只能坐以待毙。我们需要尽量降低问题发生的概率，减少问题导致的损失，因为就算事故不可避免，1 年发生 3 次和 10 年发生 1 次，影响和意义也是完全不同的。

问题复盘的意义就在于找到问题的原因然后加以改进，避免同样的问题反复出现，降低问题的发生的概率和影响。

四线复盘法

但是，要做好问题复盘可不是一件容易的事。复盘会议上的各种明争暗斗，可能会让刚参加工作的“萌新”惊掉下巴，甚至让一些老员工也感到头疼。尤其是一些管理比较严的公司还会通过复盘来明确责任分配和处罚措施，复盘会议的激烈程度往往不亚于电视剧中的宫斗场景。

所以，怎么组织一场复盘，怎么分配责任和避免背锅，已经成了职场人的一项生存必备技能。

问题复盘的内容涵盖事实、分析、定责和改进4 个部分，一次成功的问题复盘需要达成以下 4 个目标：

讲清楚事实：事实是复盘的基础，如果连事实都没有讲清楚就开始分析、定责和改进，无异于搭建空中楼阁，做得再漂亮也是没有意义的。

全面且深入地分析：首先需要保证没有遗漏问题，其次需要深入分析问题根因，否则以后问题还是会以其他方式反复出现。

得出让各方心服口服的定责结论：需要有明确的定责标准，避免拍脑袋定责，或者按照级别和关系来定责。

制定可以落地的改进措施：避免提出一些虚头巴脑的措施，看起来高大上，实际上却不知道怎么落地，后续也无法跟踪。

这一讲分享的四线复盘法，就是通过时间线、问题链、责任链和改进线这 4 条不同的线索来展开复盘，从而实现事实、分析、定责和改进这 4 个部分的目标。

如果你是复盘负责人，四线复盘法可以让你不偏不倚、公平公正地组织复盘；如果你是复盘参与人，它可以让你避免背不必要的黑锅。当然，如果出现问题确实是你的责任，它也不会教你怎么逃避责任，而是会告诉你怎么思考和改进。

接下来，我会针对每条线索逐一讲解说明。

第一条线：时间线

为了讲清楚事实，我们要明确时间线，也就是问题发生的经过，包括问题发现、问题处理过程中采取的各种关键措施、问题恢复的时间和问题影响的结果等。

其中，时间信息非常关键，因为它能够反映出问题发现速度、各项措施执行时间和团队响应效率等指标。比如，运维重启 30 台机器花了 1 小时，通常情况下这种处理效率肯定是有问题的。

第二条线：问题链

为了全面且深入的分析，我们要明确问题链，也就是问题的传导路径。

通常情况下，一个问题往往不是单一原因导致的，而是多个原因“碰巧”组合在一起所导致的，所以分析整个问题的传导路径，才能全面地了解产生问题的过程。

同时，针对单个问题的分析也不能浅尝辄止，而应该采用第 26 讲的“5W 根因分析法”深入分析，找到根本原因，这样才能为后续制定改进措施提供有效的指导。

问题链的路径逻辑有两类：业务流程和项目流程。

业务流程是指，端到端的业务处理的过程，分析的对象是各个关联的系统。

项目流程是指，端到端的项目开发的过程，分析的对象是项目各个阶段相关的人员，比如开发、测试、产品和运维等。

我们一般先采用业务流程的逻辑将问题定位到单个系统，然后再针对单个系统采用项目流程的方式将问题定位到具体的人或者流程中的某个步骤。

第三条线：责任链

为了得出让各方心服口服的定责结论，我们要明确责任链，也就是问题责任人之间的关系。

我们需要结合时间线中问题影响的结果、公司的故障定级标准和问题链的分析，最终确定哪些团队或个人应该承担责任，分别承担多大的责任，接受什么样的处罚。

之所以叫责任链，是因为一个问题的发生往往是整个流程上多个环节相关的人处理有问题，才会导致最终问题的发生。比如开发人员引入 bug，测试人员遗漏了测试，产品人员没有验收到，最终才会在上线后发现问题，这个环节中只要有一个环节把握住了，问题就不会发生。

定责是问题复盘中最棘手的部分，因为定责的结果会直接影响团队和个人的绩效，所以做到公平公正、让各方都心服口服是一项很大的挑战。

通常情况下，制定明确的定责标准有利于尽量减少争议，常见的标准包括以下 4 条：

违反公司规章 / 制度 / 流程的承担主责：比如公司规定必须要有灰度策略才能升级，某业务版本直接全量升级导致发生问题。

出现重大纰漏的承担主责：比如测试时漏测了某个常见的业务场景，导致上线后发生问题，测试承担主责，产品承担主责（因为上线前验收阶段没有发现问题），开发反而不一定承担责任（看具体的公司和团队要求）。

问题源头承担主责：比如 A 系统磁盘故障导致接口响应很慢且问题持续很长时间，从而进一步导致 B 系统对外响应也超时，这种情况下 A 系统应该承担主责，B 系统承担次责。

问题放大者承担主责：比如 A 系统磁盘故障导致接口响应很慢但只持续了几分钟，结果诱发了 B 系统的设计缺陷，导致 B 系统瘫痪超过 1 小时，这种情况下 B 系统应该承担主责。

第四条线：改进线

为了制定可以落地的改进措施，我们要明确改进线，也就是问题的改进计划，包括具体措施、改进责任人和时间节点等。

（注：在这一讲中，问题责任人是指为问题承担责任的人，改进责任人是指负责落实改进措施的人，不一定是同一个。）

改进计划的思路来源于两个方面：时间线和问题链，通过时间线找到问题处理过程中不合理和可以优化的地方；通过问题链找到具体需要解决的问题。

具体措施可以是流程上的调整（增加或删除流程步骤），技术上的手段（增加功能、优化系统）和团队方面的措施（学习、培训、奖惩机制）等。

无论采取什么措施，都要求能够落地执行。比如“提升团队质量意识”这种比较虚的措施，应该细化为“团队参加公司的质量规范学习和考试”“推行 Code Review”这种具体的措施。

接下来，我来带你拆解一个简单的线上问题复盘案例。

案例：线上商城

假设我们做了一个简单的线上商城，架构如下图所示：

某次线上故障导致用户下单后无法支付，我们按照四线复盘法来来复盘这个问题。

1. 时间线

首先，我们完整地回顾问题产生、处理和收尾的整个过程，梳理了时间线：

2. 问题链

我们先按照业务流程来分析问题链，由于系统架构和这次问题都比较简单，所以问题链只涉及风控服务和支付服务：

针对风控服务的问题，我们再按照项目流程来分析问题链：

3. 责任链

根据时间线中的影响结果，这次问题导致的损失是 10000 元；根据公司故障定级标准，属于轻微级别，惩罚措施是贡献活动经费；结合问题链和定责标准，我们得到了最终的责任链：

4. 改进线

我们分析了时间线中的步骤，针对两个可以改进的地方制定了改进措施：

然后，我们又分析了问题链中的问题，针对另外两个可以改进的地方制定了改进措施：

以上就是用四线复盘法对这次问题做复盘的整个过程。

小结

现在，我们回顾一下重点内容。