程序员成长第二十七篇：如何评估需求优先级?

项目的需求来源有很多方面，最终由产品整理出来哪些要做，哪些不做。我前面说过需求评审时，要讲清楚这次版本的目的是什么。这些要做的功能就是达成目的的手段。

一般情况下，我们都默认产品或技术总监给需求定优先级。比如优先级高、中、低。实际上这样分还不够细，优先级高的标准是什么？

想要做好优先级管理，首先得制定一套标准。不一定要非常准确，但一定要有且公开。

任何一个需求，都有其价值。其价值主要分为：商业价值、用户价值。

商业价值：直接给公司带来利润、完成长期战略目标、降低运营成本等功能。

用户价值：提升用户体验、提高用户效率、解决用户痛点等功能。

为此，我们可以得到一个二维四象限图

由此，我们可以得到：

高商业价值、高用户价值的需求：立马做；

高用户价值、低商业价值的需求：在资源有闲的时候做；

低用户价值、高商业价值的需求：选择性做或者换个方式做；

低商业价值、低用户价值的需求：不要做。

为什么说要商业价值优先？因为没有商业价值，项目就不可能持久。每一个需求都是要投入人力的，在资源有限的情况下，我们只能把精力放在高商业价值、高用户价值的需求上。

通过价值维度排除一部分需求后，依然会存在两个同样高商业价值、高用户价值的任务冲突的情况。我们可以选择继续细分，按紧急和成本二个维度继续划分，可以得到：

紧急、成本低的高商业价值、高用户价值的需求：优先级排第一位；

紧急、成本高的高商业价值、高用户价值的需求：优先级排第二位；

不紧急、成本低的高商业价值、高用户价值的需求：优先级排第三位；

不紧急、成本高的高商业价值、高用户价值的需求：优先级排第四位；

大部分公司，很少要拆到这个程度，如果真出现这种情况，我觉得是好事，公司应该尽快招聘更多的人来加速商业价值的落地。

项目需求能不能变？

一般需求确定下来后，最好不要做临时变动。除非特别情况。那什么是特殊情况？这就是制定需求优先级规则的好处了，如果确实有更紧急、成本低的高商业价值、高用户价值的需求。我们可以变动。只要团队内成员都认可这个规则，就会比较好实施。

那如果是领导不按规则变动需求怎么办？

谁担责谁决策。如果领导要临时变更需求，而且部门负责人已经反馈变更的影响后，还依然如此的。我们依然要听领导的。同时跟团队也讲清楚这个道理。而且领导站的位置不一样，我们以为的高价值任务对站在领导的角度并不一定对。

在公司里可能会存在很多类似的情况，每个人可能有不同的意见，最后总需要一个人来拍板。在未决议之前，我们可以提建议。但如果已经形成决议了。那就只能执行。