如何为需求划分优先级？

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

不知道你有没有遇到过这样的情况，按照书上说的，找客户划分需求优先级，客户会瞪大了眼睛看着你：”都重要啊，优先级都高。”
于是，你开始尝试使用书上说的另外一种方法问：“哪些是又重要又紧急的呢？”客户会白你一眼“都很重要都很紧急，快去干活吧，别瞎琢磨了。”

书上说的方法其实没错，但是却没有实际应用的价值，太过于理论化了。
我今天想来和大家聊一聊我是如何给需求划分优先级的。

在讲这个之前，我想问大家一个问题，你们了解测试人员是怎么划分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），如果想与小婧同行，就请关注我吧！