清单可以帮助你记住处理复杂工作的方法，在很多事情中整理优先顺序，不要漏掉重要的工作环节，促进团队合作。
我们拥有的知识数量和复杂性超出了个人正确、安全、稳定地发挥其效果的能力范围。 知识确实拯救了我们，但让我们不堪重负。 我们需要开展伟大的变革以防止错误和失败。 这种变革立足于现有的经验，既可以充分利用我们所拥有的知识，又可以弥补人类不可避免的缺陷和不足。
这个变革并不困难，非常简单，特别是对于花了很多年培养和磨练高级技术的专家来说，投身于这个变革是令人发笑的。 这场变革是列表革命！
—— 《清单革命》
作为产品一员，每天的工作非常繁琐琐碎。 处理需求、制定计划和逻辑、输出需求文档、协调各方面的资源、推动需求按时上线、产品培训和使用说明、数据分析、用户调查、竞争产品调查、行业了解、项目管理、产品迭代
下面以项目为例，说明项目从无到在线的经历过程。
许多类型的工作对产品经理的能力要求也各不相同。 在日常工作中，除了上述工作内容外，还经常会被各种琐事“打扰”，暂时搁置手头的工作。
在这种背景下，产品经理要想比较完美地处理日常工作，除了各种维度的能力外，还必须在各种场合灵活准确地使用应对能力进行处理，不要忘记所有的工作和步骤。
无可奈何的“理想丰满，现实粗犷。 ”
由于人类的认知缺陷和有限的记忆力，在每天的工作中面对很多繁杂的工作内容，在中途被“打扰”的场面中，难免会忘记一些步骤和工作。 我说我忘记的这些步骤和工作很可能是对产品产生致命影响的极少数，刺激不刺激！
我们不能解决吗？
当然有！
只要有一张清单，真的有一张清单，就能解决上述问题！ (是否脑海中浮现出了那个经典的广告语)如果是998的话，真的是998的话，以上的商品会全部带回家！ hhhhh )
清单为我们提供了认知防护网，不仅可以抓住所有人生所拥有的认知缺陷，例如记忆不完整和注意力不集中，还可以提醒我们不要忘记必要的步骤，让操作者明白该做什么。 这不仅是检查方法，也是保障高效高质量完成工作的法宝。
下图是本文的中心内容。
详细说明清单上记载的内容。
产品经理自检清单V1.0—详细说明
项目环节
1)获得需求在获取需求时，首先要全面、充分地利用获取用户需求的各种途径，其次在获取需求阶段尽量不排斥任何人的需求，区分需求、身份和动机，在之后的需求分析阶段充分考虑它们。
2 )需求分析
在需求分析时，首先要结合自己对业务的理解，从用户的角度，判断需求是否合理，然后要结合业务的现状和未来的计划，判断需求是否真的有必要，最后，要结合需求反馈者和业务现状，这才是需求的重要
3 )需求确认
在确认需求时，结合业务现状、开发资源、业务端实际需求情况等因素，评价所选需求是否是需求池中最重要、最紧急的。
4 )计划设计
慢慢想快点实行。
设计方案之前一定要全面深入地考虑，尽早磨刀，全面深入地考虑之后再开始设计方案。 在设计方案的过程中，要本着“注重结果”的原则，出结果后追求完美，出初版方案后不断优化。
5 )要件书
叙述概要之后再具体说明。
在输出需求文件时，首先概要介绍本次项目的背景、目标以及相关的需求点和影响面，使参加者对本次项目有全面的认识。 然后详细介绍具体的需求实现细节，保证文档简洁易懂。
输出文档后，自己反复仔细阅读多次，确认是否有遗漏、逻辑上是否有漏洞，然后对文档进行优化。 修改文档时一定要有修改记录。 如果您对要求书感到满意，并且需要UI或其他帮助，请确保您的帮助资源已准备好。
如果产品功能复杂，还需要着手准备产品的使用方法和培训资料。
6 )立案审查
立项评审前，先通盘应考虑此次项目是否涉及产品其他模块或其他部门的支持，必要时应事先向各方同步信息。 在拉会进行立案审查之前，最好先和相关人员事先打声招呼，定好时间，然后按约定的时间定好会议室，发出会议邀请函，拉个项目组，在会议开始前集体提醒大家。
立项评审的主要目的是与相关人员初步简要评审后进行的项目，大家从各自的角度评价项目的可行性。
立案审查合格的情况下，为了确保项目的继承人，需要在会议上决定各终端的负责人和需求审查时间
作能够更好地开展。在立项会议上要确认项目是否需要进行灰度测试，以及是否需要市场及运营部门协助进行运营推广，如有需要，应当提前做好相应准备。7）内部评审
内部评审的主要目的是：提升方案和需求文档的质量。
同行从不同的角度来对方案和文档进行检查评估能够更好地发现问题，在此基础上再对项目方案和需求文档进行迭代优化，从而使得方案和需求文档更加完善。
8）需求评审
需求评审是一个项目的生命周期中较为重要的环节，此环节需要产品经理通过需求文档和讲述的方式，让项目相关成员能够对此次需求有一个完整的清晰的了解，只有在清晰了解了需求的基础上，才能将需求实现地更好。
根据立项评审上定好的需求评审时间，给项目成员提前发好会议邀请并在会议快开始时提醒大家。会议过程中，产品经理要详细地向各位项目成员介绍需求，根据文档的每个模块讲完之后用几分钟作为QA环节，加深项目成员对需求的了解程度，在会议结尾要确定好技术评审的时间。
9）技术评审
技术评审的主要目的是项目开发成员从技术的角度，对此次项目的影响面以及实现细节进行讨论评估，给出各自需要的开发时间，而后汇总得到项目的排期。
在得到排期之后要跟预期做比较，如果远超出了预期时间，则需要再次评审，通过增加人员等方式缩短周期，尽量达到预期。一般情况下，如果项目周期超过一个月，则需要将项目分期进行开发上线。
10）开发过程
项目进入开发过程后，产品经理需要着重关注项目开发进度是否正常。对于较大的项目，要结合项目周期适时拉着项目成员，通过简短的站会形式跟大家一起同步各自的开发进度，尤其在联调和提测的时间节点之前，需要加大进度跟进及同步频率，确保项目能够如期联调和提测。
若发现延期风险，需要及时向相关负责人及领导同步，寻找解决办法。若无法避免延期，则需结合实际开发进度及剩余时间重新给出合理排期并向相关人员同步最新排期。
11）测试过程
项目提测后，如果涉及到有UI协助，需要及时通知相关UI同事介入帮忙进行UI走查，确保UI层面的问题能够在早期修复。
在测试阶段，要跟测试同事紧密沟通，掌握BUG数量及解决进度，确保BUG能被以合理的时间修复好不要影响整体的排期。
测试过程中也应尽量亲身参与测试过程，发现一些细节层面的问题，推动测试过程更快的进行。当测试同事提出验收申请后，要全面仔细的走一遍整体流程，确定此次需求没有问题之后再上预发环境。预发环境中重复一遍测试环境的步骤，确认验收通过后达到上线标准。
若测试过程发现延期风险，需要及时向相关负责人及领导同步，寻找解决办法。若无法避免延期，则需结合实际测试进度及剩余时间重新给出合理排期并向相关人员同步最新排期。
12）上线前后
上线前若项目需要进行灰度测试，则需要提前给出灰度测试的用户范围；若需要市场及运营部门协助进行推广，则需要在上线前后的相应时间点与市场运营部门紧密沟通，确保项目在上线前后能够得到及时的推广。
正式上线后，要做的第一件事是对线上环境进行回归测试，确保上线后的产品功能没有问题之后再发布上线邮件（里程碑性的产品上线还应适当庆祝）。若产品功能较为复杂，需要及时跟相关人员约好时间进行内部培训，或向用户发布产品使用说明。在上线后也应及时对项目整个过程进行全面复盘，如有需要可召集所有项目成员一起进行复盘会议。
而后，需要持续对新上线的产品功能进行体验，分析相关数据，评估项目的效果和收益情况，也应主动及时搜集用户对新功能的反馈，形成相应的迭代需求，然后再次以迭代优化的形式进入项目开发流程。
其他环节
1）沟通前后
沟通之前要先明确此次沟通的目的，开始时先向沟通对象介绍沟通的背景和此次沟通的主题，沟通过程中语言要尽量简练，尽量不要说与此次沟通主题无关的话题，最终要达成明确的结论。
2）调研前后
产品经理的日常工作中，需要经常对用户，竞品及行业进行调研。在调研之前需要先明确好调研的目标，根据目标选择合适的调研对象及调研方法，而后需要设置好调研的问题或者是思路。待这些都思考清楚之后，在开始调研，调研的过程中要细心，应当尽量围绕目标展开，最终要形成有效的调研结论。
3）汇报前后
在汇报工作之前，要先明确好汇报的目标，结合目标提前做好相应的准备工作，如有需要还需准备PPT。
汇报过程应尽量简练，本着结论先行的原则，先汇报结论然后再阐述原因，理由需要足够充分且有说服力，如果涉及到相应问题，需提前想好几个解决方案让领导做选择题。
4）遇到问题
遇到问题之后，不要一上来就想解决方案。需要先认真了解清楚问题的背景及产生的原因，深挖出问题的本质，在此基础之上对问题的影响面进行评估，看是否需要其他产品端或部门的协助。而后再开始针对问题的本质思考解决方案，解决方案要能够从根本上解决问题且最简最优，具备良好的拓展性。还应及时向相关人员同步问题解决进度。
5）主持会议前后
会议开始之前，要先明确召开本次会议的目标和会议主题，提前跟相关参会人员打招呼约好时间，根据约定好的时间提前发送会议邀请，在会议快开始之前再提醒一下大家。
会议开始时，需要先向大家介绍会议的主题及目标，然后进入主题。会议的过程中要注意对论题及节奏的把控，不讨论与会议主题无关的话题，推动会议正常进行，最终要达成明确的会议结论和后继TODO。会议结束后，及时将会议达成的结论整理成会议纪要同步给相关人员。
最近看了《清单革命》这本书，联想到产品经理的日常工作，便有了此文。
本着xsdl“小步快跑，快速迭代”的思想，本文结合笔者将近一年（算上实习）的产品工作经历，输出了【产品经理自检清单】的V1.0最简版本。后继会结合该清单在实践中的使用情况，及用户反馈对其不断迭代优化，也非常欢迎阅读本文后对此清单有优化建议的用户，通过微信公众号与我建立联系，互相交流学习。
清单的力量是有限的。它虽然能帮助我们记忆如何处理复杂的工作，帮助我们搞清楚哪些事情是最重要的，帮助我们不遗漏重要的工作环节，并且促使我们进行团队合作，但解决问题的主角毕竟是人，而不是清单。
愿本文能给你我带来一定的帮助和启发。
以上。
本文由 @心中有这个世界 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议