什么是检查列表(checklist)？

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

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

检查列表有什么标准?

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

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

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

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

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

检查列表何去何从?

一般的情况是这样的。

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

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

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

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