如何与你的老大沟通？

看了 CSDN 冯大侠的《老 大，我想说两句》， 深有感触，因为我也曾经遇到过类似的情况，深知这种情况下个人的郁闷感觉。

 

但现实毕竟是“老大”就是老 大，你的前途、薪水都掌握在老大手里，抱怨和郁闷都不能解决问题，反而会使问题更加恶化；而且既然是老大，那么必然有过人之处（不管是技术、还是有关系、 还是会说话，那都是老大的优势）。因此，我们要学会和老大沟通交流的技巧（当然这些技巧同样适合跟其他人沟通交流）。

 

下面是我根据自己的经验总结的 几条，希望对各位遇到类似问题的兄弟姐妹能有帮助。

1 ）用别人听得懂的语言

这个道理其实很简单，比如说你 要和老美交流，你用中文，他只懂英文，你们能够交流吗？对老美你可以说“这个老美不懂中文，我没法和他交流”，对老大你能这么做吗？这么做就只有走人了， 但是换个地方还是有老大的啊：）

 

但遇到实际情况的时候，很多人 就忘记了这条简单重要的原则。

我们就以 CSDN 冯大侠的《老大，我想说两句》一文中的内容来做样例吧（没有看不起或者批评冯大侠的意思，就事论 事）：

1 、 需要考虑“开 - 闭”原则，以便于增加新的服务 不修改原来的程序；

从博文来看，冯大侠的技术功力 非常深厚，但问题就在这里：别人听不懂！不要说做管理的，就是做技术的，估计也没有几个人能达到这样的高度。我原来的公司从架构师到资深设计师到设计师， 没有几个人懂“开闭原则“，最多就听说过而已，对于开闭原则怎么做、有什么作用都不清楚，你要说开闭原则可以“增加新的服务不修改原来的程序”，别人还会 说你吹牛“不修改程序怎么增加新的服务”！这样不就是用中文和老美交谈么？

 

但“开闭原则”确实有用，那 么，这种情况下我们应该如何把“开闭原则”的好处用别人听得懂的语言描述出来呢？理论上很难定义，给个样例大家就会明白，还是以冯大侠的这条来说吧，用老 大听得懂的语言可以这么说：

如果用了开闭原则，下次增加另 外一个功能时只需要 500 行，如果不用开闭原则，那么增加另外一个功能要 5000 行。

或者干脆不要提“开闭原则”， 因为有的老大听到你这么说，担心你提一个他听不懂的概念来忽悠他，或者通过这种东东来鄙视他，所以你干脆这么说：

如果这么做，下次增加另外一个 功能时只需要 500 行，如果不这么做，那么增加 另外一个功能要 5000 行。

当然，如果你的老大连 500 行和 5000 行都听不懂，那么要多少人天总能听懂吧，那么你就可以这么说（假设一人天全流程 20 行）：

如果这么做，下次增加另外一个 功能时只需要 25 人天，如果不这么做，那么增 加另外一个功能要 250 人天。

如果这样还听不懂，那我只能为 你祈祷了：）

 

以下是我总结的常用“技术语 言”对应的“管理语言”说法，抛砖引玉，具体应用的时候根据具体情况来选择：

1 ）可扩展性：转换成增加一个新功能需要的工 作量；

2 ）可移植性：转换成切换系统所需要的工作 量；

3 ）可靠性：转换成一年宕机几次，每次宕机恢 复时间多长，需要多少人维护系统等；

4 ）可维护性：转换成客户经过多久可以熟悉系 统、一个复杂的操作所耗时间的前后对比；

5 ）可测试性：转换成是否可以自动化测试，测 试人力减少多少，测试时间减少多少；

6 ）性能：转换成系统容量、客户完成一个操作 的时间；

7 ）技术优势：转换成工作量，例如用 Java 做工作量多少，用 Python 做多少；

 

2 ）关注对别人有利的东西

让别人听得懂只是沟通交流的第 一步，别人听得懂还不一定会听你的，因此我们要用上第二招：关注对别人有利的东西，简单来说就是“利诱”！

 

“利诱”这个词可能不好听，但 非常有效，因为人都具有爱面子、重实利的心理。别人和你争执，争的是什么？当然是面子和利益了。如果你竭尽全力证明别人是完全错误的，或者这件事只对你有 益，别人凭什么要听你的，好处都让你拿了，面子都让你挣了，别人还有什么？那还不和你拼个鱼死网破？

 

所以，沟通交流讲究的是“双赢”，大家都有面子，大家都有肉吃，这样最后大家才能双赢，才能和谐 。

 

我们来看冯大侠的样例吧：

你知道 JAVA 但是从来没写过，但是你不知道 JAVA 是面象对象的，编程是要考虑扩 展性、安全性、易维护性，并且要采用合适的模式，这样设计出来的系统才是可以越做越好的，而不是象我们原来做的财务系统一样，去每个行都有新功能要做，但 是就是没有一个综合的系统，像金蝶、用友那样功能越来越全的系统；

通过这段话，我们可以看到冯大 侠在抱怨老大不懂技术，导致做了一个不好的产品。但这样说无疑是打了老大两个耳光：“老大不懂技术”、“因为老大不懂技术所以做了一个垃圾产品”，这样老 大的面子往哪里搁啊？

 

而且这段话内容虽然是正确的，但如果老大来看，他的利益体现在哪里？没有地方体现。“越做越好”、 “综合的系统”、“功能越来越全”这种不是老大的利益，而是公司的利益，老大关注的是开发周期、产品 BUG 率、工作量、需求实现率、以及各种针对他的考核指标。

 

因此，如果关注老大的利益，我 们就不能这么说，而要站在老大的角度，看看对老大究竟有什么好处。以下样例仅供参考：

如果用 Java 开发，结合设计模式等相关理 念，开发周期可以减少到原来的 50% ，产品 BUG 率降低到 0.1% ，工作量降低 50%......

 

3 ）提供足够的事实证据

我们知道，在实际交流的时候有 很多感性的东东，比如说“好”和“坏”、“较多”、“较少”、“可能”、“也许”。。。。。。等等，这些词语说起来简单，也给说的人留下了一些回旋的余 地，但这些词语是沟通交流的很大一个障碍，因为每个人理解的都不一样，理解不一样就会产生误解和矛盾。相信大家都有这个经历：要么是大家都对牛弹琴、鸡同 鸭讲，要么最后才发现原来双方争论的不是一回事。

 

有一个笑话：同样是看到“美 女”这个词，人想到的是“貂蝉”，猪想到的是“乌克兰大白猪”、猫想到的是“金丝猫”！

 

所以，沟通交流的时候，尽量避免这种感性的描述，而要提供事实证据，比如说数据、图表、分析报告等 。

 

还有一个方法：找更多赞同你的人来一起沟通，如果里面有老大信任的人更好，所谓“三人成虎” 。人越多，事实就 会表现得越真实：）

 

4 ）如果以上措施都没有生效，那么放弃沟 通交流，不要浪费时间

最后，如果你以上方法都试过 了，但还是没有效果，那么我的建议是放弃说服和沟通，不要浪费时间了。

 

这种情况下要么按照老大的说法 去做，要么自己该怎么做就怎么做，反正老大不会来看代码。

 

但我要提醒你，如果按照自己的 方法做，风险很大：做得好，老大不会感激你，因为这相当于证明了他的无能；做的不好，所有错误都是你来承担！

 

最后，希望各位 XDJM 看到这篇博文能够有所收获。当然，最好的情况是有个好老大，即使不 懂技术也没有关系，希望各位 XDJM 能够有这样的运气了：）