需求管理之价值复杂性矩阵

                                                本文作者要给大家介绍一种用来评估功能优先级方面的工具——「价值复杂性矩阵」，希望对你有用。enjoy~


每个产品经理在面对纷繁复杂的需求时都会产生一种「我该如何是好」的想法，确定需求做与不做相对简单，但是哪个先做哪个后做这就极度折磨着一个产品经理。毕竟对于每一个需求方来说，都希望它提出的需求优先处理。
大家肯定都听过大名鼎鼎的 Kano (卡诺）模型用来对用户需求分类和优先排序，今天我要给大家介绍的是另外一种用来评估功能优先级方面的工具——「价值复杂性矩阵」（The Value-Complexity Matrix，好吧我承认我是在不知道这应该怎么翻译，就按照字面意思翻译的）。
什么是「价值复杂性矩阵」
从名字就可以看出，这个矩阵是通过对比每一个需求的价值和需要实现的复杂姓来进行对比，我更愿意叫他「性价比」模型。这个概念有一个很重要的前提：所有的需求都有一个固有的商业价值和实现的复杂性，并可以将其展示在一个由「价值」和「复杂性」形成的「平面直角坐标系」中，从而形成一个可视化的图像来确定哪些需求应该先做，哪些应该后做，哪些不应该做。比如：

确定需求的价值和复杂性
1、确定需求的价值
需求的价值，并不单单是这个需求可以换回多少收入还包括了增加流量、促进用户活跃、减少成本等各个方面，这些价值的权重可能不尽相同。随着产品业务的发展或行业的不同，也可能会有其它方面的机制出现。比如作为一个互金产品经理，我会把监管合规要求以及银行爸爸的需求的价值放在一个较高的位置。
同时，需要强调的一点是，某一项（或某一类）需求的价值并不是已成不变的，而是会随着时间的变化而改变，也会随着产品需要达成的阶段性目标的变化而变化。
2、确定需求的复杂性
每一个需求都需要实现，一般我们可以用（预计）工作时长来表示该需求的复杂性。（感谢我司大力推行使用「禅道」项目管理软件，我可以很准确的获得开发小伙伴们的历史开发记录及现有工作。）
另外，需求做完是用来使用的，在考虑复杂性的时候还需要考虑使用压力。比如：这个功能是否需要投入较高的运营费用？是否拥有足够的人力去支持该需求的运营？
最后，还需要去考虑该项目的风险程度？比如：是否会涉及合规风险（额，一看就是做金融的产品经理），开发小伙伴是否有能力完成，该需求是否会对已有的其它功能产生影响（我现在晚上做梦都是新需求千万别影响现有功能，据说我项目组的开发 leader 每天做梦和我差不多……）
最后来一个公式：「需求复杂性=时间+使用压力+风险程度」，当然「时间」、「使用压力」和「风险程度」是需要根据项目组的实际加权处理的，比如在我负责的项目组里，因为是互金产品，所以「风险程度」的权重可能达到80%~100%（也就是风控第一，不打折扣。）而我司另外一个「小工具」项目，工期紧任务重，因此「时间」的在复杂性确定的时候占据了较大的权重。
3、找谁来确定需求价值和复杂性
关于价值，我建议产品经理去和相关需求方去谈，但是需要注意的是：
[ol]

人数越少越好；

最好有较高层（或了解整个项目）的人参与。
[/ol]
人数越少，越容易达成共识；而每个需求方都会觉得自己的需求价值最高，如果有较高层（或了解整个项目）的人参与，可以从整个项目的角度去判断需求的价值，可以较快速的做出关于需求价值的排序（即使这个人也不能判断，但作为产品经理，说服一个人总比说服一群人简单。）
价值复杂性矩阵的使用
上边说到，通过确定需求的价值和复杂性（比如通过1-5来讲需求进行排序），展示在一个由「价值」和「复杂性」形成的「平面直角坐标系」中，从而形成一个可视化的图像。我们对这个图像分割成2X2的网格，这样就将所有需求分割在了四个区域内。如图：

我们来对这张图进行下分析，为了方便，我对这张图上的四个区域进行了编号：

第1号区域：「高价值，高复杂性」，这些需求都属于重要的需求，但是实现起来很困难，我们必须有足够的时间（精力）去处理它，因此我们应该优先处理该区域内的需求。

第2号区域：「高价值，低复杂性」，这些需求做起来绝对是一本万利，性价比最高。但是正是因为比较简单，所以我们可以给一个较低的优先级来处理。不过这种需求一般比较少，是不是很失望。

第3号区域：「低价值，低复杂性」，对于这些需求虽然实现起来比较简单，但是也不会为你带来什么价值。性价比也就不是很高，所以你可以把它列入你的需求列表里，如果资源允许就做，如果资源不允许，就痛快的舍弃掉。

第4号区域：「低价值，高复杂性」，性价比最低，复杂还没有价值，做它干啥。愉快的把它排除吧。

你可能遇到的四个坑
1、部分文章中认为「高价值，低复杂性」需求的优先级应该最高。我则优先保障「高价值，高复杂性」需求，以保障我有充足的时间和资源来降低风险。关于这两块的优先级排序我认为没有固定的顺序，根据项目或产品的不同，应该有产品经理自己来设定。
2、对于「高价值，高复杂性」的需求我更愿意将其进行拆解，将其分割成若干可以通过迭代来完成的小需求，这有助于控制时间、降低风险。
3、对于所有需求的划分并不是已成不变的，我的建议是定期（比如一周或者一个月）把现有（未做）的需求拿出来根据实际的情况重新梳理和分区。
4、开发同学们喜欢解决复杂的问题，他们认为这是他们的价值。但是对于产品经理，一定要禁得住开发同学的「诱惑」，守住底线！对于可能花费过多时间讨论和规划，而实际价值低的功能一定要大声说「不」！避免浪费宝贵的开发资源。