新闻资讯频道
域名领域最新资讯

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

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

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

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

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

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

    在讲这个之前,我想问大家一个问题,你们了解测试人员是怎么划分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的要求真的没那么复杂,但是如果自己思路都不清晰,你还能指望产品能带来怎样的价值和体验呢?

    未经允许不得转载,或转载时需注明出处:西部数码域名资讯|域名门户|域名新闻中心 » 案例实操:如何为需求划分优先级?
    分享到:更多 ()

    中国领先的互联网域名及云服务提供商

    域名注册云服务器