3.欲望也有輕重緩急
在需求收集和整理完成后和項目開始開發之前，我們需要召開需求評審會來確定每個需求的優先級和開發計劃。如果你的團隊正在使用Scrum敏捷開發，那么你們一定在用用戶故事來整理用戶需求。用戶故事通常使用客戶和團隊都可以看懂的表達方式來寫，每一個用戶故事都是產品的一個需求。當然，用戶故事還包括需求的商業價值和相關人員。使用用戶故事可以方便的與客戶溝通，而且不用查看繁瑣的需求文檔。
用戶故事一般使用如下格式：為了[商業價值]，作為[角色]，我想要[做某事]。還是使用“餓了么”軟件為例，比如上班族想找到送外賣快的餐廳的需求可以表述為：為了讓外賣更快的送達，作為上班族，我想要查看每家餐廳的外賣送達預估時間。
在用戶故事確定以后，我們需要召集開發人員，客戶還以一些產品的相關人員來參加需求評審會。在會議上，我們需要對每個需求的商業風險，技術風險，開發耗時和優先級作出評估。
首先需要確定的是商業風險，也就是確定哪些是核心需求，哪些是亮點需求。核心需求需要盡早完成，缺失了產品就不完整。而亮點需求有則會給產品加分，沒有也不會影響用戶的使用。一般來講，核心需求的商業風險會比較低，因為這些需求都是產品必須的，被砍掉的可能性很低。而亮點需求的商業風險就會高，可能會因為開發時間不足而被砍掉或者被放入下次版本迭代的周期中。
下來需要確定技術風險和開發耗時，技術風險代表的是這個需求開發的難易程度。如果這個需求所需要的技術開發團隊從來沒接觸過，需要對這個技術從頭開始學習。那么這個需求的技術風險就會很高，因為這個新技術不知道開發團隊是否能掌握，多久才能掌握。技術風險的評估對開發耗時的評估有很大影響。開發耗時在Scrum開發團隊中一般用時間點來計算，一個時間點代表一個理想工作日。在我的團隊中，一般使用斐波那契數列來劃分時間點的等級。因為我們發現工程師經常在為一個需求的時間點而爭論不休。如果為一個需求是2個時間點還是3個時間點而爭論，這是有意義的，因為3個時間點比2個多了一半的工作量。但是如果在為一個需求是99個時間點還是100個時間點而爭論就是沒有意義的，因為這一個時間點的差別對我們的影響很小。為了避免這種無意義的爭論，我們使用斐波那契數列來劃分時間點，這個時候工程師只需要考慮這個需求的耗時更靠近89還是144，而不用為了細小的差別而爭論不休。在評估技術風險和開發耗時時，一般都有技術人員和項目經理來確定，其他人員不應該左右技術人員和項目經理的思維。
最后則是評估需求的優先級，綜合分析以上三個要素，來最后給需求評估優先級。一般情況下核心需求的優先級往往是最高的，不過有時候由于技術風險過大，或者開發耗時過長，有些核心需求的優先級會被降低。在優先級評估完畢后，開發團隊會確定第一輪的迭代要完成的需求。如果是使用Scrum敏捷開發有一段時間的話，開發團隊是知道自己在一個迭代周期能夠完成多少時間點的任務的，也就是團隊的速率。一些高優先級的需求由于時間點太大而不能放入本次迭代，而使用其他優先級相對較低但時間點小的需求代替的情況也會時常發生。
