文 / 十三

明天这篇文章聊聊定义需求优先级的办法，这几个办法是十三经过学习战争时任务的复盘考虑总结而来，在这里分享给你，希望与你一同交流。

请屏住呼吸仔细读，由于前面也许一句废话都没有。

总的来说，定义需求优先级暂时有这七个办法：

KANO模型法：根本型需求>希冀型需求>兴奋型需求

矩阵剖析法：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急

经济收益法：经济收益高且紧迫的功用需求  ＞ 经济收益高但不紧迫的功用需求  ＞ 紧迫但经济收益不高的功用需求  ＞ 不紧迫且经济收益不高的功用需求

前/后置需求剖析法：前置需求的优先级  ＞ 后置需求的优先级；前置需求的重要性和紧迫性  ＞ 后置需求的重要性和紧迫性

满足中心用户需求的优先（二八准绳）

满足中心业务的需求优先（资源最大化应用）

满足中心业务的投入产出比最大的需求优先（ROI最大化）

上面为你逐个道来。

办法1：KANO模型法：根本型需求>希冀型需求>兴奋型需求

KANO模型是东京理工大学教授狩野纪昭(Noriaki Kano)创造的对用户需求分类和优先排序的一种工具。

浅显地讲，人的需求可以分为三种，包括根本型需求，希冀型需求和兴奋型需求。

以我们平常坐车下班为例，坐公交坐地铁是根本型需求，打的是希冀型需求，每天有人接送上上班则是兴奋型需求。很容易了解吧。

所以，不言而喻，根本型需求的优先级该当排在第一位，希冀型需求排在第二位，而兴奋型需求则排在最初。在互联网产品的设计研发进程中，我们可以依照这个顺序来排定需求优先级。

办法二：矩阵剖析法：重要且紧急>重要不紧急>紧急不重要>不重要也不紧急

矩阵剖析法，也叫四象限规律，把一个二维的横竖坐标分红四个象限，横坐标是重要性，纵坐标是紧急性。第一象限为重要且紧急，第二象限为紧急不重要，第三象限为不重要也不紧急，第四象限为重要不紧急。

在任务当中，我们可以依据以后实践状况，把手头上的一切任务依据四象限规律停止重要性与紧急性的剖析定义，然后把这些任务逐个放进相应的象限当中，最初再依照矩阵剖析法的顺序来完成任务。

举个例子，你如今手头有四件事情需求处置。第一件事情是你女冤家今天生日，而你还没预备好礼物（偷笑）。第二件事情是运营部本月15号要做一个活动，明天是3号，运营部希冀最晚14号要完成内测，确保可以在15号按时上线。第三件事是开发说需求文档里有个中央表述有点成绩，怕了解错误，希望你在上班前跟他解说一下。第四件事是周末有个聚会，大家让你引荐个地儿。

依据矩阵剖析法，你应该依照事情一>事情二>事情三>事情四的顺序来顺次完成。

办法三：经济收益法：经济收益高且紧迫的功用需求  ＞ 经济收益高但不紧迫的功用需求  ＞ 紧迫但经济收益不高的功用需求  ＞ 不紧迫且经济收益不高的功用需求

这个办法其实跟矩阵剖析法道理是一样的。异样是把一个二维坐标轴分红一个矩阵（四个象限），横坐标是经济收益，纵坐标是紧迫度。第一象限是经济收益高且紧迫度高，第二象限是紧迫度高但经济收益不高，第三象限是紧迫度低且经济收益不高，第四象限是经济收益高但紧迫度低。

那么同理可得，我们在停止用户需求剖析，排需求优先级的时分，也可以依照这个办法来处置。关于经济收益高且紧迫的需求，我们就该当列在 P1 优先级里。而关于经济收益低又不紧迫的需求，我们就该当列在 P3 优先级里。（注：P1，P2表示优先级的上下，P1>P2>P3）

办法四：前/后置需求剖析法：前置需求的优先级  ＞ 后置需求的优先级；前置需求的重要性和紧迫性  ＞ 后置需求的重要性和紧迫性

所谓前/后置需求剖析法，是指在一款产品的开发进程中，有的需求是必需要提早开发的，而有些需求是可以放在项目前期开发的。

比方电商网站中，注册登录、选品加购、下单结算和领取这些是必需要优先开发终了的，否则用户基本无法顺畅地完成一个完好的购物流程。

不过，为了使整个购物流程更闭环，我们能够需求添加评价模块，支持用户下单成功后可以评价商品，以此作为获取用户需求的一种通道；为了安慰和进步用户回流，我们能够需求在领取成功页添加特性化商品引荐模块和促销广告模块；为了引导用户停止购置决策，我们能够需求在分类列表页/商详页/活动页等各个页面添加一个促销标识、用户评价数、下双数等信息。前面说的这些，都是可以在完成最复杂根底的MVP 电商网站之后再排期开发的。

或许任何一个需求前后端协作的需求，接到需求的时分，前端和后端可以同时开端，但由于任务量或其他缘由，能够后端需求的工夫久一些。但前端要写完这个功用必需用到后端接口，所以从实际上后端接口该当提早开发终了，这样才干在 deadline 使前后端都完成这个功用的全部开发任务。

前/后置需求剖析法也是日常任务中时常可以运用的，大家可以尝试下。

办法五：满足中心用户需求的优先（二八准绳）

这个很好了解的。产品的用户有中心用户（能够 80% 左右），也有边缘用户（能够 20%  左右）。产品自身就是为那 80% 的中心用户开发的，不能够满足一切用户的一切需求。

所以，中心目的用户的需求永远是放在第一位的，非中心的边缘用户的需求在剖析的时分很顺其自然就会往后排，甚至排到你基本不想开发。

这是绝大局部公司的通用做法，能够只要相似鹅厂这样的公司才会略微思索点边缘用户的需求吧，比方会思索和照顾残障人士的需求。

而在实践任务中，我们能够并不能很明晰地域分出谁是中心用户，谁又是边缘用户。那我们可以复杂转换下思想——提出相反或许相似需求的用户体量有多少。提的人多咱就做（比方100团体里有70团体说要做。），提的人少咱就不做（比方10团体里就1团体说可以做。）

办法六：满足中心业务的需求优先（资源最大化应用）

公司有本人的主营业务，一款产品也有本人重点开展的业务和需求满足的用户群。

比方我如今做餐饮软件，我重点参与的项目次要集中于“智慧门店”这块，那么围绕“智慧门店”的正餐、快餐业务、会员营销、门店的数据统计与剖析等是我们的重点业务，所以在排定需求优先级时，我们就会把这方面的需求排在 P1 优先级里，把其他非中心业务的需求排得比拟靠后。

办法七：满足中心业务的投入产出比最大的需求优先（ROI最大化）

依照办法六的说法，我们该当优先满足中心业务的需求，但中心业务的需求能够有很多，比方我方才说的正餐业务需求，光说正餐业务其实是比拟笼统而空泛的，由于整个正餐业务也许有几百上千个需求。

那么如何从这些需求当中找到优先级排第一的需求呢，这时就可以参考办法七了——在一切能满足中心业务的需求外面，找到投入产出比最大的需求优先开发。

举个例子，我们从整个正餐业务的需求外面抽出 20 个需求放入 P1 优先级需求池，那这 20 个需求究竟先开发哪个呢，依照办法七，先开发投入产出比最大的需求。从实际上讲，总的准绳就是，花最少的工夫、最少的资源、最少的预算开发完功用，尽能够快地赶在工夫窗口，获取最多的用户，赚最多的钱。

当然，说了这么多，能够最终都敌不过老板那句话——来，我们先做这个需求吧。听我说，这是大局部公司的常态，心态放好就ok。

不过，碰到这种状况，我们还是需求剖析一下的。

首先，我们需求尝试站在老板角度考虑成绩，由于我们不是老板，站的高度没有老板高，看得也不如老板远，他对市场的判别能够比你更精确，要命的是也许比你还更懂产品。那么在这种状况下，假如我们跟老板的意见相左，我们可以提出本人的想法，但最终决策权交给老板。

但是，假如老板对产品啥也不懂，就晓得瞎指挥，明天让你先做 a 需求，今天就让你先做 b 需求了，反重复复没个定数。那么作为伟哥，能给你的建议只要一个——赶忙拾掇东西跑路。恩，这也许是你 2018 年听到的最真诚的建议。

最初，不论你在任务中遭到老板多大水平的牵制与干预，作为产品经理，如何去排定需求的优先级，你本人心里要有一杆秤。

好的，明天的分享就酱。