对检查列表的一点看法

什么是检查列表(checklist)?

我们一个项目告一段落之后,通常会有一些知识沉淀。这些沉淀的意义在于同类型项目具备哪些指导意义,在后续做同类型工作的时候,提前发现一些问题。

其中有一个常见的措施就是检查列表(checklist),对着列表一项项,不容易遗漏重要问题,可以及时排查隐患。

检查列表有什么标准?

在最近的xx化项目里面,检查列表同样也是很有必要的。首先它是一系列项目工程的改造,具备一定的共性,另外大家普遍对相关技术比较陌生,工作开展很容易只依赖某些人的经验。

我们检查了对应项目的检查列表,发现实际的指导意义不高。简单的说,就是看了也没什么用,不知怎么下手。

后来我们意识到这其实是一个普遍现象。

我们认为检查列表的核心是可操作性。这和规范的作用是有些差异的,规范是说我为什么要做这个,不做这个会有什么问题,什么才是正确的做法。但在实操过程中,我需要理解,这个东西我怎么去检查,检查标准,检查步骤是不是明确的。还有更进一步的是,检查列表也要适当关注检查效率,检查步骤是否工具化,还是说只能单靠人力。

让我们想想,假设我是一个新人,当我拿到检查列表的时候,对我的知识背景有什么要求,能不能帮助我开展工作,我按照这个检查列表去操作的时候,结果是不是可信的?

检查列表何去何从?

图例1

一般的情况是这样的。

我们会遇到各种各样的问题,在解决问题的过程中,逐渐发现某些问题存在共性,我们把这部分问题以规范、设计准则的方式固化下来,作为后续开展同类型工作的标准。但规范可能是比较详细的,方方面面都照顾了一下,在实际操作中不容易抓住重点,容易遗漏。我们再对规范中的要点进行提取,针对步骤、结果进行实例化,甚至进一步提炼检查工具,形成检查列表,希望可以更多更快的提前发现问题。

按照这个先后顺序,肯定是已经遇过问题,并且有意识的总结过。实际也是有的,只是存在某个人的脑子里边。如何形成知识管理,靠自觉是不大行的,主要靠督促,我的做法比较暴力,我看到某同学在处理某个问题,有思路解决之后,我会要求把输出成文档总结,对配合性比较好的同学,我还会对内容有更多要求。输出之后,再广而告之。

我们可以看到,一些特定领域的规范,已经可以直接跳过检查列表,完全的工具化。例如代码静态检查的findbugs、checkstyle之类,例如阿里的java规范,也可以通过pmd形成工具落地。例如安全相关的规范,也有一些检查工具。但大多数的场景,还是没有办法工具化的,或者部分工具化,我们更专注的是,如何才能更容易操作。

例如,我们发现更换环境可能存在网络放通问题。那检查列表可能就有一项检查网络放通,但要点肯定是知道有哪些地址需要放通。的确,这不直观,怎么提升可操作性呢? 可以先从单纯的思路开始,我们可以说,收集各个外围平台(从设计、测试、运维的角度来收集)。也可以说,根据代码中的相关代码来分析(例如网络访问的api等关键字),反推访问的地址。其中第二点是可能实例化的。虽然没法工具化,但这样是不是更好一点?