作为产品经理或者交互设计师，亦或者 UI 设计师，每天都会遇到各式各样的需求。有的一句话，有的一个简单的文档，有的只是一个线框图，各种程度的资料，不一而足。特别是如果在一个 ued 部门内的时候，处理的需求更为繁杂。如果没有一个比较好的处理排序优先级的方法，很容易将需求层级搞混乱，从而导致整体研发进度受影响。

当前在需求分析阶段，比较受欢迎的主要是 KANO 模型分析法、BCGmatrix 分析法、MoSCoW 分析法，这三个又被称为「需求分析三剑客」。还有一个最近也比较受欢迎的分析方法，就是 RICE 法则，又称为大米法则。在一个团队中，不会过于去依赖某一个分析法，综合的运用和考虑才能够更高效和快速的处理当前的需求池。

这四个方法，难不成在我们日常处理工作需求的时候，一个一个的去尝试？显然，这是一种依葫芦画瓢的行为。在比较长的工作项目中，我们多少有了一些运用的经验和理解。希望接下来的讲述，也可以对你解决多而复杂的需求分级有一定的帮助。

简略思路

BCGmatrix 分析法、RICE 分析法，这两个的针对对象层级都含有产品层，或者说用户体验要素中的战略层考虑。而 KANO 模型分析法和MoSCoW 分析法，偏向针对的是具体的产品功能层级，所以，在我们考虑需求优先级初步判断的过程中，可以优先使用 BCGmatrix 和 RICE分析法进行判断。这其中 RICE 分析法，也可以针对产品功能层级进行分析（后文会详细阐述）。BCGmatrix 从对用户价值和对公司价值维度，也可以涉及到功能层级。但这并不妨碍优先使用此两个方法。

通过前两个方法，就可以优先排除一部分伪需求存在，但是下沉到产品功能层级的时候，就不可以再接着运用 RICE 方法了。可以从BCGmatrix 分析法角度，筛选出需求的维度（对用户价值高还是对公司价值高）偏向。再结合接下来的两个分析法，以团队实际和公司业务实际，来判断需求处理的策略和优先级。

介绍具体方法的日常思考运用

1. BCGmatrix分析法

波士顿矩阵是由波士顿咨询公司创始人布鲁斯·亨德森于 20 世纪 60 年代首创，被视为企业战略策划时代的一个节点。作为分析企业成长（企业实力）与市场份额（市场引力）之间的关系的工具，它高度概括了企业战略决策的一般方法，最早用于分析企业的市场增长率和市场份额（市场占有率），又称为「市场增长率-相对市场份额矩阵分析、产品系列结构管理法等」。

虽然波士顿矩阵方法最初并非应用于互联网领域，但是后来经过变化升级，渐渐的开始在互联网领域应用。特别是在产品需求优先级的判断上。

 产品层筛选

依据当前公司或者团队产品偏向，或者新的业务场景需求对于当前公司产品的增长率或者市场占有率影响性，初步区分需求池中真伪需求存在。此时，有些内容需求恐怕需要进行完整的报告文档，比较偏向战略层的决策，都是上层推动的。你的意见建议，必须拿出有力的证据，才可以让管理层认识到你的建议是对的。

例如在「易出行」（已隐去真实项目名称）中，当时涉及到几个新的业务场景接入的问题，涵盖扫码、维保、充电等，那么到底优先接入哪个场景的业务？关于战略层的决策，一般做为产品经理或者交互设计师，是没有权限参与的，除非你已经达到总监级别了。当时，比较看好的是维保和充电，主要是结合市场层热度以及结合我们内部项目主营业务来决定的。但是，却忽略了团队的资源配置以及所处阶段的更为重要的任务是抢占垂直市场，而不是去和其他已有实力的人抢份额。

当然，关于最终的建议和讨论是我们 UED 部分大佬去和老板说明的。但是关键点你是可以和老大去表明的。

产品功能层筛选

正如上图所示，对用户有价值的需求，一般属于用户需求；对公司有价值的需求，一般偏向产品需求。这个时候，就看一下，其需求的本质是偏向哪一种类型了。

明星功能需求

即对用户有价值，同时对公司也有价值的产品功能需求。可以既满足用户的部分需求，又可以实现产品的部分目标需求。和在企业规划中一样，处于双高级别，是优先级最高的需求。例如，在我们某一个场景的门店列表中是否增加导航入口这一功能，一方面，用户购买之后，可以快速方便的去到附近门店消费，一方面门店提升了营业额，对我们平台的信任度增加，这个功能就可以划归明星类产品需求。

问题功能需求，问题类需求虽然表面对公司没有直接的商业价值，但是从对用户价值角度而言，可以提升用户的满意度和忠诚度，所，综合来说，这类需求从本质上来说也是对公司有价值，只是不直接。之所以是问题需求，因为会随着时间或者业务变化，会变成明星需求或者现金牛需求，甚至会变为疯狗需求。最终走向，存在不确定性，有很大的风险。

例如，扫码挪车这个需求，这个是一个不高也不低的需求，但是对于用户而言，很多时候，又是一个非常必要的存在。特别是一二三线城市，因为各种原因，总有需要联系车主挪车的情况。它短期内，对于公司产品来说，其实算是一个鸡肋的功能，和主营业务没有强相关。但是对用户的确有价值的，所以，我们在前期推广的时候，很多人还是比较乐意注册，但是出现了一个小失误，就是没有处理好注册使用的流程限制门槛，比较繁琐。结果可想而知。

现金牛类需求，这类需求比较明显的自然就是对公司有明显的价值，但是从用户角度而言，多少会有一些负面影响。从理论上来说，应该尽量避免对用户体验造成不良的影响。但是，需要看公司产品的情况的。

例如，当前各种游戏非常火热，当然，似乎游戏一直都是比较热的。但是在你玩游戏的过程中，会常常引导你去看直播，这种体验，你应该不陌生。那么像是某易或 TX 为啥这么做呢？之前公众号也有文章说明，这种就属于现金牛类需求，公司的目的就是希望引流赚钱以盈利。

疯狗类需求，最后这种需求，就是和第一类需求相反的「双低」需求，也就是我们常说的伪需求。需要你判断出，并尽量去排除掉。

其实从以上几个需求类型的分类阐述，就可以看出对于问题类需求和现金牛需求，考虑的时候，需要多考虑一步。在产品成长初期，例如我们之前的「易出行」，获取用户增长和提升用户的留存率是第一要考虑的，那个时候，我们并没有去考虑如何去盈利。所以，问题类需求优先级高于现金牛需求。

但是如果产品处于稳定成熟期，例如，现在的很多超级 APP，公司的目标自然都是以提升盈利水平为第一要务，像是「拼多多、瑞幸」等。

除此之外，我们在考虑需求的时候，涉及的因素是非常多的。上述的波士顿矩阵也只是提供我们一个分析的思路和处理的方向。自然还有其他的方法，可以帮我们进一步的去验证其合理性，例如：RICE 法则。

2. RICE分析法

一个好的优先级排序框架可以帮助你用清晰的思考去理清项目里面的每个因素，并以严谨、一致的方式将这些因素结合起来。但是你可能很难找到一个能让你以一致的方法去对比不同思路的系统。所以，我们需求掌握不止一种分析思考的方法，才可以有效的管理我们的工作和生活。

RICE 是用来评估各项目需求的四大因素的首字母缩写：触达（Reach），影响力（Impact），信心度（Confidence）和努力（Effort）。

REACH触达

为了避免出现主观需求的偏差，我们应该评估每个项目在既定时间内会影响多少人。对于我的团队来说，就是「在一个季度内，这一个项目将会影响到多少客户？」

触达范围是衡量每个时间段内产生的用户数或活跃数。也许会是「每季度客户数」或者「每月交易额」。尽可能使用产品指标中真实的测试数据而非虚构的数据。最终，我们选取的是 DAU 和 MAU。

举例：

• 每个月，目前有 10W 个客户（总部支持，有推广位，且每月都有营销活动），能够进入到注册漏斗的阶段，有 30% 的人选择这个选项，那触达的结果就是每月 100，000 x 30% = 30，000个客户。
• 每个季度，每个使用该功能的客户都能看到这个改变。那触达的结果就是每季度 60,000 个客户。
• 这个改变将会对 50W 个现有客户造成一次性影响，但并没有持续的影响。那触达的结果就是每季度 60，000 个客户。

IMPACT影响力

关注项目中直接影响结果的数据，评估独立个体的影响程度。对于团队来说，就是「当有客户接触这个项目，它能够提供多少转化率？」 你的团队也许会用其他的指标来取代，比如「提高使用率」或者「最大化用户满意度」。

影响力很难精确的衡量，所以可以设定几个加权选项：3 代表「重大影响」，2 代表「高度影响」，1 代表「中度影响」，0.5 代表「低度影响」，以及最小的 0.25 代表「轻微影响」。这些数字将作为权重值与各项评分相乘，加权得出评估结果。

选择影响力的权重值看起来似乎不太准确，另外的一种方法就是依靠个人的经验直觉。

举例：

• 对所有看见它的客户而言，它都能产生巨大的影响。则影响分数为 3。
• 这对每个客户而言将有比较少的影响。则影响分数为 1。
• 产生的影响程度适中，则影响权重为 2。

CONFIDENCE信心

为了遏制对于鼓动性强但概念不明的想法的热情，需要把评估的信心水平也考虑进来。如果你认为一个项目本可以有巨大的影响力，但是并没有足够的数据来支撑这样的看法，这时，你对该项目的掌控度源于你的「自信度」。

自信度是一个百分数，可以采用一个有多项选择的量表来辅助避免决策失误的可能性。100% 是「信心程度高」，80% 是「中等」，50% 是「低」。任何时候，如果信心程度低于 50%，那根本就是天方夜谭。坦白告诉自己，你的评估，到底有多少事实和数据支持？

举例：

• 我们有影响范围的量化指标、影响力的用户研究、努力程度的工程评估。那么这个项目有 100% 的信心度分数。
• 我有数据支撑影响范围和努力程度，但是对影响力不是很确定。这个项目有 80% 的信心度分数。
• 影响范围和影响力可能比评估的还要低，努力程度可能比评估的还要高。这个项目有 50% 的信心度分数。

EFFORT努力（这里我们理解的是工时）

为了能够快速发展并用最少的努力获得影响力，从团队的所有成员出发，去评估一个项目需要的时间总量，包括产品、设计和开发。

努力程度的评估是以「人-月」（一个团队成员一个月的工作）为单位对努力程度进行评估（我们团队的日常评估是「人-天」，这里我们采用他们的单位）。这里会出现许多未知情况，所以为了让评估留有余地，在这里我采用整数，或者用 0.5 来代表任何小于一个月的工作。不像其他的正向因素，更多的努力程度是一件坏事，因此我把它放在了分母，来除总的影响力。

举例：

• 该项目将需要 1 周的规划，1-2 周的设计，以及 2-4 周的工程时间。我给它的 1「人-月」的努力程度分。
• 该项目将需要几周时间来规划，非常多的设计时间，一个工程师来做至少需要两个月。我给它的 2「人-月」的努力程度得分。
• 该项目只需要 1 周时间来规划，没有新的设计，而工程时间需要半月开发。我给它0.5「人-月」的努力程度得分。

RICE分析法公式得分算法

一旦你完成了这些因素的预估，把它们合并成一个单一的得分，这样你就能一目了然的比较不同项目的分数了，如下方公式：

一旦最初的评分完成，排序你的项目表单，并重新评估。有没有哪些项目的分数似乎太高或太低？如果是的话，重新考虑你的估算并做出调整，或者接受你的直觉可能是错误的。在决定难以比较的项目想法时，RICE 可以提供极大的帮助。它迫使你思考为什么一个项目会产生影响力，并且诚实地预估为达到目标所需的努力程度付出。

多数时候，我们只需要评估一个大概就会比较明显的可以得出，哪些需求是优先级比较高的，哪些是伪需求的。

怎么说呢，这个 RICE 法则分析，和后面的 KANO 模型分析在量化指标这块，比较好明晰的。但是回归产品业务场景来说，比较难以一时间可以看出，先做哪个的力证。所以，关于 RICE 法则，产品可以多考虑一下，因为在我们看来，这个更多的是偏战略层的。交互或者用户体验设计师，可以做到了解其分析原理即可。

参考资料：

https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/

3. MoSCoW法则分析（莫斯科法则分析法）

在 PRINCE2 中有一种叫 MoSCoW 的排序法。其名称是 4 个级别的首字母缩写。这 4 个级别分别是：Must：必须做的/必须有的；Shoud：应该做的/应该有的；Could：可以做的/可以有的；Wouldnot：现在不可做/现在没有的。

以之前易出行后台服务系统为例，在定制化开发软件产品前，项目组和产品经理通常会开展用户调研。在调研中，不同用户会从自身场景提出许多需求。当期项目的产品功能应该满足哪些用户的哪些需求就成了一个待回答的问题。MoSCoW 排序法提供了一种思考方式，引导大家围绕交付物展开思考：

哪些需求是必须有的、对应的功能是必须做的，如果缺失则产品不可行、或者会严重影响用户最终的使用目的；哪些需求对应的功能如果可能的话是应该有的，即便用户可能没有想到或意识到；哪些需求对应的功能是可以有的，即便本期项目没有也无伤大雅，或者有其他替代方案；哪些是不能有的，是一些不合理的需求。

使用 MoSCoW 排序法的优点是：

体现了PRINCE2关注产品（最终交付物）的原则。

在使用 MoSCoW 为需求排优先级的时候，实际上是围绕交付物思考，在排序的同时划定了产品的功能范围以及当期项目范围，一举多得。避免了盲目响应需求、轻重缓急拎不清，导致的范围蔓延。

明确了产品（交付物）的定位和演进方向。

这一点在 PRINCE2 中没有明确提到，但在工作中却能实实在在感受到的。我们仍以易出行车主服务系统为例：用户提出的需求实际上是从自己角度出发的，往往方向差异很大。对需求响应的排序，实际上影响了产品定位——到底要解决谁的什么问题。

系统上线后，用户在使用中还会不断提出新需求，一些需求如果不仔细斟酌就盲目响应，会导致系统被改成「四不像」，沦为功能模块的堆砌，背离系统设计之初的定位，这个时候，特别是内部孵化项目或者中小型团队公司的项目，还容易受直接管理层的意见左右，虽然这种情况，难以避免，但是希望我们可以明确一个立场「这个公司不是你的，但是这个项目在由你负责的时候，就是属于你的」所以，它的好坏也是你职业生涯中的重要一笔，希望可以必要的时候，力争一下。此时，运用 MoSCoW 方法，能协助项目组或产品经理理清思路，明确产品演进的方向。

但同样的，这个分析方法也有其一定的缺陷，比较明显的就是：must 和 should 两个层级的需求输出的时候，会产生一定的迷惑。因为这两个层级，比较难以区分。所以，这个时候，kano 模型分析法也许就该走上前台了。不同的优先级排序方法背后是不同的思想和视角，但是我们可以从自身需要出发，去结合合适的方法，而不是按本文的顺序去一一试验哈。

欢迎关注作者微信公众号：「PGDWORKS」