让每个人学会更好的沟通.docx

《让每个人学会更好的沟通.docx》由会员分享，可在线阅读，更多相关《让每个人学会更好的沟通.docx（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、让每个人学会更好的沟通让每个人学会更好的沟通软件活动的主体是人，频繁的沟通贯穿于工程计划执行的 全过程。然而，一个让人深有感触的普遍现象是，人与人之 间的沟通本钱往往远远超出你的预期，从而大大降低了工作 效率。1.1. 认识沟通本钱 沟通是必须的，但是沟通存在“巨大”本钱。Robert Cecil Martin在他的敏捷软件开发一书中曾经清晰的描述了沟通为什么总是那么费力。作者在书中创造 性使用了一个“皮肤触觉”的比喻，用来说明身体接受到的 信息和实际上发生的信息之间的差异。为了让大家对沟通的 本钱有个感性的认识，下面列举一些会让大家感觉非常亲切 的场景：1 .作为部门架构师的Andel非常苦

2、恼，工程已经到了关 键时刻，可是属于自己处理工程核心问题的时间太不够用。 排在日程表上的事情很多：9:30参加关于“跨部门技术协调 会”；11:00为测试部作产品部署培训；13:30参加基础部 门的权限设计评审；15:30讨论产品EAI集成模型。晚上 6:30以后的时间才真正属于自己，本想可以干点实事，可是 还有开发人员间歇过来询问开发问题。2 .控件部的david是公司报表控件的主要开发者，最近 抱怨有效工作时间太少。问明原因才知道，由于前期工程时 间紧张，报表匆促开发出来，结果bug很多，每天都有很多 人叫他过去救火。不去又不行，去了的话，这种中断性的工作让他没有时间来修复很多的错误，同时

3、也拖延了许多 新功能的开发，导致大家整体进度受损。3 .测试部要开始对系统进行功能测试了，发现需求规格 说明中的功能描述与实际开发的工作产品存在很多不一致。 碰到这种情况，测试人员gigi不知道应该先问明需求再测 呢，还是先测再去核实需求文档。这种情况比拟普遍，gigi 反映严重影响测试效率。4 .性能测试虚拟团队工作了一个星期，发现一点进展都没 有。原因是负责准备测试数据的开发人员在二楼，而测试人 员在三楼。面对面交流不方便，只能邮件讨论。邮件讨论效 率低，从提问到回复可能要半天、几轮、一周。5 .设计师martin跟开发人员jack在晨会中通过白板描 述调度算法的原理，并嘱咐开发人员一定按

4、照该设计意图去 实现，jack也允偌了。一周后，martin在代码走查时发现,jack居然没有正确实现该调度算法。Martin非常恼怒，怎么明明白白面对面讲明白的事情也会做错呢。而jack解释说, 自己可能当时没太明白，很多地方可能是误解了，所以还有很多场景可能在身边发生。对于这一切，告诉我们 什么呢?沟通是有本钱的，这个本钱表现在：(1)沟通无法实现100%的信息传递，由于信息失真导 致的本钱(2)沟通本身存在的时间和空间本钱(3)由于一次沟通不到位，导致发生后续屡次沟通，每 次沟通都存在上诉1,2的本钱。下列图描述了一个简单的沟通本钱模型。图中借用了通讯 理论的“信源”和“信宿”概念。信源

5、表示信息的发生端，信宿表示信息的接收端。可以看到，理想的沟通是把全部信 息从信源传递给信宿，其间不发生任何信息失真。而实际情 况，根据沟通的效果不同，信息会存在或多或少的失真。如 果失真过大，势必导致后续进一步的屡次沟通，沟通本钱无 疑提高了。1.2. 降低沟通本钱 从上面的沟通本钱模型我们可以看到，降低沟通本钱的关键在于“如何在一次沟通中尽可能完成更多信息从信源到 信宿的传递”。这里面包括两个要素:1 .尽可能让信息不失真.尽可能减少沟通对时间和空间的占用明确了以上两个基本要素，就可以进化出很多沟通技巧。1 .选择正确的沟通途径.使表述的内容易于理解2 .根据情况应用各种沟通技巧以实际的案例

6、来说明上述各种技巧：1.2.1.选择正确的沟通途径选择正确的沟通途径对于确保完成沟通目标起到非常重 要的作用。在软件工程管理中，存在各种各样的沟通。可能 因为沟通的受众不同，也可能因为沟通的内容不同，我们可 型需要选择不同沟通途经。XP和敏捷方法论中比拟显著的建 议是face to face的沟通，为了达成这样的沟通效果，建议 结对编程，建议为工程组营造无障碍的沟通环境，比方一个 工程组的成员坐在一个没有挡板的单元区间内。但是，这只是建议，具体采取什么途径还依赖实际情况。下面以一些实 际案例来说明如何选择正确的沟通途径。案例1: “我希望每个人都清楚，并且要坚决无误地执 行”Milkyway工

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

8、式往往比拟正式，容易引起员工的注意。同 时，只要会议议题明确，就能起到众所周知的作用。会议适 用于实施影响面大、行动迅速的强决策。案例2： “我的任务完成依赖于他的工作进展，我想敦促 他尽快工作”测试人员给Jack的系统管理模块录了 3个bug,其中有 个bug是参数处理不当引起的。Jack非常清楚知道这个bug 的修复要依赖参数管理模块存取接口的重构才能完成。而参 数管理模块是Michael负责的。Jack想敦促他快点完成重 构，以便他可以在正常的bug帐龄内修复它。Jack想给 Michael发送一封邮件来告诉他这件事，后来觉得还是打个电 话过去比拟好。因为现在正在集成阶段，每个人的修复任

9、务都很多，邮件也很多，如果光发邮件可能缺乏以引起Michael 对这个问题的重视。打 可以确认它知悉了这件事。评价： 沟通适合沟通动机，要求对方明确告知某件 事，要求对方尽快回复。但双方只需要语言沟通就能明确目 的。案例3： “这件事情虽然不紧急，但是我必须知会对方, 并且希望以后在必要时可以确认各自的责任”Michael的参数模块接口因为新的需求加入最近可能要作 一些代码重构，Michael考虑了 一下，觉得有两种重构方法。一种重构方法是直接修改现在既存的接口 ,但是Michael担心这个修改可能引起大面积调用该接口程序的稳定。另一种 重构方法是增加新的接口满足新的需求，同时保存老的接口 以

10、暂时兼容现有的程序，但是把这个接口设置为 depricate（不建议使用）。稳妥起见，Michael选择了第二种 方式。为了知会大家，Michael决定给整个工程组发送一封邮 件，明确目前新增接口的原因，以及老接口依然保存的决 定，但是不建议大家再使用老接口。Michael同时告诉大家， 希望大家在两周内把程序从老接口迁移到新接口。因为老接 口将在两周后被删除，评价：电子邮件适用于点对多点的异步事件通知，希望通 知对方，但不要求对方立即回复。同时邮件可以留着备查。上述的案例只是实际生活中案例的一角，但是作者希望 可以帮助读者理解，在任何沟通进行前，你需要思考一下：“我究竟如何跟他沟通才更好呢？

11、”1. 2. 2.使表述的内容易于理解沟通的困难往往在于无法把想要讲述的内容以一种对方 容易理解的方式呈现给对方。这里的呈现可能是face toface的讲述，也可能是电子邮件，还可能是文档或者代码。 笔者参加过很屡次工程设计评审、代码走查，对于这一点体 会非常深刻。很多程序员（即需求人员）与用户交流起来都很困难，这 是导致程序员无法精确理解用户的需求，从而使产品迷失方 向的一个主要原因。Jack很想让用户明白他新设计的权限模 型非常灵活，可以支持多种授权模型，绝对能够满足用户的 需要。在一次用户需求调查时，Jack听取了用户提出来的一 些操作上的人为约束后，便开始向用户津津乐道起他的权限 模

12、型来。Jack提到他的权限模型是基于角色的，可以灵活分 配权限项。只要把操作和权限项对应起来，就可以根据角色 来授权。用户很认真地在听，可是听后还是不明白Jack想表 达的东西究竟是什么，为什么要描述得这么费力。设计师很多时候也很难和开发者沟通。这些困难会直接导 致开发人员误解设计意图，从而在后续编码中偏离最初的设 计方向，造成一些无法弥补的本钱。Martin是一个有很多年网络通讯编程经验的新任设计 师，他非常了解基于多线程的socket程序是如何工作的。但 是在设计上他还是一个新手。在他设计的通讯中间件通讯线 程调度模型中，他认为自己非常简练的构架出了多个通讯代 理是如何合作完成数据交换的。

13、但是对于负责该局部开发的jack来说，jack虽然能够读懂局部类图和协作图，但是他无 法真正理解为什么要划分这些类，根据什么来划分这些类， 以及这些类之间的协作为什么需要通过第三方的类来间接达 到?Jack是个很主动地程序员，在不明白设计模型的时候他就 直接去问Martin,但是Martin认为这些模型已经描述得足够 清楚了，“就这样工作的，没问题“ o Jack的这种经常性的 询问，有时会打断Martin的手头工作，在本身任务很急的时 候，Martin不自觉地对Jack产生了不好的感觉。而Jack感受到了这种“厌烦”，遇到问题也就不再乐意主动去问 Martin T ,而是按照自己的想法去编程

14、了。一周后，martin 在代码走查时发现，jack居然没有正确实现该调度算法。 Martin非常恼怒，而jack解释说自己可能当时没太明白，很 多地方可能是误解了。问题出在哪里呢?也许无论什么时候，经理们指着他们的鼻子问,鼻子问,“在沟通的时候你们难道不希望对方理解你更多一点吗？“，他们都会回答“我们希望”。但是，在工作当中, 我们客观地发现，不少人会忘记这一点。在作者本人的持续 调查中发现，经常是如下几个理由导致沟通中的障碍。1 .相当然认为对方会理解自己的意图.认为没有足够的时间，所以在表述问题的时候采取了省略的措施.忽略了对于不同的问题应该采取不同的表述方法让他人更好的理解你的表述，有

15、什么好的方法呢?作者本 人有一些经验可以与大家共享：1.无论在工作中还是生活中，要学会多站在对方的角度 来考虑问题。中国有句成语，叫“设身处地”，就表达了这 个意思。训练的方法就是多问问自己，“他能听懂吗？”，“这种方式他能接受吗？” , “要是我是他，我会感觉如 何？”。具体一点，可能会是，“我的这段代码这么复杂，别 人能看懂吗？”、“我的设计模型描述得是否足够细致，开发 人员能正确理解吗？、“我要求完成的这些任务列表，是否 划分得足够明确，让他们一看就清楚？”、“专业上的这些词 汇，用户是否能够很好理解？”等等。1.要认识到不同的表述方式，会到达不同的效果。比 如，图形比拟简洁，适合描述一

16、些框架性的东西，从大处勾 画。文字比拟细节，适合对细微处补充说明。颜色也很重 要。在图形上通过颜色可以划分类别，让人一目了然;在文字 中可以使用颜色来强调局部内容，比方你想表达的核心思 想。坚决反对采用大段的文字来描述一个复杂的问题，因为 事实上紧张的工作中没有人愿意花上珍贵的时间来看你的大 段描述。主张表达要图文并茂，并划分细节层次。1.2. 3.沟通技巧如何更好的沟通是一门独立的学问。在这里，作者只强调 几个在我们日常工作中最有用的技巧。技巧一：向讲者复述你的理解 当别人跟你讲述某个复杂的事情的时候，保持沉默，耐心地倾听，尽管表达了你良好的修养，但是请不要随便相信 自己全部理解对方的意图。

17、很多时候你以为你理解了，其实 并未真正理解。正确的做法是根据你的理解、在适当的时机 向对方复述一遍，“听了您刚才的解释，我想描述一下我的 理解，你看对不对？“ o这样尝试一下，你往往会发现自己的理解和对方的意图往往存在差异。0K, “向讲者复述你的理 解”就是把握机会争取一次沟通就到达100%的信息传递。技巧二：好记性不如烂笔头也许你是一个记忆天才，有过目不忘之能，如果你没有 这么自信的话，请记住作者的话“好记性不如烂笔头”。这 是一个习惯，去听知识讲座，去开部门例会，去与客户谈 判，去参加需求评审，你最好都带个小本，以备不时之需。 养成良好的记笔记的习惯是高效人士的一个工作经验。技巧三：先礼

18、后“兵”工程管理中离不开对工程成员的批评和激励。批评并不等于责骂，而是要对方心服口服，重新拾起工作责任感。项 目成员没有按时完成工作任务，或者完成的质量不高，作为 工程经理应该先“礼” 先倾听一下他的个人理由。“最 近工作检查，我发现你的工作有些不太理想，是不是有什么 特殊的原因影响了你，我想听听你的解释？“。待对方解释完 ; 藤对方确实有正当理由，这样可以防止勺错误 的批评”。如果对方理由不正当，你就可以坦诚揭不他的理 由的荒谬，让他自觉低头。完成这份手稿花了两个周末。关于敏捷工程管理，我个人 感觉内容还是很多的，但是要把这些内容系统化，讲清楚， 难度很大，时间和精力对我来说太多了。还是留给大家各抒 己见，补充吧。