引言：技术硬实力很重要，然而技术软实力同样也很重要，本文一起探讨下应该怎样做事。
吴孟达的一句”你在教我做事啊“成了生活中一个开玩笑的梗，大家都喜欢以自己的方式做事情，然而我们的做事方式真的正确吗，是否有更好的做事方式了，值得深入研究探讨。
如果本文是告诉你，要认真做事，要专心做事，巴拉巴拉，说一大推老生常谈的东西，估计你看到直接想骂人：“真是闲的蛋疼，扯一堆没用的”。如果真是那样，我自己也会骂自己吃饱了撑的，浪费大好时间和精力。
那么，本文究竟想探讨什么了？本文是想探讨和总结一些好的做事方式或者是一些形成体系的方法论，它不是那种笼统的东西，而是一些具体的且行之有效的且经过实践检验的做事理论。
按照时间顺序，对于做一件事情，我们将其分为事前、事中和事后三个阶段，就每个阶段，再分别探讨分析下，应该做什么以及怎么做。为什么要这么拆分了？是因为，我们很多时候，只关注“事中”阶段，只想着怎么把事情做好做完，而事情做完后，又马上投入了其他事情，忽略了事前和事后阶段，然后那才是往往决定一个人成长和发展的关键环节。比如我们有没有思考过什么要做这件事、目标是啥。做完后，是否有思考过这个是否可以适用其他场景甚至抽象出一些通用的东西，此外自己从中是否有学到什么了时候有总结了。
本文将围绕“事前-事中-事后”三个阶段，去展开各个环节中的一些方论论讨论，最终希望形成一个成体系的闭环思维和做事方法论。
事前阶段
“为什么要做这件事？”，“痛点是什么？”，这是很多大佬经常问的问题，往往是在你滔滔不绝地介绍方案的时候，大佬们就用这个问题打断了你，既然大佬们经常问，说明背后一定有其深层原因，结合我自身的理解我从技术优化类和产品需求类来分析这个思考的必要性吧，这是码农日常最常见的两类事情。
产品需求类： 很多人说， 这个产品都已经思考好了， 照着做就是了，哪来那么多为什么呀？的确，在我们这些码农接到需求之前，产品同学内部应该都讨论多伦了，但是我们还是要去理解一下需求背后的深层原因，一方面能够加深对需求的理解、提高业务理解能力， 另一方面也能通过对需求本质的理解在设计方案的时候思路更清晰，例如技术方案评审的时候被问到为什么这么做、而不是那么做的时候， 你能结合需求业务场景和扩展性等作出清晰的解释。
技术优化类： 比如你觉得现在网络框架中需要引入 quic ，你要思考的问题就是为什么要引入 ， 是 quic 比较弱网情况下性能比较好？那再问，我们目前的网络库性能表现不好吗？ 有没有数据支撑说明？ 另外做完这件事投入是多少？ 收益是多少？能不能从现有的数据情况推论出做这件事之后的收益？ 这些问题想清楚之后，规划执行才能有理有据，你的 leader 才可能给你争取资源来做。
思考动机
知道经常被问和理解其必要性之后，我们就来准备怎么才能清晰回答这些问题，要想应对自如，就是提前问自己，方法论是：“2P挖掘法”：
即至少找出两个痛点或者两个论据来支持你做这件事的必要性， 这两个痛点不是拍脑袋或凭感觉，最好要有严格的数据说明。
例如，现在要对一个百人的项目做组件化重构，痛点是： 1. 编译太慢，影响开发效率；2. 模块耦合严重，维护成本高； 为了进一步说明这个痛点有多痛， 你可以用一些数据说明，例如一次编译要 20min， 一般开发在开发和解 bug 平均一天编译 6 次，一天花在编译上的时间就是 2h， 一百人的团队， 一天浪费的时间就是 200h； 如果能组件化后单独编译组件只要 2min ， 一天就能节约180h 的时间。 如果每件事情都逼迫自己至少挖出两个以上类似的痛点或论据，后续被问到 why 的时候，一定能应对自如， 因为你早就已经经过了深思熟虑 。
目标制定
如何深刻理解目标？一方面要有基础的知识、能力积累，另一方面要灵活运用SMART原则从不同维度梳理目标。
● S：具体，把目标明确到一件具体的结果上，而不是虚无缥缈抓不住的想法；M：量化，搞清楚需要达到什么量化的结果；
● A：可实现，认真考量目标是否可以实现，团队的资源、能力、士气是否足够达成目标所需的条件，如果不满足怎么办，如果远远超出能力范围，就不要做承诺；
● R：有意义，做这件事对公司、对团队、对个人是否有意义，深刻理解其中的意义是什么；
● T：有时限，明确了解完成目标最终实现的时间限制。
事中阶段
想清楚为什么做这件事之后，做的时候就能放开顾虑去做了， 包括方案设计、落地实施、问题处理等重要的步骤。
设计优先
“设计优先”这条原则，相对来说更加具体一些。之所以单列一项，是因为架构设计太重要了。Uncle Bob曾说过：“软件架构的目标，是为了让构建与维护系统的所需人力资源最小化。”
架构设计，并不仅仅关系到系统的质量，还关乎团队的效能问题。很多团队也有明文规定，开发周期在3pd以上的项目必须有设计文档，开发周期在5pd以上的项目必须有设计评审。在具体的执行过程中，由于各种原因，设计往往并不能达到预期的效果。究其原因，有的是因为项目周期紧，来不及设计得足够详细；有的是因为RD主观上认为项目比较简单，设计草草了事。无数事实证明，忽略了前期设计，往往会导致后续开发周期被大幅拉长，给项目带来了很大的Delay风险。而且最可怕的是，不当的设计会给项目带来巨大的后期维护成本，我们不得不腾出时间，专门进行项目的优化与重构。因此，无论什么时候都要记住“设计优先”这一原则。磨刀不误砍柴工，前期良好的设计，会给项目开发以及后期维护带来极大的收益。
“设计优先”这一原则，要求写别人看得懂的设计。我们了解一个系统最直接的途径就是结合设计文档与代码。在实际工作中，很多同学的设计文档让大家看得一头雾水，通篇下来，看不出系统整体的设计思路。其实，设计的过程是一种智力上的创造，我们更希望它能成为个人与集体智慧的结晶。如何才能让我们的设计变得通俗易懂？我个人认为，设计应该尽量使用比较合理的逻辑，进而把设计中的一些点组织起来。比如可以使用从抽象到具体，由总到分的结构来组织材料。在设计过程中，要以需求为出发点，通过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。做完设计之后，可以发给比较资深的RD或者PM审阅一下，根据他们的反馈再进行完善。好的设计，一定是逻辑清晰易懂、细节落地可执行的。
如何设计方案
“你为什么选择这个方案？”、“你的方案考虑过xxx这种情况吗？”、“业界是怎么做的？为啥不使用xxx开源方案？”，这些都是在一场技术评审会上被问得最多的问题， 如果你的回答是支支吾吾、临时拼凑，那么就会给人留下你没有深入研究的印象。 解决这个问题的方法是：每次设计方案的时候逼迫自己想出三个备选方案，如果你想出了三个方案，那么前面提到的哪些问题，你一定都提前问过自己了。这个其实就是3C 方案设计法：
3C ，即三个 Choice, 主要是逼迫自己去想更多的可能性， 横向对比行业是怎么做的，是不是可以拿来用， 自身业务情况下是不是有更多选择， 严格按照这个思维去做方案， 久而久之也会无形中提高自己的深度和广度，有人可能会觉得浪费时间，想快，这也是人的天性，但是我们用这些方法论不就是对抗人性的弱点吗？ 如果为了快，方案有多潦草，技术评审会上讨论就有多激烈， 最终也浪费了大家的时间，最终返工浪费的时间更多，还给大佬留下不好的印象， 所以”3C“还是值得花时间去做的。
稳步推进
落地实施的进度条
方案设计之后， 就是怎么推动事情落地了。 首先把任务按照依赖关系最小粒度的划分，评估每个模块的工作量，最后评估出总的工作量， 然后排上计划，执行的时候就开始了我们的进度条， 如果太长 ，可以划分为 2~3 个里程碑，执行过程随时检测进度，是不是存在风险。需要注意的是， 在拆解任务的时候尽量识别出依赖或被依赖的关键节点，尽早安排，实际开发中， 工作量评估最常见的盲区就是忽略了跨组联调、对接话的时间，这些节点往往也容易成为项目进度风险的关键因素。
借助他人的力量
程序员最容易犯的错误就是习惯自己一个人埋头苦干，希望自己能搞定一切事情，怕打扰他人， 但是有些事情需要他人配合才能完成，甚至需要依赖外部团队， 怎么推动他人按照自己的计划配合完成事情呢？ 这里我觉得和平时做人有些关系（并不是指人品好坏），我觉得会有一篇《大佬们的做人方法论》， 如果是熟人、或有交情的人，推动起来就事半功倍，如果不熟悉，的确不太好推动，可能平时多和兄弟团队多打打招呼、多认识认识会有些好处。 如果自己无法驱动时， 可以借助 leader 的力量， leader 出面，对方也会重视起来，别人配合你做事也有名有分。
问题分析
方案执行或上线灰度中会遇到一些问题，需要我们第一时间去分析原因。这里，我们要注意直接原因和根本原因的区分，那么什么是直接原因和根本原因了？举个例子：
问题：为何请求出现502？
回答：因为服务发生了重启。
对于，上面这个例子，当用户请求发生502时，分析下，很快就发现服务发生了重启导致请求找不到服务，进而导致了502。因为服务重启频率很低，很多人到这一步可能就结束了。然而，真正原因是什么了，继续深入：
问题：为何发生重启?
回答：因为服务发生OOM？
问题：为何OOM?
回答：因为服务JVM参数设置不合理，导致OOM
可以，发现服务是由于JVM参数设置不合理，在某些特殊的场景后，就会发生OOM。对于上面这个例子，其中服务重启就是直接原因，而JVM参数设置不合理才是根本原因。如果找到直接原因就打住，那么其实根本原因没找到， 迟早还是会出问题。
因此，我们需要区分直接原因和根本原因，对于每一个问题都要找到根本原因，那么如何找到根本原因了？通过连续追问，就可以找到根本原因，这个方法叫做 “5W根因分析法”，最初是由丰田集团创始人丰田佐吉提出的, 这方法论指导丰田成为世界名企，具体内容如下：
实践应用中，不一定要问5个问题，有时可能问到第三个就找到了根本原因了，这里需要注意的时，在连续追问的时候可能容易挑起情绪化，认为发问者是在刁难你，容易引发撕逼；问之前也可以强调下，接下来我们要用5W根因分析法找原因了，大家不要情绪化。 我相信大家在实际过程中都被 leader 的连环夺命问折磨过， 解决的方法是：提前用连环夺命问先折磨自己，避免同步问题的时候被 leader 连环夺命问折磨。
事后阶段
事后包括：事后反馈，事后汇报，事后总结。
事后反馈
凡事有交代，件件有着落，事事有回音。很多人，事情做完了， leader 不问，你也不说，那leader就无法把握事情的进展，如果出现问题影响了项目整体进度，那这风险就不可控了。
因此，面对别人交代的事，尤其是上级交代的一件事情，作为下属应该尽力去完成 ，而最后不管完成的质量如何都应该在约定的时间内给领导一个反馈。
事后汇报
当我们把事情做完后，很多时候，像别人汇报或称述时，总是逻辑混乱，或者啰哩啰嗦，抓不住重点，这里建议采用金字塔模式展开。
何为金字塔模式？简单来讲，就是任何事都可以总结出一个结论（结论先行），然后这个结论由三至七个分论据支撑，而这些分论据又本身也可作为分论点，如此延伸下去，犹如一个金字塔。
逻辑上，可以采用金字塔模式，形式上可以如果可以用上SCQOR法则，那就更完美了，何为SCQOR？其中：
● S是情景(Situation);由听众熟悉的情景引入——项目背景
● C是矛盾(Complication); 说明发生的冲突——现状分析
● Q是问题(Question)：引发或提出问题？——问题解析
● O是具体内容或过程（Obstracle)，如何解决问题，客服障碍
● R是解决收尾（Resolution ）
如果要将SCQOR大致做出区分，SCQ是故事的导入，通过汇报对象已经熟知的事物或信息来导入，使汇报对象产生疑问，过渡到希望要引出回答的问题上。O为故事的中心，R则是故事的结尾。一般来说故事的导入和结尾内容比较少，故事的中心内容篇幅最多。以大家熟悉的“起、承、转、合”架构来做对照，SCQ为起，O为“承、转、承、转、承、转”，R是合。
事后总结
很多人，事情做完了，自己也很少去总结，但是辛辛苦苦做完事情，如果不去做一个总结的话，其实是比较亏的。更重要的是给自己一个总结、帮组自己成长。哪些没做好需要提升，哪些是做的好的，有没有什么亮点、难点、挑战等。
那么，如何总结了，可以采用4D总结法，从四个维度对这件事情做个总结： 结果、数据、技术提升、个人成长四个维度：
● 结果： 做完这件事，我们取得了什么结果？ 可能是开发效率提升了， 也可能是稳定性提升了，用户 DAU 提升了。
● 数据： 这个是对结果的补充， 比如你说经过你的重构，开发效率提升了，提升了多少？ 这是很容易被挑战的， 你在做之前应该就统计过或者调查过开发团队， 开发一个版本时间是多少， 解决一个 bug 平均耗时是多少； 经过优化之后， 一个版本迭代缩短了 xx 天。
● 技术提升： 个人技术得到了哪些提升， 是不是可以给团队做一个分享， 是否可以在一个领域复用。
● 个人成长： 比如在执行力上、事情推动力上、方法论沉淀等软实力上是不是也有收获。
后记说明
这里，我简单介绍下自己，我只是一个在腾讯才工作三年的菜鸟，谈不上自己的做事方法论总结，上述大多是参考其他大佬的建议和文章，本文是个开篇，我希望自己能时常来更新这篇文章，不断丰富和调整其内容。
参考文章：
一图看透腾讯大佬们的做事方法论
写给工程师的十条精进原则
浅谈写作逻辑思维之SCQOR模型
《金字塔原理》
5w2h分析法最全解析，收藏了