【WT1.1】Janick处理“人为因素”的三个预防&纠正措施

一件事情效率不高，往往是流程和方法出了问题——我曾经的PM说...



====== 前文补充 ======

今天首先把昨天的内容做进一步澄清。我在Janick原图1-4的基础上，添加了“W模型”的概念，与“背靠背模型”进行比较。





通过两张图的比较，你可以发现“W模型”的检查点明显靠前于“背靠背模型”。让检查点靠前的意义是：

1.让较多的问题更早被发现，减少总的修正问题的投入；

2.在项目生命周期中，选择更“优质”的时间，来认真分析系统性问题（需求、架构等）。

我的观点非常明确：推荐“W模型”，摒弃“背靠背模型”。当然，验证工程师相应的，也要做好自己对业务知识理解的积累，这样才能在提早的检查点，更多发挥自己的价值。

====== 正文开始 ======

Janick面对“人为因素”，提出了三个预防&纠正措施：自动化，防误防错（poka-yoke），冗余检验。但在分析这三种措施前，我觉得有必要区分一下“纠正措施”和“预防措施”。

纠正措施。为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。

预防措施。为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。

一般情况下，预防措施较纠正措施，能够获得更大的投入产出比。

=== 自动化 ===

Janick说自动化可以消除人为因素的干扰，相信这句话大家是认同的。

例如，使用可靠的工具（IP）生成的总线设计，就消除了大部分人为设计出错的可能。类似的，各个公司的设计库，应该也会包含ram（单口、双口等），FIFO（同步、异步）等组件。如果一个设计团队，还需要由工程师手动编码完成一个异步FIFO，只能说明该团队的积累相当薄弱。

当然，Janick后面这段话，在自研设计较多的情况下，应该能获得大家的认可，“However, automation is not always possible, especially in processes that are not well-defined and continue to require human ingenuity and creativity, such as hardware design”。

当芯片设计逐步步入到SOC时代，当大部分设计由IP来提供时，人为因素就越来越少了。但原创性的设计依然存在，例如设计实现新的CPU、DSP架构。这条工具链在国内的成熟度还不够。

至于设计之上的设计需求、用户需求，则更会引入“人为因素”，较难采用“自动化”的措施来消除隐患（如果你的团队有优秀的需求管理工具，一定要用起来）。

=== 防误防错（poka-yoke） ===

从这个组合词的发音，你就应该猜出该措施的出处：日本。

日本的质量管理专家、著名的丰田生产体系创建人新乡重夫先生根据其长期从事现场质量改进的丰富经验，首创了poka-yoke的概念，并将其发展成为用以获得零缺陷，最终免除质量检验的工具。

Janick的解释是：“……mistake-proof the human intervention by reducing it to simple, and foolproof steps. Human intervention is needed only to decide on the particular sequence or steps requiredto obtain the desired results”，这么长一段话，就一个意思：将操作行为简化到“傻瓜步骤”。

但是，我并不完全认同Janick的简化理解。的确，将操作简化的确可以减少产生错误的几率。但是，poka-yoke提出的要求是：如果有一种设计方式，能够让人不犯错，会更好。例如USB Type-C接口。

举个硬件设计中的例子：

两个人各自负责紧密相连的上下游模块，如果上下游接口设计理解不一致，就可能导致出错。

一种方式是，在评审规范中明确，上下游接口的设计人员应互为评审员。该规定明确了评审的人员配备，形成了一套可行的流程。一定程度上，简化了评审组织的流程，降低了评审失效的风险。

另一种方式，仅仅输出一份独立的接口文档，上下游的设计工程师都以该文档为准。如果后续再出任何问题，统一由该文档的定义，判断责任方。这种方式就比仅仅定义评审人员能获得更多的投入产出比。

poka-yoke方法的精髓是想尽办法，减少错误发生的概率，仅仅停留在“简化步骤”是不够的。

由于对于poka-yoke的理解不够深刻，Janick在应用该方法时，有些略显无奈：“However, just like automation, it requires a well-defined process with standard transformation steps. The verification process remains an art that, to this day, does not lend itself to fool-proof steps”。

毕竟，Janick的结论提出在十年前，在SOC流程逐步优化固化的今天，我觉得该方法应该还是有许多用武之地的。

=== 冗余检验 ===

在资源（人力，财力）支持的情况下，多一个团队用不同的方式对结果再做一遍检验是再好不过的。比如，某个团队（例如系统测试团队）使用黑盒的方式，搭建全系统环境，对设计进行检查，的确能够提高设计的质量。而且，在系统级，能够发现一些验证环境不容易发现的问题。

但是，我不认为验证团队应该采用“背靠背模型”，原因我在本章开头也再次重申了。

验证团队，还是应该尽量将问题发现在早期，冗余检验工作，应由其它团队来完成。

=== 总结 ===

“自动化措施”更接近预防措施；

“防误防错措施”既包括预防，也包括纠正，目标是“零缺陷”，更倾向于预防；

“冗余检验措施”更倾向于纠正措施。

基于之前的论述，预防措施的投入产出比一般高于纠正措施，在资源有限的情况下，更应关注哪些措施就不言自明了。

对于以上措施的实施，还有一个前提：对已有发现的问题进行“根因分析”，通过案例，不断优化和丰富我们的“预防措施”和“纠正措施”，积累“组织过程资产（详见“拍马屁Pmbok”）”。

本文举的例子，都是设计工程师的例子。当然，验证工程师的例子也类似，例如多使用VIP，多积累UVC。在涉及到验证平台集成时，也可以规划好文档结构，目录结构，让集成减少或消除出错的可能性等等。如果大家还有什么好的想法，可以分享出来，如果留言和群讨论区的内容比较丰富，我打算将这部分信息集合为一篇文章，方便大家在项目中使用。本文只是提供了一个思路，抛砖引玉罢了。

本文为原创，欢迎转载。转载时请注明出处：公众号“IC验证工程师”

欢迎加入“IC验证工程师交流群”一起讨论。可由现有群成员加入，或添加群主吴杉的微信birdshanshan（请注明加入IC验证工程师交流群），由他将您加入交流群。

    关注 IC验证工程师