以上对话，纯属事实；如有雷同，绝对不是巧合！

无论是作为用户产品经理本身就是业务方，还是作为主要承接业务方需求的后端产品经理，在高速发展的互联网公司，每天都会出现各种各样的需求。虽然“没有什么不能做的，只要给我足够的资源”，但是资源永远都是紧张的，大厂的各产品经理互相争取资源，小厂的产品经理在少的可怜的资源中苦苦挣扎。所谓资（qian)源（qiong）的稀缺性和需（yu）求（wang）的无限性之间的矛盾，在各行各业都存在，互联网公司也不例外。

产品经理必须要掌握的技能之一，就是评估/平衡需求的优先级。

磨刀不误砍柴工，在评估优先级前，我们先对需求本身进行简单的分类。

1.1 按需求来源划分：

产品经理的需求来源很多，和产品经理本身负责的系统模块相关的所有关联方，都有可能向产品经理发起需求。这里我简单分为4类：

1. 主动发起：产品经理基于业务/系统的分析，自发产生的需求；

2. 业务方发起：产品经理作为需求承接方的角色，处理业务方发起的需求（常见于后端产品）；

3. 其他业务系统联调需求：其他系统/团队在自身需求实现时需本系统配合改造/提供服务而发起的需求；

4. 老板：这里泛指一切产品经理的领导，基于业务/工作安排等各目的，向产品经理提起的需求。

1.2 按需求类型划分：

产品经理的需求按照需求的类型，可以按照如下进行分类：

1.3 按需求重要和紧急程度划分：

根据需求对于业务的影响，以及需求实现的紧迫程度，我们可以按照如下方式将需求归为4个象限。这也是需求归类的经典4分法。

二、需求优先级划分

一般来说，在评估优先级时，我们可以根据以下思路对需求再次进行评估。

需求评估

在对需求有了充分认知之后，结合需求的影响以及需求的分类，我们可以将需求按照如下方式划分优先级。

在任何情况下，对于事故类/严重bug类问题，都需要第一时间快速修复上线。该类需求可能不是由产品经理/任何业务方发起，但由于产品经理作为系统/产品的负责人，而该类问题会导致产品使用上的严重影响，哪怕是由研发主动发现的问题，也需要配合协调资源，尽可能缩短上线时间，尽快完成。

该类需求往往是重要而紧急的需求，一般是对于业务具有极大帮助，可以快速看到经济价值/业务战略意义，且需要第一时间响应市场需求，快速上线的项目。比如疫情期间，各大厂配合社会情况第一时间上线的随申码，就属于这种需求。再比如青山目前所从事的风控系统领域，对于策略改版类需求，由于可以极快的提升策略质量，从而提高通过率/提升资产质量，就属于典型的重要而紧急需求。

有一类需求比较特殊，就是老板的需求。这里的老板泛指产品经理汇报的各垂直线的总监、公司老板、大老板等。一般老说，老板直接发起的需求，往往是出于公司战（ge）略（ren）目（kan）的（fa）和对于业务发展角度的考量而发起的需求。只要不是距离业务本质偏差太远，青山本人的做法一般都是排在优先级第三及时处理的。毕竟，大家都是在老板手下恰饭不是（^_^)

这里特指重要而不紧急的需求，往往是项目类的需求。这类需求对于产品的发展和业务的提升帮助很大，又或者是公司下一阶段/下一个项目的重要辅助功能。但由于周期较长，所以给需求的响应/处理留存了足够充足的时间。对于这一类的需求，可以放在优先级第四的位置。

以上就是青山日常在处理需求优先级划分的常规思路。

当然，这个划分方式其实是非常理想化的模型，现实的情况往往是复杂而多变的。具体问题需要具体分析，本文所提供的也只是一个最基础的公式，具体问题/不同公司/不同产品岗位的方法论还需要各自在实际工作岗位上才能慢慢摸索，琢磨出一套符合自己所处生态环境下的优先级排序大法。