在我的工作经历中质量与进度是项目中永远的话题。测试如何保障质量？开发如何减少返工？我希望质量是可以通过科学的方法衡量并改进的，而不仅是依靠部分人的细心。
核心思想
- 质量就是符合要求
- 必须是可以衡量的要求，可以说明清楚的要求
- 衡量质量要用金钱或代价，把事情做错的成本
- 第一次就把事情做对
- 预防缺陷是降低成本的最好方法
- 以零缺陷作为工作标准
问题思考
以零缺陷作为工作标准是否现实，实际工作中如何践行？
我的理解是即使将目标设置为4个9甚至6个9都是不够完美的，允许缺陷的存在工作中就给了自己一个借口，而这样一个借口就可能成为万恶之源。关于质量改进并不是只有达成和不达成2个结果，而是每一点进步都有意义，每一点改进都是金钱。勇敢地以零缺陷作为工作标准吧。这确实需要勇气与决心。
工作中的实践方式我的一个原则就是不要挖坑，不要有“现在先挖一个坑将来再填”的想法。按照无数的经验将来一定不会填，或者填的代价往往超过预期。
零缺陷目标与绩效目标的关系？
绩效目标我们更关注是否达成，今年的绩效达成明年就有更高的要求。所以在绩效目标设定上常常会根据现实情况设定一个数值。而零缺陷目标则不允许有这样一个数字。我并没有太多绩效评定的经验，但有一点原则，绩效的成果是看实际达成情况的，并不只看目标是否达成，否则没人愿意设定高目标了。
我的想法是零缺陷目标可以作为标准、价值观，但不适合直接做为绩效目标。
缺陷指标更适合做为一个负分指标，只有0缺陷才是合理的，哪怕只有1个缺陷也是会造成损失的。同时奖励预防缺陷活动，预防损失节省下的钱也是钱。
预防缺陷是否需要提前付出巨大代价？会像过早优化一样成为问题？
方案设计中通过分析会出现一些发生概率极低的场景，而为了完美处理这些场景，需要在增加方案复杂性、投入很多工作量，甚至引入更多其他的风险。这样的事情与零缺陷的工作标准是否违背呢？
我的想法是应该基于风险考虑，如果概率极低影响小，是应该考虑利用更高层的机制（例如告警/重启/文档说明/人员培训）等方式解决问题，而不应该使方案复杂度提升太多。对于这类场景我们并不缺少关注，预防缺陷的方法可以很多，不是所有风险都需要一定通过软件代码保障，眼界可以更宽广一些。
其他想法
《质量免费》是一本写给管理者的书，如果工作上不是管理岗位，可以把自己当成自己的管理者。