导读:
01.
难题
02.
价值
周末，一个提问在质量专家微信群里引起了大家的关注——
A：各位大咖老总，周末愉快，想请教一下，质量部的价值在哪里，通常说到帮老板/公司创造价值，特别在中小民营企业，老板期望的这个“价值”是什么，谢谢！
于是，各位专家各抒己见——
B：这个要和你老板深入沟通，每个公司老板期望不一样
C ：这是个好问题，每一个人对质量的认知都是不一样的，非常同意楼上说的，你想在企业里发展的好，一定要和老板去沟通，企业的发展阶段是不一样的，老板的认知不 一样，质量部的价值也是不尽相同，我之前遇到一个老板，他的质量部长除了做好质量工作，还要做好兼职司机，随叫随到。
D：all of business are money.
E： 是的，有Business Quality 这个词语/策略出现了！
F：我认为质量部的一个价，值在于说如何使用最合适的质量成本来保证我们获取到最长远的利益。当然在长期利益和短期利益之间的平衡，以及预防质量成本和后期质量成本的平衡。这个得根据每个公司的现状还有客户的要求不一样的。不应该过度地亲和老板，更应该有自己的想法和分析。当然还有可以使用质量获取到客户，这些就看行业了
G：部门低成本运维，公司层面不创造明显利益但必须产生附加值。
H：嗯。那再说到质量就更深层，产品小质量和运营大质量。那是有比较大的差别的
I：每个工厂口号放在前面的都是质量第一，这不是value是啥？
J：我很同意F的说法 质量工作还是要不卑不亢 （虽然有难度）
K：很多时候嗯，老板不缺人家给他一个方向，但是他缺乏一个第三方，或者更加公平公正的一个声音，甚至对他的决策做出一些判定的一个声音，可能会更好一点。
L：其实质量总监经理很多时候还是要看自己的定位，自己的理想，最关键的是怎么经营自己的未来，只有自己的目标和方向明确了，这些问题就迎刃而解了。
M：是的，老板/公司/客户/行业对质量部的定位也是极为重要的指导方向！
N：你让他到质量部的各岗位干一天，和他讲价值就是秀才遇到兵，只有干了才知道 当然他也知道可以分出来部分给其它部门。
……
一时间，微信群里众说纷纭，好不热闹。设身处地在现实场景中，被老板问到你的部门有什么价值，任谁都会多少有些危机感——敏感些的会想到该不是要把整个部门给裁了吧。尤其作为质量部门，既不像销售部门能秀出订单上的真金白银，又不像开发部门拿出产品功能跑一跑，就连数据报表里的也不一定有项目管理部门更能吸引老板的眼球，如若不能在老板问出这个问题之前先发制人地在日常工作中潜移默化地用质量文化把老板给“向上管理”了，至少应该未雨绸缪再被问道这个问题的时候给出答案。
在质量领域，每个人的答案随着实际情况会有不同，但一定能体现他的层次。以下是个人根据十多年质量经验整理出来的层次图，比较主观，不同的质量专家根据自己经验可能整理出不同的层次表。其中，虽然人的本能都期待达到最高层次的流程咨询师，但不可能一蹴而就，作为下面层次的打杂、检查单、教练、培训、数据分析作为上游层次的基石，是不可能直接跳过的。没有现地现场的“打杂”、没有按部就班的检查单（checklist）、没有严谨的数据收集，上游的流程咨询不过是空中楼阁。
打杂人手：收集数据、整理报告、协调审计……这些都是质量人员的打杂日常，至于能不能快点升级，就看是否具备相应的技术能力——自动化脚本收集数据、规范化模板整理报告、畅通的沟通机制做好协调等等，在效率提升的基础上自然可以进行个人提升。
检查单检查者：检查单（Checklist）是质量人员不可或缺的工具也是无法跨越的阶段，脚踏实地一条一条地实施检查，该看代码看代码、该看架构看架构、该看客户抱怨看客户抱怨，积累到了一定程度才能真正理解检查项背后的逻辑和所要达成的目标是什么。
项目教练：基于日常与各个团队的协同，质量人员在特定细节把控上强于项目经理、而在全局把控上又强于单个部门如软件开发、测试、产品经理，因而应当在项目层级担当教练（coach）的角色，有效地落地改进。
组织培训讲师：从项目级到组织级的积累，对于质量人员是一个量变到质变的过程，看的项目多了、看的问题多了、看的解决方案也多了，它山之石可以攻玉，在整个组织内部可以成为一个打破壁垒的培训者的存在。
数据分析专家：与外来咨询公司的一大差异在于，内在流程人员可以拿到实际的数据，无论是项目缺陷、代码warning、需求条目、交付延迟……因此可以做到“纯干货、重实战”，而通过有效的方法组织分析就可以实打实的把流程落地，而非纸上谈兵。
流程咨询师：在质量工作中，机械地拿着checklist逐条问询已经远远不能满足时代的需要，对各类人员的需求把控、流程实施中的专业知识、工具链的熟悉使用，都成了不可或缺的基本技能。在现下的行情下，具备这些实力，那就是一个妥妥的流程咨询师了。
当老板问到“质量部门的价值”时，他更期待的是来自于“流程咨询师”级别的高屋建瓴的回答，质量人员也应该从这个角度入手，而具体怎么操作则需要随机应变，就如其中一位专家所回答的“这个要和你老板深入沟通，每个公司老板期望不一样”。只是记住，在回答这个问题，预备预判后续可能问到的问题，因为——
“Detail is Knowledge, Knowledge is Power.”（细节就是知识，知识就是力量）
03.
周期
在传统汽车主机厂（OEM）和供应商（Tier 1/2/3）的软件开发流程转型中，短时间内就很容易积累大量的“怨念”——
系统工程师：原来的系统需求写得好好的，又详细又清晰，看着就能把代码写出来。现在可好，一定要把软件需求拆出来，一拆就拆出一大堆事情——原来系统需求里重复的内容得删掉吧；改过的文档得评审吧；追溯性得建立吧；一致性得确认吧……你说好好的都放在系统需求里不就好了，费那事干嘛？
软件工程师：把软件需求拆出来挺好的，这样咱们软件有了自主权，不然按照系统那帮人写的需求做出来东西来了，出了问题还得我们背锅。不过要把软件的合规性测试和集成测试拆出来就比较坑了，之前虽然软件都测但追溯性什么的要求没那么严，基本都是让测试团队把关。现在多了这么多测试的工作量，叫我们上哪要人去？
测试工程师：谢天谢地，流程总算要求软件团队自己测试了，不然每次东西基本不测一坨软件丢过来让直接我们把关，报过的问题还反复出现，这样他们自己把关问题再给出来的软件问题总归能少一点。但是现在组织流程把测试统括的责任都放到我们这边是肿么回事，从SIL、MIL、PIL、HIL还要有VIL都让我们确认是不是有一点夸张。明明是一个ECU的开发偏偏搞到整车级别的测试，这个怎么搞。
EE/ME工程师：这么多年我们的流程都定义得好好的，为了个追溯性（Traceability）偏偏要让我们把所有文档都往系统（DOORS、Polarion等类的工具）上搬，用起来超复杂的，还容易出错，简直是为了流程而流程……
项目经理：这平常列一个EXCEL、写一封邮件、拉一个会就能搞清楚的事情，偏偏要上JIRA分配任务，这个工具一直都是软件部门才用的我们项目经理就从来没用过，不是强人所难么！
不同于特斯拉的横空出世，多数的传统汽车在软件开发流程方面，都面临着已有多年积累的弃旧迎新批判继承，而又不同于纯粹的软件开发，汽车软件依附于汽车这个产品的应用程序开发。因此在汽车软件开发流程建立/转型之初，就应该明确一个前提：汽车软件开发的生命周期不是一般的软件开发生命周期（SDLC - Software Development Life Cycle），而属于更广义的应用程序生命周期管理（ALM - Application lifecycle management）。（以下就用ALM代替）
应用程序生命周期管理 (ALM) 是计算机程序的产品生命周期管理（治理、开发和维护）。它包括需求管理、软件架构、计算机编程、软件测试、软件维护、变更管理、持续集成、项目管理和发布管理。ALM 是比软件开发生命周期 (SDLC) 更广泛的视角，SDLC仅限于软件开发的各个阶段，例如需求、设计、编码、测试、配置、项目管理和变更管理。ALM 在开发后继续，直到不再使用应用程序，并且可能跨越许多 SDLC。（参考资料）
在互联网寒冬的同时，智能制造对软件的需求在各制造业中与日俱增，如汽车、医疗器械、能源、船舶、航空航天……软件人才进入这些领域之初，对于SDLC与ALM这两类生命周期的区别应当有清醒的认识。而原本就扎根这些领域的专业人员，同样需要基于这样的认识，积极面对软件开发流程所带来的的变化。固然在转型的过程中会遇到各种难以预料的难题，但身处“在短短几十年里就走完了西方发达国家几百年的路”的中国，这样的变化不早已习以为常了么？
面对ALM的复杂性，不同的行业作出了各自的应对，而德国汽车工业联合会VDA给出方案之一则是“插件（Plug-in）”的概念，即把产品分解为不同的级别（Layer）。系统级别提纲挈领，而软件、机械、硬件（电子）各司其职，如下图——
在构建汽车软件质量体系的时候，虽然不一定全盘接受ASPICE的标准要求，但考虑ALM的复杂性进行分层还是非常必要的。如同前面提到的，转型必然会带来各个部门的“怨念”，如何务实地落地，则是对整个组织的考验，当年以IPD为代表的的流程在华为的落地就带来了公司的持续发展，可见方向对了，带来的收益将是巨大且持久的。
阅读原文，关注作者知乎！
