不论你是科班出身，还是半路出家，只要涉及到需求管理，就会涉及到“优先级”这个话题。
不知道你有没有遇到过这样的情况，按照书上说的，找客户划分需求优先级，客户会瞪大了眼睛看着你：”都重要啊，优先级都高。”
于是，你开始尝试使用书上说的另外一种方法问：“哪些是又重要又紧急的呢？”客户会白你一眼“都很重要都很紧急，快去干活吧，别瞎琢磨了。”
书上说的方法其实没错，但是却没有实际应用的价值，太过于理论化了。
我今天想来和大家聊一聊我是如何给需求划分优先级的。
在讲这个之前，我想问大家一个问题，你们了解测试人员是怎么划分BUG等级的吗？
我来列举一下一般的划分方法：
致命：系统崩溃
严重：主线流程阻塞
一般：对分支有影响，但是不影响主线流程
轻微：不影响使用，只是用户体验不是那么好
你看，非常清晰吧？
测试人员在提BUG的时候，就是根据这些标准进行等级划分，程序猿优先修正致命、严重的缺陷。
大家就像机械中的齿轮一样，高效运转。这完全依赖于齿轮间的规则定义。
需求是否也可以以此类推呢？
我们可以借鉴下，但是需求的情况可能更复杂一些。
众所周知，需求一般分为：高、中、低。
但是分别代表了什么呢？
借鉴对BUG的划分：
高：主线需求
中：主线上的分支需求
低：锦上添花的需求
怎么定义主线需求呢？
我在以前的文中提到过“BackBone”这个词。这个词怎么理解呢？
我们一般在做整个产品规划、模块规划的时候，会将这个定义清楚。
以下的需求属于BackBone的范畴：
-
体现产品核心价值
这个说的有点虚，咱务点实。
也就是你的产品定位是怎样的，为了解决用户的什么问题，而这个需求就是解决这个痛点问题的。
比如，KEEP是为了解决想要坚持锻炼的问题，那么核心的运动记录的需求就肯定不能砍。
影响主流程的需求
你在画整体业务流程的时候，就可以清晰的定义出哪些是必不可少的活动，比如，登录。
但是，一定要把业务流程画清楚了再讨论，别把自己想象的那么强大，用大脑就能定义出哪些是主流程。如果没有，客户会抓狂的需求
这点往往被忽视。
有那么一些需求，你觉得可有可无，即不属于核心价值也不属于主流程.
但是你一定要多问一句：如果没有会造成什么后果。
比如，有的工具软件有“云备份”的需求。这个需求就属于这个范畴的。
当你终于列出所有需求的优先级后，又傻了。
发现100个需求里面，高的50个，中的30个，低的20个。
显而易见，50个肯定是要先做的，最重要的。
但是，50中间又有哪些是需要最先做的呢？
这里分享给大家一个非常好用的方法，我不仅将其应用在了需求优先级定义上，更是应用在了我的日常生活和工作中：Point。
你可以想象一下，一开始所有的需求在一个大盆里，你通过第一次筛选，把它们放在了三个小盆里。
接下来要做的就是把它们码一遍，定义point。
一个需求只有唯一的一个point。
首先将最重要的需求定义为100，然后将最不重要的定义为5。
接下来进行两两比较，依次给每个需求都定义一个point。
比如，我定义100的是“作为运动者，我希望可以用文字进行运动记录，以便未来进行查看和分享”；
接下来一个“作为运动者，我希望可以用文字+一张图片进行运动记录，以便未来进行查看和分享”我会定义为90。
中间为什么空了那么多？是为了后面更重要的腾位置。
比如“作为运动者，我希望可以将记录进行累计，以便可以炫耀我坚持了多久”，这个需求我可以定义为95，而不用挪动已有需求的位置。
等你整理完，你会发现神清气爽，任督二脉都被打通了。
怎么会有这么神奇的功效？
这个过程其实是你对自己产品的深度整理和理解的过程。
之前很多混混沌沌的东西，你必须比较清晰了才能完成这项工作。
而且你并非拍脑袋得出优先级和Point，而是通过缜密的思考和分析得出的结论。
在后面真正投入研发后，你会发现需求变更也随之减少，你对于新需求到底要不要做，放在哪个版本做也会有很清晰的判断。
最重要的是，妈妈再也不用担心程序猿GG砍你了……
写在最后：
划分需求优先级是一件很严肃的事情，真的。
我希望大家能重视起来这件事。
最近不论简书还是公众号上都有不少人和我说起了程序猿心里苦，详细问下来觉得可能很多时候是产品经理或者BA真的没想清楚就开工造成的。
但是这其中原因有很多，工期紧、老板凶……
我只能和他们强调，我们要接受需求变更，以乐观的心态。
但是真心建议大家根据我说的方法去尝试划分一下需求的优先级，整理一下，让自己和团队的工作更井井有条。
对BA的要求真的没那么复杂，但是如果自己思路都不清晰，你还能指望产品能带来怎样的价值和体验呢？
小婧是一名资深业务分析师（BA），如果想与小婧同行，就请关注我吧！
