马斯克解读，践行第一性原理的五步流程

通常优秀的工程师犯的最大的错误是，对本不该存在的东西进行优化。

比如很多时候，不管是架构设计，还是方案设计，总会出现watch dog的设计在里面。

举两个工作中经常遇到的例子。

什么是watch dog？

比如A服务调用B服务，上线之后发现会出现调用失败的情况，很多人就基于这个思想又搞出来了个日志对账功能，就是定时看A调用的日志和B收到调用的日志做对账，如果发现存在调用失败情况，则发出报警。

这第三个系统就是watch dog。

如果用第一性原理可以想两个问题。

1. 这种情况真的需要一个第三个系统去解决这个问题吗？
   

2. 第三个系统真的可以解决这个问题吗？

最好的方式还是在服务调用本身去解决这个问题。他本来就是一个确定性要解决的分布式服务调用异常的问题，这个问题所属的问题域也只应该服务调用层面，在这里解决这个问题成本最低、效果最好。

其实可以想象，保证这个对账系统稳定准确又是一堆新的问题，成本和收益并不匹配。

类似的产品设计上也存在类似的情况，比如原有的查询页面，查询条件不完善，有的产品就会想到再设计一个新的查询页面给专门的场景用，其实最简单的方式，是在原有的查询页面上基于权限控制查询条件即可实现。

引入了新的查询页面解决一个小需求就是watch dog。

引入了本不应该存在的复杂度模块，也导致查询功能碎片化，为全局提出了新的问题。

带着方案分析原始问题是另一种情况。

很多人分不清问题还是现象，又有人提出问题或者思考问题痛点时，你可以听出来，他是带着自己的方案来分析原始问题的。

比如有的人遇到一个问题，第一反应就是用线上化去解决这个问题，于是他的思考上就或多或少受到了这个倾向性方案的影响。他对于原始问题的分析就无形中放大了很多非线上化时的痛点和问题了，以说服自己必须线上化才行。

表面上看从非线上化到线上化似乎是一脉相承的，但其实逻辑并不自洽，因为对于问题原始的分析上多了有色眼镜，本来的痛点的逻辑分析势必就少了很多。

有时，你问一个产品owner或者系统owner说：这个需求或者功能为什么这样设计或者实现？

经常有人会说，之前就是这么设计的。

问一个研发，为什么这么解决。

他说以前代码就是这么写的，这次只是简单优化了下。

这些人都是没有从这个需求本身出发，这种情况给出的方案可想而知肯定不是最优的，甚至有可能是错误的，因为你依赖了一个可能本质上错误的前提。

一般这些人心理活动层面有两种：

1. 甩锅心态：如果做不好，起码可以说之前就是这样实现的和我无关。

2. 过于懒惰：既然有人已经做了一部分，修修补补总是省力，跑到一线调研需求比较辛苦。

遇到这种情况，一般会追问几个本质类的问题。比如你怎么理解这个问题的，他的目标用户是谁，究竟有什么痛点是必须要解决的，长期看他的理想态应该是什么样。

如果既缺少勇气去改造历史包袱，又缺少实事求是的心态去挖掘本质痛点，而以讹传讹，那么做的很多事情其实不会带来什么价值。

那，采用第一性原理分析与解决问题就非常重要。

我们必须拒绝类比，从第一性原理出发。

第一性原理，马斯克总结了五步流程来解决问题。

第一步：让需求不要那么愚蠢。

第二步：删减不需要的部分，进行抽象/提炼。

如果你没能删减至少10%，那么你删减的肯定还不够。

第三步：提炼后的优化和迭代。

第四步：提升生产效率。

第五步：让他们自动化运转。

马斯克本人说，他自己也经常搞乱顺序，所以他会不断提醒自己必须按照这个顺序去实践。

而且马斯克觉得，很多时候直接删除比不断优化更好。