后来查问题的根源，这个复杂的功能由于两个模块的接口在最后没有同步，某重要的参数被忽略了，这个功能中最出彩的部分压根就不可能工作！那负责测试的角色怎么解释“所有测试用例通过，同意发布”的呢？

　　这还是开发人员引以自豪的“杀手级功能”（killerfeature），那其它普通的功能是什么命运呢？

　　回过头来，我们可以问：

　　·这件事真的要通过这么多环节么？

　　·测试人员真的知道最最关键的地方如何测试么？

　　·在系统上线之后，所有为这个功能感到自豪的人是否去实地测试过呢？

　　一个开发人员应该负责下面“开发功能”右边的几个圆圈呢？

　　问题：盲目信任“专业人士”扮演的角色

　　每个角色的水平不一样，软件的质量往往受最差的角色的影响最大。我们团队要为某软件写一段英语介绍文字，团队成员都是通过四六级英语考试的牛人，可他们都很谦虚，说要请一个专业的人士来写不可。于是求了一个专业人士，求了好几次（专业人士很忙的），在上市之前才得到专业的文案，于是，copy/paste几次之后，软件就向全世界发布了.

　　这个文案第一句就是热情洋溢的设问句：“haveyoueverthinkabout...”随后还有几处非常明显的语法错误.这个软件吸引了不少评论文章，有旁观者说，从介绍文字的几处典型中国式语法错误来看，这个软件是由在中国的某分部搞出来的…

　　即使有专业人士扮演各种角色，还得有专人独立地检查验证质量。

　　我们回头来看，可以问两个问题：

　　·这件事真的要专业人士来做么？

　　·专业人士做完之后，谁来负责测试？

　　问题：为了自己角色而做绩效优化

　　分工之后，每个角色为了自己的绩效而优化，会出现局部最优，而全局未必最优的情况。

　　我们团队的另一个wp7的应用也要发布，这次专业人士又出手了，写了175个英语单词的介绍，极尽溢美之事，而且找不到明显的语法问题！这的确是一种局部最优了。但是完全没考虑到用户在小小的手机屏幕上有多少耐心读完那么多形容词和状语从句。经过简化，我们把它减少到78个词，勉强能放进手机的两个屏幕。