产品经理作为产品/功能的第一负责人，要操盘产品的整个生命周期维护，项目中也要担任多个角色。日常产品迭代都要经历哪些过程？本文作者对迭代过程进行了梳理，供大家一起学习和参考。

产品迭代流程图：

一、需求管理

1. 需求获取

需求获取也称为需求收集，该过程，产品经理要面对各种角色（需求方）提的形形色色的需求，需求质量也参差不齐，一般来源于以下渠道：

虽然有的需求本身可能有问题或者是不合理的，作为产品经理要以一颗平常心、换位思考、严谨态度对待需求方，切忌直接怼回去需求！

遇到需求，无论咋样，都不要过于激动或发脾气，收集需求是产品的正常工作，以一颗平常心对待需求方，以后遇到的需求还会很多，不值得动不动就激动或者发脾气；

需求方既然提出了这样的需求，说明也是在使用中遇到的问题，产品要学会站在对方的角度思考问题，如果是你，你会不会遇到这样的问题，学会体谅对方，如果是不合理需求，要耐心给需求方讲清楚原委，让对方也理解你，而不是上来就评估需求不合理；

真心对待每个需求方，要对自己说的话负责，如果一时无法评估需求是否合理，一定要先自己思考，谨言慎行；如果有不确定性，一定不要立马回绝或者立马回复确定接受这个需求，避免谨慎评估后出现与之前结论不一致的情况。

所以，一般建议接受需求方的需求，自己独立思考评估后，给出需求方答复，尽量不要简简单单思考后就拒绝或答应，避免为后期挖坑。

2. 需求管理

从收集到需求，产品就已接入需求的全生命周期管理，需求管理会贯穿产品经理的职业生涯。有的需求是有价值确定要实现的，有的需求因为无价值或不合理而被pass掉的。

• 对于有价值的需求，会继续跟进全生命周期管理，包括产品定义、原型/交互设计、技术评审、研发、测试、上线；

• 对于无价值或者不合理的需求，就会驳回，需求的生命就此终止。

3. 需求分析

面对各种需求方提出的形形色色的需求，不是所有需求都要去设计开发的，因为不是所有的需求都是有价值的需求，产品经理要做的就是要判断需求的真伪，这就是产品经理要掌握的需求分析的技能。

• 要驳回与产品定位相违背的需求；

• 要过滤不合理或者小众场景的需求；

以上需求都可以称之为“伪需求”，识别伪需求是个长期培养的能力，对于产品新人或者刚入职的产品，在自己独立思考需求后，多与老员工或者熟悉这个模块的同事沟通，这是一种很好的学习方式，并且会学到很多其它知识。

过滤伪需求后，基本剩下都是有价值的需求，有价值就要立马去做吗？当然不是，开发资源有限，先做哪些需求后做哪些需求要有明确先后顺序，即产品要给需求排优先级，常见的需求优先级确定标准有：

需求的收益越高，当然优先级就越高；需求的使用人数/用户数量越多，需求的优先级就越高；需求的使用频率越高，需求的优先级就越高。

4. 竞品分析

当你确定要做某个需求时，不是直接就埋头开搞了，而是要做竞品调研，需求的解决方案会有很多种，自己想得不一定是最好的，也不一定是最适合自己产品的。

• 选择行业内类似3-5款产品；

• 分析针对该痛点，竞品是如何解决问题的，可以从用户群体-使用场景-用户痛点-解决方法角度思考分析；

• 对比发现竞品是如何做的，思考其背后的逻辑，自己的产品能否能借鉴竞品的功能，或者有自己独特的解决方案。

其实，调研竞品，是为了避免“井底之蛙”的局面。

• 避免自己一个人埋头设计出问题，取长补短；

• 提升设计效率，如行业已有很成熟的解决方案，为啥自己还要埋头苦想呢，可以借鉴呀；

• 培养敏锐的需求分析能力，解决方案切中要害，避免为以后挖坑。

二、产品/功能定义

需求确定要做了，就进入了产品设计阶段，该阶段要完成产品/功能的定义，即要完成功能设计，输出的关键产物有业务流程图、原型图、PRD（产品需求文档）。

1. 业务流程图

业务流程图是表示业务需求在系统各个模块间流转的图形，有用户、信息的流向，以及有异常情况的处理。

通过业务流程图能清晰了解功能会涉及哪些模块、角色，以及详细的输入、输出、任务等。后续将会针对如何画业务流程图专门讲解，本文将不再赘述。

2. 原型图

产品原型图是将需求转化成产品的一个过程示意图，通过原型来表达需求点和流程逻辑，同时向UI和技术去表达产品的概念和实现的内容。

产品原型图常用Axure、墨刀、Skerch绘画。个人推荐使用Axure，简单易懂，产品主要通过原型图表达清楚页面元素、页面逻辑，以最简单的形式表达即可。

强调一下，原型图只是表达想法的工具，能让设计、开发易懂就好，不必要做得有多炫酷、多么逼真，炫酷的设计成本高，但是投入产出比不一定高。

3. PRD

产品需求文档是产品经理日常工作中最重要的输出内容，PRD的质量直接决定了需求质量及后续人员的工作效率。

设计、研发、测试的工作均要以PRD为准，PRD漏洞百出和书写不清晰，会导致需求评审效率低下，后续设计、研发、测试会频繁和你确认细节及逻辑，更严重的是因为产品考虑不清楚，导致功能出现故障。所以PRD最重要的是清楚、全面的表达功能细节及逻辑。

PRD整体要遵循“由浅入深，由粗到细”的原则。

以上四个模块，整体由浅入深，一环套一环，让设计、研发、测试轻松读懂你的PRD。

三、交互/视觉设计

产品/功能定义完成后，要将PRD提交给交互设计师、视觉设计师，由设计师完成交互设计及视觉设计，最终会将PRD、交互设计稿、视觉设计稿统一提交给研发，由研发完成整个功能的开发工作。

交互设计师专注于界面的布局以及业务逻辑流程设计，现在多把app动效的设计也归于交互设计师做，目的是为了更好的了解用户心理为用户服务，让整个产品流程体验顺畅舒适。

视觉设计比较单纯，主要会和交互设计合作共同设计界面，用色彩和样式来满足用户的视觉需求和情感需求。

四、技术评审

在设计师完成交互及视觉设计后，就到了需求交付给研发的时候了，产品要将PRD、交互设计稿、视觉设计稿统一提交给研发。

交付之前，要由产品牵头组织需求评审，邀请设计、研发、测试参与评审，产品给大家演示讲解交互、视觉以及详细的功能介绍，中间任何同事有疑问均可提出，由产品回答，遇到的争议点由产品、设计、研发、测试一起商量确定最终方案。

评审完成后，技术负责人反馈评审结果及大致开发排期。争议点较多、问题较大的需求，可能就评审不通过了；有个别小毛病的，可能评审通过；完全没有问题的，当然也评审通过。评审通过后，研发进入开发流程；如果没有评审通过，产品继续完善需求，等待下一次评审。

针对需求评审过程中的疑问点、争议点以及各方确定的最终方案，产品都要做好记录，评审后，产品完成PRD内容修改，注意版本的迭代及标注。

五、研发

产品/功能进入研发，产品要做好项目管理、进度把控，其中就涉及关键时间点的把控及跟进，要和研发、测试共同商定开发时间、提测时间、联调时间、上线时间，针对事先确定的时间安排做好维护及跟进工作，随时关注各方工作进度。

如果研发过程有任何问题及风险，要及时暴露，评估是否影响工作进展；如果没有特殊情况，建议不要频繁变动各研发时间节点。

六、测试

1. 测试用例撰写

研发过程中，测试人员就要根据PRD、交互稿、视觉稿完成测试用例撰写。

测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

2. 测试用例评审

由测试人员牵头发起，并邀请产品、设计师、研发参与，测试主导完成用例讲解，过程中有任何问题，都可以提出，疑问点由各方共同商讨确定最终方案。

评审完成后，测试人员要完成用例内容修改及完善，并周知各位相关人员。

3. 提测与测试

研发完成后，由研发负责人申请提测，测试人员介入。按照事先多方已达成一致的测试用例测试，过程中发现的问题要及时跟产品、研发同步，研发完成bug修复，产品要跟进bug修复；修复完成后，由测试人员继续测试，直至没问题为止。

4. 测试环境测试报告

测试人员完成测试后，要输出测试报告，并周知各方人员，测试报告要体现关键结论、风险点、测试内容。测试报告也会作为上线申请的关键依据，即测试通过后，研发方可申请上线。

七、上线

1. 上线申请

由研发牵头提出上线申请，由领导审批后方可执行上线，并周知产品、设计师、测试等相关人员。

2. 上线验收

完成上线后，产品、设计师、测试均要参与线上测试及验收。若完全没有问题，则验收通过；若发现简单可修改的问题，由研发修改后执行二次发布；若发现有重大的业务逻辑问题，要各方确认后回退版本，即上线失败，完成优化后，申请下次上线。

3. 生产环境测试报告

由测试人员牵头完成，测试报告中同样要体现关键结论、风险点、测试内容。测试报告作为判别上线是否成功的唯一依据，要及时周知各方人员。

4. 上线通知

上线成功或者失败，均要及时通知需求方及利益相关方。

八、跟踪数据及优化

产品/功能上线后，产品要及时关注生产数据，并做好数据分析工作。以数据为依据评估产品/功能是否达到预期效果，如果没有达到预期效果，产品要牵头做好复盘工作，即因为啥导致的，输出完善的举措和计划，并切实执行，避免同类型的问题的出现。

所以

产品经理作为产品全生命周期的操盘者，要跟进产品迭代的全流程：需求管理、产品/功能定义、交互/视觉设计、技术评审、研发、测试、上线、跟踪数据及优化。

产品经理在项目中担任起需求管理、产品设计、项目管理、数据分析等多个角色，遇到问题，要及时复盘并完善任何问题环节，成为一名合格的产品经理。