边际效用递减

这段时间在工作中，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了。特别是在打包日把自己和团队其他成员感到身心惧疲，就更不划算了。

所以如果我们掌握了这一点，在和客户交流的过程中，就更可能会聪明的提高客户满意度以及内部软件团队管理了。