身边的朋友都知道，因为一些众所周知的原因，这周我的加班能力被提升到了新的境界：不光每天都能和技术帝们的下班时间完美匹配（技术帝们辛苦了），而且在公司的每一秒都在高速运转，生命仿佛变得更鲜活而有意义了哟（……禁止卖萌！）

总之，经过整整一周的折腾，如果再不梳理下工作，就变成白忙活了。这次，让我们不分国籍~不分种族~不分肤色~敞开心扉~促膝长谈~~~聊一聊需求优先级的问题。

互联网屌丝or麦肯锡女神？看着办吧

在这忙碌的一周里，有一个问题被放置到了非常关键的位置，那就是如何评估需求的优先级。

被压在各种各样的需求下是产品经理的常态，如何处理需求优先级往往也反映了一个产品经理的水准和能力。就像题目里说的，如果一周需要处理1000个需求，你该怎么办？老大们拍下来的要做吧？影响企业利润的要做吧？能提高工作效率的要做吧？还有自己那点小心思、想要优化的ABCDE，也要做吧？……如果顺着这个思路走下去，那么就很容易陷入到被需求牵着鼻子走的境地，打乱自己原有对产品的规划，更是会影响到整个团队的工作节奏。

（亲，你膝盖中箭了吗？）

然而，同样面对着繁重、复杂、多线程工作的某个物种，不仅凭借解决问题的能力赚得满盆满钵、驰名全球，更是总结出了一套科学且可复制的工作方法和管理经验，供更多行业的人类复用。这个物种生存的星球叫麦肯锡，这个物种分为两类，一类叫男神，一类叫女神。（……）

好吧。我知道在这个重科技轻人文的年代，管理学被当做招摇撞骗，殿堂级的几家公司也越来越不好赚钱了。但就是面对这么实际的问题，只需要对工作方式做一点改变，可能就会帮助你走出现有的困境。如果你还想被需求折磨死，面如枯槁地加班，请点叉不送。如果你希望让需求更有条理，让工作更有效率，让每天晚上可以留点时间给自己，那么，看下去吧。

万能的四象限法则

说到底，需求的优先级是个时间管理的问题。如果我们有充裕的资源，无限的时间，那么只要确认可以接的需求，我们都可以做。然而往往现状是：没有资源，没有时间，N个需求压过来，每个都说自己最重要，每个都希望今天提需求明天就上线，这时候，就必须评估需求的优先级。

《麦肯锡方法》和《麦肯锡思维》中都不断地提到，对项目管理和时间管理，非常有效的工作方式是四象限法则。根据事件的重要性和紧迫性为坐标轴，可以将所有事情区分放在四个象限：重要且紧急、重要不紧急、不重要但紧急、不重要不紧急。对所有事件分类后，才可做更好地分析处理。

当然，时间管理的四象限法则很多人都知道，只说到这里简直弱！爆！了！更为重要的是，麦肯锡在使用四象限法则之前，首先要做的是标准评估。

四象限法则的两个坐标轴是重要性和紧迫性。紧迫性和时间关联，比较好量化，而重要性则需要认真定义，树立标准。

2.1 有钱有势，不如有标准

什么叫重要？从互联网行业的普遍角度看，一个产品的需求重要性可以细化为以下几4个标准：

1）基础服务。越靠近基础服务的需求越重要。一方面，越基础的服务越靠近产品所满足的本质需求；另一方面，如果没有完善的基础服务，功能性的需求往往也无法实现。把产品比作一座塔，塔尖少盖基层，最多是矮一点，可如果不搭好基座，整个塔都有可能倒塌。

2）利润来源。比较共识的优先级取舍是，客户大于用户。如果某一个需求直接影响到公司的收益，当然会被放在高优先级。

3）战略支持。如果是公司层面的战略落地，需要业务线支持，能够支持公司决策、引起市场和舆论效益的，也会被判定为重要。

4）关联性强。最后一点，有可能一些需求在你看来一般重要，但该需求会牵扯到其他部门的重大功能，或是许多部门需要该需求支撑，成为了“牵一发而动全身”的那“一发”，那就需要调高这个需求的优先级。

2.2 四象限的处理方式

确认好现有需求的重要性和紧迫性，可以让他们排排坐到四象限的格子里去啦！

然后，看看该如何去解决这几类问题吧：

1）第一象限：重要且紧急。首要解决这类事情是毋庸质疑的了，但需要控制好的是该象限的需求数量。以你的重要性标杆为主，需求提出方的标杆为辅，如果本末倒置，就永远跳不出这个坑了。

2）第二象限：重要不紧急。对待这一类的需求，不建议立即开工。比“立即执行”更重要的，是反复评估，尽量确保产品方案的严谨性。等时机成熟，能拿出一个尽量完善的方案支持开发，高效完成，避免反复。

3）第三象限：不重要但紧急。这个类型简直太经常遇到了。“反正是小事顺手做了吧”、“我们很着急用这个功能，帮个忙嘛”……这个时候千万要把持住！不要随口答应！千万记得，再紧急，它也是不重要，既然不重要，就需要好好评估。最可怕的是因为需求提出方着急，自己也跟着急，结果没有想清楚就提了开发需求，最后产品方案也不完善、功能又不重要、还浪费了开发资源，最后出力不讨好。

那么如何处理这个象限的需求呢？

第一，和需求提出方对重要性和紧迫性认知的分歧，需要我们做出进一步的沟通，以判断是否仍然需要你的配合，是否可以转移到其他象限；

第二，如果对方确认仍需要向你提出需求，那就要考虑该需求和自己的其他项目是否有重叠，如果是可以一起开发支持，那就一并放到其他项目中；

第三，如果该需求确认需要你配合，又和其他项目无重叠，又很紧急，那么这时候需要和需求提出方确认下能够接受的时间期限，尽量争取自由度，即便需要临时支持，也要给现行的项目足够的缓冲。

4）第四象限：不重要不紧急。遇到这类的需求，就不要装好人了，该推掉就推掉吧。如果对需求的认知有歧义，那么就帮助需求提出方了解为什么是不重要又不紧急。总之，把你的精力放在其他需求上吧。

到这里，相信你那一大麻袋的需求已经有一个清晰的规划了。

反思比忙碌更重要

梳理完毕现有的需求并没有结束，比起执行，更重要的是反思。为什么会有这么多需求？为什么会有这么多重要的、或者不重要的需求？

仍然从四个象限来看：

1）第一象限：重要且紧急。

真的有这么多重要且紧急的需求吗？这一类的需求过多，只有两种可能：

第一种可能是没有准确评估重要性。A说重要就觉得重要，B说重要也觉得重要，到头来就是全都很重要。假设产品是一条船，产品经理是船长，每一个需求都是你装卸货物的码头，而产品的发展是你的航线。每一次停留，有可能让你的船更坚固、储备更足，也可能让你的船消耗储备、一无所获，而最糟糕的境地，则是你痴迷于一个个码头，最终却失去了到达终点的能力和方向。

第二种可能，是基础没有打好，才会有那么多紧急的事。以社交产品为例，根据节日策划活动、根据热点事件炒热社区话题、根据客户需求订制页面，这些都会成为重要且紧急的事的话，只能说明你的产品没有做好专题运营的功能。基础功能缺乏规划落实，才会导致每一个可以用基础功能满足的需求，都变得重要且紧急。

2）第二象限：重要不紧急。

进入到第二象限的这些需求，往往才是对产品本身最重要的需求。同时，这一部分需求做好，可以有效减少其他象限的需求。工作中常犯的错误是两种极端，一种是因为不紧急一拖再拖，另一种则是因为重要，没有想清楚就着急落地。比较合理的处理方式是，针对这类型的需求树立一个落实的周期。假设我们设定了一个月，如果有第一象限的需求进入，可以暂时调整优先级，暂停的这段时间里，一定要不断完善需求本身的严谨度和可行；如果一个月的期限将近，则必须协调资源落实，毕竟该象限的需求保证了产品自身的功能和品质。

3）第三象限：不重要但紧急。

这类的需求太多，会让人失去对产品的主动，更是对资源的极大浪费。那么如何能尽量避免这类的需求？与时间管理不同，该象限的需求大多不是自发，而是他人发起的，起因往往是双发的出发点和利益点不同。为了避免这类棘手的问题，平时就要树立好自己的工作风格和职业原则，哪些可以做，哪些绝不可以做，亮出底线，即便评估后真的觉得不能做，也有理有据。另外，如果不能帮对方实现需求，也可以帮对方想出其他的解决方式。如果同一个需求，他认为很重要而你认为不重要，那么说明你们的利益相关性较弱，必定有利益相关性较强的第三方可以选择。总之，不要让这部分需求侵蚀掉你的资源和精力。

4）第四象限：不重要不紧急。

在工作中真的有需求会进入到这一象限吗？如果你一时犹豫没好意思回绝，那请培养自己的果敢；如果你对需求做错了评估，那请提升自己的专业度；如果你三心二意轻易承诺，那请校正工作态度和责任心。总之，时间浪费在第三象限就很可怕了，不要堕落到第四象限了。

？或许还没有结束

当然，用了这些方法你也未必能把所有需求规划得当，现实里总有那些坑爹的需求等你掉坑，让你恨不得把它们全部上交国。但方法的好处在于，当你面对堆积如山的需求，不再抓狂，分得清哪些可以做，哪些不能做，哪些是坑，就已经成功一半了。我这寥寥的几千字，就算没有白费。

如果你有更好的招数，可以告诉我；

如果你真的要我1周内处理1000个需求，我只能说：

#专栏作家#

莔莔有神（微信公众号：破壳，pokeclub），人人都是产品经理专栏作家，新晋产品喵，将细腻的人文视角和严谨的产品逻辑相结合，探讨互联网产品和工作的方方面面。曾经是面霸，承接职业咨询。

本文系作者授权发布，未经许可，不得转载。