从工作杠杆率引申至对软件工程质量控制的思考

前几天读到一篇文章：为什么中国的 996 干不过美国的 955 （文未有链接）

看过后有些感触，也进行了一些思考，由此引申到软件工程的质量控制，下面把自己的一些相法记录下来

文中提到的一些观点，我是比较认同的

关于工作的杠杆率，即单位工作时间产出的价值：

业务如果靠销售驱动，杠杆率最低，运营其次，产品最高。所以你去看销售驱动的公司，往往有很多人，但是人均产值很低，比如地产，软件外包。但是，产品驱动的公司/业务，往往有超高人均产值，比如微信。再比如国外的 Atlassian（典型产品 JIRA），目前市值 276 亿美元，员工 3600 人，人均市值 920 万美元。这家公司没有销售。

关于产品质量：

国内目前的 IT 大环境实质上是鼓励 60 分产品，不重视 80 分或者 100 分产品。花一份精力，可以把产品做到 60 分；花两份精力可以把产品做到 80 分；但是花 10 份精力才能做到 100 分。

有部分网友可能会说，用60分的产品也没什么不好。比如一口德国造的锅600块，可以用十年。国产的锅60块，可以用一年。同样是600块，我用国产的锅也挺好，而且每年都可以换新锅。说的没错，从消费者的角度出发，同样的投入，得到的价值是差不多的。但是如果从生产者出发，我们就能看到差距了。假如生产一口国产锅需要工人工作2个小时，那么10口锅就是20小时的工作量。假如生产一口德国锅需要的人工是国产锅的两倍，那么就是4小时，也就是说人家4小时的工作价值=我们20小时的工作价值。这就是我们经常说的为什么别人每天工作8个小时就按时下班回家了，而且还拿着那么高的工资。

好了，说回软件工程，情形是类似的，扪心自问一下，我们996赶出来的软件可以打多少分？自己的工作价值是多少？各位同学，做高质量的产品，是在提升自己的工作杠杆率。

更为关键的是，低效忙碌的加班，对自己技能的提升并没有帮助。还是以制锅为例，如果不做出改变，你掌握的永远是2小时的低端制锅工艺，加班已经占去了你很多的业余时间，你将很难再有精力去提高自己，综合下来，你损失的不仅仅是劳动所得，而且是成长和进步的机会。

当然，我理解，大部分同学的工作是无奈的，没有选择权的，被安排下来的活，必须赶时间完成。还有，现状在一定程度上是由需求决定的，广大的消费者都去买60块的锅，那么企业自然也没有动力生产更高质量的锅，现状的改变还有赖于消费价值观的改变。可能我们短时间内无法改变这种现状，但是我希望大家能认清现状，并勇于向自己的直接上级提出好的建议，逐渐的推动现状的改变。而且如果因为你的推动，进而促进了工作效率的提升或产品价值的提高，相信你会得到认可与回报（即使你在当下的工作中没有得到回报，回报也会体现在你找一下份工作当中）。

 

相信大部分同学是认同做高质量产品这件事的，但在实际工作中执行起来可能会困难重重。因为资源永远是有限的，需要在对质量的高要求与有限的资源之间寻求一种平衡。大公司还好一些，相对资源充足，舍得花成本在质量控制上。

重点说创业公司，质量控制这件事，做的不足与过了都不行：

做的不足，线上问题频出，客户投诉多，这个锅质量团队得背。

做的过了，容易被吐槽流程复杂，影响生产力，相比之下，这个锅更重，质量团队可背不起。（引申点：如何减少无效流程？这里不展开）

现实中质量控制往往会向生产力妥协。但妥协的结果就是线上质量得不到改善，甚至会恶化，真是进退两难。遇到这种情况，谁来决策？领导呗？领导肯定不会说不要生产力，但领导也从来不会说放弃质量。要质量高一点还是要生产效率高一点，就看领导心里向那个方向倾斜了。最终就是领导心里那杆称，决定了整体产品质量的上限。实情是：从大公司出来的高管，往往比较重视质量，而草根创业的老板，往往更偏向业绩，质量也往往会向业绩让路（这是是短期业绩，因为质量不好，肯定会影响长期业绩）。

 

那么领导心中那杆称的平衡点在哪里？对质量的要求是什么？

领导专业，则能够清楚的定义现阶段的质量要求。

领导不专业，则知道要保证质量，但并不知道要保证到什么程度才算合适。

大部分的情况下，领导并不是质量方面的专家，所以领导可能不太能讲清楚对质量程度的要求。在一个公司里，基本会有一个质量团队来负责保证质量，领导往往一句话，产品的质量就靠你们质量团队了！我们来分析一下这句话：

第一，保证质量，没有说保证到什么程度，可操作范围大。

第二，这个担子可不轻，产品质量仅仅是一个质量团队能保证的吗？

就这两点，我们分别来说说看。

 

第一：关于保证质量的程度

做为一名质量经理，工作的难点在哪里？组建团队？制定标准？推进实施？相信做为一名有经验的质量经理，这些应该都不是问题。难点是领会领导心中对质量控制程度的要求，把领导没有说出来的东西描绘出来，并落实为具体的指标。首先你要准确领会这个度，然后再根据这个度制定相应质量控制方案。如果你理解有偏差，或者根本不能领会，即摸不透领导想到达到什么程度，那么后续开展工作则可能会遇到很大的麻烦。中国有句话：拿捏分寸，职场如官场，分寸拿捏的好才能得到领导的赏识。所谓的分寸，就是领导虽然没说，但是内心想要的东西（这个太难了，具体如何做到，我也不是很有经验）。如果上下理解不一致，在遇到与其他部门的利益冲突时，将很难得到领导的支持。所以，即使再困难，我们也要去领会，去尝试和领导沟通，尽量准确的还原领导的想法与要求。并在和领导沟通时，向领导传达你的建议，使你的方案和管理措施得到领导的支持，所以最后就变成了，如何说服领导认可你的方案。

所以我认为好的软件质量经理难就难在：不尽要有专业的软件知识，丰富的管理经验，完善的质量控制方案，还要有理解领导，说服领导的能力。

 

第二：产品质量仅仅是一个质量团队能保证的吗？

注：这里的质量团队指测试团队，因为大部分情况下大家说的质量团队指的就是测试团队。广义上来说，质量团队不仅仅包含测试部门，还包括所有与提升质量相关的人。

先说一下，产品的质量分为适用性质量与符合性质量。

一组固有特性满足使用要求的程度就叫适用性质量；

一组固有特性满足规定要求的程度就叫符合性质量。

单纯看定义有点难以理解两者的区分，有必要说明一下。

众所周知，产品是设计和制造出来的，产品设计的好坏，满足用户需求的程度，就是产品的适用性质量，而制造出来的产品，是不是达到了设计的要求？其符合设计要求的程度，就是产品的符合性质量。所以又可以称为产品的设计质量和制造质量。我们在软件工程所说的质量，通常指的是产品的符合性质量。测试验证软件实现了需求文档所描述功能的过程，是保证软件符合性质量的过程。而需求是否合理，产品最终是否满足用户的需求，则是软件的适用性质量的范围。

我们往往强调软件的符合性质量，而忽略了软件的适用性质量。

以我呆过的一家小公司为例，软件质量很差，经常出线上故障。老板非常重视，扩充了测试团队，加大了测试力度，结果却并不理想。为啥呢？仔细梳理一下，发现真正是测试漏测的bug的比例很少，有很大一部分都是用户需求得不到满足，如：扣分规则与预期不一致，设计过于复杂，以致于用户自己操作过但是找不到记录，新的改动未通知用户，导致用户不知道如何使用，或者找不到入口，用户用的好好的功能，产品经理私自增加功能导致用户不满意等，然后还有一部分是产品架构设计引起的和代码发错引起的，可见很大一部分都是适用性质量出了问题。

这些适用性质量的问题，不仅仅是靠质量团队就能解决的，而是需要从整个公司层面出发，需要各部门之间的合作，涉及从用户到销售，客服，从销售到市场，从市场，客服到产品，再从产品到开发，测试，运维，再到运营，销后的一整套流程。假设在传达用户需求时就就出了偏差，试想做出来的产品即使没有任何bug，可能也不会使用户满意。这就是方向性的问题，就好比一条路修歪了，无论这条路的质量再好，也无法到达终点。而且还有失之毫厘，谬以千里的放大效应。

我想强调的是，测试只是整个质量控制过程中的一部分，测试部门所做的测试工作，基本都属于保证符合性质量的的范畴。在设计质量没有保障的情况下，加强测试起到的往往是谬以千里的放大效应。所以产品总体质量的提升，应该先考虑设计质量，而提升设计质量，需要从控制需求开始。

下面再列举一些小公司内普遍存在的，会引起产品质量问题的现象（包括适用性质量和符合性质量），相信这些大家或多或少都遇到过：

• 需求文档不全或根本没有需求文档
• 存在口头需求，多重需求通道，需求传达不一致
• 开发来活就干，不写设计文档，也没有设计评审
• 没有接口文档或过期不维护
• 没有测试用例评审
• 分支管理混乱，经常合分支出问题，合丢代码
• 上线分支没有控制，开发说发那个分支到线上就发那个分支
• 缺乏总体规划，接口复用性差
• 没有沉淀，之前犯过的错，以后还会再犯
• 经常性的打补丁，还以前的技术债

等等，不一而论，可见，无论是产品的设计质量，还是符合性质量，都不是都不是单纯依靠质量团队所能解决的。

 

那么如何解决呢？规范化与标准化呗，什么是规范化？什么是标准化？当然就是软件工程开发流程那一套东西了，这些东西都是前人实践出来的，相信前人如果不是踩过坑，也不会弄这么多繁文缛节。而人类的本性就是好了伤疤忘了痛，虽然有历史教训，但是我们从来都不吸取。这里我简单列举一下软件研发过程中应该具备，但是往往被小公司省略的一些流程，而这些流程对提升软件质量至关重要：

• 需求评审
• 技术方案评审
• 概要设计评审
• 详细设计评审
• 测试用例评审
• 分支管理规范
• 上线流程规范

这些谁都懂，但是就是执行不下去。为啥呢？慢，影响生产力。

但是回过头来想一想，那个生产效率更高呢？长期生产低质量的软件，就像前面生产锅的例子一样，经常996，劳动强度大，然而还得不到提升，无法实现价值最大化。

 

很多的软件创业公司，当产品出现问题时，往往会归因到人才不足，资源有限，很少会归因到规范化与标准化。“招一些自动化工程师吧，以后测试基本上自动化了，不仅就不需要这么多人了，质量还能上一个台阶”，如果这些话出自老板嘴里，还好，质量经理还有机会予以纠正。但如果这些话出自质量经理嘴里，那么就危险了，有可能在偏差的路线上越走越远。在规范化和标准化还没有起步的情况下，就盲目引入自动化，效果是要打折扣的。孰不知规范化与标准化对质量的影响，是远大于自动化所带来的收益的。

 

说在最后，企业处在不同的阶段，对质量控制程度的要求也不尽相同。不能千篇一律，用同样的高标准要求，对于有些小公司的确做不到，也没必要。但也不能停滞不前，随着企业的发展，要不断的提高对质量的要求，质量的提升，其实就是生产效率的提升啊。

最后希望奋斗在一线的程序员们都不用996，就能产出高质量的产品，实现财富自由，成为人生赢家。

 

链接：https://mp.weixin.qq.com/s/VvdZrDsIThEungCTyWUgmw