第30件事 定义需求优先级的4种方法

Posted 2020-11-17 sanmaospace

从定义需求的优先级也能看出产品经理的能力。在前面已经详细阐述了如何评估哪些需求该做，哪些需求不该做。对于已经决定要做的需求，若数量很多，就可确定哪些是现在做，哪些是以后做，不可能在同一时间内全部研发完毕。总得有先有后，优先级高的需求优先研发，优先级低的需求延后研发。这就会涉及需求优先级定义的标准。在产品实践中，很多产品经理都是拍脑门决定先做哪些需求，后做哪些需求，要么就是老板拍脑门决定需求的优先级。那到底定义需求的优先级有没有原则和方法呢？先说说原则。在日常生活中，处理任务的优先级有四种情况：重要且紧急、重要不紧急、紧急不重要、不紧急不重要。这四种情况也是我们处理需求优先级的原则，即“重要性+紧急性”。我们把需求的“重要性+紧急性”统称为商业价值原则。基于这个商业价值原则，下面主要阐述需求优先级定义的四种方法。

1.新产品未上线
产品未上线这种情况指的是产品从无到有的这个过程，这种情况因为没有相关的运营数据作为支撑，所以从需求对用户的重要性和紧迫性来判断需求的优先级是一种比较合理的方法。那么如何判断需求对用户的重要性呢？一般情况下，用户需求的重要性依次为：基本型需求>期望型需求>兴奋型需求。使用需求的金字塔法则来表达，金字塔的最底层是基本型的需求，往上是期望型需求，最上面一层是兴奋型需求。
(1).基本型需求是必须有的需求，若没有，用户基本上就使用不了产品，如果金字塔最底层被砍掉，这个需求的金字塔就可能站立不稳而倒下，所以基本型需求的重要性最高。
(2).期望型的需求是用户期望能有的需求，用户希望越多越好，但是如果金字塔的第二层被砍掉，需求的金字塔不会受较大的影响，因为最底层的需求还在，用户还能继续使用产品，所以期望型需求的重要性要低于基本型需求。
(3).兴奋型需求是超出用户预期的需求，若存在，可以给产品加分，没有也无大碍。如果我们砍掉金字塔的最顶层，需求的金字塔更加不会受到影响，因为基本型需求和期望型需求都存在，用户还能继续使用产品，所以，兴奋型需求的重要性要低于期望型需求。其实我们从金字塔的建造过程来看，也是先建造最底层，然后是中间层，最后是最高层。
需要特别注意的是，每个用户心里的基本型需求、期望型需求和兴奋型需求都是不一样的。比如，有的用户认为期望型需求是基本型需求，而有的用户认为兴奋型需求是基本型需求，而且这还随着时间在动态变化，甚至衰减，所以产品需求优先级的定义也要根据当时的实际情况来定。是不是明确需求的重要性之后就可以判断需求的优先级了呢？这里还需要加上一个因素，即紧迫性。基本型需求的重要性最高，且最紧迫，所以基本型需求的优先级默认是最高的。一般情况下，肯定是先做基本型需求，在研发基本型需求的同时，有时候因为运营、营销、销售等业务需求的迫切需要，会同时研发一部分期望型需求（重要不紧迫）和兴奋型需求（紧迫不重要），主要是制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔，这也有利于产品上线初期凭借期望型需求或兴奋型需求赢得用户良好的口碑。
产品与运营是不分家的，从这个案例可以看出，虽然新产品未上线，但是已经开始有以运营为导向的元素出现。因为运营需求的迫切性，应该研发一部分需求来制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔。此外，在产品实践中，很多产品的成功都具有时效性，有的产品在当时的环境中虽然成功了，但是在现在的环境下复制这种曾经成功的模式却不一定会成功，所以通过QQ这个案例，至少可以得出三点结论：一是需求优先级的定义要基于当时的环境和实际情况；二是用户需求是一个动态变化过程，需要适时调整；三是产品与运营不分家，在确保满足基本型需求的同时，也要适当考虑满足用户期望型和兴奋型的需求。

2.免费型产品已经上线
免费型产品已经上线这种情况指的是全部免费型产品（全部功能免费）或者部分免费型产品（有些功能免费，有些功能收费）从有到优（调优）的这个过程，这时候因为有了运营数据的支撑，通过运营数据，能聚类分析出用户的行为，甚至可以给用户画像。那么如何定义需求的优先级呢？这里还是采用需求的商业价值原则，即“重要性+紧迫性”原则。用户有需求，产品利用相应的功能或内容来对应和满足需求，可以根据功能的使用率、使用次数和重要性，形成一个需求重要性的计算公式，根据计算的结果和紧迫性来定义需求的优先级。
用户需求重要性的判断标准：用户基数、使用次数和类别重要性。其中，类别重要性分为基本型、期望型和兴奋型需求三类。对于基本型需求，比如产品的性能、安全、浏览器兼容等方面，一旦出现问题，用户便不能正常使用产品，此时应该立即放下手头的工作，利用一切可利用的资源尽快解决问题。有的公司把这种问题称为“911bug”，意思是说其属于最高级别的bug，优先级最高。比如，网站被黑了，或者使用起来非常慢，用户快崩溃了，这个时候应该想方设法尽快解决。试想一下，如果用户访问或使用不了你的产品，那么不管你的产品功能有多强大，做得有多好，用户还是享受不到。这个时候如果还是投入资源做期望型需求和奋型需求，那么用户就会流失，这是一个常识。对于期望型需求和兴奋型需求，可以通过运营数据形成公式计算。需求对应相应的产品功能，看下边的公式：
用户需求重要性=功能使用用户百分比（用户使用率）×功能使用次数百分比（功能或内容使用率）×类别重要性百分比（期望型需求、兴奋型需求）
注意：最底层的基本型需求不在计算范围内，因为默认其为最高级别。这个需求级别的公式就是综合考虑有多少用户需要、用户是经常需要还是偶尔需要、对用户重要还是不重要三个因素。比如，有的功能相对类别来说重要性虽然高一些，但是使用该功能的用户数和用户次数却比较少；有的功能相对类别来说重要性虽然低一些，但是使用该功能的用户数和用户次数却比较多。根据上述公式计算后得出的结果有可能是：类别重要性比较低的功能，其整体重要性要高于类别重要性比较高的功能的整体重要性。
关于计算公式举例：
A功能属于期望型需求，在一定时期内，假设总的用户数有100人，其中有50人使用过A功能，那么A功能使用用户百分比就是50/100=50%；在这50人使用的过程中，一共使用了10000次，那么使用次数百分比就是10000/50=200；在求类别重要性百分比时，假定期望型需求是50%，那么A功能级别数值为50%×200×50%=50。
B功能属于兴奋型需求，在一定时期内，假设总的用户数有100人，其中有30人使用过B功能，那么B功能使用用户百分比就是30/100=30%；在这30人使用的过程中，一共使用了90000次，那么使用次数百分比就是90000/30=3000；在求类别重要性百分比时，假定兴奋型需求是25%，那么B功能级别数值为30%×3000×25%=225。
可以看出，B功能级别数值225要大于A功能级别数值50，所以B功能的整体重要性要高于A功能。
对用户来说，基本型、期望型与兴奋型需求并不是一成不变的，是一种动态的变化过程，并且运营数据也在不断地发生变化，需要及时做出相应的调整。因此，明确需求的重要性之后，还要按照先做重要且紧迫的需求，后做重要不紧迫的需求，接着做紧迫不重要的需求，最后做不紧迫不重要的需求。

3.收费型产品
收费型产品的情况指的是已经上线或者未上线的全部收费（全部功能收费）或者部分收费的产品（有些功能免费，有些功能收费）。在这里特别说明一下，收费型产品的需求主要也是期望型需求和兴奋型需求，因为基本型需求的优先级默认是最高的（重要且紧迫）。一般情况下，收费型产品是公司的收入来源，如无特殊情况，在同等条件下，收费型的功能优先级一般要高于免费型的功能。那么收费型产品的优先级如何定义呢？定义的标准就是商业价值，即“重要性+紧迫性”，这里的重要性主要指的是经济收益（将战略上的收益也归结为经济收益，包括有形的和无形的收益），经济收益高且紧迫的功能需求先做，经济收益高且不紧迫的功能需求后做，紧急且经济收益不高的功能需求再往后做，不紧迫且经济收益不高的功能需求最后做。

4.前置/后置需求
前置需求的开始日期或完成日期决定后续需求的开始日期或完成日期。注意这里的后续需求就是后置需求。有时候必须先完成前置需求，然后才能实现后置需求。从需求的优先级来看，前置需求的优先级肯定要高于后置需求优先级。前置需求的重要性和紧迫性都要高于后置需求。

总的来说，对于上述四种定义需求优先级的方法，在公司范围内，在特定的产品阶段是可以搭配使用的。需求优先级定义的原则基本上是一样的，都是商业价值原则，即“重要性+紧迫性”。不管在哪一种方法下，基本型需求的优先级默认都是最高的，至于期望型需求和兴奋型需求的优先级，要根据具体的实际情况运用上述一种或几种方法来综合评定，而不是用“拍脑门”的方法确定。
需要特别注意的是，上述内容都是围绕需求的优先级来展开的，是从产品人员的角度来说的。但是从研发人员的角度来说，毕竟他们受到各种人力、物力、财力的限制和影响，并不能完完全全按照产品人员确定的需求优先级来进行研发。相对于基于产品人员确定的需求优先级来说，研发人员会基于开发资源定义出自己的一套研发优先级。至于研发优先级如何定义，将在第31件事中详细阐述。

需求优先级的定义要基于当时的环境和实际情况；用户需求是一个动态变化的过程，需要适时调整；产品与运营不分家，在确保满足基本型需求的同时，也要适当考虑满足用户期望型和兴奋型的需求。