sp; 使表述的内容易于理解
沟通的困难往往在于无法把想要讲述的内容以一种对方容易理解的方式呈现给对方。这里的呈现可能是face to face的讲述，也可能是电子邮件，还可能是文档或者代码。笔者参加过很多次项目设计评审、代码走查，对于这一点体会非常深刻。
很多程序员（即需求人员）与用户交流起来都很困难，这是导致程序员无法精确理解用户的需求，从而使产品迷失方向的一个主要原因。Jack 很想让用户明白他新设计的权限模型非常灵活，可以支持多种授权模型，绝对能够满足用户的需要。在一次用户需求调查时，Jack听取了用户提出来的一些操作上的人为约束后，便开始向用户津津乐道起他的权限模型来。Jack提到他的权限模型是基于角色的，可以灵活分配权限项。只要把操作和权限项对应起来，就可以根据角色来授权。用户很认真地在听，可是听后还是不明白Jack想表达的东西究竟是什么，为什么要描述得这么费劲。
设计人员与开发人员交流起来很多时候也同样困难，这些困难会直接导致开发人员误解设计意图，从而在后续编码中偏离了原始的设计方向，造成一些难以挽回的代价。
Martin是一个有很多年网络通讯编程经验的新任设计师，他非常了解基于多线程的socket程序是如何工作的。但是在设计上他还是一个新手。在他设计的通讯中间件通讯线程调度模型中，他认为自己非常简练的构架出了多个通讯代理是如何合作完成数据交换的。但是对于负责该部分开发的jack来说，jack虽然能够读懂部分类图和协作图，但是他无法真正理解为什么要划分这些类，根据什么来划分这些类，以及这些类之间的协作为什么需要通过第三方的类来间接达到？Jack是个很主动地程序员，在不明白设计模型的时候他就直接去问Martin，但是Martin认为这些模型已经描述得足够清楚了，“就这样工作的，没问题”。Jack的这种经常性的询问，有时会打断Martin的手头工作，在本身任务很急的时候，Martin不自觉地对Jack产生了不好的感觉。而Jack感受到了这种“厌烦”，遇到问题也就不再乐意主动去问Martin了，而是按照自己的想法去编程了。一周后，martin在代码走查时发现，jack居然没有正确实现该调度算法。Martin非常恼怒，而jack解释说自己可能当时没太明白，很多地方可能是误解了。
问题出在哪里呢？也许无论什么时候，经理们指着他们的鼻子问，“在沟通的时候你们难道不希望对方理解你更多一点吗？”，他们都会回答“我们希望”。但是，在工作当中，我们客观地发现，不少人会忘记这一点。在作者本人的持续调查中发现，经常是如下几个理由导致沟通中的障碍。
1. 相当然认为对方会理解自己的意图
2. 认为没有足够的时间，所以在表述问题的时候采取了省略的措施
3. 忽略了对于不同的问题应该采取不同的表述方法
让他人更好的理解你的表述，有什么好的办法呢？作者本人有一些经验可以与大家共享：
1. 无论在工作中还是生活中，要学会多站在对方的角度来考虑问题。中国有句成语，叫“设身处地”，就表达了这个意思。训练的方法就是多问问自己，“他能听懂吗？”，“这种方式他能接受吗？”，“要是我是他，我会感觉如何？”。具体一点，可能会是，“我的这段代码这么复杂，别人能看懂吗？”、“我的设计模型描述得是否足够细致，开发人员能正确理解吗？”、“我要求完成的这些任务列表，是否划分得足够明确，让他们一看就清楚？”、“专业上的这些词汇，用户是否能够很好理解？”等等。
1. 要认识到不同的表述方式，会达到不同的效果。比如，图形比较简洁，适合描述一些框架性的东西，从大处勾画。文字比较细节，适合对细微处补充说明。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
