乍一看，好大的一个话题，而且被N多的质量大师、软件××师嚼过N次了...那这里再嚼一遍也不算多吧。

　　项目上你也倡导我也倡导质量是关键。质量优先，进度靠后。但当市场上告诉你产品再不出来我们的客户就丢了，当项目经理告诉你我们已经进度拖延了，××时就是我们的deadline，要是再拖，汗，奖金就泡汤啦。于是，苦命Coding哥哥们加班啊加班，挑剔的testing妹妹们提bug啊提Bug，最后bug满天飞，哥哥妹妹们都围绕bug转去了，进度还是拖了，质量还是没上去。于是，客户没满意，我们要重构，我们要重写，我们要重测。OK，若干有些小想法的人开始思考了，老路不能再走一遍，一定要变革。

　　于是，

　　妹妹：哥哥啊，质量很关键，一定要自测，一定要写单元测试代码，一定要学习好业务，一定要开发出高质量的产品。

　　哥哥：妹妹你不知道我的苦，我也不想让你们给提bug，多丢人啊，我也想写高质量的代码。可是，我代码还没到炉火纯青的地步，我天天加班天天加班也没时间学习，我进度安排得很紧，大家都在赶，我再不赶，本月绩效就完蛋啦。

　　好复杂的一个话题。我们很多时候在讨论如何做需求管理，如何尽量少的变更，如何提高开发人员的质量意识，如何提高测试人员的技术水平，但从另一个角度讲，当你所在的公司文化中不含倡导质量的字眼时，这些底层的工程师是没有办法的。有关上面的谈话，显然参与讨论的人的身份还承担不起这么大的一个话题。一棵大树顶上的一两片叶子就是再摇晃再随风招展也不能让一棵大树动一动啊。

　　怎么办？先分析产品开发的这根链条。市场管理－市场－－产品管理－－产品－－需求管理－需求－项目管理－－开发－－测试。链条的末端再动也没用。市场是龙头，龙头牵着整个链条走，方向正确了好办，方向错了－－难办。对一个很重视市场的公司来讲，如果单单重市场而忽略研发，那质量－－难办。由于才识较浅，目前关于这个也继续说不出什么道道来。但有一点，如果软件企业一开始就将质量放到一个比较高的位置，那我们就不信凭大家这些智慧的头脑和70、80后年轻人的吃苦劲头搞不定一个“质量”！