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同时告诉大家，希望大家在两周内把程序从老接口迁移到新接口。因为老接口将在两周后被删除，
评价：邮件方式适合点对多点的异步事件通知，希望知会对方，但是并不要求对方立即响应。同时邮件可以保留以备查阅。
上述的案例只是实际生活中案例的一角，但是作者希望可以帮助读者理解，在任何沟通进行前，你需要思考一下：“我究竟如何跟他沟通才更好呢?”
1.2.2. 使表述的内容易于理解
沟通的困难往往在于无法把想要讲述的内容以一种对方容易理解的方式呈现给对方。这里的呈现可能是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. 要认识到不同的表述方式，会达到不同的效果。比如，图形比较简洁，适合描述一些框架性的东西，从大处勾画。文字比较细节，适合对细微处补充说明。颜色也很重要。在图形上通过颜色可以划分类别，让人一目了然;在文字中可以使用颜色来强调部分内容，比如你想表达的核心思想。坚决反对采用大段的文字来描述一个复杂的问题，因为事实上紧张的工作中没有人愿意花上宝贵的时间来看你的大段描述。主张表达要图文并茂，并划分细节层次。
1.2.3. 沟通技巧
如何更好沟通是一门独立的学问，作者在这里只强调几个在我们日常工作中最用得着的技巧。
技巧一：向讲者复述你的理解
当别人跟你讲述某个复杂的事情的时候，保持沉默，耐心地倾听，尽管体现了你良好的修养，但是请不要随便相信自己全部理解对方的意图。很多时候你以为你理解了，其实并未真正理解。正确的做法是根据你的理解、在适当的时机向对方复述一遍，“听了您刚才的解释，我想描述一下我的理解，你看对不对?”。这样尝试一下，你往往会发现自己的理解和对方的意图往往存在差异。OK,“向讲者复述你的理解”就是把握机会争取一次沟通就达到100%的信息传递。
技巧二：好记性不如烂笔头
也许你是一个记忆天才，有过目不忘之能，如果你没有这么自信的话，请记住作者的话“好记性不如烂笔头”。这是一个习惯，去听知识讲座，去开部门例会，去与客户谈判，去参加需求评审，你最好都带个小本，以备不时之需。养成良好的记笔记的习惯是高效人士的一个工作经验。
技巧三：先礼后“兵”
项目管理中离不开对项目成员的批评和激励。批评并不等于责骂，而是要对方心服口服，重新拾起工作责任感。项目成员没有按时完成工作任务，或者完成的质量不高，作为项目经理应该先“礼”——先倾听一下他的个人理由。“最近工作检查，我发现你的工作有些不太理想，是不是有什么特殊的原因影响了你，我想听听你的解释?”。待对方解释完了，如果对方的确有“正当理由”，这样可以避免你“错误的批评”。如果对方理由不正当，你就可以坦诚揭示他的理由的荒谬，让他自觉低头。
利用两个周末的时间，完成了这份稿件。关于敏捷项目管理，个人感觉内容上还有很多，但是要把这些内容系统化，清清楚楚讲述出来，感觉存在很大难度，时间和精力上都有些力不从心，索性就留待大家来发表意见和补充吧。
