本文内容结构
一、模型建立
二、模型应用
1、研发质量评价结果样例
2、雷达图识别短板
3、柏拉图聚焦改进
三、模型演进
四、小结
五、红：追根溯源 黑：头痛医头
七、红：不忘初心 黑：唯指标论
八、红：思想先行 黑：工具至上
九、红：群策群力 黑：单打独斗
十、小结
十一、什么是质量成本
十二、软件质量成本的构成
十三、导致不良软件质量成本的主因
主因1：业务软件故障
主因2：运营和维护遗留系统
主因3：开发项目失败
十四、小结
十五、亲和图的前世今生
1、何为亲和图
2、适用场合
（1）理清思路，打破现状
（2）相互启发，认清问题
（3）统一意见，达成共识
展开全文
3、使用步骤
十六、那些可能会踩的“坑”
1、认为“亲和图”一招鲜
2、想要速战速决解决问题
3、收集资料时提前决定分组类别
4、归纳分类时未做到“高内聚低耦合”
十七、三强联手，所向披靡
1、“亲和图”与“头脑风暴”的美妙组合
2、“亲和图”、“头脑风暴”、“矩阵”的三剑合一
十八、结束语
十九、SQA的三大困惑
1、互联网时代都敏捷了，还需要SQA吗？
2、为什么SQA常常被团队“提防”着，无法融入？
3、SQA的工作成果如何能够量化，从而被相关方认可？
二十、SQA的不同使命
二十一、SQA的破困之路
1、认识自我
2、认准方向
3、认知未来
二十二、小结
二十三、理念宣贯与方法导入
二十四、来源获取与问题统筹
二十五、核心要素与前置准备
1、召开会议时，问题背景没有了解清楚，增加沟通成本
2、分析问题时，相关材料缺失，问题分析不透彻
3、问题定责时，责任切分不清楚，导致效率低下召开多次会议
二十六、关键活动与回溯过程
1、识别问题引入点/控制点
2、问题产生原因分析
3、确认根本原因
二十七、改进总结与警示分享
二十八、结束语
管理就是要可衡量。能量化尽量量化。不能量化尽量细化，不能细化尽量流程化。——彼得﹒德鲁克
管理如此，质量管理亦是如此。
对于一个千人规模的研发组织，每天会产生大量的数据，如：代码提交、编译构建、单元测试、自动化测试、环境变更、版本发布等。
如何从纷繁的数据中沙里淘金，提取并加工成对于质量管理有用的信息，从而支撑研发过程改进和管理决策，成为了我们亟待解决的课题。
一、模型建立
通过对一些经典软件质量模型（Mccall模型、Boehm模型、ISO9126模型）的研究，并结合在苏宁金融开展的研发质量管理实践，我们提炼了一套“研发质量评价模型”，其整体框架结构和体系支撑如下：
在不同的领域，有不同的工具支撑整个业务流，比如：项目是通过ITP系统来管理的，它涵盖了立项管理、开发管理、上线管理、结项管理等项目全生命周期。不同的工具通过底层数据进行拉通，形成完整的IT解决方案。
评价模型由产品质量、过程质量、持续改进质量、成果转化质量4大维度组成。通过对维度进行细化，又细分为9个子维度、16个评价指标，全方位客观地评估各研发中心的质量管理水平。
二、模型应用
根据木桶原理，一只水桶能装多少水取决于它最短的那块木板。
研发质量评价模型就是要识别出整个组织的共性问题及能力短板，由SQA牵头驱动组织级的过程改进，进行能力补齐。
1、研发质量评价结果样例
2、雷达图识别短板
通过雷达图，我们可以方便地识别在“缺陷修复”这个指标上整个组织是存在短板的，需要进行专项改进。
3、柏拉图聚焦改进
借助质量工具，我们绘制了柏拉图。根据二八原则，发现流程流转不及时、外部因素无法联调、新员工不熟悉代码这3个原因是导致缺陷修复得分偏低的主要原因。问题的症结找到了，问题自然可以迎刃而解了！
三、模型演进
研发质量评价模型不是一成不变的，它有一个逐步演进的过程。我们的模型已经初步完成了从1.0到2.0的转变。
2.0相对1.0版本，使用探索性因子分析法（EFA）对指标维度进行了重新亲和，使评价维度更为合理。同时，增加了质量保证及质量控制的过程性指标，从而提高了模型评价的实时性和效用。
上医医未病之病，中医医欲起之病，下医医已病之病。从结果性的数据描述，到对过程数据及时分析，最终建立预测模型支撑组织决策。
四、小结
数据是为管理做服务的，但数据本身不能脱离研发实际。庞大的指标体系和盲目的数据分析都是不可取的。
发现问题、解决问题、不断提升组织能力才是研发质量评价的初衷。
任何事物都有两点，即都有优点和缺点、成绩和错误，这是辩证的唯物主义思想。研发过程也不例外，总有做的好的和做的不尽如人意的地方。质量人员通常会用“红黑榜”进行晾晒以达到一定的改进效果。那么反思己身，质量人员在研发质量管理中又存在哪些典型的“红与黑”呢？
五、红：追根溯源 黑：头痛医头
质量管理一个重要职能就是要解决质量问题，就好像医生的职责天生就是要解决病人的病痛一样。好的医生通过“望闻问切”详细了解病人的病情，对症下药彻底根治病情；孬的医生往往头痛医头、脚痛医脚，短时间能收到效果，但总断不了病根。
举个例子，近期小Q在审计时发现，很多项目不执行代码评审活动，导致转测质量很差。于是他要求项目组后续整改，必须提供代码评审记录。项目组也很配合地做了“整改”：欺负小Q不懂技术，拿一些其他项目的代码评审记录糊弄一下。小Q也不深究，对改进效果沾沾自喜。
这种情况，建议小Q这样做：召集技术经理、开发人员等核心干系人开会讨论，详细了解项目执行过程，可以利用5WHY、鱼骨图进行引导，追根溯源，挖掘不执行代码评审的根本原因。是项目进度太紧?还是不涉及核心代码修订？抑或是真的质量意识淡薄？只有找到病根，才好对症下药。
六、红：不忘初心 黑：唯指标论
没有度量，就没有管理。质量管理也离不开有效的度量。我们在质量改进过程中，会设定改进目标。但很多时候，目标被曲解成了KPI（指标），通过指标分解，层层加码。希望通过加大绩效考核力度的方式，达到推行质量管理的目的，并坚信只要达到这些指标，就满足质量要求，达成改进目标。
举个例子，近期生产问题频发，小Q被要求评估各事业部产品质量现状。于是，小Q不管三七二十一，先上马一个质量度量体系，大大小小的指标50多个，定期出报告晾晒数据。各事业部为了达成指标，八仙过海各显神通，疲于奔命。最后的结果可想而知：一片大好河山，可质量却内卷了!
这种情况，建议小Q这样做：忘掉指标，不忘初心。首先，领导的真正诉求是什么?需要充分挖掘，不要改进错了方向；其次，改进目标设定时，可以定量与定性相结合，借鉴平衡计分卡等工具，从不同维度设定综合指标;最后，定量指标设定最好选取结果指标，过程指标支撑结果指标并分解。
七、红：思想先行 黑：工具至上
子曰：“工欲善其事，必先利其器”。质量管理有很多先进的控制、分析、改善的技巧和工具，比如：新老质量管理七大工具。于是，很多质量人员开始推崇“工具至上”的理念，无所不用工具，胡乱使用工具，脱离实际只为形式化的管理往往带来巨大的浪费。
举个例子，小Q心血来潮，想分析近一年来测试发现的BUG解决时长的情况。于是，他下载BUG数据，安装minitab软件进行统计分析，并绘制控制图。他找出所有异常情况，比如：数据点超出控制线；连续9点在中心线一侧等，并要求技术经理分析每个异常的原因并给出整改措施。这真是闹了一个大大的笑话，浪费人力不说，还特不专业。
这种情况，建议小Q这样做：了解工具背后的管理思想、适用场景，只有了解质量工具使用的真正意义，才能找到适用该工作的工具；平时需要提升质量专业能力，质量工具只有不断应用才能熟练掌握，切忌一知半解，照猫画虎式的使用。
八、红：群策群力 黑：单打独斗
质量管理不是一个人、一个部门的事情。但由于质量人员人数较少，在开展工作时又往往会遇到阻力，所以容易形成“单打独斗”的工作方式。典型的表现形式就是一项工作，从头到尾自己干到底，几乎不进行协同。这样带来的后果多半是工作流于形式，做了形象工程。
举个例子，小Q发现近期缺陷漏测情况比较多，于是想分析一下测试过程是否存在问题并推动改进。他找了几个测试经理却碰壁后，决定自己分析。由于小Q不是测试专业出身，仅凭自己的工作经验来判断漏测的原因，导致原因分类有重叠、不完整，问题定责不正确等问题，分析报告完全不可用。
这种情况，建议小Q这样做：通过摆事实、列数据等方式，获得领导授权，尤其是主管测试领导的支持；利用集体的力量，协调相关干系人一同参与分析，群策群力。缺陷漏测必然不只是测试的问题，也可能在需求阶段就引入需求遗漏、需求描述歧义等问题。另外，在分析应对措施时，也需要借助技术专家的力量，通过技术改进或工具优化减少漏测的几率。
九、红：有始有终 黑：虎头蛇尾
一个房子窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙的被人打破。在质量管理上，也很容易形成这种破窗效应。很多工作轰轰烈烈地开了个头，然后越做声音越小，最后就悄无声息地结束，没有形成完整的闭环。
举个例子，小Q在牵头一次重大的质量回溯工作，由于该问题涉及面广，且为历史遗留问题，所以他声势浩大地开了启动会议，乌泱泱坐了一屋子人。后续又陆续召开几场专题分析会议，光改进措施就列了二十几条。可因为有的措施需要长期跟踪落地、有的不具备可执行性、有的流于形式等，该回溯真正闭环的改进措施寥寥无几，改进效果可想而知。
这种情况，建议小Q这样做：质量保证或质量改进活动中的改进措施不在多而在于精，挑选团队确实能改进或够一够能改进的，做一件成一件，有始有终；利用改进措施跟进表或借助跟踪工具，定期跟踪措施的实施情况，对于需要长期解决或者解决难度较大的措施，可以通过专项改进的形式推动。
十、小结
以上只是总结了一些典型案例，类似的还有很多。如果我们能做到“吾日三省吾身”：我是不是存在以上问题？我有没有针对问题做改进?我如何避免犯同样的问题？每天进步一点点，日积月累，相信量变一定会引起质变！
十一、什么是质量成本
质量成本的概念最早可以追溯到古代朴素的商品交易逻辑。所谓“一分价钱一分货”，那时便萌发了质量成本的意识。直到20世纪50年代，质量成本的概念才由美国质量专家A.V.菲根堡姆系统性地提出来，其定义是：为了确保产品（或服务）满足规定要求的费用以及没有满足规定要求引起损失，是企业生产总成本的一个组成部分。
质量成本中可见的部分就像冰山上的一角，而大量的成本却隐藏在海平面以下，深不可测。比如：某汽车制造商发现某款汽车发动机设计存在缺陷，需要全部召回。这属于可见成本中的返工成本。但是，因为该事件造成多起重大交通事故，引发广泛的社会舆论和关注。该汽车的品牌美誉度一落千丈，销售量持续下滑。这属于隐藏成本中的失去的顾客/商誉。一般来说：隐藏成本损失至少是可见成本损失的4倍以上。
十二、软件质量成本的构成
通常质量成本一般包括：为确保与要求一致而作的所有工作叫做一致成本，以及由于不符合要求而引起的全部工作叫做不一致成本。其中预防成本和鉴定成本属于一致成本，而内部损失成本和外部损失成本，又统称为故障成本，属于不一致成本。下图为一个公司收入、利润与质量成本的示意图：
与传统制造行业相比，软件行业的主要成本类型为人力成本，对外提供的是无形产品或服务，在质量成本子类划分上也有所区别。下表为软件行业与传统行业质量成本活动和费用的构成：
增加预防成本和鉴定成本通常会提高产品质量，内部失效成本和外部失效成本也会随之减少。反之，如果预防鉴定成本过少，将导致内外部损失成本剧增，利润急剧下降。这就需要在成本和品质保证之间寻找一个最佳平衡点。
十三、导致不良软件质量成本的主因
《美国不良软件质量成本：2020年报告》 中，对导致不良软件质量成本的原因进行了分析，主要原因如下图：
主因1：业务软件故障
业务软件故障主要是未解决的软件缺陷问题导致的。这些缺陷隐藏在软件系统内部，在某个特定场景或条件下被触发，从而引发重大的软件事故，给社会、企业带来巨大的有形及无形损失。
大家最熟知的莫过于“千年虫”问题，它与2000年开始的日历数据的存储和格式化有关。它影响到了每天计算利率的银行、核电站、医院、交通运输等中心以及很多其他方面。为纠正这一错误，全世界耗费了数十亿美元来升级计算机系统。2020年在国内也发生了一起影响面较大的软件事故：当天用户打开某App，就会有一个告警弹窗提示：您使用的版本是内测版本，将于当地时间2020-03-28到期。到期后将无法使用，请尽快下载最新版本。虽然该问题不会对用户造成任何经济损失，但其严重影响了用户的使用体验。
主因2：运营和维护遗留系统
运营和维护遗留系统也是一个吃成本的“超级大老虎”。运维工作主要包括桌面系统维护、网络系统维护、网络安全系统维护、服务器维护、软件系统维护、机房环境维护、IT固定资产管理服务等。很多企业不重视IT系统建设后的运行维护，往往采取被动救火式的运维管理模式，只有当故障已经发生并已造成影响时才能发现和着手处理。同时，缺少专业的运维组织，没有行之有效的运维流程，从而导致事件产生后没有第一时间响应和处理。缺乏对事件的监控和跟踪机制，事件无法及时处理，就会产生许多隐性质量成本。
主因3：开发项目失败
开发项目失败主要带来人力成本的浪费，几百人天成本的项目说打水漂就打水漂了。试想，项目团队为了保证按时上线，日日夜夜加班加点，只为上线后得到公司和客户的认可。可是，“理想很丰满、现实很骨感”，往往由于各种原因，造成项目不同程度的“失败”，不能实现项目价值。其中，项目范围不清晰、需求变更频繁、缺乏对质量的关注度、沟通不畅等是软件开发项目失败的主要原因。
十四、小结
在互联网时代，唯快不破。企业在发展过程中，往往为了追求速度而放弃了质量或者将质量排在其他业务目标之后。但不关注质量的代价往往是高昂的，就像文中开头列举的那组触目惊心的数字一样。那么，如何让企业高层管理者重视质量？如何制定合理的质量成本管理策略？如何消减软件不良质量成本？（来源：苏宁金融 王威）
十五、亲和图的前世今生
1、何为亲和图
亲和图是把大量收集到的事实、意见或构思等语言资料，按其相互亲和性（相近性）归纳整理，使问题明确起来，求得统一认识以利于问题解决的一种方法，也叫KJ法。
2、适用场合
亲和图好用，那么当我们遇到什么场合时可以使用它呢？听我来韶一韶：
（1）理清思路，打破现状
当事实或观点处于混乱状态时，可以使用亲和图来理清思路，打破现状。
（2）相互启发，认清问题
当问题看起来太大，太复杂而无法掌握时，可以用亲和图来相互启发，认清问题。
（3）统一意见，达成共识
当小组成员意见不一，需要达成一致意见时，可以用亲和图帮助统一意见，达成共识，减少内耗。
3、使用步骤
知道“亲和图“的适用场合，没用过的人可能还是会有些懵。没关系，一张图让你秒懂其使用步骤。
十六、那些可能会踩的“坑”
在使用亲和图的过程中容易踩坑，作为新手上路，格外要注意以下几个大坑：
1、认为“亲和图”一招鲜
亲和图不是万能的，它也有适用性。如果认为“一招在手，天下我有”，那么恭喜“入坑”。俗话说好钢用在刀刃上，不然也体现不了价值，如下几种情况则不适合使用亲和图：
领导过于重视自己的权威，参与者不能畅所欲言；
解决方案涉及参与人员自身重大利益，参与者争论不下；
讨论大家明知却不愿意参与的问题，无人愿意出头。
2、想要速战速决解决问题
俗话说“心急吃不了热豆腐”、“慢工出细活”。如果是火急火燎的想要速战速决解决问题。那么亲和图爱莫能助，出门左拐，不送。建议在“收集资料”环节充分调动大家参与的积极性，多花点时间收集。
3、收集资料时提前决定分组类别
在收集资料时提前决定分组，恭喜你又入坑啦！亲和图的分组是在对收集到的资料不断地整理、归纳、补充过程中根据相似性进行归类而得到的。如果一开始就进行分组，则与亲和图背道而驰。
其他几步相对而言比较好操作，影响最终亲和效果的是中间的环形步骤，它可能需要多轮才能结束。要有丰富经验的人来进行引导，否则在归纳和分类时容易出现偏差，导致亲而不和！
4、归纳分类时未做到“高内聚低耦合”
在对资料进行归纳分类的时候需要做到“高内聚低耦合“，这样才能有针对性地对每个分类或聚焦到某个分类时，制定相应的执行方案和措施，否则又回到了原点。
十七、三强联手，所向披靡
成功绕开了上述的各种“坑”，你也不一定能把亲和图用好。如果能和其他工具配合使用，则可以起到事半功倍的效果。例如：它可以和“头脑风暴”组合使用，还可以加上“矩阵”三剑合一。
1、“亲和图”与“头脑风暴”的美妙组合
头脑风暴是快速大量寻求解决问题方案的集体思考方法。它适合个人或团队一起不受限制的讨论，打破沉默的氛围，在自由思考环境中创造出有价值的方案和想法。它与亲和图可谓是黄金搭档：头脑风暴负责发散，激发出好点子；亲和图负责收敛，归纳出好分类。“一发散一收敛”之间问题解决，完美！
例如：需要制定一个愉快的假期出行计划，则可以和家人一起头脑风暴，再用亲和图把头脑风暴的想法进行聚合。下图是一个经典的亲和图例子：
2、“亲和图”、“头脑风暴”、“矩阵”的三剑合
如果说“头脑风暴”与“亲和图“这两个黄金搭档的结合好比鸟枪换炮，那么“亲和图”、“头脑风暴“、”矩阵“的三剑合一使用效果会更佳，堪比氢弹。当需要制定执行措施的情况下与矩阵结合使用，效果最好。矩阵横坐标代表事情的重要程度，纵坐标代表是否容易被实施。实施头脑风暴前，与参与成员达成共识，后续头脑风暴的点子需要考虑到如下4个象限，并标识。
例如讨论主题是：有哪些措施可以提升研发效率，头脑风暴后执行亲和图归纳整理，最后每个类别的措施又分为A、B、C、D四象限。这样想要采取的执行措施很愉快地就决定啦！
十八、结束语
当你拥有大量无从下手的数据/问题时，亲和图可以帮助你从复杂的数据中整理出思路，抓住实质，找出解决问题的途径，拨开云雾见月明。亲和图已送出，好不好用，谁用谁知道。（来源：苏宁金融研发 朱冬）
十九、SQA的三大困惑
和其他职业一样，SQA在工作过程中也会遇到很多困惑。困而不学，惑而不解，徒添烦矣！我先抛出三个令SQA最困惑的问题：
1、互联网时代都敏捷了，还需要SQA吗？
随着互联网时代的到来，市场竞争愈加激烈，导致时间特性成为影响质量的主要因素。企业如何能以客户为中心，快速响应，高效协同？于是，敏捷，DevOps成了主流，通过它们来加速信息流动，快速反馈。
敏捷的Scrum团队中包括三种角色，分别是ScrumMaster（教练）、ProductOwner（产品负责人）和DevTeam（开发团队），没有SQA的一席之地。SQA可以担任ScrumMaster，但扪心自问，传统的SQA是否具备相关能力？那是不是SQA就没有存在的价值呢？答案是否定的。
2、为什么SQA常常被团队“提防”着，无法融入？
SQA在开展组织级工作时，往往承担着看护高层领导质量指标的职责，有的还会和绩效考核挂钩。于是乎，上有政策下有对策。SQA收集数据时就要面临数据有效性的各种挑战：数据缺失、数据造假等。
SQA在开展项目级工作时，被“提防”最多的场景是质量审计。在提供交付物等证据，以及对审计结果沟通确认时，各种“防”就来了：能不提供的文档尽量不提供（文多必失），能不多说的话尽量不说（言多必失）。毕竟审计结果是会被通报的，谁都不想被晾晒。
所以，SQA很难融入研发团队，和团队成员打成一片，往往会被“排斥”或“敌视”。
3、SQA的工作成果如何能够量化，从而被相关方认可？
如果要问SQA最怕什么，我觉得“年终总结”算一个。看过长篇大论，洋洋洒洒几千字的总结，但是没有干货；看过数据、图表、动画做得很好看的总结，但是文不符实。产生这种现象的原因可能有以下几点：
（1）很多SQA的工作偏执行，领导让干啥就干啥，缺乏主动思考的意识，欠缺质量策划的能力。等总结时才发现，没有拿得出手的工作成果；
（2）SQA的工作要想真正产生价值，更多的还是要聚焦于质量改进。但是，在这种弱矩阵微权力条件下，SQA牵头过程改进往往举步维艰，改进效果可想而知。当然，也可能存在工作方式和技巧的问题。
二十、SQA的不同使命
以上三个问题反映的都是表象，归根结底说的还是关于SQA的定位及其岗位职责的问题。追根溯源，这就不得不回顾下质量管理的百年发展史。
QA（质量保证）诞生于20世纪60年代，军工企业为了提升产品质量，用严密的程序手册来保证过程的进行，一直延续到我国20世纪80年代后期到90年代。其中最典型的就是ISO9000族系列标准。
1987年美国CarnegieMellon大学软件工程研究所(SEI)发表了CMM框架，它用5个不断进化的层次来评定软件生产的历史与现状，包括：初始层、可重复层、定义层、管理层和优化层。其中，又划分为18个过程域，SQA（软件质量保证）就是其中之一。于是，SQA这个名词就诞生了！后来，CMM不断演进发展，于2012年发布了CMMI-DEVV1.3，2018年发布了CMMI-DEVV2.0，其中关于质量保证的过程域有些许调整，名称分别变为PPQA、PQA，但其本质没有发生变化。
软件质量岗位诞生后，随着软件产业的发展而衍生出了不同的定位和职责，从一开始较单一的过程评审和产品审计工作，到后来的软件度量与分析、软件质量策划、研发过程改进、质量文化建设等。SQA也在企业中扮演着不同的角色，承担着相应的使命。
很多软件企业没有独立的质量管理部门或者专职的SQA人员，往往由其他部门或岗位兼职质量相关的角色职责。SQA一人身兼多角，难免又当裁判又当运动员。角色定位不太清晰、职业发展通道狭窄、工作绩效不好评估，一系列的问题都来了。那么，作为SQA如何破除这些困惑呢？
二十一、SQA的破困之路
问：要让SQA不再困惑需要几步？答：总共有三步。第一步：认识自我；第二步：认准方向；第三步：认知未来。
1、认识自我
一切烦恼都是来自于对自己认识不够。如何更清楚地认识自我？其实有一个很实用的工具，即个人的三环理论。它包含三个问题：我的擅长是什么？我的热爱是什么？我的机会是什么？
作为SQA，需要掌握大量的软/硬技能，软技能有：良好的人际沟通技巧、严谨的逻辑思维能力、持续的自我反思能力、坚忍的毅力与决心等；硬技能有：质量体系知识、质量工具与方法、软件工程知识、项目管理能力、测试管理知识、统计分析能力、扎实的文字功底等。你最擅长的技能有哪些呢？画一个环，把它们填进去。
什么是热爱？热爱就是喜欢做这件事并且做起来很愉悦；热爱就是做这件事是否有激情并且迫不及待；热爱就是愿不愿意一辈子做这件事。有的SQA对质量体系非常有研究，他们喜欢从事质量管理体系建设、流程设计类的工作；有的SQA则对数字特别敏感，他们喜欢做统计分析类的工作。你热爱的工作内容有哪些呢？也画一个环，把它们填进去吧。
机会往往是留给有准备的人。不论公司的好坏、舞台的大小，只要有一双善于发现的眼睛，机会总是有的。比如：在一个小公司，质量体系空白或不健全，你是否可以提一些相关的改进建议，给自己创造一个机会呢？把这些机会点梳理出来，再画一个环填进去。
画完这三个环，你会发现它们之间有交叉重叠的部分。那么恭喜你，你对自我有了更进一步的认识，在交叉的领域就是你后续需要重点发力的地方。
2、认准方向
认识自我后，还需要进一步明确自己的发展方向，也就是职业通道。通常个人的发展可以划分为管理通道和专业/技术通道两个方向。自己是擅长做管理还是更适合在专业领域深耕？这个选择题相信你很快就会有答案。
走管理发展通道需要积累大量的QA经验、项目开发与管理经验、甚至软件配置、软件测试等经验。另外，沟通能力、协调能力、高情商的培养等管理技能也不可或缺。从管理一个2-5人的质量小团队，到跨职能（QA、QC、CM）几十人的大团队，甚至能成为一个公司的首席质量官（CQO），每一步都是一个大的跃升，需要多年的积累和不懈的努力！
走专业发展通道可以成为某个领域的专家，所谓专家就是对该领域的方法论理解透彻，知行合一，甚至形成自己的理论和实践方法，达到传道授业解惑的境界。我们将专业领域划分成流程改进、内控审计、工程能力、管理咨询四个方向。流程改进主要专注于流程体系建设、流程重组与优化、组织过程改进等；内控审计需要精通各类体系标准、对企业的内部控制和风险管理进行检查和评价，防患于未然；工程能力的范围比较广，又可以细分成很多子领域，如：需求管理、需求开发、产品集成、测试验证等；管理咨询的门槛相对较高，不仅对专业知识的涉猎要求广泛，而且需要有在多家大型企业从事过流程改进（六西格玛）的经验。
无论选择走哪个发展通道，我们都要努力成为“T”字型人才。“T”字的一竖代表“所在领域”，就是你要尽力成为所在领域里很难替代或无可替代的人。“T”字的一横代表“知识面”，就是同时你要尽力拓展知识面，成为一个拥有横向整合能力的人。
3、认知未来
随着社会的发展，一些新兴技术日新月异。据数据分析表明，在未来的20年里，AI自动化将会席卷全世界，大约有36%的岗位将会彻底被AI所取代。另外，Devops技术越来越成熟，其推动开发、运维和QA高效协作。它可以内建质量，甚至不需要SQA的介入。这些都是作为SQA需要直面的问题，我们需要有危机意识，不主动学习、不快速成长，势必会被淘汰，大家的困惑也会愈来愈多！
在认识自我和认准方向后，还要结合未来的发展对自己的规划进行调整。如果你擅长的工作是重复性的、可替代性的工作，请逐渐“放弃”它，去培养你感兴趣又能跟得上这飞速发展时代的新技能。创造性的劳动总是很难被替代的，而且价值高。所以，不妨跳出自己的舒适区，勇敢接受挑战！（来源：苏宁金融 王威）
二十二、小结
任何一个职业都是充满挑战和艰辛的，SQA也一样。但同时，我也深刻地体会到：不经历风雨怎么见彩虹，不经历困惑怎么得成长！如果再有（来源：苏宁金融 王威）
二十三、理念宣贯与方法导入
提起质量回溯，不少研发人员都会有抵触情绪，甚至有些谈“虎”色变，在这样的氛围下是不利于回溯工作开展的。质量人员在开展回溯工作前，需要有意识的进行回溯理念的宣贯：
回溯目的：通过问题定位、根因分析、措施改进，预防同类问题再次发生，提高产品质量水平。
回溯导向：质量回溯不是追责和考核，而是自省和改进。
质量回溯理念的宣贯是思想的松土，埋下了一颗持续改进的种子。接下来要做的就是给种子浇浇水、施施肥，质量人员应组织一系列的赋能培训，导入质量回溯的规范要求、常用的根因分析工具，如：5WHY、鱼骨图等，以提高质量回溯的效率和效果，帮忙团队找到问题的根本所在，彻底解决问题。
二十四、来源获取与问题统筹
质量回溯适用于组织内部各种问题的改进场景。在金服集团，质量回溯问题的来源通常包括：生产事故、紧急BUG、上线验证问题、生产发布失败、项目重大变更/延期、用户体验问题等。
针对不同的来源，需要建立稳定可靠的问题获取渠道，如：生产事故可以通过“生产事故专家保障群”第一时间获取；紧急BUG可以通过缺陷管理平台（JIRA）实时导出等。这些问题由质量人员统一扎口，形成质量回溯问题台账。
根据二八原则，质量人员会对问题进行统筹管理，从问题台账中挑选其中20%最值得回溯的问题。逐步建立回溯问题的筛选原则，比如只要满足以下任一情况则组织回溯：
重大生产事故（一、二级）
造成公司资产重大损失的问题（XXX金额以上）
严重影响用户体验的问题（用户投诉数XXX以上）
共性或批量发生的问题
二十五、核心要素与前置准备
对具体问题进行质量回溯时，需要掌握一些核心要素并做好充分的准备，否则可能会带来以下问题：
1、召开会议时，问题背景没有了解清楚，增加沟通成本
2、分析问题时，相关材料缺失，问题分析不透彻
3、问题定责时，责任切分不清楚，导致效率低下召开多次会议
为了避免以上问题的发生，我们要做好两方面工作：
（一）充分识别相关方问题相关的当事人（业务、产品、开发、测试等）
◆ 管理层领导（技术总监、产品总监等）
◆ 有经验的回溯引导人员（SQA、PM或Scrum Master等）
◆ 技术领域和管理领域的专家（架构师、技术专家、PMO等）
（二）提前准备回溯材料
◆ 回溯报告准备
问题当事人（通常技术经理牵头）整理输出问题的描述、影响、处理过程等。问题描述应详尽，可采用5W2H方式。
◆ 相关材料准备
该问题涉及的过程交付物，包括：需求文档、设计文档、源码、测试案例、测试报告等。
二十六、关键活动与回溯过程
前期准备充分后，一般可采用质量回溯会议的形式对问题进行回溯，通过这种高带宽的沟通形式，提升相关方的沟通效率。回溯过程主要包括过程回放、根因分析、措施制定、问题定责四个活动。
（一）过程回放
过程回放应遵循“三现”原则，由问题当事人还原问题发生的“现场”，对问题进行详细描述并说明其影响程度以及当时的处理过程。
（二）根因分析
根因分析是质量回溯的关键活动，找到产生问题的根本原因才能对症下药，有针对性的进行预防和控制，从而避免问题重犯。
1、识别问题引入点/控制点
通常，每个公司都有项目或研发流程管理规范指导项目开发工作。对问题进行分析时，可以在白板上绘制简单的活动流程图，从源头开始共同识别问题是从哪个环节引入的。
找到问题引入点后，继续分析其后面的所有环节，识别哪些环节能够提前发现或阻止该问题的发生。
2、问题产生原因分析
工欲善其事必先利其器，在进行问题产生原因分析时可以借助质量工具来达到事半功倍的效果。
首先，与会人员进行头脑风暴，列出问题产生的所有可能原因；
然后，利用亲和图将纷繁芜杂的原因进行归类，厘清头绪；
最后，绘制鱼骨图对问题进一步展开，直到无法细分为止。
3、确认根本原因
可以通过定性（专家决策）或定量（矩阵数据分析法）方法来最终确认问题产生的根本原因，并在鱼骨图上圈出。
（三）措施制定
问题的根因找到后，需要制定相应的改进措施。针对问题引入点，应从源头上切断，避免问题发生；针对问题控制点，可通过管控、评审等控制手段防止问题流入下个环节。
改进措施制定时可以参考以下原则：
◆ 在组织能力范围内，尽量采用低成本解决方案
◆ 要遵循SMART原则，便于落实改进
◆ 技术方式应优先于管理方式
◆ 短期与长期措施相结合
◆ 改进措施的结果固化到流程和工具中
（四）回溯定责
回溯定责是根据问题根因，明确问题责任主体及责任比例。定责的目的是为了更好的驱动改进。
为了保证定责的权威性，减少责任界定的成本，可以参考如下实践：
◆ 制定定责划分原则，如：跨中心的问题根据技术架构设计原因进行划分；发生测试漏测问题，测试承担50%以上责任
◆ 引入技术专家团队，采取轮值的形式，对于跨中心或复杂问题邀请3-5人参与回溯过程并投票定责
◆ 如果定责存在争议，及时上升至高层领导决策
二十七、改进总结与警示分享
改进措施制定后，质量人员需定期跟踪其执行情况。为了保证措施切实落地执行，可采用一些工作技巧：
◆ 通过工具（如Jira）统一管理改进措施，方便查询统计
◆ 定期晾晒改进措施执行进展，针对短期/长期措施采用不同的晾晒策略
◆ 不定期参加团队的改进活动，如：代码评审、测试案例评审等
已开展的质量回溯可以定期进行总结，经验教训共享，警钟长鸣。分享途径有：
◆ 技术例会：技术例会由各研发中心技术总监参加，邀请问题当事人对回溯案例进行分享，各中心可以从中汲取教训，起到警示作用
◆ 质量报告：通过定期的质量周报/月报形式，通报当期的质量回溯情况，引以为戒
二十八、结束语
质量回溯看似简单，实则复杂。质量人员要想做好质量回溯工作，不仅需要长期耕耘于组织流程规范，掌握质量工具的适用场景和用法，还要了解业务及技术知识，才能整体协调，游刃有余。（来源：苏宁金融 石达）
