本质归因法
咨询行业中经常使用一种名为RCA（Root Cause Analysis）的方法，翻译过来亦称为“根本原因解析法/根本原因分析法”，是一种用于分析失败的程序、技术问题、意外事件等所导致任务未完成根本原因的方法。
当然我们小程序员们不用搞那么复杂，写什么流程画什么图啥的，用个意思就行。我习惯于画个多叉树，把根问题的可能直接原因列成叶子，再对每个直接原因进行推导，直到难以继续分解为止。
举个例子，某公司2020年1月1日大版本延期了，要开会找出原因。注意以下场景纯属虚构。
按老板的意思，你们这批程序员不行，都开除掉重新招算了。即使远程会议上看不见大家的脸，想必也是喜上眉梢，要感谢老板送来买年货的钱，顺便跳个槽涨个薪。当然负责人的思路还是清醒的，要我们回去正常总结一下。
其实RCA非常适合分析项目延期问题。不妨就拿这个例子来说，表层现象就是项目延期，直接原因是大家没有及时完成原定任务。
那老板说开除大家不很对么？当然不是，因为再分解一下就会发现，不是所有人都没完成任务，后端声称接口已完成，是前端没有完成。
于是老板又跳出来，那就是前端不行，换前端！我们无视之，继续分析可能原因，前端没完成接口，是接口给的晚？还是工作太多？还是前端怠工了？
首先接口给的不晚，因为我们是个虚构公司，接口不是由后端先给出，而是由项目经理根据需求提前约定字段双方实现，避免接口依赖空等。工作太多也不可能，因为我们是个虚构公司，按照合理的工作结构分解(WBS)和关键路径分析(CPA)，避免了关键路径过长导致项目延期。
随后老板再次跳出来！那一定是前端工作能力或态度不行！我亲眼看见他上班时候摸了下手机！以后没收手机开发！–其实这是RCA常见的问题，当我们对目标问题层层分解，达到一个符合领导期望的解释的时候，往往就会止步于此，完成归因。很不幸，指标不治本的时候居多，不要得到一个解释就满意了，RCA的精髓就是不断本质归因。
继续分析前端小伙。首先不存在工作能力不行问题，因为完成过同等难度问题。那是工作态度不行？当然小伙确实存在手机摸鱼现象，但是，因为我们是一个虚构公司，我们不以现象而是以实际成果来评价工作产出。
继续分析前端小伙的每周产出，经过评估，每周产出完全达标。等等不对！既然工作结构分解那里保证了每周正常工作足以完成项目，那延期是怎么回事？再细看看，这个首页美化任务两周是怎么回事？怎么不记得大版本里还有这个玩意？
这时产品经理反应过来，哦，我看这个首页效果不错，就让前端加一下，还有两个模块，竞品有了我们也得有啊。哦嚯，就是你小子差点帮助我们脱离苦海，啊不对，害得我们差点被开啊？
这也不能归因于产品经理，优化产品和分析竞品都是本职工作，问题在于不能随随便便就在菜里加料。那就继续分解，回到前端小伙，为啥让你加你就加啊。前端小伙儿一脸无辜，他说加就加呗，每周五个模块干啥不是干呢，再说他力主要加功能，上次开会都跟后端大哥拍桌子了。
随着层层分解，逐渐接近问题的本质了，因为我们是一家真实的，啊不对，虚构的公司。我们，没有，项目经理！任务规划很随意，排期很随意，加个功能很随意，眼看完不成了也没人调整规划，全靠领导一言堂说干就干，依仗于基层程序员们强大的自驱力和经验，搞成这样已经很不容易了。
话说回来，虽然问题能层层分解，但是不是分解到最底层才解决最好。比如一个函数工作不正常了，层层分解最后发现是C++编译器有问题，能在这一层解决么？老老实实返回上一层取消O3优化。RCA至少是避免在非常浅的层次去分析解决问题，减少指标不治本的现象，也有助于锻炼深度思考。
再回到这个不恰当的例子，本质上是老板没招项目经理，但是我们能在这一层解决问题么？很难的啦。最后我们规范了版本需求表，另外拆分出了OKR表放置产品经理的奇思妙想，等有余力的同学去完成。