时间: 2021-08-03 09:47:53 人气: 15 评论: 0
作为产品团队的信息收集者与传递者，产品经理的工作所涉及的部门和人员是非常多的，今天我们就从人和事两个方面聊一聊产品经理的工作流程。
关于产品经理的基本工作流程，我们用一个产品迭代优化的例子来阐述。
要迭代优化，产品经理遇到的第一个问题就是要做什么，即工作流程的第一部分：搜集需求。
在这个阶段，产品经理需要弄清楚需求在哪里。归纳起来，需求可能**在领导那里；可能在协同部门那里；可能在用户的反馈里；可能在产品后台监控的数据里，还有可能在产品经理自己对产品的理解与洞察里。
既然需求可能在这么多地方，那产品经理就要想办法来搜集这些需求。在收集需求的过程中，产品经理需要应用多种方法，例如用户访谈、调查问卷、数据分析、用户画像等，总体可以归为定性和定量两大类，同时还需要关注需求方的表达与行为（很多时候，需求方说的并不是他们真正想要的）。这里我们不展开讲，建议想深入了解的同学可以读相关的专项书籍或文章。
假设产品经理搜集到了这些需求，那接下来就要考虑哪些需求能做，哪些不能做，哪些需求重要要先做，哪些不重要要排后，即工作流程的第二部分：需求筛选与分析。
需求筛选与分析面临的第一个问题就是甄别哪些需求是真的，哪些需求是假的。相信大家都听过亨利·福特的经典语句 “如果我最初问消费者他们想要什么，他们应该是**告诉我，‘要一匹更快的马！’”。而事实上，用户的最终目的是要更快的到达目的地。所以产品经理需要通过搜集的信息甄别出，用户的真正需求是什么。
当弄清楚这个问题后，接下来就是对需求进行排序，即开始说的确定哪些需求重要，哪些不重要。这个排序的过程，需要考虑的因素很多。理想的情况下，需求的优先级是基于产品规划及商业目标展开的，当然也可能**出现其他情况，例如老板需求等。
将需求排好了序，接下来该做什么了呢？那就是把需求整理成可执行的方案，即工作流程的第三部分：文档撰写。
这里所说的文档是一个统称，指产品迭代过程所用到的所有文档，例如思维导图、流程图、产品原型、需求文档等。所以文档撰写是一个由抽象到具体的过程，可以分几个层次来看。
首先，要确定大的方向，核心流程。对此，产品经理可以整理思维导图或流程图，和需求方确认核心是否正确；确认了核心流程以后，产品经理就可以整理更加细化的原型，前期原型只需要将页面的结构及交互关系体现出来（低保真原型），然后再与需求方确认；确认后进一步细化，形成细致的原型及配套的需求文档。特别要注意的是，这个阶段的沟通不仅包括需求方，还应包括技术以评估技术的可行性。
有了完整的文档，产品经理就可以考虑进入下一阶段，即工作流程的第四部分：项目启动。
项目启动首先是要组织项目启动**议，**议上产品经理需要向各方完整阐述项目的背景及需求内容。值得注意的是，产品经理在发送**议通知时，需要把原型及文档同时发给团队成员，让大家带着问题参加**议，这样**议的效率**更高。
**议中，在与**人员明晰之后，确定相关负责人，由项目团队给出项目排期（需要确定项目排期的时间节点）。
有了排期，就进入工作流程的下一阶段：项目开发。
在项目开发过程中，产品经理需要沟通，沟通，再沟通，再有就是关注项目关键节点及成果，以确保项目的按时按质完成。
项目开发完了，就是安排上线了，同时给相关成员发送上线通知邮件。一般而言，上线之后的一两周内，都是产品的重点监控时间区间，及时发现问题，及时解决（上线时应该制定相应的应急方案）。
当新版产品运行经过平稳期，产品经理就该考虑下版迭代了。
这个问题可以分两部分来说：产品规划与产品开发。
就产品规划而言，产品经理接触到的人包括但不限于：
当我们做产品规划时，必然要和直线领导就方案达成共识，才能进一步向外沟通确认，因此在产品规划阶段，你需要频繁地与直线领导沟通或汇报（有时候直线领导可能不参与具体讨论，但需要知道进度）。
有时候，公司领导可能是某个需求的提出者。这种情况下，产品经理（或直线领导）需要向公司领导汇报相关解决方案。
如果你负责的产品有业务人员的话，那他们也是产品重要的需求方，同时他们在与客户接触中，**出现种种问题。这个时候，都需要产品经理参与解决。
针对产品规划，客服人员反馈的用户数据尤为重要，因此产品经理需要频繁地与客服人员进行沟通，搜集数据，整理并转化为需求。
用户研究是产品规划阶段的核心工作之一，也是产品经理难得的接触真正用户的机**。在这个阶段中，产品经理可以采用用户访谈、调查问卷、可用性测试等方式，多多与用户进行接触。
就产品开发而言，产品经理接触的人包括但不限于：
当产品原型最终确定，就可以进入UI设计阶段，这个时候产品经理就需要和UI探讨原型细节，进入设计阶段。
UI设计完成后，就开始转入前端工作。对于前端而言，**更加关注细节，每一个按钮的状态变化，每一个交互细节，都需要详细说明。这块一般是由产品经理和UI共同提供的。
不过如果是移动端产品，前端基本上就不太**参与，页面切图和标注工作主要是由UI完成。
开发的工作主要是参照需求文档来展开的，因此产品经理需要就需求文档细节与开发进行充分沟通，以保证开发工作的有效性。
开发完成了项目工作，就进入了测试阶段。一般情况下，测试人员**在开始之前召开测试用例评审，然后才进入具体的测试阶段。无论是测试用例编写阶段，还是测试阶段，产品经理都是要与测试充分沟通的。
事实上，项目开发的工作是阶段性的，但产品经理与团队的接触则是全程的。从需求的发生，到项目的上线，产品经理都需要与UI、前端、开发、测试等人员充分接触，对产品需求进行沟通评估。
结合产品经理基本工作流程来看这个问题，**更容易理解一些。虽然具体的产品开发工作不用产品经理做，但产品经理也绝对做不了甩手掌柜。在有产品开发时，他需要时刻关注产品的进度，进行问题确认，必要的时候协调资源；在没有产品开发时，他需要进行规划，同时还要关注市场及竞品的变化，以能够及时洞察产品的发展趋势。
把以上的这段文字转换成场景，基本上产品经理的一天就能呈现在我们面前。
早上在上班通勤的路上，产品经理可能**打开新闻客户端，关注自己感兴趣或与工作相关的内容，必要的话**把重要信息或链接记在备忘录里。
到公司以后，打开电脑首先查看一下邮箱，邮箱里有四五封邮件，其中两封邮件是测试发的bug信息，需要沟通确认；有一封邮件是协同部门发来的，内容主要是得到了一些用户反馈，需要满足新的需求，需要进行评估；还有一封**议通知邮件，下午三点要开某产品需求沟通**议。
然后产品经理的一天也就围绕这几封邮件开始了。上午他可能**先去和测试沟通确认一下两个bug该如何修改，沟通的过程中又发现了新的问题，所以后来和测试的沟通就变成了和测试、开发、前端等同事的沟通。问题解决了，时间也过去了半个多小时。
解决了测试bug的问题，产品经理需要好好想想协同部门提的需求。对产品经理而言，需要很慎重地对待需求，有的需求不一定要满足，而有的则必须快速响应。经过初步分析，这个需求是需要满足的，但如何做还需要和领导沟通一下。因此，产品经理就去找领导沟通，沟通后最终形成了一个初步的方案，产品经理以此回复了邮件。而此时已经上班两个多小时了。
产品经理刚发完邮件，着手开始准备下午开**资料时，电话响了。电话是客服同事打来的，说用户使用出现了问题，需要马上解决。产品经理只好先暂时放下手里的活，去解决用户问题。用户问题解决了，时间基本上也就到中午了。
下午的工作内容相对比较整，简单说就是准备开**、开**。不过，在这个过程中，还是时不时需要跟项目成员确认信息；收到其他同事的微信或电话。下午的**开得还算成功，不过有些需求的细节还是需要调整。**议开完，产品经理就开始着手修改工作了。等修改完了，差不多也就到了下班的时间。
其实上面说了那么多，总结起来讲产品经理的一天就是由洞察趋势、内部沟通、整理信息、产品思考四大部分组成，其中沟通**占大部分时间，形式有面对面、电话、**议等等。所以沟通能力对产品经理来讲，尤为重要。
关于产品经理工作流程，我们可以归纳为想、写、说、做、改五个字。任何一个阶段，都由人、物、信息三种元素组成，产品经理的工作也都以此展开。
E木笔记，微信公众号：E木笔记，人人都是产品经理专栏作家。在线教育领域探索者，专注移动互联网产品研究
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 unsplash，基于 CC0 协议
