微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

案例实操:如何为需求划分优先级?

来源: 2389
爱盈利(aiyingli.com)移动互联网最具影响力的盈利指导网站。定位于服务移动互联网创业者,移动盈利指导。我们的目标是让盈利目标清晰可见!降低门槛,让缺乏经验、资金有限的个人和团队获得经验和机会,提高热情,激发产品。

不论你是科班出身,还是半路出家,只要涉及到需求管理,就会涉及到“优先级”这个话题。

案例实操:如何为需求划分优先级?

不知道你有没有遇到过这样的情况,按照书上说的,找客户划分需求优先级,客户会瞪大了眼睛看着你:”都重要啊,优先级都高。”

于是,你开始尝试使用书上说的另外一种方法问:“哪些是又重要又紧急的呢?”客户会白你一眼“都很重要都很紧急,快去干活吧,别瞎琢磨了。”

书上说的方法其实没错,但是却没有实际应用的价值,太过于理论化了。

我今天想来和大家聊一聊我是如何给需求划分优先级的。

在讲这个之前,我想问大家一个问题,你们了解测试人员是怎么划分BUG等级的吗?

我来列举一下一般的划分方法:

  • 致命:系统崩溃
  • 严重:主线流程阻塞
  • 一般:对分支有影响,但是不影响主线流程
  • 轻微:不影响使用,只是用户体验不是那么好

你看,非常清晰吧?

测试人员在提BUG的时候,就是根据这些标准进行等级划分,程序猿优先修正致命、严重的缺陷。
大家就像机械中的齿轮一样,高效运转。这完全依赖于齿轮间的规则定义。

需求是否也可以以此类推呢?

我们可以借鉴下,但是需求的情况可能更复杂一些。

众所周知,需求一般分为:高、中、低。

但是分别代表了什么呢?

借鉴对BUG的划分:

  • 高:主线需求
  • 中:主线上的分支需求
  • 低:锦上添花的需求

怎么定义主线需求呢?

我在以前的文中提到过“BackBone”这个词。这个词怎么理解呢?

我们一般在做整个产品规划、模块规划的时候,会将这个定义清楚。

以下的需求属于BackBone的范畴

1.体现产品核心价值

这个说的有点虚,咱务点实。也就是你的产品定位是怎样的,为了解决用户的什么问题,而这个需求就是解决这个痛点

问题的。

比如,KEEP是为了解决想要坚持锻炼的问题,那么核心的运动记录的需求就肯定不能砍。

2.影响主流程的需求

你在画整体业务流程的时候,就可以清晰的定义出哪些是必不可少的活动,比如,登录。
但是,一定要把业务流程画清楚了再讨论,别把自己想象的那么强大,用大脑就能定义出哪些是主流程。

3.如果没有,客户会抓狂的需求

这点往往被忽视。

有那么一些需求,你觉得可有可无,即不属于核心价值也不属于主流程.

但是你一定要多问一句:如果没有会造成什么后果

比如,有的工具软件有“云备份”的需求。这个需求就属于这个范畴的。

当你终于列出所有需求的优先级后,又傻了。

发现100个需求里面,高的50个,中的30个,低的20个。

显而易见,50个肯定是要先做的,最重要的。

但是,50中间又有哪些是需要最先做的呢?

这里分享给大家一个非常好用的方法,我不仅将其应用在了需求优先级定义上,更是应用在了我的日常生活和工作中:Point。

你可以想象一下,一开始所有的需求在一个大盆里,你通过第一次筛选,把它们放在了三个小盆里。

接下来要做的就是把它们码一遍,定义point

一个需求只有唯一的一个point。

首先将最重要的需求定义为100,然后将最不重要的定义为5。

接下来进行两两比较,依次给每个需求都定义一个point。

比如,我定义100的是“作为运动者,我希望可以用文字进行运动记录,以便未来进行查看和分享”;
接下来一个“作为运动者,我希望可以用文字+一张图片进行运动记录,以便未来进行查看和分享”我会定义为90。

中间为什么空了那么多?是为了后面更重要的腾位置。

比如“作为运动者,我希望可以将记录进行累计,以便可以炫耀我坚持了多久”,这个需求我可以定义为95,而不用挪动已有需求的位置。

等你整理完,你会发现神清气爽,任督二脉都被打通了。

怎么会有这么神奇的功效?

这个过程其实是你对自己产品的深度整理和理解的过程。

之前很多混混沌沌的东西,你必须比较清晰了才能完成这项工作。

而且你并非拍脑袋得出优先级和Point,而是通过缜密的思考和分析得出的结论。

在后面真正投入研发后,你会发现需求变更也随之减少,你对于新需求到底要不要做,放在哪个版本做也会有很清晰的判断。

最重要的是,妈妈再也不用担心程序猿GG砍你了……

写在最后:

划分需求优先级是一件很严肃的事情,真的。我希望大家能重视起来这件事。

最近有不少人和我说起了程序猿心里苦,详细问下来觉得可能很多时候是产品经理或者BA真的没想清楚就开工造成的。

但是这其中原因有很多,工期紧、老板凶……

我只能和他们强调,我们要接受需求变更,以乐观的心态。

但是真心建议大家根据我说的方法去尝试划分一下需求的优先级,整理一下,让自己和团队的工作更井井有条。

对BA的要求真的没那么复杂,但是如果自己思路都不清晰,你还能指望产品能带来怎样的价值和体验呢?

 

作者:小婧,资深业务分析师(BA)

来源:公众号:与小婧同行(xiaojing-jessieyj)

本文由 @小婧 授权发布于爱盈利-运营小咖秀,未经作者许可,禁止转载。

爱盈利-运营小咖秀 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号