质量免费笔记

直接的收获

质量的特定含义

读《质量免费》最重要的收获,就是了解到质量的另一种定义:质量是符合要求。不见得是唯一的、排他的定义,起码是质量这个多义词中的一个语义。其重要性就在于,在工业化、标准化的语境中,可以严谨无歧义的使用质量概念,可以与ISO9000族的质量体系国际标准,在概念上保持一致。

第一次就把事情做对

对于这个理念,我深表认同。不管是写代码,还是系统设计,或是项目协调和团队建设,都有很深刻的体会。第一次怎么做,直接决定了事情的基因。切肤之痛,并不单是修正错误、返工带来的巨大成本。更是在基因支配下,错误无可挽回、无法止血,只能将错就错下去,产生出无休止的成本和痛苦。

为了实现需求,要写一批代码的时候,我特别喜欢把第一段代码写成标兵代码。经验证明,这个做法特别有用。举个简单的例子,要实现一批列表页面,假定因为需求差异的约束,不能实现成通用组件。如果把第一个页面写成优雅的标兵代码,那么就可以在复制这段代码的基础上改来改去。哪怕最后改的面目全非,与标兵代码完全不同,也会依然优雅如初。

小到代码模块设计,大到系统设计,最初的需求往往对灵活性、扩展性、健壮性并没有什么要求。在做设计的时候,如果依然本着第一次就做好、做对的原则,设计成优雅实现,以后总是会带来惊喜。我的感受是,在设计中留下的伏笔,灵活性总是会被用到,扩展性总是会被挑战,健壮性总是会被考验。

项目协调和团队建设更是如此,所谓前有车后有辙,上梁不正下梁歪。因为在实际工作中,对大家形成约束的很少是大陆法系的法典法,更多是海洋法系的案例法。大家动不动就会援例处理新问题、新工作,以前类似的事情是如何如何做的。简单举个例子,写周报的形式在第一次定下以后,不需要再次干预就可以自动延用、运行很久。

质量免费,但不是赠品。相对于没有符合要求、第一次没有把事情做对,而产生的巨大成本,质量确实是免费的。但是要想大规模、工业化的符合要求,达到稳定可靠的质量水平,却是需要付出艰巨的努力。没有什么事能随随便便就成功,不经历风雨,怎么见彩虹。

公示制度

质量概念中要满足的要求,需要各方协商后达成一致,并且仪同公司制度要全员公布,一体施行。在执行过程中,可能有些要求太低,不能满足下流客户的诉求,也可能有些要求太高,在上游无法落地实现。这些都需要对要求做出修正。修正案本身和最初的要求列表一样,也是需要全员参与、协商一致,并正式公示。

全员协商确认并且公示这一点特别重要,可以确保上下游的对接过程流畅、无歧义。更重要的是,这样一个独立的制度体系,不依赖于人的个性化的知识而存在。上下游只要遵守制度契约,就可以根据情况换人执行。更可以在需要的时候,大规模增加人力来满足进度要求。这是质量管理体系,可以覆盖大规模工业化生产场景,可以确保质量稳定输出的必要前提条件。

进步的路线图

质量管理水平的进步,是分阶段的,有一些可以识别的特征。利用质量成熟度管理方格,可以比较客观的评估当前质量管理水平所处的阶段,既可以避免过高估计产生拨苗助长效应,也可以避免评价过低后所采取的措施浪费时间,浪费人力物力财力。

思考引申

要求就是规格

质量就是符合要求。我的理解,要求相当于制造工厂里规格,蓝图上的规格。设计部门给出蓝图,制造部门根据蓝图上的规格要求生产,质量检测部门根据蓝图规格检测验收。

规格含义着两个要素,一个是要求,一个是测量。

比如,某道工序的要求是:

  1. 用大号螺栓
  2. 螺栓拧紧
    这两条要求在日常生活中差不多是够用的,但是在工业化场景的蓝图规格上是远远不够的,起码缺少了测量的要素。

补充一下,该工序的规格可能如下:

  1. 用六角头螺栓,型号M8。这是一个组件,规格含义是遵守GB/Txxxx国家标准和XXXX私有标准的螺栓。
  2. 拧紧螺栓力矩应为[xxx, xxx] nm 区间。

测量是关键

我的理解是,在描述质量的规格中,除了要求本身外,最重要的要素就是测量。如果没有测量,一切要求都是空文。

在工业化的世界里生活日久,我们往往对几千年的科学积淀、几百年工业文明的成就视若无睹。一枚小螺栓,从矿石到材料,从工业标准到加工装备,从生产线拧螺栓的工具到质量检测测量力矩的工具,无一不是相当复杂。小螺栓本身的蓝图规格,以及相关的工业体系各部门涉及的蓝图规格,汗牛充栋,浩如烟海。

作为一个普通使用者,如此轻视小螺栓没有什么问题。但是如果作为生产制造者,尤其是设计者,把这样的生活常识带到设计生产的工业活动中,是要碰钉子的。

比如,作为一个普通的互联网用户,看到一个按钮,点了按钮后会发生些什么,简直就是一个无比简单的常识现象。一个产品经理,或开发工程师却不能这么看。一个按钮的尺寸大小、外观样式,摆放的位置,被点击后的逻辑流程、用户看到的各种操作反馈,都是需要用PRD文档描述详细的规格的。日常生活中经常用到的瓶盖、螺栓,只要百度一下就会发现,每一个小东西的规格文档都非常细致、严谨。随随便便就可以网购到的十来块钱的东西,更是了不得。不要说更复杂的工业产品了。

当然也不是所有的细节都需要由规格文档描述,因为有些部件的规格另有蓝图说明,或另有规格的标准规范。我们在设计中提到,某处使用一枚小螺栓,或使用一个按钮,除非另有规格蓝图的标准规范,都要有详细的规格文档。

如果说这些质量规格我们都不要,或者说至少不要这么详细、严密,那就是前现代的手工作坊模式。也不是说不行,毕竟那么多前店后厂的路边摊生存的也挺滋润。关键是,我们选择走哪一条路?

公示和执行

详细包含具体要求和测量的质量规格,如果不能有效的一体执行,依然是一纸空文。质量规格要像法律法规一样,在由质量组织(立法部门)制订后,要由最高权威(主席令、国务院令)背书发布。当规格因故需要变更时,也需要同样的流程修正发布。

除了权威的公示,规格还需要有实权机构执行过程中的采认和背书。比如某项国家标准、某国际标准,甚至某工业组织制订的事实标准,之所以权威,是因为有国家海关、国家质检、大公司采购验收等等实权部门在使用该规格标准。

除了规格由权威部门发布,由实权部门采认以外,测量方法、测量工具及测量精度等具体的测量手段也是要公示的,起码要在一定范围内的检验者和被检验者达成共识。

质疑

宏观场景和微观场景

我们不可能去质疑一个存在已久的,而且运转良好的现实。我们网购3C产品,只要看看详情页上的规格说明,就可以无脑下单,而不必担心货不对板。我们花几千块买一辆七手夏利,定期做保养维护,就敢开着上高速,而不会担心车子会出P0故障。我们在晚上开车跑高速,连个路灯都没有,完全不会担心前车突然抛锚被我们怼上,也不会担心前面路况异常发生事故。这些都是书中的质量观念,在各行各业的工业化场景下的大规模使用。我们所有人都受益于此。

在工业化的大测量尺度上,我们的观点没有分歧,但是在不能被工业化的领域、在微观尺度上不免就会有些分歧。之所以对书中质量观点的普遍性、真理性提出质疑,是源于日常工作中的观察和思考,尤其是日常开发工作及开发的团队管理、项目管理这些超微观的尺度。

工业化程度是需求导向的,没有足够的需求规模就无法支撑足够细致、严谨的质量规格。世界上最大电机的线圈是人工缠的,中国第一颗原子弹和铀心也是人工车的。在做这些工作的时候,没有自身的质量规格,只能参考既有的相对接近的质量规格。

没有质量规格的人工介入,在大规模工业化场景是很少的,可能只涉及到顶级生产。但是在软件开发,尤其是互联网软件开发领域,则非常普遍。一项棘手的工作,首先会有高阶工程师承接,一旦有了一些眉目,可以梳理出一个工作要求列表,就会迅速交接到低阶工程师手上执行。如果要求可以量化,可以测量,则又迅速会由软件程序自动化完成。

事情确实在从混沌状态到有质量规格确定的确定性状态流转,但是开发工程师承接工作的性质永远雷同。这种劳动力中不能被工业化的前现代要素,除了在软件开发,在艺术创作、思想生产的领域也都很常见。

什么是对?

第一次就把事情做对。这个理念是没有人质疑的。什么叫做对,却会不断被质疑。在这个地方对的,换个地方就可能不对。在这个时期对的,到了另一个时期可能就不对。

不管是总结过去成功的经验,还是总结过去失败的教训,或者有先进的理论体系指导,对下一步决策都只能是提供参考,并不能保证未来的完全正确。什么叫做对,并没有绝对值。

我们可以说,经得起实证检验的是对。如果事后检验,对错已经过去,对下一步决策无决定性意义。如果是事前检验,检验的理论依据和方法本身也需要被检验,就会产生无穷后退的问题。

一般来说,过去的成功可能有争议,但是对过去的失败比较容易达成共识。如果下一步决策能修正过去失败的错误原因,那么我们就可以假定决策是对的。这个方法可能是一个判定下一步决策对错的捷径。

非常遗憾的是,同一个事情,从不同的角度观察,可以得出完全相反的结论。抽象一点。革命失败了,这一点很容易达成共识,因为同志们淌着的鲜血不会说谎。如果能找到革命失败的原因,修正错误,那下一步就是对的。失败的原因是革命不彻底,还是因为革命是错的?这是一个永恒的争议。

常见的一类问题,我们制定了XX流程,执行下来结果令人不满意。那么问题是,这个流程是错的,还是说这个流程的原则没有得到坚持?这个争论模式,会出现在任何一个认真总结经验教训的会上。总而言之,什么是对,本身可能没有唯一解,也可能就是一个无解的问题。

测量的困难

在研发工作的测量中,有些指标测量只适合序数度量,但是为了数理实验传统的分析形式,强制使用了基数度量。比如,工程师的技术水平,比较出上下高低并不难,但是想用一个量化指标去测量,就很困难。

一个工程师技术水平好,工作积极性稍欠。另一个积极性很好,技术水平略逊。结构内的各部分不同质,我们应该怎么测量整体综合指标呢?不只是基数度量存在困难,序数度量后也很难给出综合指标的上下高低。当然在某些特定的时期、特定的环境下,为了因应团队的实际需要,我们可以给某种结构素质模型的工程师打高分,给另一种结构的素质模型打低分。可是并不能因此断言,某种素质模型结构就是优于别一种素质模型。

有些结构化的综合指标,在各部分测量中都正确的使用了基数度量和序数度量,但是计算总指标时把两种度量方式混合计算而失真。序数度量无法加总,更无法与基数度量求和加总。如果乱点鸳鸯谱,强行匹配,就会得出悖于常识的数据结论。

有些测量标的,内容的实质量无法测量到,或很难测量,只能测量到代理量,测量出的指标不能完全说明质量。比如,维生素药片,以片计、以瓶计测量代理量相对容易。以毫克计实际含量,测量起来就会很困难。研发工作中的代理量很像是盲盒福袋,一个盒子里装的东西可能价值5块,别一个可能10块、20块,也有的盒子可能装的是祝你好运。盲盒的价值,以及整体活动的总量价值,只有生产者可能知道,消费者无从知道、无从测量,只能测量到盒子代理量。研发工程师的工作时间就是这种代理量。消费者要求增加维生素片数,生产者就是增加淀粉填料。消费者要求增加盲盒数量、要求增加豆浆碗数,生产者就会兑水,或者缩小盒子、豆浆碗的大小。总之,生产者可以以成本接近于0的方式增加,而实际价值不变。不是说没有其他的机制制衡,或完全无法测量,而是很困难。

有些指标,在不作为考核依据时,是可以说明质量的。一旦成为考核依据,就立即失效。像代码行数、BUG数、工作时长、IM沟通次数,等等都是这类指标。如果不作为考核依据,拿到数据后分析,其实是可以在某种程度上测量到研发工程师的工作积极性、技术水平和团队重要程度的,很像是被动雷达的观察。如果作为考核依据,尤其是作为质量规格的关键部分正式公示,这些测量本身就携带了巨大能量。就像普朗克尺度上用于测量的粒子束一样,薛定谔的测不准量子效应就出现了。

质量的成本

按下葫芦起来瓢,质量免费的概念只是一种方程式的等价变换。我们把方程右边东西转移到左边,结果肯定等于零,左边移到右边也一样。但是问题的本质并没有发生改变。我们可以假定葫芦被按下,但是不能同时假定瓢不起来。

质量是有成本的,比如背景成本和测量成本。假定质量成本等于零,作为理论推理分析的前提有效,也是可靠的。但是在实操中也作这种假定,就会碰钉子。

背景成本包括材料、工艺、劳动力的背景成本。如果工作是造创性的,满足质量规格要求的材料,就不可能是完全免费的。只有在成熟的领域,可以不断重复的工作,才可能在市场上选购材料。只有符合质量要求和非质量的材料采购成本相等,那么质量才是免费的。工艺和劳动力的背景也是一样,只有在一个规模化重复的工业场景中,质量才是免费的。而软件和互联网应用的研发,更像是前现代的手工行业,并不属于这种场景。

测量成本包括规格蓝图的成本、测量工具的成本、测量精度的成本。在企业无界论中,测量成本即交易费用,决定了企业的边界,即市场化的规模。假定测量成本等于零,所有的经济活动都将是市场化的,就没有企业的形式存在。假定测量成本无穷大,所有的经济活动都将是企业活动,市场就没有存在空间。

价值判断的逆转条件

质量的成本在变,非质量的成本在变,双方角力的比值也在变。这种变化过了某个一个临界点,价值判断就会发生逆转。在比值小于1,趋近于0时,质量免费的理念就趋近于真理。在比值大于1,趋向于无穷大的时候,略有所获。萝卜快了不洗泥,快速迭代,快速上线就会成为管理思想的主流。

我经历过摩托车行业的这种临界转折。在转折之前,打开包装箱,摩托车没有车头都会被抢购。经销商大不了找相应的配件,再补充装配一下。在这种环境中,如果不积极略地,收割丰厚的利润,因循于严谨的质量管理,就会首先被淘汰掉。很多正规的国企大厂,就是因此出局的。当时对市场占有率有个重要观点,叫做让利不让地。利润丰厚的很,大不了折价卖出去,市场份额不能让。

在转折后,同样的厂子,同样的供应链体系,因为油门线的铅头略小,或油门把手缺口略大,总之不符合蓝图规格的测量要求,最新款的摩托车堆满了车间和库房,供应链欠款急剧增加。没有质量达标的产品出厂,市场回款大幅缩水,没有资源要求供应链提供符合质量要求配套。如此恶性循环,一个上世纪九十年代包税上千万的摩托车厂子,被市场错车将军扼杀掉。

三十年河东三十年河西,不能以前三十年否定后三十年,也不能以后三十年否定前三十年。不拘泥教条,不因循守旧,能够妥善应对这种临界转折,需要大智慧,需要对事物有本质的理解。

我们是否还信仰进化论?

还有一处逻辑硬伤不容易辩驳。质量免费一书中的理念、观点、体系大约诞生于上世纪五、六十年代。不管是当时,还是以后的工业界辉煌成果,都为这些观点作了脚注和证明,毕竟那是一个人类登上月球的时代。在上世纪七十年代,软件作为独立领域出现后,在九十年代互联网应用兴起后,工业界作出的第一个选择就是引入和采纳这些质量理念。事实上也是如此,软件工程的瀑布模式就是这一理念。后来出现的敏捷也好,迭代也罢,都是对这一理念的修正和否定。软件和互联网的工程质量理念,经过了三几十年的发展,不是说不能否定,但是直接拿过五、六十年代的理念来否定他肯定是不行的。

你可能感兴趣的:(质量免费笔记)