【思维模式】做事方法论

 

事前：2P挖掘法（为什么要做这个事情，痛点是什么？）

知道经常被问和理解事情必要性之后，我们就来准备怎么才能清晰回答这些问题，要想应对自如，就是提前问自己；方法论是：“2P挖掘法”， 即，至少找出个痛点或者两个论据来支持你做这件事的必要性， 这个两个痛点不是拍脑袋或凭感觉，最好要有严格的数据说明； 例如现在要对一个百人的项目做组件化重构，痛点是： 1. 编译太慢，影响开发效率；2. 模块耦合严重，维护成本高； 为了进一步说明这个痛点有多痛， 你可以用一些数据说明，例如一次编译要 20min， 一般开发在开发和解 bug 平均一天编译 6 次，一天花在编译上的时间就是 2h， 一百 人的团队， 一天浪费的时间就是 200h； 如果能组件化后单独编译组件只要 2min ， 一天就能节约180h 的时间。 如果每件事情都逼迫自己至少挖出两个以上类似的痛点或论据，后续被问到 why 的时候，一定能应对自如， 因为你早就已经经过了深思熟虑 。

 

个人总结：

讲述做事情必要性时，至少有２个有严格数据的痛点来支持必要性

 

事中执行

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

3C 方案设计法

“你为什么选择这个方案？”、“你的方案考虑过xxx这种情况吗？”、“业界是怎么做的？为啥不使用xxx开源方案？”，这些都是在一场技术评审会上被问得最多的问题， 如果你的回答是支支吾吾、临时拼凑，那么就会给人留下你没有深入研究的印象。 解决这个问题的方法是：每次设计方案的时候逼迫自己想出三个备选方案，如果你想出了三个方案，那么前面提到的哪些问题，你一定都提前问过自己了。

3C ，即三个 Choice, 主要是逼迫自己去想更多的可能性， 横向对比行业是怎么做的，是不是可以拿来用， 自身业务情况下是不是有更多选择， 严格按照这个思维去做方案， 久而久之也会无形中提高自己的深度和广度，有人可能会觉得浪费时间，想快，这也是人的天性，但是我们用这些方法论不就是对抗人性的弱点吗？ 如果为了快，方案有多潦草，技术评审会上讨论就有多激烈， 最终也浪费了大家的时间，最终返工浪费的时间更多，还给大佬留下不好的印象， 所以”3C“还是值得花时间去做的。

 

个人总结：

• 选举三个备选方案
• 视野广度＝》业界、公司内部、团队内部方案
• 视野深度＝》优略势分析，评估属性
  安全：是否存在安全漏洞
  容灾：免费版本是否支持集群
  性能：TPS、QPS评估
  可维护性：是否开源、复杂度（开箱即用）
  社区活跃度：
  是否稳定：待解决的issue
  人力投入：
  硬件成本：

落地实施的进度条

方案设计之后， 就是怎么推动事情落地了。 首先把任务按照依赖关系最小粒度的划分，评估每个模块的工作量，最后评估出总的工作量， 然后排上计划，执行的时候就开始了我们的进度条， 如果太长 ，可以划分为 2~3 个里程碑，执行过程随时检测进度，是不是存在风险。需要注意的是， 在拆解任务的时候尽量识别出依赖或被依赖的关键节点，尽早安排，实际开发中， 工作量评估最常见的盲区就是忽略了跨组联调、对接话的时间，这些节点往往也容易成为项目进度风险的关键因素。

个人总结：

• 分解模块和功能点、确定功能点优先级（ｐ０，ｐ１）、确定外部依赖关键节点
• 确定里程碑
• 每周中旬监控项目进度，确定项目风险
• 定期总结和复盘
  
  

借助他人的力量

程序员最容易犯的错误就是习惯自己一个人埋头苦干，希望自己能搞定一切事情，怕打扰他人， 但是有些事情需要他人配合才能完成，甚至需要依赖外部团队， 怎么推动他人按照自己的计划配合完成事情呢？ 这里我觉得和平时做人有些关系（并不是指人品好坏），我觉得会有一篇《大佬们的做人方法论》， 如果是熟人、或有交情的人，推动起来就事半功倍，如果不熟悉，的确不太好推动，可能平时多和兄弟团队多打打招呼、多认识认识会有些好处。 如果自己无法驱动时， 可以借助 leader 的力量， leader 出面，对方也会重视起来，别人配合你做事也有名有分。

 

5W根因分析法

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

Leader： CGI 成功率为啥突然降低了？
下属：请求量太大，服务器负载过大，崩溃了， 正在扩容。
Leader：为啥请求太大?
下属：客户端某个数据上报增大了？
Leader： 为啥上报请求增大了？
下属：请求失败落地存储太多，第二次启动时批量上报太多。
Leader：为啥突然请求失败存储增多了？
下属：此前服务器发布，导致部分出现抖动，上报失败了。

这里通过连续发问，找到根本原因，方案是临时扩容，同时客户端对上报请求做了限频，防止一次上报太多导致雪崩效应。 如果问到第一个问题就打住，那么采取的方案可能仅仅是扩容，但是根本原因没找到， 迟早还是会出问题。通过连续追问，找到根本原因，这个方法叫做 “5W根因分析法”，又称丰田5问法，最初是由丰田集团创始人丰田佐吉提出的, 这方法论指导丰田成为世界名企。实践应用中，不一定要问5个问题，有时可能问到第三个就找到了根本原因了，这里需要注意的时，在连续追问的时候可能容易挑起情绪化，认为发问者是在***难你，容易引发撕逼；问之前也可以强调下，接下来我们要用5W根因分析法找原因了，大家不要情绪化。 我相信大家在实际过程中都被 leader 的连环夺命问折磨过， 解决的方法是：提前用连环夺命问先折磨自己，避免同步问题的时候被 leader 连环夺命问折磨。

总结：

追溯问题连续问自己５个为什么，先折磨自己

事后总结

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

4D总结法

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