11 | 质量管理：层层卡点，一次把事情做对

质量管理在一个正在运行的项目里很重要。我2016~2018年所在的老项目(2011年)就曾经面临质量危机，它是公司收益非常大的项目，危机是不得不解决的。 危机原因：技术债务堆积数年，开发已经陷入举步维艰的地步，大部分的技术同学一周都得忙两天时间修复线上bug。 危机解决方法：小步快跑地重构崩坏的代码，对于不方便修改的代码，直接开发一套新的兼容代码，旧的代码让其尘封起来。 解决关键：所有的小步快跑都要寻找反馈来证明有效；相信工具和自动化； 项目的是周更新的，迭代速度很快，有利于项目的改动快速得到反馈，甚至说每一个人的努力都可能在下一周得到回应。我那时在团队里以上线晚上的加班时间为自己的反馈，假如超过12点而原因是研发进度问题，则优先解决最重要的研发瓶颈问题。17年花了半年时间不断地重构，重构获得更多的时间后，又可以进行新一轮更难、持续时间更长的重构，团队重新进入良心的循环，最终技术债务逐渐基本还清，17年下半年版本质量重新稳定了。 后来我补充思考了一些关于防止项目质量重新陷入崩坏的问题。 1、在技术团队中强调代码的不仅仅是正确与否，有优劣之分，由于项目是快速迭代的，所以代码的可读性和稳定性优先于代码的性能问题。保证每个技术同学都知道这个原则，敢于对违反这个原则的代码自行进行重构（还得培训相关重构知识）。 2、在技术团队中，补充规范和文档、注释，把之前重构出来的成果以肉眼可见的形式留存下来，要求是一个实习生按照文档操作不会踩到坑。 现在该项目已经又继续稳定运行了两年多，最重要的成就感莫过于自己留下的框架和规范还有用地指导着新同学去继续这个支持这个项目。 现在新的项目依然有很多质量的问题需要处理，但是要处理的维度更高了，新项目的问题不仅仅是代码质量问题，而是更多是团队问题，这是我19年下半年最大的挑战。希望两年后回望也有我今日回望17年的成就感吧。

老师我想请问下，在我已经建立好代码规范，提交标准等等规章后，有个别人就是不按照规章制度去做事，甚至沟通后依然我行我素，成为了一个“坏榜样”。该怎么去处理这种情况呢？还有一种情况是有的开发人员自己的代码从来不测试，或者测试用例很少，质量低导致测试人员工作量非常大，也对他颇有微词，同样是沟通后无果，是否有方法去解决这种情况呢？

谈谈个人的现实感受吧：其实处理这种技术债应当是两类手段，其实也是两类人的处理方式。 第一类：定期处理-做事情极度有魄力的CTO，定期会对现状做个总结然后还债，这个可能就像我们用花呗或者信用卡定期主动还款一样。 第二类：知道一堆问题，可是就是觉得太杂、知道问题、记录下来、大不了这个爆了我还有其它的，总体上最后做到核心不出问题就行，其实这种CTO自己都不知道现有的有些项目哪天会爆了。 一次性做好是不可能的：前几天刚和极客时间的老师在专栏中聊过类似的问题；有技术债不可怕，怕的是决策者不能确定技术债的风险且适当的时候定期还债，最终导致某些债务引发部分爆仓。 以上是个人的一点切身体会和薄见：期待老师下节课的分享。

质量管理最高境界还是治未病，需求质量决定了质量的上线，需求评审固然重要，但最有效的还是开发测试需求对需求的理解达成一致，包括验收条件。这样大家都心里有数，提高了效率。

感谢老师的分享。如下2个问题请教一下：1.提测前的质量门禁和上线质量标准是PMO制定后与相关部门沟通达成一致后执行，还是PMO推进相关开发及测试部门/产品部门来完成并上级review拍板？这个问题主要问相关质量标准的制定和推广是怎样进行的？2.针对产线问题的根源分析和改进措施如何做到闭环及改进效果评估？质量提高需要一个过程，有些改进需要技术不能内部立项跟进。如果按月review发现改进方案还未见到明显成效并且review下来还是类似的问题和类似的解决方案，是否参与人会感觉到review是浪费时间，这种情况下您怎样处理的？谢谢

同理心 发现了问题，也就是自己的痛点，要想团队其它人的痛点是什么？这两类痛点有哪些相同之处，也就是可以多赢的地方。 设身处地为他人着想，谁不想解决自己的痛点呢？ 先花力气与重要干系人沟通 团结一切可以团结的力量，然后，再向大家公布，阻力就小很多。 定制 同样的方法，针对不同的团队，适合落地的形式也不同，还是同理心。 发心帮助团队，学习方法，积极尝试，不断优化。

要做到“一次性把事情做对”还需要一个前提，就是项目的干系人（包括产品、设计、开发、测试等）能够统一对产品需要、目标、质量等有比较一致的理解和认知。 在我之前的一个团队中，有些项目业务逻辑会比较复杂，在产品需求沟通或者评审时，大家很少会有疑问或者问题，会后就根据各自的理解开始开发或者设计测试用例了，等功能做出来的时候，经常会发现有很大的偏差。 后来我们采取了一个方案：每次产品讲完需求后，随机让几个参会成员讲解对需要的理解，这样避免了部分成员在开会的时候划水提高大家的参与度，也可以及时发现大家都需要理解的偏差。 请问一下，大家有没有什么好的办法尽量减小团队成员对需求等理解或者认知偏差呢

蓓蓓老师，最新才开始学习，缺陷的大概率不是发生在需求设计阶段么。为什么要专注研发阶段呢

请问蓓蓓老师，一般bug率怎么统计？分母用什么算比较合理？

请问图中的质量流程概括图（从需求评审到发布上线）是用什么工具画的呢？推荐画图的工具，老师画的图都好清晰简洁