项目的需求来源有很多方面，最终由产品整理出来哪些要做，哪些不做。我前面说过需求评审时，要讲清楚这次版本的目的是什么。这些要做的功能就是达成目的的手段。
一般情况下，我们都默认产品或技术总监给需求定优先级。比如优先级高、中、低。实际上这样分还不够细，优先级高的标准是什么？
想要做好优先级管理，首先得制定一套标准。不一定要非常准确，但一定要有且公开。
任何一个需求，都有其价值。其价值主要分为：商业价值、用户价值。
商业价值：直接给公司带来利润、完成长期战略目标、降低运营成本等功能。
用户价值：提升用户体验、提高用户效率、解决用户痛点等功能。
为此，我们可以得到一个二维四象限图
由此，我们可以得到：
高商业价值、高用户价值的需求：立马做；
高用户价值、低商业价值的需求：在资源有闲的时候做；
低用户价值、高商业价值的需求：选择性做或者换个方式做；
低商业价值、低用户价值的需求：不要做。
为什么说要商业价值优先？因为没有商业价值，项目就不可能持久。每一个需求都是要投入人力的，在资源有限的情况下，我们只能把精力放在高商业价值、高用户价值的需求上。
通过价值维度排除一部分需求后，依然会存在两个同样高商业价值、高用户价值的任务冲突的情况。我们可以选择继续细分，按紧急和成本二个维度继续划分，可以得到：
紧急、成本低的高商业价值、高用户价值的需求：优先级排第一位；
紧急、成本高的高商业价值、高用户价值的需求：优先级排第二位；
不紧急、成本低的高商业价值、高用户价值的需求：优先级排第三位；
不紧急、成本高的高商业价值、高用户价值的需求：优先级排第四位；
大部分公司，很少要拆到这个程度，如果真出现这种情况，我觉得是好事，公司应该尽快招聘更多的人来加速商业价值的落地。
项目需求能不能变？
一般需求确定下来后，最好不要做临时变动。除非特别情况。那什么是特殊情况？这就是制定需求优先级规则的好处了，如果确实有更紧急、成本低的高商业价值、高用户价值的需求。我们可以变动。只要团队内成员都认可这个规则，就会比较好实施。
那如果是领导不按规则变动需求怎么办？
谁担责谁决策。如果领导要临时变更需求，而且部门负责人已经反馈变更的影响后，还依然如此的。我们依然要听领导的。同时跟团队也讲清楚这个道理。而且领导站的位置不一样，我们以为的高价值任务对站在领导的角度并不一定对。
在公司里可能会存在很多类似的情况，每个人可能有不同的意见，最后总需要一个人来拍板。在未决议之前，我们可以提建议。但如果已经形成决议了。那就只能执行。
【one more thing】
我们在需求确定后，往往还需要设计师做交互设计、视觉设计稿。那对于其中的设计师来说也会存在优先级的一个问题。
在极客时间《体验设计课》的主理人炒炒老师，在课程里介绍了一种根据需求清晰度评估优先级的方法。对设计师非常有用。
按照需求的清晰度来区分，分别是“从零开始的需求、沙子需求、板砖需求和钻石需求”。
首先，从零开始的需求是指只有需求的意向，需求清晰度在 25% 以下。需求所涉及的具体功能模块、流程、边界都是空白的，这一切都是需要进一步详细讨论的。
第二种是沙子需求。也就是已经有初稿需求，需求清晰度在 26%-70%。这个阶段的重点工作是需要明确需求的结构层内容。
第三种是板砖需求，是不是听起来很形象？板砖需求就是指需求的内容已经相对清晰，包括流程与功能，需求清晰度在 71%-90%。这个阶段的重点工作是框架层的内容设计，是可以马上开展交互设计工作的（包括前后端交互流程、页面布局、页面跳转、交互细则等）。
最后一种需求是钻石需求。也就是需求是在现有功能成熟的基础上做细节调整，需求清晰度在 90% 以上。这个阶段的重点工作是表现层的设计，例如增加提示语、调整表单内容顺序等。
需求清晰程度越低的需求，设计师需要投入的时间与精力是越长的，而且最好是整块的时间；
需求清晰度越高的需求，设计师需要投入的时间与精力相对少，且可以并行。
