nba在线观看免费回放-官网在线

nba直播3个步骤教你做软件版本规划

时间:2021-03-10 15:43

  初级产品经理的工作日常大多围绕产品的版本规划与日常迭代展开,但是版本迭代没做好,也会引发很多问题。这篇文章告诉我们可以通过正确聊需求、优先级管理和迭代节奏三方面,做好软件版本规划。推荐给刚入行的产品新人阅读学习。

  如果你是刚入行1~3年的产品新人,你的日常工作里应该至少有70%的时间是在负责产品的版本规划与正常迭代,是不是呢?

  其实做产品规划的门槛很低,低到无论你怎么安排都不会错,因为从来都不会有一个标准的尺子来衡量你的规划正确与否。例如程序员,会有万行代码出错率等指标来代表这位程序员小哥的厉害程度,但很可惜产品经理们并没有Roadmap优美度等过程指标来衡量产品经理的厉害程度。

  这是一件快乐又可悲的事情:快乐的地方在于摸鱼无人管一朝成功很意外;可悲的事情在于摸鱼一时救火一世。

  团队一致认为这个版本是具有划时代意义的,功能非常多,所以需要至少X个月的时间才能开发上线,可是版本上线后,用户已经偷偷焗了油;

  中途突然接到了用户反馈的非常紧急的需求,赶紧插入到当前的版本中进行开发,技术小哥异常生气,挥刀砍你,从此给你贴上了“需求变更魔王”的标签,互相之间信任已不存在;

  团队的整体开发效率非常低,明明一个很简单的需求都至少要开发X个月以上,最后发现耗时最大的居然是团队内的沟通;

  整个团队的开发节奏要么时紧时慢,要么天天救火,要么放羊长草,工作中体会不到迭代的优雅韵律,就像下一口不知道是粑粑还是巧克力。

  如果这个时候,你的小脑袋在控制不住地点头,那么请把你的小手手交给丽莎阿姨,让阿姨带你进入优雅版本迭代之门。

  软件产品的设计出发点都是帮助他人,所以这也意味着永远不可能存在理想情况,产品科学是一门工程科学而非纯理论研究,落地实施才是第一要务。

  其实这一点也不奇怪,因为团队的分工不同所以理解自然就不同啦。如果非要给需求下一个定义,我想这句话是比较标准的:

  那如何能大家统一对需求的理解从而正确的传递需求呢?这个法宝就是:PRD(Product Requirement Document)

  先与你的老板、产品团队内部沟通你的意图;至少要包含需求背景来源、大致框架结构与解决方案草图,这一步非常重要越早沟通越不会跑偏(如果只是是很小的功能迭代可以省略);

  在产品团队内部、设计师与开发leader一起沟通这个版本要做的具体内容,至少要包含版本目的与关键指标,细化的产品原型图等;

  与开发团队一起沟通版本的详细需求,落地版本开发策略与排期,这个阶段才需要输出详细的产品交互逻辑与细化功能说明。

  一份PRD的生产过程就是一个把抽象的需求落地到具体的开发细节的过程。这就是产品工程的美妙之处呀!

  千万不要以为自己独自刻苦冥思苦想最后拿一个漂亮的PRD甩到老板面前让他惊艳,相信阿姨,老板这个时候只想掐死你,他不拍死你拍死谁?

  所以请从今天开始答应阿姨我们一起做需求渐进式沟通的好宝宝,好吗?不要一开始就沉迷在交互细节与逻辑中无法自拔,好吗?

  产品的业务目标拆解、用户调研、数据分析、竞品分析、性能相关、UI相关、技术迭代等均属于主动式需求;而业务部门(市场、运营、销售、管理层)需求、用户反馈、遗留bug等需求都属于被动式需求。

  要注意,这个需求管理的表格必须要动态更新与定期评审,尤其要记录需求来源,评审时候经常会发生需要溯源的情况。

  很多宝宝喜欢用重要+紧急四象限来做需求的优先级排序,但事实的真相往往是:几乎所有的需求都在重要紧急那个象限里。

  所以请赶紧把这个2019年的方法扔掉,跟着阿姨一起来用2020年的解决方案:满意度模型。

  简单来说,就是把你的需求按照“可实现”与“能带来价值”两个维度来分为四个象限,重新整理你的需求属性。

  能带来价值但是实现复杂度高的需求,因为往往这些需求都需要拆解到2~4个版本来解决,所以越早开始规划,你的团队就越有预见性,节奏就越优雅

  就是安排那些带来价值一般、实现难度不高的需求了;这部分需求往往就是按照例行的版本迭代节奏来进行就OK啦

  要记住,如果你的开发小哥们是那种特别有技术情节的,他们一定会经常跟你提那些异常复杂解决难度很高的问题,此时的你一定要理性判断这部分需求能带来的价值,能按住就按住好吗?

  毕竟对于开发小哥来说能解决复杂的问题才能体现自己的价值,这往往与产品的价值背道而驰。

  这个是丽莎阿姨总结的产品开发流程,在我们团队已经跑了5年有余,非常顺畅,相信业界绝大多数团队也是适用的。

  顾名思义,就是确定需求的阶段,此时需求是OPEN的,会发生任何可能性,需要在这个阶段完成PRD评审、交互视觉评审、以及确定开发方式与开发节奏安排。

  就是需求实现的阶段,这个阶段需求是严格冻结的,也就是说不允许再插入任何需求进来(无能的产品经理才乱插入需求),在这个阶段完成技术评审、埋点评审与测试用例评审

  这个阶段需求是允许微调的,毕竟在验收的时候会发生边界条件考虑不周,文案不当等情况,这个时候的微调可不算需求变更哦(拉钩钩)。丽莎阿姨建议每周要有固定的时间来验收(这样的节奏谁不爱呢)。

  千万要记住发布之前还是要做一个发布策略评审哦,尤其要安排好灰发策略,否则一下放开全量用户,BUG扑你脸上,连回滚的时间都木有呀。

  一个版本这样迭代完,第二个版本的流程最好在第一个版本的开发阶段结束开始,因为这个时候开发小哥刚好结束开发的紧张工作,有闲情逸致与你一起来讨论新版本的需求!

  最后:相关功能的最好隔开一个版本,例如A功能与A功能的优化,安排在第1与第3版本;B功能与B功能的优化,安排在第2与第4版本,这样你留给了自己长达一个版本的调整时间,节奏是不是优美,步伐是不是优雅?

  本文由 @Lisa Deng 原创发布于人人都是产品经理,未经作者许可,禁止转载。

  不太理解为什么“满意度模型”中“高价值-高复杂度”要优先于“高价值-低复杂度” ?难道不是应该先处理低成本高回报的东西吗?

  因为低复杂度的好做,高复杂度的不好做,同样回报度的东西,要优先开始规划高复杂度的,才能保证开发的节奏

  感觉大家的进度安排都不紧不慢呀,我这边感觉““忙的飞起“这个词都无法形容我的繁忙程度

  我公司需求太多,老板没进度安排,季度初排好的这些任务,没过半个月就说,我们另一个任务很紧急,另另一个任务也很紧急,另另另一个任务更急,赶紧上,并且计划内的也不能耽误,最后还是你一个产品的活,根本没办法想丽莎这样优雅的一步步走,最严重的时候,上午是这个版本的评审,下午是那个版本的评审,第二天下午又是另另另个版本的评审,无法优雅起来,请问这种情况,如果不增加产品经理的情况下如果应付

  验收测试阶段:这个阶段需求是允许微调的,毕竟在验收的时候会发生边界条件考虑不周,文案不当等情况,这个时候的微调可不算需求变更哦(拉钩钩)。丽莎阿姨建议每周要有固定的时间来验收——请问下如果需求未开发完,每周固定时间验收什么内容呢?

  大版本需求未完成,但是小功能点是OK的,理论上来说只要产品经理会解耦,一个功能的开发时间都不应该超过一周。

  写得很棒棒,逻辑清晰,和我最近的复盘结论一致,PRD是和团队达成一致认知的利器,必须在开发前与技术小哥一起评估

  你们评估完了,研发还会再看prd么?我们做完评估,就变成人肉prd了..

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。