第一小节,如何开需求评审
为什么要需求评审:
1、从其他成员的角度上看,你的工作中有没有遗漏,错误,或者不合理不靠谱,没有考虑清楚的地方
2、了解每个人接下来要做的事情
3、让大家更好的理解需求
4、发现可能存在的风险,并提出自己的问题
5、展示需求来源,产品经理的思路等
做好需求评审不容易。产品经理无法说服所有人,不同的人对不同的地方有不同的意见吧整个需求文档的内容,都解释一遍,需要耗费非常多的时间。产品经理准备不足,会丧失威信。
怎么做。
1、不同的人讨论不同的内容。
比如跟老板或高层,就跟他们说产品的将来发展,做到什么样的程度,是怎样的发展方向。
他们主要关心的是产品目标,满足用户什么需要,给产品或公司带来什么好处。
跟中层管理人员,侧重表达功能点,实现什么样的功能点来满足什么样的需要、衍生需要
具体实现人员更关注每个功能点的细节流程和异常流程(功能细节)
2、分阶段评审。产品目标写好之后找老板或高层讨论,没有问题再设计功能点。吧功能点写好之后找中层管理人员讨论,没有问题再去设计功能细节。最后写好功能细节,写好文档后和具体实现人员讨论。
3、正式评审与非正式评审结合。正式评审之前多做非正式评审。平常小范围邮件、qq、直接讨论都可以。正式评审的额时候把涉及人员聚集一起,通过会议的形式进行正规评审。
4、正式评审前做好充足准备。自己先思考所有地方的逻辑和细节,准备好数据和事实说明,增加会议讨论的说服力。提前理清主次,讨论是按照主次逻辑顺序来说,不要东说一点,西说一点。提前确定会议室及与会人员的时间。
评审之后的工作
1、对问题持续做出跟踪,更正需要更正的地方,对需求做出变更,变更后需要对变更的地方做出重新评审。
2、如果有地方被指出有为,而你又不打算变更,说服其他成员
3、尽量不要变更,放到下一个版本中变。除非是很严重的问题。
第二小节,如何同其他团队成员协作
1、和开发人员要逻辑清楚的表达
2、不能做频繁的需求变更。
3、如果没有必要就不要去做特别难特别费时间的开发工作
4、不懂的技术不要装懂
5、不要干涉交互的工作,可以提意见,不要强加
6、主动沟通交互设计师不懂的地方
7、在设计之前就把自己的意见提给ui设计师,不要等到ui风格已经定了,再来提意见。不要用小清新这样文字描述,用参考案例产品或者图给设计师。
8、加深ui设计师对目标用户的理解。
9、运营人员有明确的kpi,往往会提出很多需求,来帮助他们达到这个目的。但往往又喝用户体验相违背,帮助他们想其他更好的方法。运营人员往往能够拿到很多第一手的数据和用户反馈、意见。
10、老板往往会强加自己的意志在他人的工作上(搞明白老板的需要,看能否更好的方式满足老板的需求。除非老板实在想不开,就听呗。)
11、产品经理也不要说大概、可能、做做看、差不多这种词汇,不然大家对你没有信任感,自己也搞不清做不做,这样别人也不会在意。
最后还是性格问题了,有些特别急躁的性格还是别做产品经理了。
第三小节,项目管理介绍
项目开展的四个点:范围多、时间快、质量好、成本省
作为产品经理更关注范围和质量
什么环节需要项目管理?1、产品经理的需求方恩熙,需求文档撰写。2、交互设计师的交互设计、原型设计。3、ui设计师的ui设计。4、架构师、程序猿的产品开发。5、测试工程师的产品测试。6、产品上线和发布。
为了产品更快更好的完成,把握住用户的需要,严格控制产品范围,在项目开始前确定产品达到目标都有哪些,拒绝不符合目标的功能点。团队内要保持沟通,问题及时反馈。
项目管理一般的工作流程:组建团队——产品经理确定项目范围——产品经理和设计团队分解工作任务、评估工作量,同时开发也分解工作任务、评估工作量——项目经理制定项目计划——项目经理跟踪任务,确保计划顺畅进行。一般创业公司产品经理兼任项目经理了。每个公司不太一样。
第四小节,如何做版本规划
为什么要分为不同版本更新。因为产品设计与开发时间特别长、版本时间短可以及时得到用户反馈、能够更快推出市场、在迭代过程中知道产品变坏或者变好的原因、版本变动小,用户能快速适应。
合理的版本规划:1、根据战略规划、趋势预测、团队资源划分目标任务先后顺序。2、根据这个版本要做的事情,决定功能的优先级。
我们可以把版本分为三种类型:大版本(上线重要的功能,产品有大的改动)、中版本(上线小功能,产品有小的改动)、小版本(修改bug,增加非功能需求,用户体验不出来有什么变化)
版本更新尽量以中版本比较好,让用户知道产品有一些变化,修复bug,有人在维护。
大版本不宜连续推出。
如果是非常紧急的bug,则要立马修复更新。
版本更新有节奏感,每个版本的发布时间间隔,尽量保持一致,间隔不要太短,不要太长。这样可以让用户有一个稳定的预期。频繁跟新和长久不更都会带来不好的体验。运营开发也有好的心理预期。
发布时要做的准备。1、如果是递交应用商店,要准备好应用商店的图片,产品介绍,和版本更新说明。2、提前告知其他团队成员,预期在什么时间发布什么版本,版本改动的是什么,好让他人做好准备。3、发布后要对产品数据和用户反馈保持持续关注,看新版本在这些地方带来的影响。
什么是灰度发布?
很多时候,你不能确定新增加的功能,用户的反馈如何,如何一下子给所有人更新,可能会带来大批量的抱怨,再次调整也变得困难,这个时候就需要灰度发布。
让一部分用户继续用A版本,一部分用户开始用b,如果用户对b没有什么发对意见,那么逐步扩大范围,把所有用户迁移到b上,灰度发布能保证整个系统的稳定,在初始灰度的时候就可以发现、调整问题,保证影响度。
做法:先选定部分用户,向这些用户推送弹窗,点击弹窗即可下载安装包。
第五小节,时间管理
1、速战速决:有的工作拖得越久越难完成,尽量一口气把这个工作干完。如果这个工作的确要花很多时间,没有办法短时间完成,就分解工作,一个任务一个任务去完成。
2、有些工作做个差不多,然后做下一个,然后回过头,也许有新想法能做的更好。
3、不要闭门造车。在某个地方有困难,可以寻求同事或他人的帮助。
4、休息一下,能有创意。
5、为任务分配优先级。紧急、重要、非重要、非紧急。
6、制定工作计划。长期目标、短期目标、周计划、日计划。
第六小节,产品生命周期管理
1、引入期。增长率在10%以内为引入期。验证产品的可行性,寻找可行的盈利方式、市场推广方法,完善产品结构。
2、成长期。增长率大于10%为成长期。不断完善产品的功能,想办法扩大用户群,加速增长,优化产品的细节和用户体验,完善产品的技术框架,加大推广力度,开始制定竞争策略。
3、成熟期。因为市场饱和导致的增长率下降为成熟期。这个阶段主要解决bug,维持产品的稳定,提升留存,用户活跃率为主,适时的增加一些亮点功能,跟随潮流持续改进,持续完善产品的细节和用户体验,争夺竞争对手的市场。
4、衰退期。增长率为负值。这个阶段做的事儿包括积极转型,寻找重新增长的方法,或想办法,降低产品衰退的速度,或利用余热,帮助其他产品增长,或放弃该产品,投入下一款产品之中。
免费型产品会有点不同,很多产品进入成熟期后都没有盈利。