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

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

产品迭代liú程图:

一、需qiú管理

1. 需qiú获取

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

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

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

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

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

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

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

2. 需qiú管理

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

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

3. 需qiú分析

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

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

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

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

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

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

4. 竞品分析

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

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

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

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

二、产品/功能定义

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

1. Xliú程图

Xliú程图是表示X需qiú在系统各个模块间liú转的图形,有用户、信息的liú向,以及有异常情况的处理。

XXliú程图能清晰了解功能会涉及哪些模块、角sè,以及详细的输入、输出、任务等。后续将会zhēn对如何画Xliú程图专门讲解,本文将不再赘述。

2. 原型图

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

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

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

3. PRD

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

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

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

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

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

三、交互/视觉设计

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

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

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

四、技术评审

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

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

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

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

五、研发

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

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

六、测试

1. 测试用例撰写

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

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

2. 测试用例评审

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

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

3. 提测与测试

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

4. 测试环境测试报告

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

七、上线

1. 上线申请

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

2. 上线验收

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

3. 生产环境测试报告

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

4. 上线通知

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

八、X数据及优化

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

总结

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

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 8个步骤,一次完整的产品迭代 https://www.xiongfawang.com/3939.html

常见问题

相关文章

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

分享本文封面