前两天和组里几个应届生朋友聊天，明显感觉到了他们的迷茫，不知道如何定位，不知道如何开展工作，不知道学习什么。实际上，不仅仅是他们，即使是很多业内人士，现在也对于汽车软件质量管理的落地模式和发展方向，也有些茫然。
方向和目标是努力的核心前提，对于软件质量管理也是一样，所以今天再来讨论下这个话题。
质量如何干？目标是什么？
干质量的目标就是干掉质量，就是要让质量角色弱化、边缘化，甚至消失。
是不是有点值得玩味的说法？也好理解，如果质量人员冲锋在前，时时刻刻抛头露面，是不是正好说明质量问题很多，当放眼望去，看不到质量的身影，而一切高质量运转，也正是质量追求的目标。
那么，路径是什么？怎么走？
依然老生常谈，用 QC、QA、QM 这三个大家再熟悉不过的质量术语来展开。
一个质量圈内总用的一个类比——驾驶车辆。
QC是仪表盘，显示车辆实际状态，比如车速、胎压、油量等，一旦有问题给驾驶员以预警提醒。
这是干质量的第一阶段，当然这个阶段也会有好和差之分，做得差的，只能给出一些状态展示，这个状态也不一定完整、客观、直观，或者即使完整、客观、直观，却仅限于此，不能给出问题所在。
做得好的呢，不单单能清晰展示客观状态，做出很好的度量，给出趋势，还能精确定位核心问题。
可能还有人接着说，是不是好QC还要给出问题的Root Cause和Solution啊，嗯，能做到呢，自然是好QC，但实际上有些强人所难，也基本做不到。做过项目的人就会知道，只有真正亲历项目的人才知道问题核心和原因所在。
那么，具体的现实的好QC是怎么样呢？
比如，我们可以及时梳理项目信息，便于项目经理或成员查阅，或提醒其不要遗忘；也可以帮团队分析Bug数据，定位聚合问题，预测趋势，制作报表，让项目或领导了解项目真实状态；或者检查过程数据，看有没有什么不合理的……做到这里就差不多了，所谓好一点呢，就是你的信息要是准确的、关键的。
不过，QC是实实在在做的事，这个是多数人眼里能看到的质量做的事。当你不知道能做啥时，先把QC做好。
实际上，测试也属于QC范畴之内，目标也是为了展示软件状态和问题，所以有的公司会把QC等同于测试。不过，由于测试本身具有很强的专业性和独立性，我们就暂不把测试包含进来讨论。
无论如何，光QC是不够的，就像司机并不只会依靠仪表盘的信息开车。
QA是驾驶手册或老司机告诉你的经验方法，QC的仪表盘报得再准确，也只能让你停下来加个油、修个车，亡羊补牢，虽话说是犹未为晚，但实际还是有点晚，最好能提前加好油、保养好，一来能快速安全到目的地，二来仪表盘显示的信息也毕竟有限嘛，再来个出错，岂不是惨了。
这时，QA要通过虚一点的流程、体系、工具、方法等去做提前预防或提高效率，它的一个目标也是要减少QC的存在感，说实话，作为开发、测试、项目管理都不是专长的Q，就靠每天去C能C出多有效的信息呢？难说。
所以，这个阶段，QC要往QA转观念，要和业务部门一起来构建及优化体系来系统化地预防或者更高效地展示状态。
这就涉及到两个环节，一是建立及优化流程，二是建立数字化工具。
前者可以让业务部门知道什么时候该由谁按照什么方法做什么事，而不是QC去不痛不痒地告知提醒；后者可以解放QC做excel的双手，提高展示效率和效果，还能更好地便利业务部门的工作，皆大欢喜。
不过，这个时候的QA还不能松懈，你要保证流程是合时宜的，保证工具的好用的，还要做很多优化改进工作的。而且呢，还不能忘记QC的活，工具和流程毕竟有局限性，在这局限中边做QC，边做QA，顺便压缩QC的空间。
最关键的是，做Q千万不能只在excel和ppt里做，要深入项目，深入业务，不做纸上谈兵的赵括，站在Q的立场去和业务部门合作。
此外，获得管理层的支持是必不可少的，一个负责任的QA加上领导赋予的产品释放权是可以帮助产品提升质量的。
然而，这个过程一定是漫长的、痛苦的、矛盾的。
再然后，随着时间的推移、行业的发展和所有人共同的努力，在某个契机，你会嗅到一点QM的味道，那是人车合一的快感和哲学。在那之后，那个老司机逐渐不再需要总是看仪表盘，驾驶技巧也慢慢烂熟于心，可以靠直觉加速、转弯、漂移……或者直接自动驾驶了。
那是技术、供应链、文化、观念的成熟。
无论如何，当足够成熟后，Q们就可以选择退居二线了，就像制造业的研发系统或某些互联网企业或某些自动化工厂，质量的身影已经若隐若现了。
QC--QC+QA--QA--QM--No Q，这或许是质量的一个轨迹和目标。
最后，再回想到那几位应届生朋友的迷茫，说心里话，我更建议行业经验比较丰富的人员来转型做软件质量，毕竟教人做事岂是随随便便就可以的，当老师前，至少得当过学生。
文章源自公众号 汽车软件质量