这段时间在工作中,QA经常给我发一些bug,这些bug确实也是bug,但是是那种“需要花费很多工作量才能达到一点效果”的bug。对于此类bug,我的态度是,
1.作为enhancement,我会在后期有时间的时候fix掉;
2.如果在软件开发正式开发过程中,我会将精力更集中在开发功能上;
3.如果在软件打包的那天,拒绝fix;
4.特殊情况除外。
在软件的早期版本包中,相当于部分功能开发完成的提交,这个期间软件产品的已有功能不可能达到完美的程度。尽管我们工程师经常有完美的意识,但是在deadline的有限时间内,我们要做的就是把基本的功能做好,然后才去fix这些bug。如果时间有很多空闲,就不在此讨论范围之类,而大多数的情况是,按照流程下午2:00打包,但是如果早上发现了此类bug,fix这些bug需要大量的工作量,但是又只能达到一点效果。这时候如果开始编码fix这个包,那么很有可能下午规定时间内不能打包,于是内部开始delay。流程被打破之后,如果为了修复这个小bug引起了其他的回归bug(regression bug),那么其他的DEV又要去修复。修复完了之后QA再做full test......如此下去,包最后一定打好了,但是所有team内人都搞得身心俱疲。
最后包发到客户那里,客户可能只会关心这次提交的主要功能,至于这个enhancement的功能,客户也许完全不在意,因为他知道这不是终极版本。而且即使这个enhancement没有,也不会影响主要的数据和用户体验。
于是我们在做完主要功能后,承担着压力和风险,在软件提交日花了大量额外时间做的一个小的enhancement,客户可能完全忽略,甚至连测都有可能没测到。换句话说,之前花费的大量精力没有对客户满意度有大的提升,甚至没有提升。
这让我想到了那个烧饼的故事,一个大汉饿了N天,有一天终于可以吃烧饼了。开始吃烧饼,第一个觉得味道太美了,简直是世界最美味的食物,第二个也很好的味道,第三个也是,到了第14个以后,望着第15个烧饼,只打饱嗝,抱怨说,这个烧饼太难吃了。其实第15个烧饼和第一个烧饼是一样的。
200多年前,Bernoulli提出的期望效用理论(expected utility theory)可以解释这种现象。期望效用理论认为,人们应该选择的是期望效用最大的那个选项,而不是期望值最大的那个。说白话一点,效用有时候是一种感觉(feeling),如果我们能够让别人有这种感觉就很好了,而不在于给别人的东西有多大价值。就像上面的烧饼,第一个和第15个一样,但是第一个给人“感觉”就很好,所以让人满意度也很好。同样的1000块钱,用于给总监加工资和给普通员工加工资完全效果不一样。
同样,给客户发包的时候,客户的满意度不在于你在这段代码里面你花了多少努力,而在于你完成的功能给他的感觉。当他看到你写的主要功能都完成之后,就像吃了14个烧饼,然后他可能就不在乎你那一点enhancement了,你那一点enhancement不会给他太大的满足感,如果你为这个enhancement花了甚至多于主要功能的努力的话,那么就显得有点stupid了。特别是在打包日把自己和团队其他成员感到身心惧疲,就更不划算了。
所以如果我们掌握了这一点,在和客户交流的过程中,就更可能会聪明的提高客户满意度以及内部软件团队管理了。