1
质量管理的历史可以说是和人类社会的发展史一样漫长，从个人的手工制作，到小作坊生产方式，到工厂生产，到发展成产业链式的生产方式，从人工，到机器，到流水线，到自动化。质量管理的概念从萌芽到逐步完善，通过理论的研究、经验的积累，已经形成一个相对比较完整的知识体系。
很多的理念和方法都可以借鉴在对软件质量的管理，如对数据的采集分析，合理的反馈体系，对流程的管理。但软件产品的研发和传统意义上的生产活动有一些本质上的不同，其中最本质的一点不同就是：软件的研发是一个需要人的智力参与并输出产出，需要人和人之间的更多的紧密合作和沟通；这一方面在整个软件研发体系里面所占的比例远高于传统意义生产流程。如果再照搬传统管理的一些方法、经验、理念则会有些水土不服。就像我们可以通过质量管理生产出一辆高质量的汽车，但无法通过质量管理让人输出李白的诗，苏轼的词。
一旦涉及到人的智力输入，复杂度和难度级则提升一个档次；并且随着软件规模的增加、团队数量的增加、整个体系链条上节点数量的的增加而呈现指数级的增加。每个环节都可以复杂到形成一个独立的知识体系，分支管理、版本发布管理、代码质量的管理、测试的管理、进度的管理、现场运维的管理等等，每一块又可以拉出来再进一步细分。
可以说软件质量管理是一件非常复杂事情，是一个系统的工程，无法在一个点上或极少的几个点上很轻易地就把软件质量管理好，或让软件质量得到显著的提升。如果认为软件质量管理不是一件复杂的事情，只有两种可能，一种是已经有了完备的知识体系，看软件研发过程如同庖丁解牛；一种就是还停在表面，看不到一头牛体内的复杂组织。
2
长周期性 是软件质量管理中另一个很重要的属性。（当然这点不一定符合所有的软件产品）
不同于传统的生产行业，把一批次的原材料质量提升，把机器性能调优，工艺流程优化，本次生产出来的产品质量可以马上得到提升。而软件质量在这一点上并不适应，它的响应和反馈过程可能周期很长，越复杂越庞大的软件产品在这一点上越明显。
软件问题从引入到暴露可能会是一个很长的过程，可能在很长时间之后的某一个特殊场景，特定流程下才会暴露，或者因为外部输入的不断变化而暴露。诸如一些非功能性的问题，如性能问题，稳定性，可扩展性等，可能需要更长久的时间。一个开放式的软件系统比一个封闭式软件系统在这一点上更为明显。
软件质量的改进也是一个缓慢的长周期过程，很多改善并不能得到立竿见影的效果，比如清理掉所有的编译告警，修正掉所有的静态代码检查报错，这种投入的成果在短期内可能根本无法得出可识别的正反馈。还有一些类型的投入，比如对代码架构的优化，对一些非功能性方面的优化，可能需要更加长久的周期才能得到反馈。比如提升了某一模块的可扩展性，在短期内并没有任何对外体现，但等到需对功能做调整或添加的时候，这种优化则可以降低改动带来非风险从而保证软件的质量。
就如同马拉火车，体积越大加速越慢，期望抽一鞭子就能让马把火车拉到飞奔会是一种不务实的期望。
3
软件质量是一个积累和沉淀的过程。
其实这也是长周期性的一部分，尽可能把更多的资源诸如人力、时间、机器等投入变成有效的成果，并能把这些成果保护住，一点点的变成有效沉淀积累下来，在长时间的跨度下质量自然能得到有效的提升。比如数量很多的临时分支和临时版本，消耗的资源和人力最终都得不到有效的沉淀，临时版本作废的那天就意味着大部分的付出都作废了，包括ST测这么多版本的付出，机器资源的付出，让大家反复merger代码的人力消耗等等。
通过合理的分支管理，发布规则管理，尽可能地减少这种得不到有效积累的成本在工作中所占的比例，让更多的投入得到有效的沉淀自然会在潜移默化中提升了软件的质量。这一点也能体现软件质量的管理是一个系统的工程，需要协调多部门多环节作为一个整体为同一目标协同作战。
生活中有一种忙叫穷忙，越穷越忙，越忙越穷，陷入一个负循环的圈子。很大的因素就是无法完成这样一个沉淀和积累的过程，金钱的积累、能力技术经验的积累。这些积累可以帮助一个人明天、下个月或者一年后能改变他的生活状态，否则就是今天疲于应付温饱，第二天依然重复同样的事。
4
改变思维方式，从要求你们输出高质量的软件产品， 变成如何确保在现有的资源下可以输出高质量的软件产品。
看似文字上没有多大差异，但有本质的区别。“要求你们输出高质量的软件产品”，这是把控制权交给了别人：别人可能交付高质量的软件产品，也可能不能。“如何确保在现有的资源下可以输出高质量的软件产品”，这是把控制权掌握在自己手上：在当前资源不可改变的情况下，比如人的能力瓶颈，经验天花板这些因素，这是不可控的，无法去给一个人的能力、经验定一个目标，但采取一些具有可执行性可操作性的方法、流程让质量在现有的条件下仍可控、可提升。扳机扣在自己手里，控制权抓在自己手里。
资源不足只是现状，不要把这点视为全部的理由或当成最终的结果，不要总等待现状的改变，在当前的现状下找到可改变可控的东西。就如生活中不要总期待别人的改变或别人能给自己带来什么，这是把喉咙放到别人手上；从内部自己成长和改变这才是自我可控的。
5
软件管理活动中要提防伪“闭环”。
经常提到要闭环，看似简单的两个字其实并没有那么容易做到。看似有结果，有讨论，有反馈，视乎是一个闭环过程，但稍不留意就形成了一个伪“闭环”。
一个闭环有3个关键点：
1、对结果不失真的呈现
必须正确地用数字来如实呈现结果，这一点难度不大，但数据失真还是时有发生。
2、准确的反馈点
不能简单地只看数字表面，要多分析和挖掘数字背后的信息，清醒地理解数字的隐藏信息，这样才能形成正确的反馈。
比如因为软件质量的长周期性属性，当前统计的BUG数量可能是对半年，一年甚至更久之前的代码质量的一个体现，加上在短周期内BUG数量受到其他因素的影响也会有很大波动，如果简单的用最近一个月新报的BUG数量作为对上一阶段工作的一个直接反馈，很可能就形成了不正确的反馈和反馈点。错误的反馈还不如没有反馈，比如可以用BUG数量的上升去否定上一阶段的任意一项工作，这无疑是具有破坏性的。
对反馈的理解和反馈点的定位一定要慎之又慎。
3、对应的调整
所谓闭环，一定要有对应的调整，计划的调整、策略的调整、方法的调整、资源的调整、人员的调整等等。
这里的调整一定是对现状可以施加某种改变的调整。不是要求，也不是期望，也不是某种强调，并且一定是具有可执行性的。如果BUG数量上升，经过讨论和分析最后的结论是：抓紧解决报出的BUG把数量降下去，这只是一种要求或期望，并没有形成闭环，如果会议讨论止步于此就是一种伪 “闭环” 。
源自公众号 叽叽歪歪的张小白