今天不知道怎的和老婆讨论起说话方式的问题，我一听忽然就想起老婆曾经说和她们公司的程序员交流特别费劲，总是一句话说不明白，开会啰哩啰嗦半天也不知道他们说的啥。我作为一个正常的程序员，我忽然发现我也有这个问题，于是我就从自身出发，思考这个问题的原因，想了好久，今天提到这个问题嘛，我就想解释一下我作为一个程序员，为啥会有上述问题：

程序员作为一个职业，当然也有其职业习惯，程序员们互相交流，往往并不会用大量语言去从头到尾详细描述一个事物，他们描述自己的工作，喜欢逐个介绍其中的特点，往往很难一句话简明扼要的说出一个事物。因为程序员正常天天写代码，确实缺少这方面的训练。逐个介绍特点这种方式对外行人来说与盲人摸象没什么区别，不要说外行人，有时候程序员自己人都听得云里雾里，不知道对方说的啥，很多时候程序员沟通时都是自设情境，按照自己的经验猜测对方说的是啥，然后和对方说的特点相匹配，匹配成功说明大家表达的是同一个意思。

很显然不管是不是程序员，上述沟通方式是很有问题的，我之前做需求开发的时候也经常犯这样的错误，觉得自己写得如此清晰，开发人员应该一点就通才对，实际上根本不是。我认为简单的需求，是因为我做过或者见过，但是开发人员真的不一定见过，这和聪明与否无关，与经验多少也无关。因为同样一个功能，实现方式可以有多种多样，不详细介绍，光说功能特点，“想到一块儿去”的可能性真是太小了。

我本来以为我解释得很好，老婆一听立马来了劲，表示说话不说情楚都是表达者的没传达好，不能怪听的人，还搬出了个“名人名言”：信息发出者对沟通负有主要责任！我一听情绪也上来了，怎么可能有这么绝对的观点！毕竟奇葩说里马东还说过，被误会是表达者的宿命，被人误解，表达者明明也是受害者，怎么能光追究表达者的责任呢？为此我们居然争辩了好久。

中午吃饭，老婆一顿好言相劝，我作为一个深明大义的好男人，忽然觉得老婆还是相当有道理的，就需求分析的工作来说，我写的需求开发人员没有搞明白，我当然有不可推卸的责任，我写需求就是为了让开发人员搞明白需求，从目的性的角度来说，这的确是表达者的责任。

但是问题又来了，表达者究竟要表达到什么程度才不会被误解呢？为此我特意上网搜索了老婆那句“名人名言”的原话，原话是这么说的：“有效的沟通是信息发出者和信息接收者共同的不可推卸的责任。”这话出自李晓光的《管理学原理》第十五章信息沟通，是大学教材，学管理的同学应该没有没听过这话的。唉，顿感被老婆摆了一道，我就说哪有那么绝对的观点。说说自己的经验吧，我有段时间带着两位同学小Y和小Z一起做项目，他们两位对待需求的态度截然不同，小Y是来者不拒，我怎么说他就怎么做，从来不在乎需求中有什么问题，也不去判断需求合不合理；而小Z每次都会仔细阅读需求文档和交互设计，每个功能都仔细琢磨才开始开发，好几次都能提出一些我没有考虑妥当的问题。说实话，起初我对于小Y还是挺欣赏的，应该最开始项目繁忙，我认为这样的同学比较让人省心，一点就通嘛；而小Z天天给我找茬，还总否定我的观点，夸张时候连大家一起讨论确定的需求也会质疑，我知道他不是故意的，但是他已经爱上了质疑，停不下来了。。但是时间没过多久，随着项目进展，我就幡然悔悟，没有所谓的一点就通，别人反驳你，不代表别人误会你；别人赞同你，也不代表你就是正确的。多亏了小Z时刻质疑我，项目才能稳步推进，虽然确实让我忙得时候更忙了，但是提前趟平了很多大坑呀，出来混早晚要还的，吃苦在前享乐在后嘛！其实小Y也是很有能力的，就算需求不那么合理，他也能发挥主观能动性，实现得很好，这也是很了不起的。

被误会是表达者的宿命？这在研发管理中是不能接受的，任何管理者都要拒绝这样的宿命，有效沟通是管理者的必备技术，需求传递、设计传递不能因为简单就忽视，不能因为麻烦就不和同事交流。倾听别的人论述千万不能预设观点，预设观点和立场是误会的源泉。需求和设计简单不简单，与是否聪明无关，与经验也无关，简单不简单不能凭主观想象，不要忽视任何一个与你共事的同事。

Ps:《管理学原理》工科生值得拥有！