8个步骤,一次完整的产品迭代

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

产品迭代流程图:

8个步骤,一次完整的产品迭代

一、需求管理

1. 需求获取

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

  1. 自己挖掘的需求;
  2. BOSS、合作商、甲方;
  3. 团队成员:产品、运营、测试、开发等;
  4. 用户反馈:App商城用户评论、贴吧、百度知道、知乎用户评论、产品自带的用户反馈、问卷调查、用户访谈等。

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

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

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

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

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

2. 需求管理

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

  • 对于有价值的需求,会继续跟进全生命周期管理,包括产品定义、原型/交互设计、技术评审、研发、测试、上线;
  • 对于无价值或者不合理的需求,就会驳回,需求的生命就此终止。

3. 需求分析

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

  • 要驳回与产品定位相违背的需求;
  • 要过滤不合理或者小众场景的需求;

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

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

  1. 需求带来的收益;
  2. 需求的用户数量;
  3. 需求的使用频率;

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

4. 竞品分析

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

  • 选择行业内类似3-5款产品;
  • 分析针对该痛点,竞品是如何解决问题的,可以从用户群体-使用场景-用户痛点-解决方法角度思考分析;
  • 对比发现竞品是如何做的,思考其背后的逻辑,自己的产品能否能借鉴竞品的功能,或者有自己独特的解决方案。

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

  • 避免自己一个人埋头设计出问题,取长补短;
  • 提升设计效率,如行业已有很成熟的解决方案,为啥自己还要埋头苦想呢,可以借鉴呀;
  • 培养敏锐的需求分析能力,解决方案切中要害,避免为以后挖坑。

二、产品/功能定义

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

1. 业务流程图

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

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

2. 原型图

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

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

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

3. PRD

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

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

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

  1. 要介绍清楚需求背景、需求收益等,让设计、研发、测试先清楚简单的背景信息,要让他们觉得这个需求是有价值的,有做的必要;
  2. 要介绍清楚需求目标,即要完成这个需求,需要做哪些关键事项,给研发总览需求涉及的功能模块/功能点;
  3. 业务流程及原型,图形化展示功能点及逻辑,相比大段文字,图形化展示更容易让研发读懂“要做什么”;
  4. 功能详述,针对业务流程所涉及的各个模块详细叙述功能细节,细化到文案字体大小。

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

三、交互/视觉设计

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

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

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

四、技术评审

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

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

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

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

五、研发

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

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

六、测试

1. 测试用例撰写

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

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

2. 测试用例评审

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

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

3. 提测与测试

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

4. 测试环境测试报告

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

七、上线

1. 上线申请

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

2. 上线验收

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

3. 生产环境测试报告

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

4. 上线通知

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

八、跟踪数据及优化

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

总结

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

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

作者:瑞阳(Rain),个人微信公众号:产品经理的那点事儿。电商中后台产品经理,先后负责B端营销工具产品设计、移动分销体系构建、派单系统产品设计及产品全生命周期管理维护。

特别申明:本站的主旨在于收集互联网运营相关的干货知识,给运营小伙伴提供便利。网站所收集到的公开内容均来自于互联网或用户投稿,并不代表本站认同其观点,也不对网站内容的真实性负责,如有侵权,请联系站长删除,转载请注明出处:8个步骤,一次完整的产品迭代:https://www.zcly.cn/17436.html。
(0)
瑞阳(Rain)的头像瑞阳(Rain)专栏作家
上一篇 2019年11月25日 20:12
下一篇 2019年11月27日

猜你喜欢

发表回复

登录后才能评论

QQ:1124602020
微信:vl54120
备注:周一至周五全天在线,周末可能不在线,另外联系时,请告知来意。

公众号
交流群
运营狗会员,开通可享海量资源与多项权益,点击了解详情