每次接手新团队，和团队的同事沟通他们对公司的想法时，最常听到的反馈之一，就是“公司领导不重视质量”，细问一下在什么事情上对质量不重视，同事们会说出很多事例，比如：
“产线上bug很多，但是领导们觉得没关系。”
“研发负责人总是压测试时间，测试经常不充分。”
“领导总是催测试进度，经常带着很多bug上线。”
“开发提测质量很烂，研发负责人也不管，质量压力都由测试来承担。”
诸如此类。
我感到吃惊吗？从来没有。
研发负责人们是不是经常不重视质量？也许在他们看来不是，在我看来，恐怕是的。
回顾我自己合作过的研发负责人，很多也都是技术全面，经验丰富，管理能力出众的行业牛人，但是合作时间长了，你也会发现，在他们的眼中，质量并没有你认为的那样重要。
问题在哪里呢？
研发负责人与测试负责人在质量重要性上的不同观点，我认为可能的主要原因，也许是研发组织（甚至是整个企业）“关于质量的价值，其实从来没有一个客观的，可量化的判断。”组织的资源总是有限的，管理者决策把资源用在什么事情上，往往需要要看这些事情到底能带来多少价值，得到资源多的事情就重要，得到资源少的事情，相对就让人看起来不那么重要。
而如果直白一点，管理者对价值判断的标准，以及决策的依据，简单讲就一个字：钱。
和一般中层的技术经理不同，研发负责人（CTO或者技术VP），作为公司的核心管理层，需要关注公司的业务成功，当然他们身上也一般都背着业务/财务指标，要么是收入，要么是利润。所以很多情况下，他们脑子里面想的更多是怎么把订单量做上去，营收做起来。
“钱”经常是技术负责人们决策的最重要的标准，能够帮助提高营收的，就应该马上去做，不能帮助提高营收的，都可以优先级放低，缓一缓甚至不做。
在研发部门里面，什么事情最能提高营收，给公司赚钱呢？最常见的就是产品的发布或者更新。每一条新产线的发布，一般都已经提早做好了业务规划，预计上线后会带来多少用户以及订单，每日营收预计做到多少都已经有了或粗或细的计划（姑且不论这些计划靠不靠谱），各个兄弟部门也都建好了相应的协作流程，就等着产品上线大家开干（至少表面上），收订单做业绩，升职加薪拿奖金。
产线发布新功能，或者线上问题的紧急修复，背后一般也都带着业务目标，比如“这个功能上线，预计能影响多少用户多少订单”，“这个问题不修复，每天会损失多少多少订单”等等。
所有的这些，都可以比较清楚地和钱，和研发负责人身上背的业务指标关联到一起，他们能不着急天天催着产品上线吗？
如果测试团队抱怨开发提测质量太差，开发团队说“可以啊，我们提测前可以自己做单元测试集成测试啊”，不过研发时间要延长一周，研发负责人掐指一算：延长一周要损失多少多少订单多少钱。。。算了，你还是抓紧实现功能，测试的事情交给测试团队做。。。
测试团队是不是很羡慕？是不是也希望我们一跟研发负责人反馈质量太差，他们就全力支持做改进？
那我们又是怎么和管理层去强调质量的重要性，期望通过强调质量的重要性来获取更多资源支持的呢？
遗憾的是，大多数时候，我们只不过是在片面地、单调地陈述高质量对用户或者技术的价值，比如高质量有利于提升用户体验，提高用户留存和忠诚度，提高系统稳定性，减少技术债务等等。
我们都知道高质量的好处和重要性，但是，我们就是没说清高质量和业务或者财务指标之间有啥关系，高质量和钱有啥关系。
我们没有描述清楚质量和公司营收或者利润之间的关系，而多数情况下，我们更没有准备好数据去证明这些逻辑关系。
我们以为自己在陈述真相，我们以为我们已经解释了问题的根源，但是我们只不过还是在用一个现象说明另外一个现象，没有触及到问题的本质。
既然我们不能让管理者理解和相信质量能够帮助他达成业务目标，节省成本，或者通过节省成本能够给组织带来多少利润，既然我们不能将我们所希望追求的质量工作与管理者最主要的决策因素-“钱”关联到一起，在产品上线等其他能够证明业务价值的工作面前，质量当然就很容易被管理者所忽视。
从这一点上看，管理者选择支持哪些有清晰明确业务价值的工作，而忽视哪些没有体现明确业务价值的工作，其实也许是个理性的选择。
工作中有时恐怕就是这样，没法用钱衡量的事情，很难说清楚这事情有多重要。
既然他们不能看到质量能省钱或者帮助他们赚钱，那自然就不会对质量有多重视。
话说到这里，这个局面怎么破？重点是要证明质量的业务价值，这要从质量成本谈起。