谈质量

时间 2019-12-10

标签质量繁體版

原文原文链接

在个人工做经历中质量与进度是项目中永远的话题。测试如何保障质量？开发如何减小返工？我但愿质量是能够经过科学的方法衡量并改进的，而不只是依靠部分人的细心。测试

核心思想

以零缺陷做为工做标准是否现实，实际工做中如何践行？优化

个人理解是即便将目标设置为4个9甚至6个9都是不够完美的，容许缺陷的存在工做中就给了本身一个借口，而这样一个借口就可能成为万恶之源。关于质量改进并非只有达成和不达成2个结果，而是每一点进步都有意义，每一点改进都是金钱。勇敢地以零缺陷做为工做标准吧。这确实须要勇气与决心。设计

工做中的实践方式个人一个原则就是不要挖坑，不要有“如今先挖一个坑未来再填”的想法。按照无数的经验未来必定不会填，或者填的代价每每超过预期。开发

零缺陷目标与绩效目标的关系？文档

绩效目标咱们更关注是否达成，今年的绩效达成明年就有更高的要求。因此在绩效目标设定上经常会根据现实状况设定一个数值。而零缺陷目标则不容许有这样一个数字。我并无太多绩效评定的经验，但有一点原则，绩效的成果是看实际达成状况的，并不仅看目标是否达成，不然没人愿意设定高目标了。get

个人想法是零缺陷目标能够做为标准、价值观，但不适合直接作为绩效目标。class

缺陷指标更适合作为一个负分指标，只有0缺陷才是合理的，哪怕只有1个缺陷也是会形成损失的。同时奖励预防缺陷活动，预防损失节省下的钱也是钱。软件

预防缺陷是否须要提早付出巨大代价？会像过早优化同样成为问题？方法

方案设计中经过分析会出现一些发生几率极低的场景，而为了完美处理这些场景，须要在增长方案复杂性、投入不少工做量，甚至引入更多其余的风险。这样的事情与零缺陷的工做标准是否违背呢？经验

个人想法是应该基于风险考虑，若是几率极低影响小，是应该考虑利用更高层的机制（例如告警/重启/文档说明/人员培训）等方式解决问题，而不该该使方案复杂度提高太多。对于这类场景咱们并不缺乏关注，预防缺陷的方法能够不少，不是全部风险都须要必定经过软件代码保障，眼界能够更宽广一些。

《质量免费》是一本写给管理者的书，若是工做上不是管理岗位，能够把本身当成本身的管理者。