突然资讯网
首页 >> 科技 >> 正文

产品经理,需求池和版本树

日期:2020-01-24 21:47:27 来源:互联网 编辑:小优 阅读人数:441

人人都是产品经理,但是产品经理的梯子上,各自的高度很不一样。有人才刚刚登上这架梯子,有人已经高入云端;有人费力攀爬,有人缓步款行;有人刻苦专研,有人冷静理智...

正式成为产品两年,在产品的路上走了好长一段...更想着和同行交流沟通,帮助他人到我的境界,学习他人优长自我成长。

各位看官,且看我先拆解产品经理。提前预告一下,进行产品的整体版本,我使用的方法是:先控制,后碎部,步步检核

一、产品研发的极简过程

产品经理,需求池和版本树(图1)

树的形象生长

1,产品概述

产品就是一棵树的形象,从生长环境的泥土里吸收养分,一个阶段一个阶段的成长。产品也需要是一颗树的形象,在自己的成长中挺直主干,直冲苍天。在努力成长中,给人一片阴凉,呵护一方水土;即使在之后倒下,也能够提供自己的身躯,给他人以借鉴,再铺一段路桥。

2,需求池和版本树

产品经理,需求池和版本树(图2)

需求池和版本树简版

抽象的需求池版本树形象,底部平台为需求池,上面分支生长开来为版本树。借用简单的形象,就能从大局着手,看清楚一些最核心的内容。

在需求池上,本质是提供产品的生长环境。作为树的形象生长,就需要生长环境土壤肥沃,获取必要元素足够。那么,在实际的需求池构建上,就需要有广泛的意见收集,经过专业的筛选过滤,输出形成定版的需求。

以上各个维度构建了需求池搭建的相对完善的框架,基于产品不同的生命周期、当前所处的阶段,需要给与不同维度不同的权重。信息的权衡采纳,决定什么内容被产品当前版本吸收,这是很关键的一部分。当前范围的确定,从宏观上,确定了产品所需要的必要元素,从而筛选出来最有效的内容,促进产品快速成长。

3,需求池和版本树关键内容

在产品成长中,产品发展相似与树,但是又不同于树。树的生长经不起一段生命周期的内容完全剥离,且在树的生长过程中,原有的树干也会逐渐粗壮起来。

也因此,延伸出来,产品的版本树需要能够在未来枝繁叶茂,需要在主干业务上搭建最强壮的框架。之后的 业务会一直使用最初始的框架,也就决定了之后的产品是否能够走的更远,长得更好。这也符合,先控制后碎部的思想,更符合事情的二八定律。做好一件事情,做好最关键的部分,事情就算完成百分之八十。

同样的,在产品树出现问题时,要敢于及时削掉不必要的部分。产品多余的部分在树上面就是个疙瘩,在实际的产品上,不只是消耗内部因为这个功能牵连的人力物力投入,更会在用户上消耗用户的好用度,会降低整个产品的品质。

而这些最关键的部分就是,树要成长,产品需要不断版本升级来变得更好,那就需要落实,需要更高效的产品成长。也就是产品一个版本一个版本的实现,一个版本基于上一个版本的迭代升级。在研发过程中,消耗最大的就是需求不确定,来回版本的更改。需求整理,需求讲解,UI设计,研发实现,验证,是一个个工作环节串联起来的。工作环节越往后靠,前面消耗的时间就越多,所以,最好的方式就是需求定版,从最开始的环节把控好需求的执行,确定最为清晰的目标。

产品经理,需求池和版本树(图3)

需求池和版本树标准版本

二、需求池

1需求收集:战略规划、市场反馈、用户反馈、产品设计、竞品分析、技术革新

2需求整理:伪需求、表层需求、真实需求、兴奋需求、深层需求

3需求筛选:需求重要性、需求紧急度、影响范围、安全性、时间要求、技术难点

4需求设计:用户角色、使用场景、业务流程、使用流程、数据追踪、原型图设计、PRD文档维护

5项目:时间进度规划、产品质量验收

产品经理,需求池和版本树(图4)

需求池和版本树豪华版本

1,需求整理

信息大时代,相比于信息匮乏年代的信息内容缺乏,信息的堆积和冗余并不会更简单更容易处理。经过需求池构建六个维度的信息收集,关于产品设计,我们获取了大量的信息。而从这些信息中筛选出来真实需求就十分必要。

需求整理,是对需求信息的遴选,是把非必要的需求信息剔除出去。

需求挖掘中,对需求进行层次划分,细分为伪需求、表层需求、真实需求、兴奋需求、深层需求。其中伪需求、表层需求,就是最没必要的需求。这些只是用户痛点的遮盖布,我们都没有看到真正的病痛表现。真实需求,就是直观的展示,看到的就是需要的,这种需求就需要再度识别,或许头疼就真的只是头疼。而对于兴奋需求、深层需求,就是掩藏在头痛下的根本,挖掘到根本,最后实现的产品才会真正接近用户的需要。

头疼若不是头疼,可能只是需要你的关心,那就是兴奋需求。不需要管什么头疼,对她呵护备至、疼爱有加,她的头疼就不是产品的问题,而是产品的价值!

头疼若不是头疼,而是其他脏器损坏的痛觉转移,那就是深层需求。不管如何去医治头疼,最后不解决脏器的问题,头疼问题就算解决,也还有其他疼痛问题。

常见的说明,都会是更快马车的真实需求,这里换工作的生活例子看看。

老板需要日周月报?是需求,是真实需求,但只是需求的表象。老板需要的是日周月报,但其实他更需要的员工的有效工作权衡证据,若是及时反馈任务进度,及时反馈异常信息,那日周月报还需要?或许这还不足够,老板为什么需要进度,为什么需要他来进度?因为进度不如预期,至少在之前的所有工作中,进度都不如预期,或者说是,常常他以为是这样但现实却不是这样。在深挖一点就是,他没有安全感,他不信任,那么是谁给了他不安全感呢?是人员的能力不匹配?是项目安排执行不够精准?

这估计就是职场,需要事事有回应、件件有着落的根本原因吧!

替换日周月报,更好的是目标、状态、进度、预期执行结果的统计表。本周正在做XX竞品分析,正常状态,进度50%,明天中午十二点结束。

2,需求筛选

经过需求整理,所留下来的需求都是真实的需求,百川终到海。而所有的需求又需要排列顺序,从而决定哪些需求优先做,逐渐形成需求的金字塔。

其中筛选的重要条件包括,需求的重要性,需求的紧急度,影响范围、安全性、时间要求、技术难点等要素。依据产品的不同的阶段,公司发展的状态,产业所处的行业,当前的生产环境等会给与需求不同要素不同的比重。

整体回馈,还是要依据先控制后碎部,步步检核的原则来设定。技术难度、安全性会在很大程度成为一票否决权的情况,需要优先确定。之后依据重要度、紧急度、时间要素等综合,按照数字打分的方式对需求的权重进行数字化,从而辅助决策。

同时,在公司进行重大决策,重大变更时,也会协调相关的人力资源倾斜来实现,从而让项目落地到实处。实际的情况就是,当前要做的内容多,重要性都高,且最好都一次性上线,在这种高度挤压集中的情况下,产品就更应该集中精力把产品的设计、需求的完善落到实处。把人力不足,时间紧迫等相关问题交于项目来协调。

专业的人办专业的事情,将是最为高效的。也就需要,在自己把控或者不属于自己管控范围内的,要迅速给与他人以合适的信息,让其他人共同协助实现。这也更是给与其他人实现自我价值的机会。

在没有那么紧迫,没有那么多需求堆积时,相对的处理也就更容易。

3,需求设计

经过前面相对较为“复杂”的过程,确保需求有效的被筛选出来,更关键的就是把需求做出来。

在需求设计时,推荐用户角色,使用场景,业务流程,使用流程,数据追踪的方式进行整体的设计。

整体业务逻辑梳理清楚,但作为步步检核的坚定执行者,还需要验核上面所有的流程是否真的完善,那就使用数据流检核。内容的数据流,主要是内容的产生到内容的消逝,就会发现之前的流程设计,还缺乏内容的撤销和删除。基于每一个功能拆解数据的产生,数据的流转过程,数据的消逝,以及所有数据的统计分析,从而验证功能设计的完善性。

最终输出就是原型图,最好能够整理PRD文档。基于当前很多公司是实际执行情况,建议把PRD文档的内容完善补充到原型图中,配合问题列表,实现文档的高效化使用,以及内容的可追踪性。

三、版本树

1核心业务实现,业务框架的搭建

2登录注册用户体系搭建

3业务商城推广

4活动模板构建

5数据挖掘

6产品监控自我优化

从实际的经验中来,需求讲解,其他相关人员参与度不一定很高。而在需求讲解中,给其他人不确定的提问,有助于帮助集中所有成员的注意力。更是通过提高他的信息输出来倒逼他的信息输入。在相对规范的公司,会需要所有人员再写需求确认,从而实现需求的传达一致性。

在过去从事的项目执行中,配合先控制后碎部,步步检核的理论,整理出来如下项目的模型,期许能够辅助大家将项目执行更好的落地。整个项目的执行,主要分为阶段,应用里程碑作检核;把阶段拆解为任务,用检查表来检核。

一般的版本升级迭代,阶段划分可以分为需求整理阶段,UI设计阶段,研发实现阶段,阶段。各个阶段的里程碑是对过去的一个阶段的整理,也是两个阶段的交接,更是阶段产物的验核。对产品来说,需求设计完成的阶段,需要交给下一个阶段需求设计原型图,若是输出完整的PRD文档是最恰当的。通过需求评审,进行需求设计的再一次检核,集大家的智慧完善需求,确保需求设计考虑完善。需求设计阶段中的任务拆解,就可以使用之前的环节,包括需求收集,需求整理,需求筛选,需求设计,而对应各个任务的检查表就是对应任务的结果。需求收集,得到的结果应该是一张需求统计表,记录当前所有有可能需要执行的需求;需求整理,则是将哪些需求屏弃掉,将精力锁定在最关键的需求上;需求筛选,得到的结果是用什么样的理由决定了哪些需求当前版本优先执行,且各自的执行顺序是怎样的;需求设计也就是原型图设计,达到能够很好传递信息给后续环节的目标。

产品经理,需求池和版本树(图5)

项目的理论整合

在项目的执行中,也要求项目做结项处理。从而形成项目经验,让后续新项目的执行基于当前项目进行维度升级。同时,项目中的执行文档、检查表、项目阶段规划,都是相关项目的实例,可依据这个内容抽取形成模板,构成每个参与者的勋章。

四、产品自我优化

1产品自我审视:版本树复盘

2用户行为研究,大数据分析

3用户直接反馈渠道

4MVP:最小最有价值产品版本

产品经理,需求池和版本树(图6)

用心耕耘

一个产品就是在这样的流程下,产品逐渐变得越来越好;一个团队,也就是在这样的项目执行下,变得越来越专业,越来越高效。

在项目都在推行项目复盘的情况,那么每一次的需求实现及运行,也需要对产品进行需求复盘,对“枝丫”需求进行适当的删减,对“主干”进行适当的补充完善,使其更加茁壮成长。

在产品过程中,也需要监控产品本身。依据产品用户群体的活跃度、留存率等来辅助确定产品的朝向;用各个页面的使用率及使用路径跟踪,确定产品的设计优化,辅助产品进行内容改版和升级;用产品的版本对比、时间对比、峰值、数据量等多方面变化来检核产品,进行自我的辩证认知。大数据的分析和挖掘,将能辅助产品走的更远,走的更稳。

产品还是需要根植于用户,构建用户的反馈渠道,就能更直接的和用户接触,也更能发现那些细节问题、特殊情况问题,也是另一个坚持,步步检核。

在整个整理过程中,会发现,需求的整理及实现,花费了大量的时间和精力。在实际的执行中,因为需求池的明确,需求筛选之前的很多事情都省掉。最关键是,所有的需求按照深度思维都是可以不断挖掘的,但是在实际的清醒中,会因为生命周期、产品阶段,会存在部分功能隐藏较深,不被使用的情况。所以,产品在初期的需求设计中,不必尽善尽美。在完成核心业务逻辑的实现后,需要尽快投入市场,依据市场的反馈,更加及时的修改,以确保产品深耕于用户群。这就是产品最小最有价值版本设计的方法,即是MVP,也确实是MVP。

一个人可以走很快,一群人可以走很远!

也是如此,整个内容框架适合整个方向的工作,而个人需要依据实际情况,进行方法的筛选,截取对自己最有效的部分,执行正确的内容,并正确的执行

向阳生长,和有趣的人同行。别怂~

本文相关词条概念解析:

需求

需求,是指系统必须符合的条件或具备的功能。经济学中需求是在一定的时期,在一既定的价格水平下,消费者愿意并且能够购买的商品数量。需求显示了随着价钱升降而其它因素不变的情况下(ceterisparibus),某个体在每段时间内所愿意买的某货物的数量。在某一价格下,消费者愿意购买的某一货物的总数量称为需求量。在不同价格下,需求量会不同。需求也就是说价格与需求量的关系。若以图像表示,便称为需求曲线。

网友评论