公司的实施工程师在甲方现场反映了一个问题，大概就是我们的软件在一种未知的情况下，会将磁盘空间占用到百分之九十左右。在这种情况下，会让甲方的电脑变得特别的卡，导致程序无法正常运行。
得知这个问题后，负责这个项目的研发部门的同事就开始找原因。因为客户环境是有硬件支持的，所以想要在公司内部复现这个问题就很难，所以负责这个项目的程序员只能靠翻看代码来分析问题出现的原因。
可是，这个程序员找了很久也没有找到出现这个问题的真正原因，只能凭借自己的猜测，优化一些可能导致磁盘占用过高的代码。尽管代码改了很多次，问题依然没有解决。
最后，公司包括我在内的其他研发同事看不下去了，纷纷加入了找问题的队伍当中。大家各抒己见，代码照样改了很多个版本，依然没有找到问题的所在。
留在客户现场的实施同事都急坏了，因为甲方每隔一段时间就会问他一次问题解决了没有。而且，每次更新版本都需要甲方这边暂时停工才能把新版本的软件部署上去。对于甲方来说，停工就意味着要耽误生产进度，因此，甲方很快就没有了耐心。
当甲方没有耐心以后，就开始找我们公司在现场的实施同事的麻烦，甚至是打电话给我们公司的老板来向我们施压。
老板也急，他很能体会甲方的感受。因为整个寻找问题的过程持续了好几天，已经严重影响到了甲方的生产，问题再不解决的话不光甲方损失惨重，到时候公司可能都要受到甲方的索赔。
于是，老板多次去找我们公司的研发总监，觉得他是研发部门的老大，技术能力应该要比公司任何人都要好才对，让他去找问题效率会高一点。
但是，每次老板让研发总监去找问题时，研发总监都以自己在忙为由，拒绝自己亲自去找问题。还说研发部人那么多，大家细心点一定能发现问题。
而且，研发总监每次都把问题描述得好像很简单一样。因此，大家找不出问题就会藏着不说，因为没有人愿意承认一个简单的问题他们找不出来。
看研发总监已经拒绝了自己好几次求助，而且大家都没有找出问题时，老板终于火了，直接命令研发总监，不管他手头有多么重要的事情，这回一定要停下，直到把当前的问题解决了为止。
但是，研发总监也不是个软柿子，直接就跟老板吵了起来。
老板认为眼下这个甲方的问题是最重要的，如果再不解决，甲方真的会找公司麻烦。而研发总监认为他现在正在干的事情比较棘手，不应该老分散他的注意力。
他们俩当着全体员工的面就这么吵着，场面一度非常紧张。
直到研发总监说出一句话：“整个公司有那么多人，我就很难理解为什么这么一个简单的问题怎么就找了那么久！”。
听到这话，老板愣住了，半天才憋出一句话：“问题原因你早就知道了？”。
研发总监轻蔑地跟负责这个项目的程序员解释问题出现的原因，并且把代码的修改思路告诉了他。
老板问：“你既然知道为什么不早说？”。
研发总监反而表现出一副恨铁不成钢的样子，回答道：“谁知道他们是怎么搞的，这么简单的问题都找不到！”。
说完，研发总监就回到自己的座位上，继续去研究自己的代码去了。
而老板的表情怪怪的，走到负责这个项目的程序员的身边，然后大家都拢了上来，看这个研发同事分析代码、改代码。
当这个研发同事改完代码，把软件打包发给甲方现场的实施同事后，实施同事一部署，果然，问题就解决了！
虽然问题解决了，但是老板却没有怪罪这个研发同事，但也没有表现出多么高兴的样子，始终板着个脸。
其实大家都知道，老板这是被研发总监给气到了！而且还气得不轻！
当一个问题始终无法得到解决的时候，我们的研发总监并没有第一时间告诉我们问题出现的原因，而就这样看着大家手忙脚乱地翻看代码。表现出来的感觉好像就是这个事情跟他无关一样。
其实，只要他早点把问题指出来，甲方那边的生产就不会被耽误，研发部那些帮忙找问题的程序员也不会浪费那么多时间。尤其是在甲方那边的实施工程师也不需要在甲方那逗留太长的时间。
我明白研发总监的“苦衷”，他的意思是让我们自己通过找问题出现的原因来增长自己的编码功底，因为这样往往比较容易记住。这放在平时研发时间比较充裕的时候的确对大家有帮助。
可是，当一个紧急情况出现的时候，首先要解决的应当是紧急情况，而不是指望着其他人去”悟”出什么道理来。
老板最后表情也说明了一切，我感觉他对研发总监是比较失望的，觉得他分不清事情的轻重缓急。
其实像我们研发总监这样的人有很多，比较固执。虽然能力很好，但缺少了一些大局观。
也不知老板经过这件事情，心里会产生一些什么想法！
联系客服
