2006-11-26

谁是敌人?

很傻的问题,岂能不辨敌我?然而在特定情况下知道敌我之分和真正用相应行动来回应敌我是不一致的。近几年的新闻报道的科索沃、阿富汗与伊拉克战争中,给我最大的感觉就是战争中(尤其是美国及其盟友方面)死人越来越少了。从强大的一方来看,其打击的目的是摧毁对方的反击能力,现代战争中,摧毁运输通道与大规模杀伤性武器即可达到目的。而读史记等书就有不同的感觉,好像中国自古以来一大特色就是人多,命贱,像蚂蚁一样,不起眼的战争也是万人级的伤亡,时不时就“坑**万”。其实目的是一样的,摧毁对方的反击能力,因为古代打仗的决定性因素就是人,而现代战争的决定性因素变成了武器系统。然而即使进化到现在,战争中一个小问题还没有解决,即误伤自己人,古代打仗,大家一起往前冲,挥刀狂砍,相信死在自己人刀下的冤死鬼不少,现在新闻中也经常报道美国与其盟友内部互相误伤的事例。可见,真正能明辨敌我不容易啊。

近日在site工作也遇到了这种尴尬,如果把调测与解决问题看成战争,显然tester与developer是盟友,共同的敌人是存在的问题,tester发现问题,developer解决问题,互相配合赢得战争。而实际的情况并不如此完美,往往在内部展开了暗斗,tester发现问题,developer想掩盖问题,于是tester想扩大问题以引起注意,developer更想掩盖并反击,其结果是双方文明地“剑拔弩张”。比较尴尬,不过也还算不坏,至少在争吵中还是能解决问题,大方向上不至于在和和气气中输掉战争。也许tester和developer之间的现实关系就是这样,在和共同的敌人斗争的同时内部打打闹闹,不值得奇怪。但理想的情况应该不是这样的,盟友之间应该“狼狈为奸”才对。问题出在哪儿呢?

首先是沟通。

沟通应该是个普遍问题,由于表达能力及方式的有限,不可能完全表达清楚思想及感受,人与人之间总会产生误解,因此一方的话传到另一方可能意思就反了。本来好意提醒错误的存在,会被认为是挑衅、找麻烦;本来仅想描述错误,却被理解为对其的指责,于是“仇恨”的种子便生根发芽,茁壮成长。
避免这种情况需要双方做到就事论事,不带强烈的感情色彩,尤其tester在找到问题时不能太过得意,以免产生误解,找到愚蠢错误时也不要过于愤怒,人总会犯错误。

从辩证法上来看,双方也有不可调和的矛盾,立场不同,tester的本职就是找错误,错误找的越多越有成绩,而developer虽然解决问题多也有其成绩,而往往由于其解决的问题就是其先前留下的,便成了其污点,问题越多,污点越多,越会被人指责,于是不可避免想掩盖错误,质疑与模糊tester的战果,有责任心的tester是不能允许这样的,于是会更加努力证明developer的确存在问题,矛盾的双方的人民内部斗争便开始升级。
从辩证法的观点看,双方也应该是统一的,共同为了同一个终极目标而奋斗:消灭bug。为什么往往会忘记这点呢?developer难道不知道掩盖问题无异于给自己埋炸弹吗?不知道故意抵赖与狡辩是不职业的行为吗?否也,这些理放在平时谁都懂,但是一到参与其中,便很少有人能做到恰到好处。为什么会这样?是什么使正常情况下的正常人变成非理智人?

是压力!

如果没有各种限制,比如时间限制,完全在理想情况下,放松的状态下,双方心平气和,相信都是谦谦君子,互相谅解、礼让,好好就问题论事、解决问题。但是实际情况不可能是这样的,每个项目都不可能没有时间限制,总是时间不够用,受各种条件制约。于是,对于tester找出的问题,developer必须在限定时间解决,找的越多压力越大,而往往问题多的地方正是前期质量较差的地方,需要修复的时间越多,带来压力更大,developer不堪重负,于是设法掩盖问题。尤其是再有从上层来的压力的时候,developer更会崩溃。同时,tester在site上遇到的问题多,也会倍感压力,更多来自客户,一般很多问题都不便向客户坦白,而是寻求内部尽快解决,于是把受到的压力也传递到developer那儿。由此可见,tester和developer都会很有压力,压力倾向于汇聚于developer,但developer也会通过抵赖的方法来自卫并反击tester,并且可能会通过各种解释使上层相信tester报告的问题不准确或不存在,使上层challenge tester,让tester做更多的测试来证明的确是问题,加重了tester的压力,于是“怨恨”在双方之间传开,不加控制会造成不合作状态。

在压力情况下,不光tester和developer会失去理智,manager也同样会失去理智。人总是偏向于听好消息,对坏消息有拒斥心理,于是developer很容易使manager相信问题不大,能很快找到“银弹”,而tester专报告问题,并且有时会夸大问题,显得很讨厌,便有可能受到无理惩罚。至此也明白为什么历史上在皇帝身边出了那么多得势的花言巧语的奸臣,而又冤死了那么秉言直书的忠臣:(

事态至此,如果不加控制,恐走向毁灭的深渊。如下方面入手:
1. Developer从被问题导向变为主动解决问题,当tester发现一个问题时,应在解决这个问题的同时,举一反三,解决相关可能的问题,而不是仅解决这个问题,然后把脑袋埋进沙子里,等待tester发现另一个问题再解决,这样会很被动,并且会让tester很恼火,类似问题重复出现是很令人沮丧的一件事。如果在某一模块发现问题较多,则不待tester发现问题,主动重新review 设计和代码,提前发现和解决问题,不至于被报告问题时手忙脚乱,这样也会减轻tester的工作量,否则每提交一个版本都要做回归测试,很累的。

2. Tester描述问题尽量客观,不带情绪与成见。记录更多的问题相关发生环境,帮助developer定位问题的原因,让developer强烈感觉到是盟军,而不是敌人。

3. Manager控制自己情绪,听取客观情况,协调developer与tester之间的沟通,必要的时候为双方减压而不是一直加压,直到崩溃。重要的职责是指导相关人员有条不紊地解决问题,而不是责骂,否则会使developer和tester都向其隐瞒问题,直到无可隐瞒,彻底崩溃。

其实,如上的努力只是没有办法的办法,项目已经进行到测试的阶段。如果项目正在设计或编码,还是奉劝developer多做努力,通过design、review、UT等把容易发现或可以预见的问题尽早发现和解决,带入到最后阶段的问题越多就越被动,直至失去理智把盟友当成敌人斗,岂不缪哉?!

没有评论: