今天想要分享的内容是关于“清单”的，灵感是来自于《清单革命》这本书，书中主要描写作者通过努力将清单应用于外科手术的场景中，从而提升手术的安全性， 降低事故率。然而其清单思想能够应用的领域远远不止于此，对于产品经理来说，清单思维同样重要，也能够帮助我们在产品工作中进行提升。

    刚好借这个机会，聊聊读书感悟以及对产品工作的启发。

    作者首先引出了一组概念，将人类会犯的错误分成了“无知之错”和“无能之错”。

    所谓“无知之错”比较好理解，不掌握某方面的技能，这事儿不会干，必然有可能出错。但这种情况还属于可理解的范畴内，毕竟“不知者无罪”嘛，并且这类的问题很好规避，因为“不会干”是很容易发现的，被发现了就可以提前预防和控制，减少损失。

    另外一种情况就不乐观了。“无能之错”，什么是无能之错呢？本来掌握着相应的技能，但在实践的过程中没有能够正确的使用技能。说白了就是，粗心了。“粗心”这个词，通常会在我们小的时候被用到，平时做的挺好的题，考试的时候做错了，我们会说：粗心了。从而会认为不是实力不济，而是运气不好。这种观点是时候调整了。能够将自己掌握的知识正确的运用到实践当中不仅不是运气，反而是实力的重要组成部分。而这种情况，就是我们要讨论的“无能之错”。更进一步来分析，出现无能之错的原因远远不止一种。之所以会“粗心”，基本是因为过度自信，因为对于流程、操作的熟悉程度，让我们相信一定不会有问题，从而忽略了对流程的遵守和对行动的谨慎。在此之外，还有可能是突发状况的影响，类似于作者在书中提到的，手术过程中往往会出现突发情况，当急于处理突发状况时，平常熟练的动作有可能就会被忘记。还有面临巨大压力的时候，也会造成类似的后果。

    如果说“无知之错”尚可预防和原谅的话，那么“无能之错”其实是一种不可原谅的过错。那么怎么来解决这个问题呢？一个“清单”的概念被引入进来。

建立清单思维——坦白承认我们的不足

清单的概念

    清单的概念其实已经诞生很久了，最早是出现在飞机工业中，随着技术的突飞猛进，人们发现，即使最优秀、最熟练的飞行员，也已经难以凭借经验来操纵复杂的飞行系统了，他们在操作飞机的过程中，会出现这样或那样的失误，漏掉一些关键动作。这在以前是完全没有出现过的情况。正是由于系统变得越来越复杂，需要人们记忆的流程越来越长，同时要关注的点越来越多，从而产生了“无能之错”。要知道，在飞行的过程中任何一种失误都有可能造成巨大的灾难，这种问题必须立即得到解决。

    面对这种情况，飞行员们开始寻找一种方法，帮助他们检查必要的动作及流程是否完成。于是，飞行工作被划分为几个阶段，并且在进入每一个新的阶段时，停下来检查上一阶段的必要动作是否都已经做完。例如，起飞前-沟通飞行计划，检查各种仪表设备，检查应急方案。降落前-检查起落架是否已就位，核对复飞计划等等。

    我无意去研究详细的飞行操作清单，但这种思路可以被我们借鉴来使用。

    使用清单之前，我们需要先做一些心理上的调整和准备，这个前提就是你得“愿意”使用清单。

    很多人基于自己对流程的熟悉，或者基于丰富的经验，而对外界辅助工具产生抵触心理。类似的情况并不止体现在对于“清单”的态度。实际上我们能够体会到的是，恰当的使用工具进行辅助，是提升效率和质量的很好的办法。我们能够从很多成功的案例中看到合理使用工具的显著效果。但就算是这样，很多人还是会抱怨工具的引入会改变原有的操作习惯和流程。从产品工作的实践中我们也能找到很多例证，例如SWOT分析能够帮助我们厘清项目的优劣势及市场竞争情况；PRD能够帮助我们梳理和固化需求内容，供多方参照；项目进度管理表格，可以帮助我们了解我们所要完成的全部任务以及当前进展。从整体而言，花时间来学习、使用这些工具，并在事情开始前做好相应的准备工作，是相当值得的，所谓“磨刀不误砍柴工”嘛。

    我们还能够发现清单的另一个作用，就是帮助我们保持理智。实际上由于人类情感和情绪的存在，始终保持理智是比较困难的一件事情，我们常听到“屋漏偏风连阴雨”这句话，这里一部分是外因，另一部分是内因，人们在消极情绪或焦急状态下所作出的判断和响应，往往会偏离自己的理智，导致判断失误和动作变形，从而带来另一个负面影响。借助清单工具，可以让人们暂时剥离情绪的影响，而执行正确的操作和动作。从而帮助我们在紧要关头做出更为理智的判断。

    我们再回归到工具本身，从上面的例子我们可以看出，一张清单，应当包含两部分，第一是关键节点，第二是关键动作。

    首先需要确定在一个完整的流程里，有哪些节点是必须要停下来进行检查的。一般来说，这样的节点是两个阶段操作的分割点。例如飞行操作的起飞前、降落前；手术中的开刀前、缝合前、送病人离开手术室前，都是关键的系统节点，可以在这些节点上停下来检查必要的动作是否已经完成。

    回归到产品工作中，一个项目的策划方案公布前、研发工作开始前、上线前等等，也都是非常重要的节点，这个会在后面详细来探讨。

    另外一件事情就是要选择确定每个关键节点，停下来之后我们要做什么。不同的行业，不同的场景，不同的团队，其内容也都会有所不同。后面我们也会具体来讨论什么事情应该放入清单。

你需要什么样的清单

    从清单的使用场景来看，可以大致分成两类，一类是“边做边看”型的清单，另一类是“做完确认”型的清单。

    不同的清单类型，其应用场景也会不太相同。

    “边做边看”型的清单，其效果更加类似于工作指导或操作手册，但又不像操作手册那样大而全。更多的时候可以用来在突发情况下指导人们的行为。当我们遇到突发事件或者面临巨大压力时，往往外界的影响因素会对我们的判断和决策产生影响，这个时候，清单就会起到两种作用：一是像前面提到过的那样，在突发情况面前帮助我们进行理性思考；二是让我们可以不再去思考流程和行动，不需要再去重新考虑我应该做什么，而是将节省出来的精力集中的关注在事情本身，以得到最好的响应和结果。

    “做完确认”型的清单则具有不同的特点，他的作用更多的是在我们即将进入下一环节或下一阶段的时候，帮助我们来检查所有必要的操作是否都已经完成。这类的清单能够帮助我们确认关键事项，帮助我们检查是否有遗漏，从而确保在进入下一环节之前的操作和流程是完备且正确的。起到的效果更多的是备忘作用。

哪些事情应当被列入清单

    清单中所列的内容不应该是全部的流程，毕竟构建清单的目的并不是建立另一套操作手册。

    我们列入清单的行为一定是那些关键的且容易被忽略的动作。清单是提醒我们关键事项的辅助工具，我们所熟悉的流程还是那个流程，我们该做的事情还是那么多，该思考的也还是那么多。

    由此可见，确定哪些事情应当放入清单，实际上是一个需要反复推敲的过程，并且其前提是我们要对整体流程有完整且深入的了解。清单不是一个拍脑袋来决定的事情，但是也不要担心，清单也不是一成不变的，应当被不断地试错和优化。

    从整体上讲，这里有三个原则帮助大家建立清单：简洁，高效，可测试。

    简洁。清单上的每个检查项或者每个动作描述，语言应当是简洁的。整体清单来看，长度不宜过长，最好不要超过20项，否则就会变成累赘而不能起到提升效率的作用。整体风格也应当以简洁为标准。

    高效。我们罗列到清单上的动作或检查项，应当全部都是可以高效执行的动作，这就要求我们把动作进行适当的拆分，不能将一个复杂操作直接列为清单的一项。

    可测试。这里指的是清单所列的内容必须是可以进行结果验收的，也就是清单的效果必须是收敛的而不能是开放的。一个开放的结果并不能够帮助我们进行动作校验或者指导。

清单的层级

    清单只是指导实际操作的一些步骤或流程么？这就想的太简单了！实际上，在我们接触到的项目或者工作中，往往不是单纯的把一系列动作集成到一起就能够完成的。当我们需要处理复杂或者大型项目时，往往需要把整体工作按照不同的层级进行拆分。在每一个层级上，都需要有相应的清单来进行辅助，同样的，每个清单都有它的推动者来负责清单的应用。

    以我们产品实际工作来举例，最高的清单层级，会用来记录部门之间的合作或流程，比如说什么时候应该和什么部门开会，有哪些问题必须在某个节点和某部门进行确认等等。再往下一层可能是部门内部各个小组之间的合作，例如A组，B组，C组分别负责不同工作的落地实施，那么在哪些节点必须要进行组间信息同步，是否需要各小组间的评审等等。再往下可能就是具体实施层面的清单，例如某个员工的工作检查清单。

    如此，我们就将一个项目的清单分为了3个层级，每一个清单工作在自己的位置上，为整体项目的推进发挥着作用。

    实际上，这是一个值得我们借鉴的项目管理思路。产品经理在参与项目管理和推动相关工作的时候，也需要将自己的思考划分为不同的层级，自顶向下拆分工作，并且明确每一个层级上的干系人、目标和计划等等。

    产品经理的项目管理职能是一个很大的话题，完全值得单独花篇幅来详细探讨，这个后续有机会再详细讨论。

构建自己的清单——产品工作中的清单

         说了这么多清单本身的概念，下面我们来研究一下，清单这个工具怎么在产品工作中发挥效用。

         产品经理的工作，在平常的时间里很少会面临紧急时间或突发故障，更多的时候我们都是在按部就班的进行我们的工作，这种情况下，我们更加适用的是“做完确认”类型的清单，在关键的节点中提醒我们关键动作是否已经做完。

         我以一个项目从策划到落地的这个过程为例，来拟定一个产品工作清单。

         首先完成第一步工作，确定产品工作流程中，有哪几个节点需要停下来进行检查。

         以需求方发起的项目为例，我们的需求方可能是业务运营部门，或者是市场推广部门、销售部门等等，当然也有很多的需求是产品部门直接发起的，需求汇总至产品经理后，根据排期形成项目组，项目组成立后，产品经理会对需求进行过滤整理并形成产品方案（输出物可能包括PRD、流程图、架构图、系统交互图等等），方案经各方确认后，可进入研发阶段。功能研发完成后即可开始测试（无论是整体测试或按模块进行快速迭代），测试完成后即发布上线。上线后还要做线上回归等工作。

         从工作流出发，我们可以确认几个关键节点作为行动检查点。以下我列举几个简单的例子来说明检查点和清单事项怎么拟定。

         检查节点一：产品方案开始整理之前

         检查事项：

        →项目组内成员及相关干系人已明确

        →业务背景及场景说明，已不存在疑问点

        →如有不能实现或本期暂不实现的功能，已做说明

        →原始需求中不合理的事项已指出

        →产品经理工作时间预期已告知

         检查节点二：项目方案最终定稿前

         检查事项：

        →整体方案已由需求方确认无误

        →项目干系人都已知悉方案

        →项目成本评估已发送给各干系人并已获得确认

        →对方案整体效果和预期已进行说明，关键事项已进行解释

        →后续流程已说明

         检查节点三：项目上线前

         检查事项：

        →所有功能联调测试已通过

        →与产品方案不一致的点产品经理全部知悉并已经过确认

        →与原始需求不一致的点需求方已经全部知悉并已经过确认

        →上线失败的应急方案已经过组内确认

         以上是几个确认清单的例子，下来我们再看看应急事项操作清单。

         紧急事项一：上线出现问题，需对代码进行回滚

         操作事项：

        →操作代码回滚

        →验证回滚后线上是否运行正常

        →收集线上问题影响范围、流量及持续时间

        →定位问题

        →输出问题总结报告

        →拟定解决方案

        →制定下一次上线计划

构建用户的清单——使用你产品的人也会产生“无能之错”

         所有我们之前聊的事情，都是“清单”这个工具怎么在我们的日常工作中发挥效用，我们一直在考虑产品经理用好清单工具能够给自己的工作带来多少提升。而实际上“无能之错”并不止出现在我们这些“幕后工作者”的工作日常当中，使用我们产品的用户，在使用过程中也会遇到这样或那样的问题。

         在互联网和智能设备如此普及的今天，我们的用户出现“无知之错”的情况会越来越少，当然，降低用户的使用和学习成本也是产品经理的重要思考方向之一，我们也应该尽力去减少用户“无知之错”出现的场景，毕竟，人家不会用我们的产品，并不代表我们是正确的，相反是我们的错误。

         而用户出现的“无能之错”，基本可以理解为我们平常所说的“异常处理”。也就是在功能全部正常的情况下，我们也会遇到很多情况能够导致预期之外的响应。当这种情况出现的时候，用户感知到的是疑惑、压力和烦躁。与此同时，用户所需要的，正是一个帮助他解决这个困境的“边做边看”型的清单。

         回想一下，在你使用产品的过程中有没有遇到过这样的提示，比如说输错了密码，这个时候会产生一种焦虑感，因为现在人的密码实在是太多了，除非一个密码走天下，否则你总要想一想，甚至有些情况下，你是凭借肌肉记忆在输入密码，你根本想不起来刚才输的是哪个密码。

         我们看看目前的产品会给我们怎样的提示呢？

         “密码错误超过3次账户将锁定。已输错1次。”

         你一定遇到过这样的提示吧，这种提示除了给人带来压力、增加下一次输错的可能性之外，还有什么意义么？这就是不友好的产品设计。

         我们来看看比较好的设计会是什么样呢，“这个密码你在3个月前使用过，但现在的密码不是这个”“是否忘记了密码？可以试试以下操作。。。”

         再来看一个例子，我们经常需要上传图片或者附件，那么如果图片或附件超出限制，我们应该怎样提示呢？我们经常会遇到的是一个大大的错误提示，然后就没有然后了。可能有的产品会多做一点，扔出来一个“帮助链接”。实际上在这种情况下，我们用户所需要的可能只是一个操作建议，帮助他来排查并解决问题。一个小小的清单就能够帮助用户获得更加的使用体验。

         所以，往往用户在“异常流程”里，需要的是指导和减压，简单的抛给他一个“帮助”链接设置于向用户进行威胁，都不是一种好的产品设计。

         结合到我们工作当中也是一样，无论是新用户指导，还是异常流程处理，或者是功能升级通知，我们都应该考虑到用户在面临新事物、不知所措甚至面临压力时，我们应当怎样去帮助他，毕竟与用户直接沟通的并不是我们而是我们的产品。当然，“沟通”的事情完全可以独立来开篇讨论了，这里只是提醒大家，时刻要提醒自己注重产品设计的思路。而在这个方向上，清单的应用也可以帮助我们的产品更好的服务于用户。

如何推广清单——教会我们如何推进项目

         《清单革命》书中除了介绍清单的概念和作用，还描述了将“清单”工具推广至全球的过程，作者作为一名医生以及减少手术伤害的研究者，应世卫组织的邀请，将医疗手术清单工具推广至全球使用，首先开始的是一个实验项目，在项目中除了要拟定手术清单外，还需要将清单推广至选定的实验医院，并且观察和收集实验效果。

         我们可能会比较少有机会参与全球规模的项目，但是从作者的故事中，我们可以学习大型项目的推进方法。

先期调研很重要

         说到调研这个问题，好像这个词会被很多产品经理经常挂在嘴边，但是真正的在一件事情开始前做好调研，做到深入调研的产品经理并不多。在我日常工作当中接触到的例子来看，大部分产品经理只是简单的把和业务聊需求、从需求方那里收集信息，或者从网上找一些相关资料就当作是调研过程的完成。实际上这是很欠缺的。

         在书中，作者提到他们在项目开始前，针对全球范围内的医院进行了详尽的调研。他们先将全球的医院根据其所处地区的发展情况划分成几类，包括发达地区、欠发达地区、新兴国家、落后地区等等。

         然后，从中挑选了一些医院进行实地考察，所谓的实地考察，是真正的进驻到这些医院的手术室中，对手术的情况进行记录并对手术后并发症及恢复情况进行跟踪。

         之后，将所有数据汇总起来进行分析，并由此总结得出目前的现状以及“最需要的清单”。

         回归到产品工作，我们在日常工作中收到需求或者发现需求后，我们有没有进行如此详细周密的调研呢？

         可能有的同学会说，有的事情要得急、时间紧，根本没有足够的时间去做详尽的调研，更别提花上几个月的时间去实地观察、形成详尽的数据报告了。固然有现实的限制，时间永远都会是我们最重要的资源之一，而我们需要理解的是资源总是有限的，优秀的产品经理要做的就是如何在有限的资源下获得最大的产出。

         我们在调研的时候，合理的使用工具获得最重要的资讯才是关键。这里不妨也借用清单这个工具，给大家一些提示。

         项目调研清单：

        →当前项目所处行业背景已了解

        →行业内竞品动向已掌握

        →在市场背景下，当前项目定位已清晰

        →用户群特征及需求痛点已掌握

        →用户现状已掌握

        →数据已经过分析并形成结论

        →新项目效果的衡量标准已制定

制定完整计划

         很多同事喜欢上来就动手，热情指的肯定但这种方法并不值得提倡。

         一个项目开始前，需要有一个完整的计划，花时间制定计划将会帮助后面的进行变得更加顺利。

         制定计划的过程，就是对方案的一次推演和论证。在此过程中，我们可以对项目进行过程中发生的重大节点有一个预知，并且可以根据这些节点整理形成节点检查清单，另外，通过对项目的推演还可以掌握有可能存在的意外情况，根据这些情况我们可以提前指定应急操作清单，这些清单将会在后面的项目进程中发挥重要的作用。

         与此同时，完整计划带来的是明确的时间节点，这也是帮助我们进行项目推进和跟踪的重要工具。

         另外，一个“完整”的计划不仅应当包括如何实施的问题，还应该包含如何进行效果验收和结果校验的计划。

输出方案并进行方案论证，允许调整空间的存在

         项目计划制定完毕后就要开始依计划而执行了，第一步就是整理并输出项目方案，并且对这个方案加以论证。

         具体的方案制定和论证的方法不在这里展开讨论，这里项重点聊一聊的是对于执行方案的可变空间的控制。

         在中小型项目中，我们还是有很大的几率能够保证方案被完整的执行贯彻下来，而面临大型项目时，往往会有一客观因素制约方案的执行。以书中的例子来说，同样的一个清单，应用到各个不同国家时，都需要进行调整，有的国家操作顺序会不相同，有的国家因其实际情况，另外的检查项目会更重要等等。

         对于产品经理来说，合理的评估和控制项目的可变空间是一门学问，既是经验的积累，也是一种变通能力的体现。

         当我们需要制定和评估可变空间时，可以参考下面的清单，看看是否做足评估了功课。

         项目方案的可变空间检查：

        →各干系人及需求方对可变空间已知晓

        →可变空间对整体项目目标的实施有无影响

        →可变空间对项目整体时间计划有无影响

        →是否涉及到研发资源调整

        →处理方式确认：临时可变、删减、暂缓（到下一期实现）

项目推进

         我们可能会经常遇到项目的推进过程中的一些难题，比如推进上的困难，干系人配合度较低，意外事件影响项目进程等等。

         面临这种情况的时候我们应该怎么办呢？

         首先要保持良好的心态和鉴定的信念。大型项目涉及的人员多，推进周期长，出现困难是正常的，相反而言当你面临大型项目但是有感觉一帆风顺时，恰恰有可能是危机即将出现的时候。

         第二，找到问题点，以及问题根源。出现了问题，我们要对问题进行定位，找到问题的原因。是因为信息不同步，或者资源紧张？是因为方案不恰当，或者是对方案的解释不透彻？是对方有更重要的项目在前，还是双方的合作习惯不同？找到问题的原因是解决问题推进项目的关键一步。

         第三，对问题进行评估。找到了问题后，对问题进行一个全面的评估，该问题影响面有多大？紧迫程度有多高？是否会对其他正在进行的工作产生影响？后续有哪些工作会因此中断等等。初步评估后，对于立即需要解决的问题，我们就要来寻求具体的解决方案了。

         第四，寻求针对性的解决方案。这里其实想强调的是“针对性”。我们的脑子里可能有好多解决项目推进问题的方法模型，但哪一种才是这个状态下最适合的，需要我们自己分辨并把它找出来。

         第五，及时实施。找到解决方案后，应当立即将解决方案投入到应用当中。寻求第一时间解决问题。

         你看，经过以上的分析步骤，实际上我们又形成了一个针对于项目推进过程中产生的问题的清单，这个清单是“边做边看”型的清单。具体的清单你可以试着自己来整理。

结果收集

         项目实施后，一个非常重要的习惯就是及时的进行复盘。项目复盘既是对整体效果的验收，也是我们学习和提高的一个重要机会。

         最近在工作中发现许多同学并没有复盘和总结的习惯，我觉着可能有两方面的原因。一方面是还没有形成习惯，其实大家应该把这个事情重视起来，实际上我们的能力和思维，就是在一次又一次的结果校验和总结提炼中获得提升的，否则的话我们会发现做了一个又一个项目，最后我们的能力没有变。第二个原因就是项目开始前，效果验收的计划就没有做好。就像之前我们提到过的那样，一个清单必须是可以验收的，而一个项目开始之前，完整的计划中也应该包含效果验收的部分。如果在开始的时候就没有想到怎么来验收成果，那项目结束后自然就无从开始了。

         说到这里你发现，其实你也可以制作一个清单，来对项目结果收集这个环节进行校验。其实我们能够感觉到，清单这个工具可以应用到很多的场景中，学会灵活的运用一个工具也是我们能力的一部分，而这全都依赖于我们的思考。

结语

         在这里和大家谈了许多关于清单工具的概念和应用，希望大家也能够根据自己的工作情况，建立适合自己的清单，毕竟我们所处的环境不尽相同，我在文中所列举的清单有些可以直接拿来用，更多的则需要靠大家自己来发挥。根据实际情况制定符合实际应用场景的清单，能够帮助我们在工作中减少无谓的失误，达到理想的效果。

         就像我们谈到的项目推进一样，制定了清单只是第一步，更多的是要将我们的清单应用到实践中并且不断地根据实际效果进行优化和调整。

         大家有空也可以读一读《清单革命》这本书，结合到我们的产品工作当中，能获得哪些启示，希望能够拿出来一起交流。