需求挖掘入門

來自專欄 產品經理：從0到1

用戶的需求往往不是能直接看到，它們隱藏在話語和行為的背後，我們需要將它們挖掘出來。

• 需求

產品就是為了滿足人們慾望(需求)而產生的工具

需求是人性想達到的某個要求，而產品作為實現其要求的工具。

• 需求與角色

每一款產品都有自己的受眾，我們需要找出產品的受眾---用戶角色建模。

用戶角色建模首先通過頭腦風暴的方式列舉可能的用戶角色集合，然後對這些角色進行整理，剔除重合的部分。整理完後，對每個用戶寫下其特徵，也可以建立角色實例，可以建立起一個真實的人物，例如：

角色建模後，將自身代入角色，考慮該角色會有怎樣的需求，都記錄下來。然後進行需求整理。

• 需求評審

召開需求評審會來確定每個需求的優先順序和開發計劃。

Scrum敏捷開發---用用戶故事來整理用戶需求

用戶故事一般使用如下格式：為了[商業價值]，作為[角色]，我想要[做某事]。還是使用「餓了么」軟體為例，比如上班族想找到送外賣快的餐廳的需求可以表述為：為了讓外賣更快的送達，作為上班族，我想要查看每家餐廳的外賣送達預估時間。

在用戶故事確定以後，我們需要召集開發人員，客戶還以一些產品的相關人員來參加需求評審會。在會議上，我們需要對每個需求的商業風險，技術風險，開發耗時和優先順序作出評估。

首先需要確定的是商業風險，也就是確定哪些是核心需求，哪些是亮點需求。核心需求需要儘早完成，缺失了產品就不完整。而亮點需求有則會給產品加分，沒有也不會影響用戶的使用。一般來講，核心需求的商業風險會比較低，因為這些需求都是產品必須的，被砍掉的可能性很低。而亮點需求的商業風險就會高，可能會因為開發時間不足而被砍掉或者被放入下次版本迭代的周期中。

下來需要確定技術風險和開發耗時，技術風險代表的是這個需求開發的難易程度。如果這個需求所需要的技術開發團隊從來沒接觸過，需要對這個技術從頭開始學習。那麼這個需求的技術風險就會很高，因為這個新技術不知道開發團隊是否能掌握，多久才能掌握。技術風險的評估對開發耗時的評估有很大影響。開發耗時在Scrum開發團隊中一般用時間點來計算，一個時間點代表一個理想工作日。在我的團隊中，一般使用斐波那契數列來劃分時間點的等級。因為我們發現工程師經常在為一個需求的時間點而爭論不休。如果為一個需求是2個時間點還是3個時間點而爭論，這是有意義的，因為3個時間點比2個多了一半的工作量。但是如果在為一個需求是99個時間點還是100個時間點而爭論就是沒有意義的，因為這一個時間點的差別對我們的影響很小。為了避免這種無意義的爭論，我們使用斐波那契數列來劃分時間點，這個時候工程師只需要考慮這個需求的耗時更靠近89還是144，而不用為了細小的差別而爭論不休。在評估技術風險和開發耗時時，一般都有技術人員和項目經理來確定，其他人員不應該左右技術人員和項目經理的思維。

最後則是評估需求的優先順序，綜合分析以上三個要素，來最後給需求評估優先順序。一般情況下核心需求的優先順序往往是最高的，不過有時候由於技術風險過大，或者開發耗時過長，有些核心需求的優先順序會被降低。在優先順序評估完畢後，開發團隊會確定第一輪的迭代要完成的需求。如果是使用Scrum敏捷開發有一段時間的話，開發團隊是知道自己在一個迭代周期能夠完成多少時間點的任務的，也就是團隊的速率。一些高優先順序的需求由於時間點太大而不能放入本次迭代，而使用其他優先順序相對較低但時間點小的需求代替的情況也會時常發生。

• 需求開發管理

在完成需求評估後，開發團隊就會進入開發階段。在Scrum團隊中，需要對開發中的需求進行管理。常用的方法是在一塊木板或是一面牆上列出正在開發的，開發完成的，正在測試的和完成了的需求。這塊木板或強被稱為看板。每個人都可以在看板上清晰的看到團隊現在的開發狀況。我的團隊沒有使用實體的看板，而是使用JIRA這個軟體提供的電子看板。

在開發過程中，需求的變更是必然會發生的。正常情況下，如果一輪迭代已經開始了，Scrum團隊是不會中途停止的。新的需求必須在下一輪迭代中才能加入，這樣可以保證開發的正常秩序。為此，我們在看板最前方新加了一項：待開發。我們會將變更的而且有限級高的需求放在這一列，以保證在下一輪迭代中實現這些需求。

大部分公司都會要求寫需求文檔，這樣對所有需求歸類，並且可以方便以後的查閱。但是這些需求文檔有時候書寫的並不是很規範，或是很全面。導致查閱的時候很難找到我們需要的內容而且在需求，有時候甚至是寫完後根本無人去理會。而且，在需求變更時需要進行維護，耗費人力，文檔在多次修改後導致內容很亂，或是前後需求矛盾的情況時有發生。

現在一個新的需求管理方法，需求的實例化，可以解決這些問題。需求的實例化是不再編寫和維護需求文檔，而是直接使用高質量的測試用例作為需求文檔。通過測試用例可以很清楚的看到產品的需求內容，而且，在需求變更時，必然會產生新的測試用例，而不必費力去維護。在清晰的表現需求的同時，減少了維護需求文檔的人力。