首页 > 编程知识 正文

迭代步骤(在产品迭代更新的过程中)

时间:2023-05-06 04:44:20 阅读:88743 作者:3816

产品经理作为产品/功能的首要负责人,负责产品整个生命周期的维护,在项目中也担任着多个角色。 日常产品迭代需要什么样的过程? 作者整理迭代过程,供大家一起学习和参考。

产品迭代流程图:

一、需求管理

1. 需求获取

需求获取也称为需求收集,这个过程,产品经理面临着各种角色(需求者)提出的各种需求,需求质量也参差不齐,一般来源于以下渠道。

自己挖掘的需要; BOSS、合作商、甲方; 团队成员:产品、运营、测试、开发等用户反馈: App商城的用户评论、论坛、百度知道、知道的用户评论、产品附带的用户反馈、问卷、用户虽然有些需求本身有问题,也有不合理的地方,但是作为产品经理要保持平常心,转换思维,以严格的态度对待需求者,避免直接回到需求上来。

如果遇到需求,无论发生什么事,都不要太兴奋或生气。 收集需求是产品的正常工作,以平常心应对需求方,今后遇到的需求还有很多。 不值得马上兴奋或生气。

需求zydxyz提出了这样的需求,说明也是使用中遇到的问题,产品必须学会站在对方的立场上思考问题。 如果是你的话,遇到这样的问题,必须学会体谅对方。 如果是不合理的需求,就要耐心地和需求方谈谈经过,让对方也了解你。 不是从上到下,而是评价需求的不合理性。

要诚实对待每个消费者,就必须对自己说的话负责。 暂时无法评价需求是否合理时,首先要自己考虑,如果有必须慎重行动的不确定性,请立即拒绝或立即回复,不要确定接受这个需求。 仔细评估后,不要出现与先前结论不一致的情况。

所以,一般来说,建议自己考虑接受需求一方的需求并进行评估后,再回答需求一方。 尽量不要简单地考虑拒绝或答应,避免为后期挖坑。

2. 需求管理

从收集到需求,产品已经访问了需求的全生命周期管理,需求管理通过产品经理的职业生涯进行。 有些需求的实现价值是固定的,而另一些则是不值得或不合理的。

对于有价值的需求,持续跟进全生命周期管理,包括产品定义、原型/交互设计、技术评审、研发、测试、在线化等; 对于无价值或不合理的需求,将被驳回,需求的生命就此结束。

3. 需求分析

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

需要过滤掉违背产品定位的需求不合理的场景和小场景的需求这些需求都可以称为“伪需求”,识别伪需求是长期培养的能力,对于产品新人和刚入职的产品,可以自己独立需求多与老员工和熟悉这个模块的同事交流,这是一种很好的学习方式,可以学到很多其他知识。

过滤了虚拟需求后,基本上剩下了有价值的需求,如果有价值的话需要马上做吗? 不,当然,开发资源有限。 先制造哪个需求再制造哪个需求需要明确的优先顺序。 也就是说,产品必须对需求进行优先排序。 一般的需求优先顺序决定基准如下。

需求带来的利益需要的用户数; 需求使用频率需求收益越高,当然优先级越高; 的使用者数量/用户数量越多,需求优先级越高;需求使用频率越高,需求优先级越高。

4. 竞品分析

yqdmt在确定制造某种需求时,不是直接埋头做的,而是要做竞品的调查。 需求的解决方案有很多,自己考虑未必是最好的,也未必最符合自己的产品。

选择行业内的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. 测试用例评审

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

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

3. 提测与测试

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

4. 测试环境测试报告

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

七、上线

1. 上线申请

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

2. 上线验收

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

3. 生产环境测试报告

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

4. 上线通知

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

八、跟踪数据及优化

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

总结

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

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

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

本文由 @瑞阳(Rain)原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。