案例实操：如何为需求划分优先级？

《案例实操：如何为需求划分优先级？》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、案例实操：如何为需求划分优先级？不论你是科班出身，还是半路出家，只要涉及到需求管理，就会涉及到“优先级”这个话题。不知道你有没有遇到过这样的情况，按照书上说的，找客户划分需求优先级，客户会瞪大了眼睛看着你：”都重要啊，优先级都高。”于是，你开始尝试使用书上说的另外一种方法问：“哪些是又重要又紧急的呢？”客户会白你一眼“都很重要都很紧急，快去干活吧，别瞎琢磨了。”书上说的方法其实没错，但是却没有实际应用的价值，太过于理论化了。我今天想来和大家聊一聊我是如何给需求划分优先级的。在讲这个之前，我想问大家一个问题，你们了解测试人员是怎么划分BUG等级的吗

2、？我来列举一下一般的划分方法：致命：系统崩溃严重：主线流程阻塞一般：对分支有影响，但是不影响主线流程轻微：不影响使用，只是用户体验不是那么好你看，非常清晰吧？测试人员在提BUG的时候，就是根据这些标准进行等级划分，程序猿优先修正致命、严重的缺陷。大家就像机械中的齿轮一样，高效运转。这完全依赖于齿轮间的规则定义。需求是否也可以以此类推呢？我们可以借鉴下，但是需求的情况可能更复杂一些。众所周知，需求一般分为：高、中、低。但是分别代表了什么呢？借鉴对BUG的划分：高：主线需求中：主线上的分支需求低：锦上添花的需求怎么定义主线需求呢？我在以前的文中提到过

3、“BackBone”这个词。这个词怎么理解呢？我们一般在做整个产品规划、模块规划的时候，会将这个定义清楚。以下的需求属于BackBone的范畴：1.体现产品核心价值这个说的有点虚，咱务点实。也就是你的产品定位是怎样的，为了解决用户的什么问题，而这个需求就是解决这个痛点问题的。比如，KEEP是为了解决想要坚持锻炼的问题，那么核心的运动记录的需求就肯定不能砍。2.影响主流程的需求你在画整体业务流程的时候，就可以清晰的定义出哪些是必不可少的活动，比如，登录。但是，一定要把业务流程画清楚了再讨论，别把自己想象的那么强大，用大脑就能定义出哪些是主流程。3.

4、如果没有，客户会抓狂的需求这点往往被忽视。有那么一些需求，你觉得可有可无，即不属于核心价值也不属于主流程.但是你一定要多问一句：如果没有会造成什么后果。比如，有的工具软件有“云备份”的需求。这个需求就属于这个范畴的。当你终于列出所有需求的优先级后，又傻了。发现100个需求里面，高的50个，中的30个，低的20个。显而易见，50个肯定是要先做的，最重要的。但是，50中间又有哪些是需要最先做的呢？这里分享给大家一个非常好用的方法，我不仅将其应用在了需求优先级定义上，更是应用在了我的日常生活和工作中：Point。你可以想象一下，一开始所有的需求在一个大

5、盆里，你通过第一次筛选，把它们放在了三个小盆里。接下来要做的就是把它们码一遍，定义point。一个需求只有唯一的一个point。首先将最重要的需求定义为100，然后将最不重要的定义为5。接下来进行两两比较，依次给每个需求都定义一个point。比如，我定义100的是“作为运动者，我希望可以用文字进行运动记录，以便未来进行查看和分享”；接下来一个“作为运动者，我希望可以用文字+一张图片进行运动记录，以便未来进行查看和分享”我会定义为90。中间为什么空了那么多？是为了后面更重要的腾位置。比如“作为运动者，我希望可以将记录进行累计，以便可以炫耀我坚持了多

6、久”，这个需求我可以定义为95，而不用挪动已有需求的位置。等你整理完，你会发现神清气爽，任督二脉都被打通了。怎么会有这么神奇的功效？这个过程其实是你对自己产品的深度整理和理解的过程。之前很多混混沌沌的东西，你必须比较清晰了才能完成这项工作。而且你并非拍脑袋得出优先级和Point，而是通过缜密的思考和分析得出的结论。在后面真正投入研发后，你会发现需求变更也随之减少，你对于新需求到底要不要做，放在哪个版本做也会有很清晰的判断。最重要的是，妈妈再也不用担心程序猿GG砍你了……写在最后：划分需求优先级是一件很严肃的事情，真的。我希望大家能重视起来这件事。

7、最近有不少人和我说起了程序猿心里苦，详细问下来觉得可能很多时候是产品经理或者BA真的没想清楚就开工造成的。但是这其中原因有很多，工期紧、老板凶……我只能和他们强调，我们要接受需求变更，以乐观的心态。但是真心建议大家根据我说的方法去尝试划分一下需求的优先级，整理一下，让自己和团队的工作更井井有条。对BA的要求真的没那么复杂，但是如果自己思路都不清晰，你还能指望产品能带来怎样的价值和体验呢？标签：案例分析需求优先级需求分析