原文：http://blog.sina.com.cn/s/blog_4ff1764801012sod.html

如何定义需求的优先级也是挺能看出产品经理的能力水平的，在上一节已经详细阐述了评估哪些需求该做，哪些需求不该做，对于已经决定要做的需求，这样的需求数量很多，是现在做，还是以后做，不可能在同一时间内全部研发完毕，总得有先有后，优先级高的需求优先研发，优先级低的需求延后研发，这样的话就涉及到需求优先级定义的标准了，在产品实践中，很多产品经理都是拍脑门决定先做哪些需求，后做哪些需求，要么就是老板拍脑门决定需求的优先级，那到底定义需求的优先级有没有原则和方法呢？

先来说说原则，在日常生活中，处理任务的优先级有四种情况：重要且紧急；重要不紧急；紧急不重要；不紧急不重要。这四种情况也是我们处理需求优先级的原则，即重要性+紧急性。把需求的重要性+紧急性统称为商业价值原则。基于这个商业价值原则，《神一样的产品经理》一书中主要阐述了需求优先级定义的四种方法。

1、新产品未上线

新产品未上线这种情况指的是产品从无到有的这个过程，这种情况因为没有相关的运营数据做支撑，所以从需求对用户的重要性和紧迫性来判断需求的优先级是一种比较合理的优先级定义方法，那么如何判断需求对用户的重要性呢？一般情况而言，用户需求重要性：基本型需求>期望性需求>兴奋型需求。使用需求的金字塔法则来表达，金字塔的最底层是基本型的需求，往上是期望型需求，最上面一层是兴奋型需求。基本型需求是必须有的需求，没有的话用户基本使用不了产品，如果金字塔最底层被砍掉的话，这个需求的金字塔就可能站立不稳而倒下，所以基本型需求的重要性最高，期望型的需求是用户期望能有的需求，用户希望越多越好，但是如果金字塔的第二层被砍掉的话，需求的金字塔不会受较大的影响，因为最底层的需求还在，用户还能继续使用产品，所以期望型需求重要性要低于基本型需求。兴奋型需求是超出用户预期的需求，有的话可以给产品加分，没有的话也无大碍，如果我们砍掉金字塔的最顶层，需求的金字塔更加不会受到影响，因为基本型需求和期望型需求都存在，用户还能继续使用产品，所以说兴奋型需求的重要性要低于期望型需求。其实我们从金字塔的建造过程来看，也是先建造最底层，然后是中间层，最后是最高层。 

    需要特别注意的是每个用户心里的基本型需求、期望型需求和兴奋型需求是不完全一样的，是千差万别的，比如说有的用户认为期望型需求是基本型需求，而有的用户认为兴奋型需求是基本型需求，这也随着时间在动态变化，甚至衰减，所以产品需求优先级的定义也要根据当时的实际情况来定。

    是不是明确需求的重要性之后就可以判断需求的优先级了呢，这里面还需要加上一个因素，即紧迫性。基本型需求重要性最高，且也最紧迫，所以基本型需求的优先级默认是最高的。 

    一般情况下，肯定是先做基本型需求，在研发基本型需求的同时，有时候因为运营、营销、销售等业务需求的迫切需要，会同时研发一部分的期望型需求（重要不紧急）和兴奋型需求（紧急不重要），主要是制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔，也有利于产品上线初期凭借期望型需求或兴奋型需求赢得用户良好的口碑。 

案例：智能手机的金字塔需求 

    先来看看智能手机的金字塔需求，如下所示： 

 

智能手机的金字塔需求

 

    智能手机的金字塔需求一共5层，最底层是第1层，往上是第2层，直到第5层。

    通过分析，不难发现，第1层和第2层属于基本型需求，第3层和第4层属于期望型需求，第5层属于兴奋型需求。如何评定哪些需求是基本型需求，简单方法就是：砍掉这些需求，这个产品还能用么？ 

案例：用户需求优先级排序 

    案例来源于腾讯公司内部的产品培训。1998年，QQ开始规划，1999年2月Beta1，1999年5月Beta2，1999年8月Beta3。

    请排版本Beta1，只能实现3个特性：

1、卡通头像                      7、聊天记录管理器

2、不可窃听安全通讯                 8、语音

3、聊天室                      9、视频

4、很小的.exe文件                  10、看谁在线上

5、皮肤skin                     11、传文件

6、速度超快0.5秒反映                 12、QQ表情

 

    这道题难倒了很多产品经理，很多产品经理考虑到当时的网络环境和背景，对这道题的答案有较大的分歧。在这里提供两种解答方法，一种是基于腾讯当时实际情况的解答（从当时角度出发，比较现实），一种是基于智能手机金字塔的解答（从现在角度出发，比较理想）。 

（1）       基于腾讯当时实际情况的解答 

    笔者跟腾讯公司最早的一批产品经理韩宇宙Punk，曾昭朗Paul和胡俊智Kinzeer曾经探讨过这个问题，给出了当时的答案是1，3，10。至于为什么选择1，3，10？从当时角度出发，理由阐述如下： 

    在当时情况下，早期的IM竞争对手有，有13家左右，各有一些特色，从单纯的功能上而言，QQ的功能并不突出。真正促使QQ让用户很HI的主要有两个地方： 

    第一个是卡通头像，让用户活了起来，它不算是啥功能，但是是用户情感需要很重要的出口。当时QQ的头像第一批用的是迪斯尼的，因为用户对这个经典头像熟悉，容易对号入座，有情感认知。当时都是70后嘛，这一代对迪斯尼，蓝精灵等比较熟悉。这些在当时选型时，都有考虑的。 

    QQ和其他IM不一样的地方，是有一个聊天室，而且是客户端形态的，所有的IM都要解决一个问题，就是用户从哪来。QQ聊天室解决了用户从哪来的问题，因为早期的用户习惯聊天室，对IM还不熟悉和习惯，更谈不上熟人关系。当时的环境和现在不一样，用户上了QQ后，用户的QQ上没有人，所以聊天室，是早期QQ用户聚集的地方，并因此互相加好友，从陌生变熟悉。其他IM的用户关系，一直是相对陌生的，而QQ的关系链是从聊天室的陌生，转化为比较熟悉，是有一定的社区关系的，然后再相互加一下QQ，很好的解决了用户QQ上没有任何好友的问题，有了好友，用户才会持续用QQ。最重要的需求在于怎么解决用户持续使用QQ，所有的功能先围着这个来转。QQ客户端的聊天室是客户端形态，因此聊天室的体验比当时Web 要好很多，功能强很大，而且还引入了社交化的体系，还有金字塔管理体系，让大量的用户每天都进入固定的聊天室相互熟悉，泡妞，有很强的成熟感，这批用户后来也成为QQ论坛的核心用户。聊天室为QQ用户贡献第一批好友，有点社区关系的好友。由于有这些好友，才有持续的动力上来和这些好友进行互动。 

    一开始，QQ安全性很低，随便都能偷QQ，用户都还不习惯用这个产品，做得再安全又怎么样，关于安全这东西，在早期的互联网用户上，不存在这个考虑。不要用现在的安全意识来评估当时的环境。性能的话，从技术的角度咯，当时的机器就那样，软件再怎么优化也是看不出来的。第一代的密码保护是02年底才有的，02年之前的QQ暴力破解就可以得到本地密码的，很弱。03年之前的密码保护也很弱，随便进后台就可以更改密保和密码。当时的IM还太技术化，但产业环境和用户习惯未到那个层面。比如说音频视频这东西，说真的，当时56K猫上网，支撑不了这个，大家都不用，并且网恋的风行，使文字聊天更有想像空间。 

    正如马化腾所说的：“exe小是结果，不是规划出来的，第一个版本想写成大也写不出。简而言之，10秒内找到人聊，且头像有趣是最朴素的需求，还有一个是好友保存在服务器端，换电脑也可以恢复。” 

    总的来说就是表情头像让用户很HI，毕竟要找人聊天，得知到谁在线上，而聊天室解决的是用户从零关系到弱关系再到强关系的问题，解决了第一批种子用户的问题。 

    从某种程度上来说，在当时环境下，卡通头像属于用户的兴奋型需求，聊天室属于用户的期望型需求，看谁在线上属于用户的基本型需求。 

    产品跟运营是不分家的，从这个案例可以看出，虽然是新产品未上线，但是已经开始有以运营为导向的元素出现，因为运营需求的迫切需要，研发一部分需求来制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔。 

    在介绍KANO模型的时候也阐述过用户需求是一个随着时间在动态变化的过程，如果以现在的角度来选择最重要的三项特性，可能就不是1，3，10的答案了。 

（2）       基于智能手机金字塔的解答 

    使用金字塔的需求层次来解答这道题目，上面已经阐述过智能手机的需求金字塔，如何评定哪些需求是基本型需求，从现在的角度和环境出发，简单方法就是：砍掉这些需求，这个产品还能用么？ 

    砍掉卡通头像，产品还能用，产品刚开始的时候使用普通头像也是可以的。砍掉QQ表情，产品还能用，不影响使用。没有聊天记录器，就不能使用QQ聊天了吗？显然是可以的，这也解释了MSN的聊天记录保存功能并不是默认帮用户勾选上的。很小的.exe文件，在这方面分歧比较大，很多人说当时是用猫拨号上网的，网速很慢，很多人认为很小的.exe文件是最重要三项中的一项，是这样么？答案不是，试想一下，一款网游好几个G，文件很大，网速虽然慢，但是用户就不去下载了吗？显然用户还是会去下载使用，再想一下，每一个新产品刚推出的时候，都是比较笨重粗糙的，比如以前最初的计算机庞大得可以占用整个办公室，携带非常不方便，回过头来再看看今天的电脑，小巧、轻薄了很多，所以说很小的.exe文件不是最重要的三项之一，可以理解为从用户体验角度来说，文件太大，用户获取的成本稍微有点高，但是用户体验的层次是有用、能用、可用、用的爽和品牌，文件虽然比较大，但是还能用，产品前提的条件是有用。聊天室是多人聊天，一对一聊天的需求还没有满足，就去满足多人聊天需求，显然也不合理。砍掉传文件的功能，产品照样能用，用户之间还可以发文字信息沟通。视频语音也是同理。这样分析下来，反映速度快、安全性和看谁在线上是最重要的三项，这跟智能手能的金字塔需求也是匹配的。如果反映速度太慢，基本上是用不了，用户在使用过程中会崩溃。如果1.0的版本很容易就被黑客攻击，导致瘫痪，照样也使用不了，再说了，QQ上都是自己的社交关系联系人，是比较隐私的，一旦被人盗用不堪设想（尤其是2011年12月震惊圈内的因黑客攻击导致知名互联网公司密码泄露的“密码门”事件，无疑给网站主敲响了网站安全的警钟，提高了安全需求的优先级。）。要想跟人沟通，首先要知道谁在线上，这是最基本的。 

    此外，在产品实践中，很多产品的成功具有时效性，有的产品在当时的环境虽然成功了，但是在现在的环境下复制这种曾经成功的模式，不一定见得会成功，所以通过QQ这个案例，至少可以得出三点结论：一是需求优先级的定义要基于当时的环境和实际情况；二是用户需求是一个动态变化过程，需要适时调整；三是产品与运营不分家，在确保满足基本型需求的同时，也要适当考虑满足用户期望型和兴奋型的需求。

2、免费型产品已经上线

免费型产品已经上线这种情况指的是全部免费型产品（全部功能免费）或者部分免费型产品（有些功能免费，有些功能收费）从有到优（调优）的这个过程，这个时候因为有了运营数据的支撑，通过运营数据，能聚类分析出用户的行为，甚至可以给用户画像。那么如何定义需求的优先级呢？这里还是采用需求的商业价值原则，即重要性+紧迫性原则。前面已经阐述过，用户有需求，产品利用相应的功能或内容来对应和满足需求，可以根据功能的使用率，使用次数和重要性，形成一个需求重要性的计算公式，根据计算的结果和紧迫性来定义需求的优先级。 

    现在互联网和移动互联网产品形态很多，比如Web、桌面客户端、第三方平台App、WAP、iPhone客户端、Android客户端、iPad客户端等等，用户对每一种终端产品的需求是不一样的，所以不能机械地认为用户对各种终端产品的基本型需求、期望型需求和兴奋型需求是一样的，这里要区分对待。对于要做跨终端产品的公司尤其要注意。比如，在使用Web 产品时，可以使用鼠标滚轮滚动页面阅读隐藏在下面的内容，能不翻页就尽量不翻页，因为用户比较习惯；而在iPad客户端产品上，从上而下滚动页面，需要使用手指自下而上滑动，用户使用起来有点别扭，很多App产品，尤其阅读型产品，改成了手指自右向左的横向滑动阅读未读的内容，用户使用起来比较自然。 

    用户需求重要性的判断标准：用户基数、使用次数和类别重要性。类别重要性分成基本型、期望型和兴奋型需求三类。 

    对于基本型需求，比如产品的性能、安全、浏览器兼容等方面，一旦出现问题，用户不能访问使用产品的情况，应该立马放下手头的工作，利用一切可利用的资源尽快解决这方面的问题，在有的公司称为“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、前置后置条件

 前置后置条件指的是有时候必须先完成A功能，然后才能做B功能，从需求的优先级来看，A功能的需求优先级肯定要高于B功能的需求优先级。A功能的重要性和紧急性都要高于B功能。 

    总的来说，上述四种定义需求优先级的方法，在公司范围内，在特定的产品阶段，是可以搭配使用的。需求优先级定义的原则基本上是一样的，都是商业价值原则，即重要性+紧急性。 

    不管在哪一种方法下，基本型需求的优先级永远默认是最高级别的，至于期望型需求和兴奋型需求要根据具体的实际情况使用方法的一种或几种方法搭配使用，而不是再用拍脑门来决定需求的优先级。特别注意的是，上述的内容都是围绕需求的优先级来展开的，是从产品人员的角度来说，但是从研发人员的角度来说，毕竟受到各种人力、物力、财力的限制和影响，并不能完完全全按照产品人员确定的需求优先级来进行研发，基于产品人员确定的需求优先级，研发人员基于开发资源提出相应需求优先级的研发优先级。至于研发优先级如何定义，将在下一节管理需求中作详细阐述。

Maven Jar 加载原则

1. 依赖最短路径优先原则

如:a.jar 依赖 b.jar,b.jar 依赖 c.jar, c.jar依赖 d.0.jar;

a.jar 依赖 e.jar,e.jar 依赖 d.1.jar

则：最终依赖d.1.jar

   2.pom文件中申明顺序优先

如：a.jar 依赖 d.0.jar  ;  b.jar 依赖 d.1.jar且 a.jar 依赖在 b.jar 前面

则：最终依赖 d.0.jar

Jar冲突场景

遵循Maven jar加载原则

注：针对同一个jar冲突

本级依赖>本级依赖管理>父级依赖>父级依赖管理>下级依赖

本级依赖优先级冲突

本级依赖环境：后置Jar版本优先级高于前值Jar版本

 

本级依赖管理和本级依赖冲突

本级依赖环境：后置Jar版本优先级高于前值Jar版本

 

父级依赖和本级依赖冲突

父级依赖

本级依赖

本级依赖优先级高于父级依赖

 

本级依赖没有引用，引用父级依赖

 

本级依赖管理和父级依赖管理冲突

父级依赖

 

本级没有依赖管理

默认使用父级依赖管理

 

本级依赖管理

本级依赖管理高于父级依赖管理

 

本级依赖和下级依赖冲突

本级依赖优先级高于下级依赖存，与依赖jar记载位置无关

 

 

 

下级依赖和下级依赖冲突

先加载的下级依赖高于后加载的下级依赖

 

 

父级依赖和下级依赖冲突

父级依赖高于下级依赖

 

Jar 冲突解决

定义Jar版本管理-dependencyManagement

 

排除冲突Jar-exclusions

注：使用exclusions比较繁琐，需要所有冲突jar中不同版本排查