超级项目经理应该掌握的99种武器之23：需求优先级评估12维空间

我们在项目需求管理过程中经常遇到的一个问题是需求优先级管理，本文列出了需求评估常见的12个评估维度，大家在实际的工作过程中可以选择2个维度组成优先级评估矩阵，也可以选择3个以上维度，形成多标准决策分析框架。

需求优先级评估12维空间

维度1：需求的重要性

维度2：需求的紧急性

维度3：需求的技术实现难度

维度4：需求带来的财务收益（ROI）大小

维度5：需求的大小，对项目成本的影响（需要投入的资源）

维度6：需求提出人的影响力（级别高低等）

维度7：需求与公司战略（部门工作重点）的匹配度

维度8：需求对用户体验的影响（对项目交付质量的影响）

维度9：需求服务于核心客户还是边缘客户

维度10：需求的外部依赖大小（受国家政策影响，需要依靠强运营推动、市场竞争激烈程度等）

维度11：需求对项目进度的影响

维度12：干系人对需求的共识程度（少数服从多数法则）

需求评估的12维空间就是12个评估角度，在实际中大概率会选择2-5个来进行评估，其中最常见的还是二维的评估矩阵，本文也列举几个常见的需求优先级评估矩阵，供大家参考借鉴。

重要紧急矩阵

开发难度贡献大小矩阵

用户故事优先级Moscow法则：

在敏捷开发模式中，对于用户故事优先级普遍使用了Moscow法则，该法则将需求分类为四类：

• Must have：必须有。如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能。比如微信的聊天信息、通讯录、朋友圈。
• Should have: 应该有。这些功能很重要，但不是必需的。虽然’应该有’的要求与’必须有’一样重要，但它们通常可以用另一种方式来代替，去满足客户要求。
• Could have： 可以有。 这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。
• Won’t have： 这次不会有。 最不重要，最低回报项目，或在当下是不适合的要求。不会被计划到当前交货计划中。 “不会有”会被要求删除，或重新考虑。

每个项目经理和产品经理都应该有一套属于自己的对于需求优先级判定的标准和工具，本文提出的12维空间是一个更加开放的体系，各位看官可以根据自身业务的特性，增加优先级判断的维度，并按照自己业务的需要，选择不同数量的评估维度对需求优先级进行评估，大家都有什么更好的需求优先级管理心得，欢迎留言一起分享一起讨论。