（复制自 Y酱 http://www.pmcaff.com/article/index/917963525567616?from=search）
这一两个月团队来了很多产品新人，发现他们共同的问题就是很被动，且对整个项目流程中自己需要做的事情没有全面的认知。所以我依据自身的经验，总结了一份产品经理通用工作流程。
1、梳理需求思路
一般用脑图来整理思路，如果涉及到比较多的交互流程，最好再用流程图来梳理。
这一步的重要性就是你需要来不断否定自己，找到能够说服你自己的方案。
需求思路要包括：
需求的目的
需求的实现方式
需求的流程步骤
需求的长期规划和短期落地
最重要的还是需求的目的，为了拉新还是促活，为了提升转化率还是客单价，如果连自己都没有想明白，在需求评审阶段就没办法应对开发的终极问题——”做这个需求有什么用么？”
2、整理需求原型
这一步看起来是产品日常投入时间最多的，但实际上，很多产品并没有在需求原型上投入太多的思考，导致需求细节不清不楚。你要知道，一般的开发只做你需求里面提到的，你没考虑到的，他们不会替你去完善。
需求原型要包括：
交互操作的说明
数据获取的说明
各种异常情况的说明
数据埋点的说明
最重要的是数据获取的说明，是前端静态还是需要数据接口，是否需要提供给产品或运营进行可配置的后台。因为后台需求原型，也是需要产品来进行规划的。
3、跟进设计进度
设计最好在需求评审前就要开始投入，这样可以留给设计师多一些的思考时间。对于设计进度，需要关注以下：
设计完成的时间节点
设计完成的效果
设计评审是一件很主观的事情，牵涉的人不要太多，一般来说谁对上线效果负责谁拍板，你背KPI的话那就你来拍板。为了避免做出来的效果偏差太多，一定要先给设计师提供一些参考案例，只要整体效果在你的评判标准内，细节上可以更多的遵循设计师的建议。
最重要的是把握时间节点，不要永无止境的修改下去，这是大忌。
4、组织需求评审
需求评审环节拉上开发和测试，让他们了解这个需求大概要做的内容，重点说明以下几点：
是否涉及后端
是否涉及第三方接口
UI设计的输出时间
计划提测时间
计划上线时间
因为涉及后端和第三方接口，就会出现不可控因素，联调的沟通成本很高，开发需要预估多一些时间。
5、跟进开发进度
跟进开发和跟进设计一样，最重要的是把握时间节点，所以要及时去了解开发进度的情况。开发大多数时候对进度的预估都比较乐观，你必须抛出一些影响项目延期的关键因素让他们确认，比如“这个地方应该还挺花时间的，周五搞定来得及吗？”。
另外一个重要的事情就是需求变更，需求变更不可怕，最怕的是只是你和开发知道修改了，设计、测试都不知道。另外需求原型一定要进行更新，否则一两个月后你想要迭代这个功能时，发现需求文档的细节跟线上效果不一致，你就知道多痛苦了。
时间节点是第一位的，一个版本做不了的放到下个版本做，一个版本做不完全的放到下个版本迭代。
6、跟进测试与验收
在提测之前需要做两件事：
设计走查
showcase
设计走查在前端页面开发完成后就可以进行，主要是让设计师对实际开发的效果进行验收，大多数时候开发不会100%按照设计稿上的标注来，比如渐变的背景变为纯色背景，弹框样式直接用系统样式等等。而这些细节的损失会让整体效果大打折扣，所以这时一定要协助设计师来推进开发进行修改。
showcase是在开发基本完成后但未提测前，拉上开发、设计、测试对比实际的开发效果，把需求的流程和细节都完整的走一遍，避免各方对于需求的理解不一致，提高测试的效率。
提测后主要是为开发过滤bug和制定修复优先级，有时测试会提出的一些体验性问题，要及时认领，放入后续迭代优化的需求池。
7、跟进上线效果
上线后及时关注数据情况，主要关注两点：
是否出现严重问题
是否达到预期的目标
上线后的一两天，主要关注数据是否有大的波动，如果涉及功能不可用甚至更严重的问题，就需要紧急回滚或者下线。如果是一些体验问题，如机型适配等，可以记录下来下个版本优化。
上线后的两周，需要对运营数据进行分析对比，总结该需求实际的效果。有可能上线后数据没什么变化，也有可能数据变得更差了，一定要基于数据分析原因，在下个版本进行推论的验证。
不要轻易否定自己，更不要轻易否定团队的投入。