如何用闭环思维建立一套自己的做事方法论

本文来自微信公众号：人人都是产品经理（ID：woshipm），原文来自：腾讯大讲堂，作者：刘光利（腾讯CSIG研发工程师），原文标题：《一图看透腾讯大佬们的做事方法论》，题图来自：unsplash

Leader 在安排任务的时候是怎么安排的？为什么这件事给 A 做会觉得比较放心，给B做心里会没底？

尝试从大佬们的角度去分析问题，会发现大佬们的一些做事的方法论。

同一件事情，不同的人做，结果不一样，取决于有的人“会做事”，有的人“不会做事”——给 A 做比较放心，因为 A 一直都“会做事” 。

一、闭环思维

会做事的总体思维结构是：做事要有闭环思维， 也就是一件事情必须要做好“事前”、“事中”、“事后”这三个闭环。

很多人“不会做事”，是因为都只关注到 “事中”，事前大部分都是 leader 安排好了，自己没有思考过为什么要做这件事、目标是啥；至于事后，由于项目紧张，事情做完很快就投入到另一件事情了，关于这件事后续如何，如果不是出了线上问题，或者 leader 过问，自己很少会去关注。

其实大家技术都差不多，但思维上的细微偏差，长此以往可能就会导致截然不同的发展轨迹， 这里围绕“事前-事中-事后”这个闭环思维去展开各个环节中的一些方法论吧。

二、事前分析

“为什么要做这件事？”，“痛点是什么？”，这是很多大佬经常问的问题，往往是在你滔滔不绝地介绍方案的时候，大佬们就用这个问题打断了你，既然大佬们经常问，说明背后一定有其深层原因。

结合我自身的理解，从技术优化类和产品需求类来分析这个思考的必要性，这是码农日常最常见的两类事情。

1. 产品需求类

很多人说，这个产品都已经思考好了，照着做就是了，哪来那么多为什么呀？

的确，在我们这些码农接到需求之前，产品同学内部应该都讨论多轮了，但是我们还是要去理解一下需求背后的深层原因，一方面能够加深对需求的理解、提高业务理解能力， 另一方面也能通过对需求本质的理解，在设计方案的时候思路更清晰。

例如技术方案评审的时候被问到为什么这么做，而不是那么做的时候，你能结合需求业务场景和扩展性等作出清晰的解释。

2. 技术优化类

比如你觉得现在网络框架中需要引入 quic ，你要思考的问题就是为什么要引入，是 quic 比较弱网情况下性能比较好？

那再问，我们目前的网络库性能表现不好吗？有没有数据支撑说明？另外做完这件事投入是多少？收益是多少？能不能从现有的数据情况推论出做这件事之后的收益？

这些问题想清楚之后，规划执行才能有理有据，你的 leader 才可能给你争取资源来做。

3. 2P挖掘法

知道经常被问和理解其必要性之后，我们就来准备怎么才能清晰回答这些问题，要想应对自如，就是提前问自己。

方法论是：“2P挖掘法”， 即，至少找出个痛点或者两个论据来支持你做这件事的必要性，这两个痛点不是拍脑袋或凭感觉，最好要有严格的数据说明。

例如现在要对一个百人的项目做组件化重构，痛点是：

• 编译太慢，影响开发效率；

• 模块耦合严重，维护成本高。

为了进一步说明这个痛点有多痛，你可以用一些数据说明：

例如一次编译要 20min，一般开发在开发和解 bug 平均一天编译6次，一天花在编译上的时间就是 2h， 一百人的团队，一天浪费的时间就是200h；如果能组件化后单独编译组件只要2min ，一天就能节约180h的时间。

如果每件事情都逼迫自己至少挖出两个以上类似的痛点或论据，后续被问到 why 的时候，一定能应对自如——因为你早就已经经过了深思熟虑 。

三、事中执行

想清楚为什么做这件事之后，做的时候就能放开顾虑去做了，包括方案设计、落地实施、问题处理等重要的步骤。

“你为什么选择这个方案？”、“你的方案考虑过xxx这种情况吗？”、“业界是怎么做的？为啥不使用xxx开源方案？”，这些都是在一场技术评审会上被问得最多的问题，如果你的回答是支支吾吾、临时拼凑，那么就会给人留下你没有深入研究的印象。

解决这个问题的方法是：每次设计方案的时候逼迫自己想出三个备选方案，如果你想出了三个方案，那么前面提到的哪些问题，你一定都提前问过自己了。

1. 3C 方案设计法

3C ，即三个 Choice，主要是逼迫自己去想更多的可能性，横向对比行业是怎么做的，是不是可以拿来用，自身业务情况下是不是有更多选择，严格按照这个思维去做方案，久而久之也会无形中提高自己的深度和广度。

有人可能会觉得浪费时间，想快，这也是人的天性，但是我们用这些方法论不就是对抗人性的弱点吗？如果为了快，方案有多潦草，技术评审会上讨论就有多激烈，最终也浪费了大家的时间，最终返工浪费的时间更多，还给大佬留下不好的印象， 所以“3C”还是值得花时间去做的。

2. 落地实施的进度条

方案设计之后，就是怎么推动事情落地了。

首先把任务按照依赖关系最小粒度进行划分，评估每个模块的工作量，最后评估出总的工作量，然后排上计划，执行的时候就开始了我们的进度条。

如果太长，可以划分为 2~3 个里程碑，执行过程随时检测进度，是不是存在风险。

需要注意的是：在拆解任务的时候尽量识别出依赖或被依赖的关键节点，尽早安排，实际开发中，工作量评估最常见的盲区就是忽略了跨组联调、对接的时间，这些节点往往也容易成为项目进度风险的关键因素。

3. 借助他人的力量

程序员最容易犯的错误就是习惯自己一个人埋头苦干，希望自己能搞定一切事情，怕打扰他人，但是有些事情需要他人配合才能完成，甚至需要依赖外部团队，怎么推动他人按照自己的计划配合完成事情呢？

这里我觉得和平时做人有些关系（并不是指人品好坏），我觉得会有一篇《大佬们的做人方法论》， 如果是熟人、或有交情的人，推动起来就事半功倍，如果不熟悉，的确不太好推动，可能平时多和兄弟团队多打打招呼、多认识认识会有些好处。

如果自己无法驱动时，可以借助 leader 的力量；leader 出面，对方也会重视起来，别人配合你做事也有名有分。

4. 5W根因分析法

方案执行或上线灰度中会遇到一些问题，需要我们第一时间去分析原因、总结方案。

说一个遇到的例子：

Leader：CGI 成功率为啥突然降低了？

下属：请求量太大，服务器负载过大，崩溃了， 正在扩容。

Leader：为啥请求太大?

下属：客户端某个数据上报增大了？

Leader：为啥上报请求增大了？

下属：请求失败落地存储太多，第二次启动时批量上报太多。

Leader：为啥突然请求失败存储增多了？

下属：此前服务器发布，导致部分出现抖动，上报失败了。

这里通过连续发问，找到根本原因，方案是临时扩容，同时客户端对上报请求做了限频，防止一次上报太多导致雪崩效应。

如果问到第一个问题就打住，那么采取的方案可能仅仅是扩容，但是根本原因没找到， 迟早还是会出问题。

通过连续追问，找到根本原因，这个方法叫做 “5W根因分析法”，又称丰田5问法。最初是由丰田集团创始人丰田佐吉提出的, 这方法论指导丰田成为世界名企。

实践应用中，不一定要问5个问题，有时可能问到第三个就找到了根本原因了。

这里需要注意的是：在连续追问的时候可能容易挑起情绪化，认为发问者是在刁难你，容易引发撕逼；问之前也可以强调下，接下来我们要用5W根因分析法找原因了，大家不要情绪化。

我相信大家在实际过程中都被 leader 的连环夺命问折磨过， 解决的方法是：提前用连环夺命问先折磨自己，避免同步问题的时候被 leader 连环夺命问折磨。

四、事后总结

很多人，事情做完了，leader 不问，自己也很少去总结。但是辛辛苦苦做完事情，如果不去做一个总结的话，其实是比较亏的。

倒不一定是为了让 Leader 知道做这件事取得了什么成果（当然这个也很重要），更重要的是给自己一个总结、帮助自己成长——哪些没做好需要提升，哪些是做的好的，有没有什么亮点、难点、挑战等。

1. 4D总结法

从四个维度对这件事情做个总结：即结果、数据、技术提升、个人成长四个维度。

（1）结果

做完这件事，我们取得了什么结果？可能是开发效率提升了，也可能是稳定性提升了，用户 DAU 提升了。

（2）数据

这个是对结果的补充，比如你说经过你的重构，开发效率提升了，提升了多少？

这是很容易被挑战的，你在做之前应该就统计过或者调查过开发团队，开发一个版本时间是多少，解决一个 bug 平均耗时是多少，经过优化之后，一个版本迭代缩短了 xx 天。

（3）技术提升

个人技术得到了哪些提升，是不是可以给团队做一个分享，是否可以在一个领域复用。

（4）个人成长

比如在执行力上、事情推动力上、方法论沉淀等软实力上是不是也有收获。

最后一张图总结大佬们一些做事方法论：

大家看完，可能有些共鸣。

其实我们多多少少都可以从大佬们对我们的提问和指导中体会到一些，只是我们自己没有总结而已。

以上方法，有些是企业管理界知名的方法论，而且在各行各业中应用， 例如 “5W”；有些是我们业界技术大佬们总结的，例如 “3C”、“4D” 就是我的前 leader 李运华总结的；也有些是本人结合经验自己总结的例如 “2P”……

本文来自微信公众号：人人都是产品经理（ID：woshipm），作者：刘光利