如果情况有变，却不及时沟通，自己想当然的去做，往往会引起大问题。”
接下来叶奕凡讲了一个上半年，在人事业务部门中发生的一个真实故事。
故事主人公就是费文，他是外派员工，一直在java组工作，责任心强，能力也强，很受内外认可。
java组维护着一个人事业务的网站，上半年网站要增加几个新功能，就专门开了一个新项目去做。
前面非常顺利，设计、编码、测试、客户测试都结束，马上就准备上线了。
在上线之前，费文还在认真的检查着项目代码。结果很意外的发现了在一个重要的页面上，有一行代码写的有错误。
这个错误本身，非常明显，毫无争议，确实是错误。但这行代码，并不是这次新功能的代码，而是系统中以前就存在的，也就是说，它并不属于这次项目的工作范围。
而且这个错误的影响，只不过使页面某处显示格式不太正常而已，客户用了很长时间，估计都没注意到过，当看不见也完全没问题。
但费文实在是太有责任心了，一看到这么明显的错误，就直接给改了过来。正常情况下，代码有改动，是一定要在客户测试的环境中，测一遍的。
可当时客户环境有些问题没有启动，他也就没马上测试，再过不久，产品就上线了。
可悲的是，他把那行代码改了后，以前的错误确实没有了，但改动有手误，引出了另一个更严重的错误。
以前的错误，只是页面显示有些问题，不注意都发现不了，他改后，会出现系统级的错误，页面本身都无法访问了。
产品上线后，用户访问那个页面的时，果然出现了系统错误，页面无法访问。
有这种事情发生，影响当然是极其不好的，客户马上要求查明原因，原因很好查，费文把他做的事情老实交待了。
这种事情，客户当然是十分愤怒的，质问你们经过允许了吗，凭什么改以前的代码。
寺野为这个事，专门和叶奕凡好好谈了一下。
发现了系统上以前的，客户都没有注意到的错误，这本来是个天大的好事。
如果与客户沟通后，再对此错误进行处理，会格外增加客户的满意度。
而且如果与客户沟通后再动作，就算我们修改出现手误，那也是正常范围内的工作失误，不算大事。
但现在这种情况，是在没有经过客户同意的情况下，改动了本来是这次项目范围之外的代码，还出了错，这就是天大的坏事了。
这好比是人家请你来装修厨房，你觉得他家的卫生间不好，自做主张给重修了一下，还给干漏水了，这叫什么事?
寺野痛心疾首的对叶奕凡说：“本来是天大的好事，结果，变成了天大的坏事，这真是太遗憾，太遗憾，太遗憾了。”
在面对客户的时候，寺野和叶奕凡应该是算同一战壕的。这次的事件，寺野直接承受了客户的怒火。连续三个遗憾，隔着屏幕，叶奕凡都感受到了他的委屈。
天大的好事，与天大的坏事之间，就差了一个，沟通。