本文提到的产品经理工作流程，主要来源于本人在日常工作中的总结凝练，并不适用于所有公司的实际工作流程，仅供各位大佬参考，欢迎大家批评指正哦。
一个中后台产品项目从最开始接到需求到最后开发完成上线，这期间产品经理到底运筹帷幄了哪些事情？经过了哪些流程？一个需求到底是怎么完成的？
本文将对产品经理的大致工作流程进行阐述，因为本人做的是中后台系统方向的产品，所以讲述的流程和C端产品经理的工作流程多少会有些出入，当然我会尽量从更广的维度上去概述产品经理的工作流程，争取把平常的工作流程都覆盖到，后续再写文章对各个流程做详细的介绍。
所有的产品需求，必定会有一个需求的来源。
常见的需求来源有：
1、业务人员提需
业务方在使用产品的过程中，会反馈产品的bug、体验、流程等各方面的问题。
此处的业务人员，你可以将其理解为一个泛称，它可以是客户、老板、领导等各个使用产品的角色。
2、技术人员提需
技术方案的升级迭代，有时也需要产品的同步支持。或者可能会有技术上一些解决问题的手段，需要产品化和平台化，方便各部门员工的使用。
3、产品规划
产品规划，需要适应公司战略方向，所以当战略方向有所调整时，产品规划可能也要跟着有所变动，这个时候，就会有新的产品需求出现。
产品经理不可能一下子把所有需求都做完，总要有一个先后顺序，所以就会涉及到需求的记录管理。
一般产品经理会将需求放到需求池中，记录清楚需求的提出人、提出时间、需求描述/需求场景、需求类型、需求进度等信息。
产品需求池要秉承一个宽进严出的原则，在需求收集阶段时，可以广泛的收集需求，不用太过于深究需求的合理性，主要就是做好需求的记录，便于后期追溯和需求分析。
需求分析到底分析个啥呢？主要就是弄清楚需求的真伪、价值收益、成本、本质、优先级等，进而综合考虑有哪些需求要做、什么时候做、谁来做、投入多少资源等。
所谓评审立项，各个公司的方式更是五花八门，有的公司需要需求发布，讲明需求背景、收益、成本等各个条件，各个有关部门的老板们觉得ok了，这个需求才能安排开发人力，正式提上日程；有的公司产品总监一个人就能拍板做不做一个需求。
虽然立项的方式有繁有简，各不相同，但立项这个步骤是不可省略的，这标志着一个需求从冷冰冰的需求池中正式提了出来，踏上了即将上线的路程，所以产品经理需要重视立项这个步骤。
有同学可能会问了，在需求分析管理阶段，不是已经分析过需求了吗，为什么又要有需求调研这一步，两者有什么区别吗？
需求分析管理，产品经理解决的是要不要做一个需求的问题，而需求调研，解决的是如何做的问题。
特别是b端产品，涉及到较为复杂的业务场景，以及不同用户角色间的需求差异，所以在做需求时，就需要通过调研，了解业务实际，综合的考虑需求实现方式，避免需求场景遗漏，或出现顾此失彼，考虑不全的情况。
至于具体的需求调研方式，常见的有访谈法、问卷调研、观察法等，产品经理可以根据自身实际情况，灵活掌握并判断使用什么方式。
不管是B端产品还是C端产品，竞品分析都是一个做好需求的利器，大到产品架构，小到功能交互和文案，都能通过竞品分析来获取灵感。
因为很多东西，你空想的话是很难想出来的，而且还会浪费很多时间，所以要善于使用竞品分析，站在巨人的肩膀上。
正所谓天下文章一大抄，就看你会抄不会抄。做竞品分析肯定不是让你原封不动的照搬人家的东西，那样的话，一是不道德，甚至有法律风险，二是可能并不符合需求的实际情况。所以竞品分析更多的是提供方向和灵感，就算是抄，也要有差异化，做到“因地制宜”。
对于新人产品经理来说，这一步往往是最让人期待和激动的，就好像学了好久的车，终于可以上路行驶了一样。
不过新手上路，总会碰到一些意想不到的情况，如果没有什么经验，或者考虑不周，难免会有些磕磕碰碰，出产品的需求方案也是一样的道理，需要谨慎细致，考虑全面。
出需求方案，并不是一上来就开始画原型写prd，而是还有一些前置工作需要做。
需求调研清楚后，产品经理需要绘制相应的用例图/业务流程图/产品结构图/系统交互流程图/状态图等各种需要的图，不过这些也要看具体需求的复杂程度，并不是每个需求都要画一堆图出来，产品经理可以根据实际情况，判断是否需要以及需要绘制哪种图。
一般较为常用的是流程图和产品结构图，流程图帮助产品经理在动手画原型之前，梳理清楚主干、分支和异常流程，避免遗漏关键场景；产品结构图一般包括了产品信息和功能，基本上产品结构图画好后，产品原型图就能跟着画出来了。
不要一上来就画原型的另一个原因，是因为在主要流程还没有梳理流畅时，原型画起来会很慢，而且很容易出错，而错了改起来又很麻烦，费时费力，还不一定能把逻辑搞清楚。
所以可以先用低成本的流程图理清逻辑，利用流程图跟业务和技术去沟通，如果发现错误还能及时修正，避免后续大反工。
做完前置工作，再画原型、写prd就会流畅很多，即使发现没有考虑到的地方，也能很轻松的进行修改。
需求方案出来后，如果没有其他情况的话，接下来的一个大动作就是要需求评审了。
需求评审对于很多产品经理，不管是新手老手，都是一座山，被怼互撕那都是常有的事情。所以产品经理不仅要平时和研发同学搞好人际关系，而且要尽可能的把需求文档写好，在实现需求的同时，也要考虑研发成本。
评审前
可以把方案发给关键的业务和技术人员看一看，避免用一个有巨大逻辑漏洞的方案来进行评审，否则那种感觉真的会很难受。
另外，大家都很忙，召开评审之前，一定要确定好参会人员，约好大家的时间，将方案发到群里，给大家预留看文档的时间。
评审中
对于各方提出的问题，要及时做好记录，如果有会议录制条件的，最好进行录制，一是如果会后有遗忘的点，可以回溯查看，二是留下评审的证据，如果后续有甩不清的锅，可以看看评审记录到底当时是咋说的。
另外，评审结束时，记得让开发给排期，有时较为复杂的需求，技术可能还会有一个技术评审才能出排期（如果涉及到ui介入的，还要有ui设计的排期），总之，要及时跟进要排期，防止需求开发被一拖再拖。
评审后
需要将评审中提到的需要改动的点，或者是一些待办事项总结好发给各参会方，如果有群的话也可以发到群里，并艾特全体成员。有针对某个人的待办，也可以再单独私发一次，防止对方遗忘。
ui、前后端、测试的排期给出后，接下来一段时间，产品经理的主要工作就是跟进开发进度了。
跟进开发进度，除了单纯的过问开发进度，保证开发按计划进行之外，还要积极配合前后端的开发。
因为有些问题在评审中可能并不会暴露出来，对于前后端在开发中抛出的问题，产品经理要及时处理，做出决策，毕竟在没有项目经理的情况下，产品经理一般是会作为需求的主owner的，一定要对得起岗位名称中“经理”这两个字，做一个负责任的产品经理。
在开发过程中，原则上是不做大的需求改动的，如果有需要改动比较大的情况，只要不是本期必须要实现的功能，也不是碰到技术不能实现的功能点，都可以考虑放到下一期需求迭代中，确保当期需求顺利开发完成，避免拖泥带水。
需求开发完并联调后，前后端一般会给出一个走查环境（也可以叫测试环境），产品经理需要根据需求文档进行走查测试，排查问题，由开发人员及时解决。
走查时也要注意，一定要细致全面，如果在走查过程中有什么新想法，或者发现哪里由遗漏（prd中没写，但是却需要的），小改动可以跟开发人员协商直接在当期做了，如果是大改动的话，只要当期需求能跑的通，尽量把改动点放到下一期进行迭代。要是因为产品经理执意加需求导致需求开发延期，那么这锅是绝对摘不掉的，一定要注意。
测试工程师介入测试，可以和产品经理走查并行，也可以在走查之后进行，具体什么时候开始测试，可以看公司的工作习惯和需求的难易程度，一些太小太简单的需求，可能不需要测试工程师的介入，走查没问题即可上线。
终于迎来了这关键的时刻了，激动人心啊。
但是也不要高兴的太早哦，产品上线后，产品经理也要进行线上验收，如果涉及到灰度发布，后续还要看什么时候全量发布上线。
为什么上线前也走查了，也测试了，上线后还要再检查一遍呢？因为产品上线并不是像打开一个开关一样，点击一下上线就上线了，在上线过程中，有可能会出现各种各样的问题，这都会影响产品实际到线上的效果，产品经理要和前后端开发人员一起，防范并处理产品上线后可能出现的风险。
产品终于成功上线了，对于中后台产品，或者是B端产品来说，较为复杂的需求上线后，需要撰写操作手册，并组织相关培训，方便业务人员的使用。
产品上线后，到底能不能被用户认可，就要通过相应的数据分析来体现了，如果产品上线后，压根就没什么人用，那么很有可能这个需求就是个伪需求，或者是缺乏相应的运营手段支撑。
本文由 @向上的小霍 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。