3.欲望也有轻重缓急
在需求收集和整理完成后和项目开始开发之前，我们需要召开需求评审会来确定每个需求的优先级和开发计划。如果你的团队正在使用Scrum敏捷开发，那么你们一定在用用户故事来整理用户需求。用户故事通常使用客户和团队都可以看懂的表达方式来写，每一个用户故事都是产品的一个需求。当然，用户故事还包括需求的商业价值和相关人员。使用用户故事可以方便的与客户沟通，而且不用查看繁琐的需求文档。
用户故事一般使用如下格式：为了[商业价值]，作为[角色]，我想要[做某事]。还是使用“饿了么”软件为例，比如上班族想找到送外卖快的餐厅的需求可以表述为：为了让外卖更快的送达，作为上班族，我想要查看每家餐厅的外卖送达预估时间。
在用户故事确定以后，我们需要召集开发人员，客户还以一些产品的相关人员来参加需求评审会。在会议上，我们需要对每个需求的商业风险，技术风险，开发耗时和优先级作出评估。
首先需要确定的是商业风险，也就是确定哪些是核心需求，哪些是亮点需求。核心需求需要尽早完成，缺失了产品就不完整。而亮点需求有则会给产品加分，没有也不会影响用户的使用。一般来讲，核心需求的商业风险会比较低，因为这些需求都是产品必须的，被砍掉的可能性很低。而亮点需求的商业风险就会高，可能会因为开发时间不足而被砍掉或者被放入下次版本迭代的周期中。
下来需要确定技术风险和开发耗时，技术风险代表的是这个需求开发的难易程度。如果这个需求所需要的技术开发团队从来没接触过，需要对这个技术从头开始学习。那么这个需求的技术风险就会很高，因为这个新技术不知道开发团队是否能掌握，多久才能掌握。技术风险的评估对开发耗时的评估有很大影响。开发耗时在Scrum开发团队中一般用时间点来计算，一个时间点代表一个理想工作日。在我的团队中，一般使用斐波那契数列来划分时间点的等级。因为我们发现工程师经常在为一个需求的时间点而争论不休。如果为一个需求是2个时间点还是3个时间点而争论，这是有意义的，因为3个时间点比2个多了一半的工作量。但是如果在为一个需求是99个时间点还是100个时间点而争论就是没有意义的，因为这一个时间点的差别对我们的影响很小。为了避免这种无意义的争论，我们使用斐波那契数列来划分时间点，这个时候工程师只需要考虑这个需求的耗时更靠近89还是144，而不用为了细小的差别而争论不休。在评估技术风险和开发耗时时，一般都有技术人员和项目经理来确定，其他人员不应该左右技术人员和项目经理的思维。
最后则是评估需求的优先级，综合分析以上三个要素，来最后给需求评估优先级。一般情况下核心需求的优先级往往是最高的，不过有时候由于技术风险过大，或者开发耗时过长，有些核心需求的优先级会被降低。在优先级评估完毕后，开发团队会确定第一轮的迭代要完成的需求。如果是使用Scrum敏捷开发有一段时间的话，开发团队是知道自己在一个迭代周期能够完成多少时间点的任务的，也就是团队的速率。一些高优先级的需求由于时间点太大而不能放入本次迭代，而使用其他优先级相对较低但时间点小的需求代替的情况也会时常发生。
