需求分析——挖掘最根本的慾望
1.一切源於慾望
1.1慾望？需求！
慾望！何為慾望？心理學上對慾望的解釋是由人的本性產生的想達到某種目的的要求。在這個定義裡有兩個關鍵詞：本性、目的。它指出了慾望的源頭，是由人的本性產生的，是一種本能，人人皆有。同時也指出了慾望的產生原因，是為了達到某種目的。
舉個例子，吃飯，這是一項最基本的生理慾望，每個人為了生存必須要吃飯。要吃飯，就得先把飯做出來。我們有微波爐，電飯鍋等等很多可選擇的工具來幫我們做飯，甚至，做特殊的食物有專用的工具提供給我們，比如麵包機。再者，如果你不想做飯，連出門都懶得出，你可以用一款叫“餓了麼”的軟體將食物快遞上門。
前面提到的微波爐，電飯鍋，麵包機以及“餓了麼”軟體，都是我們可以用來滿足吃飯這項生理慾望的工具。換個角度，這些工具不就是工具生產廠家的產品嗎？換句話說，產品就是為了滿足人們慾望而產生的工具。既然產品是為了解決人們的需求問題，也就是說需求就是人們的慾望。
1.2慾望，如何滿足
每款產品都有自己要解決的核心的使用者需求，也就是說產品都有一個核心的慾望需要去滿足。比如，“餓了麼”軟體就是滿足人們叫外賣的慾望。但是，叫外賣的方式有很多種，為什麼使用者一定要用“餓了麼”軟體呢？這個時候，就需要對慾望進行深入的分析，已提供更好的服務來滿足人們的慾望，這個活動常常被產品人稱作需求分析。
舉個蘇傑大大在《人人都是產品經理》中的一個例子：絕跡小朋友想去吃火鍋，這是一個慾望。但是絕跡小朋友真的是嘴饞了想去吃火鍋嗎？可能絕跡只是餓了，但是這四川娃子餓了就只想到吃火鍋。如果真的只是餓了，給他倆包子也可以滿足絕跡的慾望，還能節省成本，何樂而不為呢。這就是一個典型的需求分析過程，通過需求分析找到了最簡單的滿足人們慾望的方式。
再來談談“餓了麼”軟體，在這個軟體出現之前人們也是能叫外賣的，那麼這款軟體有什麼更好的滿足人們叫外賣慾望的方面呢。我們先來看看以前叫外賣的痛點。叫外賣有兩種方式，如果店鋪有官網，可以去官網訂餐，但是，這些只限於一些大型連鎖餐廳，比如麥當勞。另一種方式就是電話預定，但是前提是你要有店鋪電話，一般人肯定不會有附近所有餐廳的電話。“餓了麼”軟體就解決了這兩個痛點，它能蒐羅使用者周圍提供送外賣服務的所有餐廳，併為所有餐廳提供網上訂餐服務，同時也免去了獲得餐廳電話的需求。通過分析，“餓了麼”軟體提供了更好的滿足需求的服務。
2.合適的慾望碰到合適的人
2.1使用者角色建模
每一款產品都有自己的受眾，沒有哪款產品是每個人都需要的。為此，我們需要對自己產品的受眾進行分析，看看這些使用者使用產品的習慣是怎麼樣的。這樣可以更好的提取使用者的需求。
首先，要找出產品的受眾，這個流程一般被稱為使用者角色建模。使用者角色建模首先要通過頭腦風暴的方式列出可能的使用者角色集合。還以“餓了麼”軟體為例，一般都是什麼樣的人會叫外賣呢？勞累一天的上班族，學校的學生，偶爾想改善伙食但不想出門的人，加班的人，不會做飯的人。
在收集了使用者角色集合以後，我們需要對這些使用者角色進行整理，看看角色之間有沒有包含或者重合的地方，如果有，則需要考慮是否用角色需要被丟棄。比如上面的使用者集合中，不會做飯的人並沒有典型的特徵，而且，在上班族、學生、加班的人中都可能會有不會做飯的人。則，不會做飯的人完全可以被其他角色所代替，這個使用者角色就可以被丟棄了。
在整理完畢使用者角色後，可以將每個使用者角色寫在一個卡片上，並在每個卡片上寫下這個使用者角色的一些特徵，這樣可以方便的對使用者角色進行分析。比如，在上班族卡片上可以寫上對菜品質量要求較高，可以熟練使用電腦，可能會經常使用該軟體等等。
有些時候為了對使用者角色更加深入的瞭解，一般會對重要的使用者角色建立角色例項。角色例項是一個貼近生活的使用者場景，通過角色例項可以建立起一個真實的人物，讓我們對角色有更真切的瞭解。如果上班族是我們主要的目標使用者，我們為上班族建立一個角色例項如下：
image
有業界的大大建議在設計新系統時對一些極端人物建立角色卡。這些極端人物並不是產品的典型使用者，但是他們卻是真的會使用我們的產品。比如一些花痴小妹妹，叫外賣或許對她們來說並不是必須的，但是她們可能僅僅是為了看某個送外賣的帥哥，而經常定那家餐廳的外賣。我們不需要浪費太多時間在這些極端人物身上，甚至這些人物的需求根本不會被實現，但是花點時間在這些使用者身上，或許會產生一些意想不到的靈感。
2.2 需求源於角色
前面在使用者角色建模上浪費了很大精力，其實都是在為這裡的需求收集做準備。不同的角色肯定會有不同的需求，這個時候，我們需要將自己代入角色，仔細想想如果自己是這個角色，會有什麼樣的需求。將所有考慮到的需求都記錄下來，為以後的需求整理做準備。
比如，作為一名上班族，很晚才回到家，這個時候叫外賣肯定希望外賣會很快的到達。而且上班族一般都習慣刷卡，如果提供刷卡或者網上支付功能會很方便。而“餓了麼”軟體就為使用者提供的外賣到達時間的預估，使用者可以方便的選擇可以快速到達的外賣。
再考慮學生，學生這是個沒有收入的群體，所以物美價廉的外賣是他們的首選。學生一般對快遞的送達時間會有相對較大的容忍度。學生中對刷卡的需求不是很迫切，他們一般更喜歡現在付款，所以如果有貨到付款的服務會很合適。同時，如果可以用學生卡打折，我想會很受學生們的歡迎。
3.慾望也有輕重緩急
在需求收集和整理完成後和專案開始開發之前，我們需要召開需求評審會來確定每個需求的優先順序和開發計劃。如果你的團隊正在使用Scrum敏捷開發，那麼你們一定在用使用者故事來整理使用者需求。使用者故事通常使用客戶和團隊都可以看懂的表達方式來寫，每一個使用者故事都是產品的一個需求。當然，使用者故事還包括需求的商業價值和相關人員。使用使用者故事可以方便的與客戶溝通，而且不用檢視繁瑣的需求文件。
使用者故事一般使用如下格式：為了[商業價值]，作為[角色]，我想要[做某事]。還是使用“餓了麼”軟體為例，比如上班族想找到送外賣快的餐廳的需求可以表述為：為了讓外賣更快的送達，作為上班族，我想要檢視每家餐廳的外賣送達預估時間。
在使用者故事確定以後，我們需要召集開發人員，客戶還以一些產品的相關人員來參加需求評審會。在會議上，我們需要對每個需求的商業風險，技術風險，開發耗時和優先順序作出評估。
首先需要確定的是商業風險，也就是確定哪些是核心需求，哪些是亮點需求。核心需求需要儘早完成，缺失了產品就不完整。而亮點需求有則會給產品加分，沒有也不會影響使用者的使用。一般來講，核心需求的商業風險會比較低，因為這些需求都是產品必須的，被砍掉的可能性很低。而亮點需求的商業風險就會高，可能會因為開發時間不足而被砍掉或者被放入下次版本迭代的週期中。
下來需要確定技術風險和開發耗時，技術風險代表的是這個需求開發的難易程度。如果這個需求所需要的技術開發團隊從來沒接觸過，需要對這個技術從頭開始學習。那麼這個需求的技術風險就會很高，因為這個新技術不知道開發團隊是否能掌握，多久才能掌握。技術風險的評估對開發耗時的評估有很大影響。開發耗時在Scrum開發團隊中一般用時間點來計算，一個時間點代表一個理想工作日。在我的團隊中，一般使用斐波那契數列來劃分時間點的等級。因為我們發現工程師經常在為一個需求的時間點而爭論不休。如果為一個需求是2個時間點還是3個時間點而爭論，這是有意義的，因為3個時間點比2個多了一半的工作量。但是如果在為一個需求是99個時間點還是100個時間點而爭論就是沒有意義的，因為這一個時間點的差別對我們的影響很小。為了避免這種無意義的爭論，我們使用斐波那契數列來劃分時間點，這個時候工程師只需要考慮這個需求的耗時更靠近89還是144，而不用為了細小的差別而爭論不休。在評估技術風險和開發耗時時，一般都有技術人員和專案經理來確定，其他人員不應該左右技術人員和專案經理的思維。
最後則是評估需求的優先順序，綜合分析以上三個要素，來最後給需求評估優先順序。一般情況下核心需求的優先順序往往是最高的，不過有時候由於技術風險過大，或者開發耗時過長，有些核心需求的優先順序會被降低。在優先順序評估完畢後，開發團隊會確定第一輪的迭代要完成的需求。如果是使用Scrum敏捷開發有一段時間的話，開發團隊是知道自己在一個迭代週期能夠完成多少時間點的任務的，也就是團隊的速率。一些高優先順序的需求由於時間點太大而不能放入本次迭代，而使用其他優先順序相對較低但時間點小的需求代替的情況也會時常發生。
4.讓慾望在掌握之中
在完成需求評估後，開發團隊就會進入開發階段。在Scrum團隊中，需要對開發中的需求進行管理。常用的方法是在一塊木板或是一面牆上列出正在開發的，開發完成的，正在測試的和完成了的需求。這塊木板或強被稱為看板。每個人都可以在看板上清晰的看到團隊現在的開發狀況。我的團隊沒有使用實體的看板，而是使用JIRA這個軟體提供的電子看板。
在開發過程中，需求的變更是必然會發生的。正常情況下，如果一輪迭代已經開始了，Scrum團隊是不會中途停止的。新的需求必須在下一輪迭代中才能加入，這樣可以保證開發的正常秩序。為此，我們在看板最前方新加了一項：待開發。我們會將變更的而且有限級高的需求放在這一列，以保證在下一輪迭代中實現這些需求。
大部分公司都會要求寫需求文件，這樣對所有需求歸類，並且可以方便以後的查閱。但是這些需求文件有時候書寫的並不是很規範，或是很全面。導致查閱的時候很難找到我們需要的內容而且在需求，有時候甚至是寫完後根本無人去理會。而且，在需求變更時需要進行維護，耗費人力，文件在多次修改後導致內容很亂，或是前後需求矛盾的情況時有發生。
現在一個新的需求管理方法，需求的例項化，可以解決這些問題。需求的例項化是不再編寫和維護需求文件，而是直接使用高質量的測試用例作為需求文件。通過測試用例可以很清楚的看到產品的需求內容，而且，在需求變更時，必然會產生新的測試用例，而不必費力去維護。在清晰的表現需求的同時，減少了維護需求文件的人力。
REF
- ofollow,noindex">http://www.woshipm.com/discuss/34783.html
原文連結 https://www.devzhao.com/post/3364e690.html
轉載時請註明出處，謝謝合作。