会做事的总体思维结构是：做事要有闭环思维， 也就是一件事情必须要做好“事前”、“事中”、“事后”这三个闭环， 很多人“不会做事”，是因为都只关注到 “事中”， 事前大部分都是 leader 安排好了，自己没有思考过为什么要做这件事、目标是啥；至于事后，由于项目紧张，事情做完很快就投入到另一件事情了， 关于这件事后续如何，如果不是出了线上问题，或者 leader 过问，自己很少会去关注。其实大家技术都差不多，但思维上的细微偏差，长此以往可能就会导致截然不同的发展轨迹， 这里围绕“事前-事中-事后”这个闭环思维去展开各个环节中的一些方法论吧。

“为什么要做这件事？”，“痛点是什么？”，这是很多大佬经常问的问题，往往是在你滔滔不绝地介绍方案的时候，大佬们就用这个问题打断了你，既然大佬们经常问，说明背后一定有其深层原因，结合我自身的理解，从技术优化类和产品需求类来分析这个思考的必要性，这是码农日常最常见的两类事情。

产品需求类： 很多人说，这个产品都已经思考好了，照着做就是了，哪来那么多为什么呀？的确，在我们这些码农接到需求之前，产品同学内部应该都讨论多轮了，但是我们还是要去理解一下需求背后的深层原因，一方面能够加深对需求的理解、提高业务理解能力， 另一方面也能通过对需求本质的理解，在设计方案的时候思路更清晰，例如技术方案评审的时候被问到为什么这么做，而不是那么做的时候，你能结合需求业务场景和扩展性等作出清晰的解释。

技术优化类： 比如你觉得现在网络框架中需要引入quic ，你要思考的问题就是为什么要引入，是 quic 比较弱网情况下性能比较好？那再问，我们目前的网络库性能表现不好吗？有没有数据支撑说明？另外做完这件事投入是多少？收益是多少？能不能从现有的数据情况推论出做这件事之后的收益？这些问题想清楚之后，规划执行才能有理有据，你的 leader 才可能给你争取资源来做。

2P挖掘法

知道经常被问和理解其必要性之后，我们就来准备怎么才能清晰回答这些问题，要想应对自如，就是提前问自己。方法论是：“2P挖掘法”， 即，至少找出个痛点或者两个论据来支持你做这件事的必要性，这个两个痛点不是拍脑袋或凭感觉，最好要有严格的数据说明。

例如现在要对一个百人的项目做组件化重构，痛点是：①编译太慢，影响开发效率；②模块耦合严重，维护成本高。为了进一步说明这个痛点有多痛，你可以用一些数据说明，例如一次编译要 20min，一般开发在开发和解 bug 平均一天编译6次，一天花在编译上的时间就是 2h， 一百人的团队，一天浪费的时间就是200h；如果能组件化后单独编译组件只要2min ，一天就能节约180h的时间。如果每件事情都逼迫自己至少挖出两个以上类似的痛点或论据，后续被问到 why 的时候，一定能应对自如， 因为你早就已经经过了深思熟虑 。

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

很多人，事情做完了，leader 不问，自己也很少去总结。但是辛辛苦苦做完事情，如果不去做一个总结的话，其实是比较亏的。到不一定是为了让 Leader知道了做了这件事取得了什么成果（当然这个也很重要），更重要的是给自己一个总结、帮助自己成长。哪些没做好需要提升，哪些是做的好的，有没有什么亮点、难点、挑战等。

4D总结法

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

结果：做完这件事，我们取得了什么结果？可能是开发效率提升了，也可能是稳定性提升了，用户 DAU 提升了。
数据：这个是对结果的补充，比如你说经过你的重构，开发效率提升了，提升了多少？这是很容易被挑战的，你在做之前应该就统计过或者调查过开发团队，开发一个版本时间是多少，解决一个 bug 平均耗时是多少，经过优化之后，一个版本迭代缩短了 xx 天。
技术提升：个人技术得到了哪些提升，是不是可以给团队做一个分享，是否可以在一个领域复用。
个人成长：比如在执行力上、事情推动力上、方法论沉淀等软实力上是不是也有收获。

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

大家看完，可能有些共鸣， 其实我们多多少少都可以从大佬们对我们的提问和指导中体会到一些，只是我们自己没有总结而已。以上方法，有些是企业管理界知名的方法论，而且在各行各业中应用， 例如 “5W”；有些是我们业界技术大佬们总结的，例如 “3C”、“4D” 就是我的前 leader 李运华 总结的；也有些是本人结合经验自己总结的例如 “2P”…