交流是贯穿整个项目之中的，项目收尾阶段，组外之间的交流尤为突出，交流不好，极容易出现问题，作为组长刚开始处理时觉得与组外人员交流很麻烦，因为大家的利益经常是对立，很容易把关系弄僵，但是后来细心观察、思考、实践后，发现一些小技巧，可以巧妙地解决很多问题，又何必大家争得脸红耳赤呢，现在回想起来还是别有一番乐趣的。
交流的前提：调节好自己的情绪
项目中间出了问题，换成谁都得恼火，特别是出现一些比较低级的错误，造成了不必要的损失，这时候你怎么办，马上跑过去，找到当事人，劈头就骂，假如你是别人上级，估计问题不大（其实也有很大问题呀，被骂人很有可能口服心不服）。假如别人跟你是平级或组外人员，再加上责任划分不是很明确，别人本来还有点愧疚感，被你这一骂，逆反的心理起了作用，就跟你吵起来了，大家吵得脸红耳赤，不可开交；等大伙把你们俩拉开的时候，你会发现：好像问题还没解决呀？
出了问题，应该以解决问题为主要目的。情绪一来，火气一大，骂得别人狗血淋头，反过来是你，你受得了吗？在进行交流之前，一定要适当地调节好自己的情绪；是调节情绪再进行交流，而不是心平气和地去和别人交流，因为脾气不是一天两天养成的，一下子达到这境界有可能吗？
说真的，我脾气也不小，特别是刚毕业那一会，几乎是有点属于眼睛容不下沙子，容不了别人犯错。在跟别人吵得脸红耳赤后的两三天，你再回过头看到引发争吵的问题，你会发现那个问题其实也没严重，稍微处理一下就可以解决的事，犯得上吵架吗？（不知道大家有这样的感觉吗？），情绪关键在于调节，以下是我的小方法：
（1）先歇而后行；遇了比较恼火的问题，觉得情绪上不是很好，不要马上去处理，先歇息一下，让其有一小段时间的间隔，比如上午出了点问题，下午再去交流处理，中午就是个间隔；这样做看似是误了些时间，实际则不然；估计你马上过去处理，怒气冲冲了，一般也办不好事情。
（2） 预演骂人；即然有了时间间隔，再加上现在火在心头，可以先预演一下骂人先了，找个没人的地方，阳台，走廊；把你想骂人的话骂出来，想怎么骂就怎么骂，当然最好是在心里或者低声，不要影响到别人。
经过了以上的调节之后，再去跟当事人进行交流，假如这时候还想骂人，那就骂他，经过了调节情绪还是要骂，可见这事比较重要，活该挨骂。不过就我自身，经过了（1）（2）之后，我觉得也没那么严重吧，该怎么处理就怎么处理得了，犯得上骂人吵架吗？就算有责怪也不会是那种骂得狗血淋头的。
关于情绪的小心得：
情绪对工作很重要，情绪好则工作效率高，情绪差则反之；在工作里遇到有些人情绪控制的能力很差，动不动就发火、骂人；这不仅仅是个人的问题，极容易形成怒火传递，例如：上级领导把小组的组长骂了，组长则骂组员，组员只好把怒火发泄在工作上，工作做不好上级领导又火（是不是成了一个循环了？），整个公司充满了火药味，大家一肚子怨气，这又何必呢？做为小组的组长要勇于承担一定的责任，让怒火在组长这一级别止步是很有必要的。
与测试小组的交流
测试小组拿到开发打包的程序，按照设计，需求说明及使用说明书对程序进行相关的测试，测出来的BUG分为如下几个级别（因公司而异）：
1、设计中存在功能但产品中没有
2、极其严重的错误导致无法工作
3、一个主要的错误但还可以工作
4、一个普通的错误但还可以工作
5、一个小问题
6、最好能加上的功能
这个BUG级别对开发人员来说比较重要
1、修复错误的时候尽量先修复级别高的。特别是时间紧的时候。还有很多时候都不是把整个程序开发完了再交给测试人员进行测试的，这时候测试人员把BUG表送过来了，但你手上又有任务，这时候只要先把3以上的错误修复即可，即保证了测试能够继续下去，又不会误自己的开发任务。
2、BUG级别是考核开发、测试人员绩效的重要依据，也是之间矛盾产生的根源。测试人员希望找出越多的高级别的错误，这正好表明了程序开发的质量不高，而在程序员这边素有把程序看做自己的孩子这一说法，再加上同一个错误划分级别主观因素比较重，测试人员与开发人员常为了BUG的级别发生争吵（在有些很严格的公司，一定数量某级别的BUG整个软件不能发版，听我一个同学说过，在他公司发生过一个开发人员在拿到BUG表后，直接把测试人员叫出来“单挑”），像这些情况主要是缺少有效的交流造成的，以下是我的做法：
（1）BUG表应先交给开发组组长，组长先过目
一来发现BUG级别划分不当，可与测试组的组长交流，平衡双方的利益，两个同一级别的人讨论下面组员的事，利益冲突不是很大，容易平衡，
二来防止两组组员之间闹矛盾，同一张BUG表由组长交给下面组员，与测试人员直接交给相应的开发人员，效果是完全不同的，前者组员一般是无条件接受，后面则不然。
三来防止两组组员之间作弊，有时两个人员私交太好，会做些小动作，影响组长对组员能力的判断，
四来有利于组长对组员工作的监督，你不知道他的程序出了多少问题，你又怎么知道他修复BUG时在忙些什么呢？
（2）平时多注意融洽感情，不要一见面交流都是工作上的事。像融洽小组内部关系一样，利用空余时间两组可以一起出去活动活动，再则可以在适当的时候请测试小组的人员吃吃便饭，中国俗语：吃了别人的嘴软，拿了别人的手短；这样的话在工作中测试人员说话就客气多了，万事好商量，当然这只为了搞好关系，更有利于开展工作，私下里搞太多小动作也是没必要的，务实才是根本。
与销售人员的交流
假如开发的是产品，在与销售人员的交流主要是对销售人员的培训（这部分的工作可以由开发人员去做，也可以交给测试人员，因公司而异），出现的问题主要有：销售人员在培训时不认真，培训时都说懂了，等去给客户做演示时出了问题就推托是软件的问题，以此推卸责任，到时丢单的责任就说不清了，在培训时，我的做法是：
（1）培训之后一定要进行考核，不及格者有相应处理措施。没有考核就没有压力，没考核，销售人员在下面听课是漫不经心，搞小动作，发短信，玩手机游戏； 一问有问题没，懂了没？个个都说懂，到了客户那就出问题；在培训之前先声明要考核，考核不通过有相应处理措施，这招一出下面的人不但听得认真，问题也多，这才能真正起到培训的作用。
（2）要求销售给客户演示的流程一定要按照之前的规范走，甚至连录入的数据都要求一样。这是确保销售人员在给客户演示时不会出现错误的，特别是程序开发时拖了时间，测试不够深入，这时候连录入的数据都要求与之前练习的一样，因为这时候你不知道程序大概还有多少错误，什么时候会出错，但你只要知道这样操作一定不会出错就够了。
还有个人认为开发人员程序应多与销售人员聊聊天，在闲聊时不仅可以获取到客户的很多想法，还可以从中提高与人交流的技巧，要知道销售人员的主要工作就是与人交流呀！
与客户之间的交流
客户用程序的时候出了问题，当然很着急，人之常情嘛；问题转到开发，去帮客户解决问题，要尽量耐心点并表示一定的歉意，在具体的交流时针对问题有两种大的处理方法。
（1）坦然承认是我方失误，换取客户的理解和信任。
（2）反扯是客户方问题，倒打一耙。
“客户是上帝”，只要说客户用的软件出了问题就应该是我方的失误，采用第一种方法进行处理，其好处也不用我多说了，书上及各种相关的小故事都有很详细的说明；例如：有客户自己电脑中了毒，软件用不了，像这种情况，我们一般也二话不说帮他清毒并弄好防毒的措施。
但客户是上帝，也不能太过份，特别是有些客户是那种得理不饶人，吃硬不吃软的，你跟他说是你的问题，他可就威风了，以此来为难你，让你难堪；遇到这种情况，一律采用方法（2）进行回击，其实软件出了问题，很大部分是客户对软件操作不当，或者环境出了问题，这本来就是有点扯皮的。
在实际操作中我基本上都是使用方法（1）（占99%），毕竟大部分客户都是比较好说话的，相互理解的，再有你责怪我、骂我，有个度我也就接受了。但林子大了，什么样的鸟都有呀，遇到特殊的，方法（2）特殊对待。
最新内容请见作者的GitHub页：http://qaseven.github.io/