产品经理的清单革命

我们所掌握的知识的数量和复杂程度已经超过了个人正确、安全和稳定地发挥其功效的能力范围。知识的确拯救了我们，但也让我们不堪重负。 我们需要开展一场伟大的变革来防止错误与失败，这一变革立足于已有的经验，既能充分利用我们所掌握的知识，又能弥补人类不可避免的缺陷和不足。这一变革并非艰难之举，而且简单至极，特别是对那些花了多年时间来培养和磨炼高超技艺的专业人士来说，投身这一变革简直让人贻笑大方。 这个变革就是：清单革命！

—《清单革命》

作为一名产品汪，日常的工作非常繁杂琐碎：处理需求，制定方案及逻辑，输出需求文档，协调各方资源，推动需求按时上线，产品培训及使用说明，分析数据，调研用户，调研竞品，了解行业，洞察用户需求，项目管理，规划产品迭代节奏，跨端跨部门合作，对接业务方......等等。

下面以项目为例，给出了一个项目从无到上线所要经历的流程：

如此众多类型的工作，对产品经理的能力要求也各不相同。在日常工作中，除了上述的工作内容之外，还会经常被各种琐碎的事情“打扰”，以至手头上的工作经常被临时搁置。

在此背景下，产品经理若想比较完美地处理日常工作，需要在具备各种维度的能力基础之上，能够在不同的场景下灵活且正确的使用对应能力去处理，且保证所有工作和步骤都没有遗忘。

怎奈何“理想很丰满，现实很骨感。”

由于人类的认知缺陷和有限的记忆力，在日常工作中面对大量繁杂的工作内容且还会被中途“打扰”的场景下，我们难免会多多少少遗忘一些步骤或工作，而遗忘掉的这些步骤或工作，很可能就是能对产品产生致命影响的那极少数，你说刺激不刺激！

难道我们就没有办法解决了嘛？

当然有！

只要一张清单，真的只要一张清单，以上问题就能引刃而解！（脑海中是否浮现出了那句经典广告语：只要998，真的只要998，以上商品全部带回家！hhhhh）

清单为我们提供了一种认知防护网，不仅能够抓住每个人生来就有的认知缺陷，如记忆不完整或注意力不集中；还能会提醒我们不要忘记一些必要的步骤，并让操作者明白该干什么。这不仅是一种检查方法，更是一种保障高效且高质量完成工作的法宝。

下图便是本文的核心内容：

下面将对清单中提到的内容进行详细说明：

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。会议结束后，及时将会议达成的结论整理成会议纪要同步给相关人员。

标签：需求,需要,革命,项目,经理,评审,上线,文档,清单
来源： https://blog.51cto.com/u_14540820/2759313