让每个人学会更好的沟通

　　软件项目活动的主体是人，项目计划的执行过程中从开始到结束，始终都贯穿着频繁的沟通。但是一个让人感慨的普遍的现象就是人与人的沟通成本往往会远远超出你的预期，从而大大降低了工作的效率。

　　1.1. 认识沟通成本

　　沟通是必须的，但是沟通存在“巨大”成本。

　　Robert Cecil Martin在他的《敏捷软件开发》一书中曾经清晰的描述了沟通为什么总是那么费劲。作者在书中创造性使用了一个“皮肤触觉”的比喻，用来说明身体接受到的信息和实际上发生的信息之间的差异。为了让大家对沟通的成本有个感性的认识，下面列举一些会让大家感觉非常亲切的场景：

　　1. 作为部门架构师的Andel非常苦恼，项目已经到了关键时刻，可是属于自己处理项目核心问题的时间太不够用。排在日程表上的事情很多：9:30参加关于“跨部门技术协调会”；11:00 为测试部作产品部署培训；13:30 参加基础部门的权限设计评审；15:30 讨论产品EAI集成模型。晚上6:30以后的时间才真正属于自己，本想可以干点实事，可是还有开发人员间歇过来询问开发问题。

　　2. 控件部的david是公司报表控件的主要开发者，最近抱怨有效工作时间太少。问明原因才知道，由于前期项目时间紧张，报表匆促开发出来，结果bug很多，每天都有很多人叫他过去救火。不去又不行，去了的话，这种中断性的工作让他没有时间来修复很多已知的错误，同时也拖延了许多新功能的开发，导致大家整体进度受损。

　　3. 测试部要开始对系统进行功能测试了，发现需求规格说明中的功能描述与实际开发的工作产品存在很多不一致。碰到这种情况，测试人员gigi不知道应该先问明需求再测呢，还是先测再去核实需求文档。这种情况比较普遍，gigi反映严重影响测试效率。

　　4. 性能测试虚拟团队已经开工一周了，可是发现工作根本没有什么进展。原因是负责测试数据准备的开发人员在二楼，而测试人员在三楼。直接面对面沟通不便，只能在邮件中讨论。邮件讨论效率很低，问题提出到响应可能都需要半天，几个回合，一周就过去了。

　　5. 设计师martin 跟开发人员jack在晨会中通过白板描述调度算法的原理，并嘱咐开发人员一定按照该设计意图去实现，jack也允偌了。一周后，martin在代码走查时发现，jack居然没有正确实现该调度算法。Martin非常恼怒，怎么明明白白面对面讲明白的事情也会做错呢。而jack解释说，自己可能当时没太明白，很多地方可能是误解了，所以…

　　还有很多场景可能在身边发生。对于这一切，告诉我们什么呢?沟通是有成本的，这个成本表现在：

　　（1） 沟通无法实现100%的信息传递，由于信息失真导致的成本

　　（2）沟通本身存在的时间和空间成本

　　（3）由于一次沟通不到位，导致发生后续多次沟通，每次沟通都存在上诉1,2的成本。

　　下图描述了一个简单的沟通成本模型。图中借用了通讯理论的“信源”和“信宿”概念。信源表示信息的发生端，信宿表示信息的接收端。可以看到，理想的沟通是把全部信息从信源传递给信宿，其间不发生任何信息失真。而实际情况，根据沟通的效果不同，信息会存在或多或少的失真。如果失真过大，势必导致后续进一步的多次沟通，沟通成本无疑提高了。

　　1.2. 降低沟通成本

　　从上面的沟通成本模型我们可以看到，降低沟通成本的关键在于“如何在一次沟通中尽可能完成更多信息从信源到信宿的传递”。这里面包括两个要素：

　　1. 尽可能让信息不失真

　　2. 尽可能减少沟通对时间和空间的占用

　　明确上述两个基本要素，可以演化出很多沟通技巧来。

　　1. 选择正确的沟通途径

　　2. 使表述的内容易于理解

　　3. 根据情况应用各种沟通技巧

　　以实际的案例来说明上述各种技巧：

　 　1.2.1. 选择正确的沟通途径

　　选择正确的沟通途径对于确保完成沟通目标起到非常重要的作用。在软件项目管理中，存在各种各样的沟通。可能因为沟通的受众不同，也可能因为沟通的内容不同，我们可能需要选择不同沟通途经。XP和敏捷方法论中比较显著的建议是face to face的沟通，为了达成这样的沟通效果，建议结对编程，建议为项目组营造无障碍的沟通环境，比如一个项目组的成员坐在一个没有挡板的单元区间内。但是，这只是建议，具体采取什么途径还依赖实际情况。下面以一些实际案例来说明如何选择正确的沟通途径。

　　案例1：“我希望每个人都清楚，并且要坚决无误地执行”

　　Milkyway项目组的负责人Rassy 从最近的项目里程碑评审发现系统存在很多中断性错误，软件的质量似乎已经到了不得不狠抓的时候了。Rassy知道这项工作的紧迫性，也知道这项工作必须把需求、设计、开发各方面的人员都调动起来，大家一起关心产品的质量，才能有效改进他。Rassy知道这样一项工作要开展下去，需要各方面人员深刻认识目前质量的现状，并且一定要拿出具体的可实施的保证方案才能有效达到目标，于是Rassy决定召开一个全员质量动员大会，在会上统一强调目前质量与预期的差异，明确提出增加一个质量评审里程碑，要求大家会后立即准备行动计划。

　　评价：对全局有着重大影响的事件，有必要采用全员会议的形式。这种形式往往比较正式，容易引起员工重视。同时，只要会议议题明确，完全可以起到众所周知的效果。全员会议适合实施影响面积大，行动快的强力决策推动。

　　案例2：“我的任务完成依赖于他的工作进展，我想敦促他尽快工作”

　　测试人员给Jack的系统管理模块录了3个bug，其中有个bug是参数处理不当引起的。Jack非常清楚知道这个bug的修复要依赖参数管理模块存取接口的重构才能完成。而参数管理模块是Michael负责的。Jack想敦促他快点完成重构，以便他可以在正常的bug帐龄内修复它。Jack想给Michael发送一封邮件来告诉他这件事，后来觉得还是打个电话过去比较好。因为现在正在集成阶段，每个人的修复任务都很多，邮件也很多，如果光发邮件可能不足以引起Michael对这个问题的重视。打电话可以确认它知悉了这件事。

　　评价：打电话的沟通方式适合于沟通动机中要求明确知会对方某件事情，并且要求对方能够尽快响应，而双方只需要语言沟通即可明确目的。

　　案例3：“这件事情虽然不紧急，但是我必须知会对方，并且希望以后在必要时可以确认各自的责任”

　　Michael的参数模块接口因为新的需求加入最近可能要作一些代码重构，Michael考虑了一下，觉得有两种重构方法。一种重构办法是直接修改现在既存的接口，但是Michael担心这个修改可能引起大面积调用该接口程序的稳定。另一种重构方法是增加新的接口满足新的需求，同时保留老的接口以暂时兼容现有的程序，但是把这个接口设置为depricate(不建议使用)。稳妥起见，Michael选择了第二种方式。为了知会大家，Michael决定给整个项目组发送一封邮件，明确目前新增接口的原因，以及老接口依然保留的决定，但是不建议大家再使用老接口。Michael同时告诉大家，希望大家在两周内把程序从老接口迁移到新接口。因为老接口将在两周后被删除，

　　评价：邮件方式适合点对多点的异步事件通知，希望知会对方，但是并不要求对方立即响应。同时邮件可以保留以备查阅。

　　上述的案例只是实际生活中案例的一角，但是作者希望可以帮助读者理解，在任何沟通进行前，你需要思考一下：“我究竟如何跟他沟通才更好呢?”