关于质量责任的界定
毋庸置疑,质量是全员质量责任,也是全面质量管控,但一旦出了问题,又该如何去追溯和复盘,最为关键的就是厘清质量管理责任,完善制度和流程,在后续过程中有效规避。
这似乎又是一个遍地鸡毛的话题,自古以来,纷扰不断,以至于清官难断因为这本是定性的东西,非要说出你占20%、我占30%,未免太过于牵强。个人为,凡是质量责任,最终界定超过三家负责,那就属于扯皮。
以下举几个例子,简要分析一下质量责任如何去界定。
1、软件实现的例子
软件编程错误,或者是可靠性、容错性不高,谁的责任更大一些?软件实现任务要求提出方,还是软件评测方?
这里有一个问题,针对定制的软件产品而言,如果任务要求可以直接转化为需求说明或代码实现,那么软件编程、代码实现就不会那么香了,距离软件系统的初衷会越来越远。
反过来,如果要求没有提清楚,单凭一已之理解,想当然地实现,也不可取,沟通一下,如果沟通完了还没有弄清楚,当然就是任务提出方的责任了。
随后就是系统测试和软件评测,这是我们经常碰到的问题,系统测试和软件评测测试不出来,首先是测试的方法、用例,然后是数据判读,一个重要的因素就是时间周期的保证。此外,业内、业外的软件评测,想要测到什么深度,就需要怎样的时间保证,一定的资源投入,对应着测试经费的投入。
综合测试(系统联调、综合试验等),测试项目的针对性,边界和压力测试甚至于注入式测试,注入什么,应该就是人为制造的异常,当软件转入异常分支后,看是走进死胡同,还是有一定的容错处置,虽然不能在硬件已经0VER的前提下解决所有的问题,但有一点,进入异常后的紧急处置还是要有的。
对于软件和硬件,可以以人比拟,软件相当于灵魂和意识,硬件就是四肢和肉体,少了什么都是不完整的。
系统工程而言,作为一个整体,系统、软件、硬件在系统试验项目设置时都脱离不了干系,只有这样才能保证整个系统的测试覆盖性。
系统在整个过程中容易出错儿的环节就是数据已然异常或者有变坏的趋势却辨识不出发现不了端倪,那系统你活该倒霉,给你了机会,不好好去把握,所谓系统的高大上,更多的应该是责任而已。
再说一下软件评测。
首先是测试用例的生成,别轻易说第三方视角的独特那是建立在对某些方面有深入把控的基础之上,不是专家,也不可能提出一些针对性的意见和建议,发现不了短板;也不要说软件编程方难以发现自己的问题,自己看自己越来越顺眼;反而是系统,却往往会成为这中间最弱的一环,在整个软件实现和试验、评测的各相关方中,谁更有优势有效把控整个软件研制,系统软件,当然是系统设计人员,包括方案算法和整个系统方案的把控。
测试用例的设计,从来都得益于系统需求方、软件实现和软件评测的精诚团结,任何一方的偷懒,测试的针对性和有效性都会大打折扣。
一个值得深入思考的问题,就是专业分工越来越细的前提下,靠什么来更为有效地把控系统需求和系统实现。
其次是测试的周期和测试的覆盖性,测试用例确定的前提下,测试周期和测试覆盖性强相关,可以定制测试的深度和广度,但随之时间也会成倍地增加,不要寄期望于三五天即完成一个配置项的全方位测试,做人终归要实际一些。
第三就是在以往评测中已经发生过的问题,如果让其白白溜走,责任就在软件评测方。
一个极端而又常见的例子就是软件编错了,系统测试测不出,软件评测又堂而皇之地通过,怎么去界定责任？
各33%,不可能。
(1)软件实现错误,如果任务书错了,那就是任务提出方的责任,因为后续的走查也罢、软件测试用例审查也罢,任务提出方都要参与,这里的唯一责任指向任务书提出方和系统；
（2）如果任务书描述不清,那就是软件实现方的责任,既然描述不清,不闻不问,低头按照自己理解实现,那就是你的责任；
(3)如果任务书描述清楚了,软件设计也正确,那么责任就在于任务提出方设计源头的问題,虽然描述清楚,但也并不代表着全面和完备,而这时的问题更多的属于系统性问题,此处也绝无可能去纠软件评测的责任。
在软件调试的过程中,也往往会遇到这样的例子,过程中因软件编程实现间题,造成设备的烧毁,也就是一些场景下设备的输出未被禁止,包括初始化、设备开关等情形.当时的界定就是系统和软件各占50%,当时系统还有些愤愤不平但今天再去回顾这件事情时,不难发现,这个问题的主要责任还是在于系统个调试过程中没有保护,二是既然软件没有调试好,干嘛让它进系统,并且在系统中进行调试,别扯什么进度,如果是真正的火工品,命都该没了。所以这里要有一个前提,进入系统调试的软件,一定要具备基本的功能,要经过单元测试。
在这一点上,只要系统受到了处置,才会更硬气地约束进入系统试验的产品要具备最为基本的条件一一自已要跑的通,输入输出要正常。
再回到极端例子,如果有时间和计划的因素在里面,那么应该纠管理责任谁对时间进度和计划负责,谁就应该理所当然地牵扯其中,不容狡辩和畏缩。
2、整个系统回路闭环确认不充分的例子
控制指令最终要到执行机构,二者存在着机械、电气和软件接口,一般而言保证自己正确和接口匹配,不会出什么大的问题,但问题就在于如何保证自己正确,如何确保自己测试的有效性和覆盖性,此外接口的匹配性也绝非纸面的匹配性。
一个典型的例子就是织女星的失利在于作动器装反,单个作动器在单元测试不出问题也不能被发现系统性问题,而在整个系统联调过程中有没有机会去发现。
责任该怎么界定?
(1)如果单机本身没有问题,单机也只有在装配之后成为系统的一部分,那么总装和系统负有不可推卸的责任,装配本身的未确认,系统测试的不覆盖；
(2)单机、总装、控制系统、总体,从我们的分工角度去理解,如果单机责任后推至总装,也就是总装保留工序由单机完成,那么首要责任在于单机,同时系统和总体也应该负有一定责任,至少是6:2:2的比例,这里不是非要强调所谓总体的无限责任,你的输出需要闭环确认,你的产品总体责任在于任务书提出方功能可以分解,但质量首责永远无法推卸。
最终产品谁交付,质量责任就在谁,不容争辩。
一般情况下,总不能出现这种令人反感的情况,好处总是你的,责任总是别人的。
尤其是对于影响成败的环节,本应测试到的测试不到,总体和系统难辞其咎要么测试到,要么在过程中提前确认到,无非这两种情形,做不到就是工作不到位,就要承担责任。
3、因技术状态变化控制不到位而带来问题的例子
这类问题在项目研制过程中经常遇到,就是想简单了,影响域分析不到位之所以分析不到位,最为关键的就是相关方不到位,分析不透彻,影响面没有把握住。有人会说,即使在位,也未必分析的清楚。错,这便是其一。
其二,就是针对变化的分析,专业和组织是否在位,相应专家是否在位,如果不在位,如果非组织而是项目刻意而为之,更多的责任在于项目,如果组织在位,相关方不在位,那么责任应该由项目和组织共同担当。
其三就又是试验验证和软件评测的事情了。针对变化,没有针对性的测试用例,还是按照以往测试正常去开展,即便是一万遍恐怕也暴露不了问题。
4、操作类问题
这对应的就是有章不循和无章可循的问题了。
对于前者,更多的在于个人,但组织在培训层面,尤其是在质量意识培训层面需要担责任,既有培训又有规章,再发生类似的问题,实在无法去追组织的责任。
对于无章可循,更多的属于组织责任,也不要太多地去追究所谓操作者的贵甚至于一些未曾细化的工艺类文件,也最好不要去追究非工艺人员的责任此时,最好由组织去负责,谁代表组织,主要领导、主管领导以及子组织的负责人,主管相关业务职能机关的负责人。
此处随之而来的又会有一个疑问,质量管理人员又该承担怎样的责任?
全员质量和全面质量管理,所有质量问题与质量管理人员存在着千丝万缕的联系,无论是评审还是试验结果评审的组织,过程更改的把控,甚至于评审相关方的在位与否?似乎质量管理人员和质量部门领导天生就是要来承担责任的。
有这种思想的人最好别做一级组织的领导,否则质量工作也无法真正搞好。
对于重大质量问题的责任追究,一般会从管理职责的落地、落实层面来考虑问题,质量体系、标准要求约束没有缺失的,一般需要再追究质量人员的直接责任。
这时,更多的是质量人员的监管责任。
这是质量人员不可推卸的职责,也是质量管理的根本职责所在,尽管很多领域又重新赋予了质量管理全新的与其地位不符的职责,所以如果有责任,那就是监管不力的责任了。
有人不免会有疑问,怎么才可以做到监管的尽职尽责,很简单,需要持续不断地内审,按照计划组织管理评审,细查相关项目的执行情况,并对问题及时有效地发布举一反三要求,监督各项目认真组织开展了举一反三。因为环节的复杂性,要想穷尽式的把控不够现实,同时人盯人的模式也不可取,所以监管也应该有重点地开展。
5、重申责任追究的范围
质量责任的界定较为复杂，切忌一哄而上，也要切忌推脱责任，所谓一碗水端平确实很难，最大的障碍就在于考核和站位的影响，但有一个总体原则得把握住，谁犯的错儿，从那里铺陈开来，查找责任的源头，一般而言，所有的环节如果都有责任，那么这些环节的设置是不合理的。
总体的无限责任，以为产品是以你的名义交付的，产品出问题了，你怎么可以不急；另外一层的意思就是任务下达及试验验证中是否存在待改进的环节，这才是真正的无限所在。
而非出了问题就要痛扁总体。
在重大质量问题出现之后，我们的惯常做法是处罚和行政处分，这一点无可厚非，但有一点，是否所有在的环节都要进行处罚，另外除了处罚，组织还可以做点什么？
技术的进步，管理的深化，标准的完善，监管的细化，这才是真正责任追究的重点之所在。
应该旗帜鲜明地反对主要领导都要追究的模式，管事的与管人的，更多的应该聚焦于管事儿的环节。
田村山下