2、BUG级别是考核开发、测试人员绩效的重要依据，也是之间矛盾产生的根源。测试人员希望找出越多的高级别的错误，这正好表明了程序开发的质量不高，而在程序员这边素有把程序看做自己的孩子这一说法，再加上同一个错误划分级别主观因素比较重，测试人员与开发人员常为了BUG的级别发生争吵（在有些很严格的公司，一定数量某级别的BUG整个软件不能发版，听我一个同学说过，在他公司发生过一个开发人员在拿到BUG表后，直接把测试人员叫出来“单挑”），像这些情况主要是缺少有效的交流造成的，以下是我的做法：
（1）BUG表应先交给开发组组长，组长先过目
一来发现BUG级别划分不当，可与测试组的组长交流，平衡双方的利益，两个同一级别的人讨论下面组员的事，利益冲突不是很大，容易平衡，
二来防止两组组员之间闹矛盾，同一张BUG表由组长交给下面组员，与测试人员直接交给相应的开发人员，效果是完全不同的，前者组员一般是无条件接受，后面则不然。
三来防止两组组员之间作弊，有时两个人员私交太好，会做些小动作，影响组长对组员能力的判断，
四来有利于组长对组员工作的监督，你不知道他的程序出了多少问题，你又怎么知道他修复BUG时在忙些什么呢？
（2）平时多注意融洽感情，不要一见面交流都是工作上的事。像融洽小组内部关系一样，利用空余时间两组可以一起出去活动活动，再则可以在适当的时候请测试小组的人员吃吃便饭，中国俗语：吃了别人的嘴软，拿了别人的手短；这样的话在工作中测试人员说话就客气多了，万事好商量，当然这只为了搞好关系，更有利于开展工作，私下里搞太多小动作也是没必要的，务实才是根本。
与销售人员的交流
假如开发的是产品，在与销售人员的交流主要是对销售人员的培训（这部分的工作可以由开发人员去做，也可以交给测试人员，因公司而异），出现的问题主要有：销售人员在培训时不认真，培训时都说懂了，等去给客户做演示时出了问题就推托是软件的问题，以此推卸责任，到时丢单的责任就说不清了，在培训时，我的做法是：
（1）培训之后一定要进行考核，不及格者有相应处理措施。没有考核就没有压力，没考核，销售人员在下面听课是漫不经心，搞小动作，发短信，玩手机游戏； 一问有问题没，懂了没？个个都说懂，到了客户那就出问题；在培训之前先声明要考核，考核不通过有相应处理措施，这招一出下面的人不但听得认真，问题也多，这才能真正起到培训的作用。
（2）要求销售给客户演示的流程一定要按照之前的规范走，甚至连录入的数据都要求一样。这是确保销售人员在给客户演示时不会出现错误的，特别是程序开发时拖了时间，测试不够深入，这时候连录入的数据都要求与之前练习的一样，因为这时候你不知道程序大概还有多少错误，什么时候会出错，但你只要知道这样操作一定不会出错就够了。
还有个人认为开发人员程序应多与销售人员聊聊天，在闲聊时不仅可以获取到客户的很多想法，还可以从中提高与人交流的技巧，要知道销售人员的主要工作就是与人交流呀！
与客户之间的交流
客户用程序的时候出了问题，当然很着急，人之常情嘛；问题转到开发，去帮客户解决问题，要尽量耐心点并表示一定的歉意，在具体的交流时针对问题有两种大的处理方法。
（1）坦然承认是我方失误，换取客户的理解和信任。
（2）反扯是客户方问题，倒打一耙。
“客户是上帝”，只要说客户用的软件出了问题就应该是我方的失误，采用第一种方法进行处理，其好处也不用我多说了，书上及各种相关的小故事都有很详细的说明；例如：有客户自己电脑中了毒，软件用不了，像这种情况，我们一般也二话不说帮他清毒并弄好防毒的措施。
但客户是上帝，也不能太过份，特别是有些客户是那种得理不饶人，吃硬不吃软的，你跟他说是你的问题，他可就威风了，以此来为难你，让你难堪；遇到这种情况，一律采用方法（2）进行回击，其实软件出了问题，很大部分是客户对软件操作不当，或者环境出了问题，这本来就是有点扯皮的。
在实际操作中我基本上都是使用方法（1）（占99%），毕竟大部分客户都是比较好说话的，相互理解的，再有你责怪我、骂我，有个度我也就接受了。但林子大了，什么样的鸟都有呀，遇到特殊的，方法（2）特殊对待。
相关链接：
