就在前两天，我们一起合作的团队某PL在本地（而不是在专门的服务器上）手工编译大包时，忘记了清理几个文件夹，导致编出的大包不可用，发布组花了一天的时间才发现原因是编译引起的。
事实上，在持续集成服务器上，有一个项目是专门用于生成大包的，但是这个PL却宁可去手动编译，我本想给他再说教一遍自动化是如何的好，可重复，效率高，但话在出口时变成了：
你干嘛不在持续集成服务器上点一下呢？ 手工编多麻烦啊，还得改配置。
我也知道啊，但是不能点啊，我看不见那个按钮
你为什么会看不见那个按钮呢？把页面打开我看看
原来是没有权限啊，你为什么不让管持续集成服务器的人给你开个权限呢？
他不给开啊
我去问问。
于是我找到了负责持续集成服务器人：
嘿，你为什么不给XX开权限呢？他在负责生成大包呢。
如果给了他权限，几个人都一起点上面的按钮怎么办呢？
不会的，你看（演示给他看），服务器自己会处理的
你看，原来真正的原因在这里，负责持续集成服务器的人不了解持续集成服务器的工作机制，对未知的恐惧让他不相信任何人，打消了他的顾虑，我又回到之前犯了错误的PL那里，
最后一个问题，就算手工编译，为什么不在服务器上进行呢？你自己的机器多慢啊
服务器是Windows 2003，允许多人登录，我如果在上面手工编译，可能会有别人也在上面编译的，协调机会出问题的，而且还有别人在上面调试脚本，我可能会影响他们的。
于是我和他一起重新配置了2003服务器，只允许同一时刻一个用户登录。
并且我得到了下面的问题列表：
为什么不能同时编译不同的项目呢？ 问题在哪儿？
为什么有人在服务器上调脚本呢？ 服务器不是工作机，他们面临的是什么问题？
…….
还记得当初我们面对的问题么？
有人不去自动化的生成大包
我们解决了的是什么问题呢？
对持续集成服务器的功能不熟悉
服务器的操作系统没有经过精心的配置
当我们不断的追问时，你会发现问题的真相在不断的浮出来，用眼睛观察问题，也不见得为实。亲爱的咨询师同事们，我建议你们也在自己的工具箱里面加上这个工具： 5 Whys
好吧，那个PL就是我。。。