多问为什么

一天，我在公司写代码，兴致正写得高。突然企业内部微信屏幕弹出一个信息，是公司另外一个部门的工程师问我：



“我的应用跑在xxx机器上，这个应用在使用你们部门开发的中间件。你能帮我开通xxx机器上的某某目录的读访问权限吗？”



我当时第一个反应就是：“好啊，只是开放一个读的权限。告诉我你的用户名，我帮你上去分配一个权限。”这应该花不了五分钟的时间，然后我又可以继续写我的代码了。正在ssh上这台机器准备操作的时候，突然一个声音在脑海闪过“他为什么要这个目录的访问权限呢？”于是，我停了下来，开始问他：



“你为什么要这个目录的访问权限啊？”



“你到底能不能给啊？不行的话，我找别人也行。”他开始有些不耐烦了，不就是开个目录的访问权限，问这么多干嘛？



“哦，我们这边开权限都需要说明业务需求的。”我随便应了一句。



“是这样，这个应用今天一直在报错，我要登到机器上，在那个目录下去看看log文件。。。”他回答。



原来他是要ssh上这台机器去看本地log文件！其实，根本没有必要！于是我回复他：



“不用这么麻烦，公司有个集中式的日志管理系统，它有个portal，你在上面可以看到你要的log。portal的地址我发给你。”



过了几分钟，他通过日志管理系统找到了想要的信息。“太谢谢你了！这样看log方便多了！”



事后，我一直在回味这件事情。我如果当初没有多想，直接给他分配目录权限，那又如何？说不定对我来说更省事儿，不是么？还和他费了这么多口舌。但是，从他的角度来说，虽然分分钟就得到了目录访问权限，但是他接下去要做的就是在黑黑的命令行下面，打各种linux命令来查找log文件寻找日志的关键线索。这哪里有日志管理系统页面上看日志来的方便啊？况且日志管理系统还有各种非常有用的过滤和聚合功能！



当初就是多问他一个“为什么”所以才能了解用户的真正需求，才能把事情做到优化。听说以前丰田公司有个著名的五个why的做法：凡遇到问题，公司都会追问问题的原因，一直问到第五个为什么。其实，很多公司，包括IT公司也有类似问题复盘的root cause分析。而root cause分析的本质就是区分真正的原因和表面的现象。



找到问题的根源才能真正解决问题，否则就是隔靴搔痒，说不定问题过几天还会出现。多问一个为什么就好比程序员在debug的时候，多step into一层。多了那一层，自己的水平就高了一层。