先讲一个编造的故事。

小新在科研中遇到一个问题，要求求解一个几乎不可能得到分析解的一元方程，小新通过查文献，发现牛顿迭代可以用数值解法得到解，于是自己开始写程序实现牛顿迭代。小新在这个问题上已经困扰了很久，因此很高兴地向老板汇报，说他终于找到可行的办法了，两天内就可以得到结果！但小新在计算的时候发现，自己的那个方程在某些系数的条件下，对给定的初值非常敏感，迭代不稳定，结果容易发散。然后经过仔细排查，发现如果不让两次迭代的结果跨越太大，比如添加一个系数，让下一步的解只跳一半的距离，迭代就稳定多了。经过加班加点，总算在两天之内按照改进的迭代算法，得到了正确的结果。

然而在向老板报告结果的时候，小新遇到了意想不到的麻烦。他向老板大致地讲了牛顿迭代的原理（编造的故事，不用在意细节~），然后重点讲了自己在迭代计算中做出的改进，最后简单讲了一下计算的结果。小新的意图是，强调自己在迭代算法中的创新，来突出自己做的工作，毕竟也是在这部分花费了最多的时间，也是最「原创」的工作。然而，从老板的角度来看，他的目的只是得到方程的解，本来听牛顿迭代就已经云里雾里了，然后又听小新大篇幅地讲了他在牛顿迭代上做的修改，怎么听都不怎么靠谱。因此，本来一次比较简短的讨论会，介绍一下采用的求解方法，然后交流一下求解的结果，最后却变成了在算法的细节上无休止的争论。老板认为小新修改了别人的算法，但又提不出足够的理由来说这样做的合理性；小新则认为老板在求解方法这个几乎不懂的领域不懂装懂，乱提意见。

经历过几次这样的事情之后，小新无奈地得出结论，老板只看重结果，不必再跟他讲具体过程。

类似的故事，相信很多研究生、职场人士都经历过。事情本身很难用对或错来单纯地判断，双方各有各的道理，但现实中遇到这样的事情，还是非常恼人的，既浪费时间，又影响情绪。

有些时候，处事还是要灵活一些，尤其是像小新这样在多次遇到这种情况的时候，就应该慎重地考虑在与老板沟通的策略上是不是要适当调整了。在跟老板报告最新结果之前，最好自己先想明白，他最关心的部分是什么，那么这些问题应该作为汇报的重点来讲，而其它方面的，尤其是太过技术的具体细节，应当避免过于深入，给出足够的证据说明它是合理的即可。