需求分析

以前講過需求採集的事兒，需求採集了不少，但從哪裏着手？用戶幫咱們想好了怎麼作，照用戶說的作嗎？

關於這一點，《人人都是產品經理》的做者蘇傑，用了這樣一個title：聽用戶說但不要照着作。

 

一、明確咱們的價值

對於採集的需求，首先要明確的知道，一個是用戶需求，一個是產品需求，這中間的轉化過程，就是這篇blog的主題——需求分析。

用戶需求 VS 產品需求

用戶需求：從用戶採集到的、用戶自覺得的需求，而且常常表達爲用戶解決方案；

產品需求：通過分析，找到的真實需求，而且表達爲產品解決方案；

需求分析：從用戶提出的需求出發，找到用戶心裏真正的渴望，再轉化爲產品需求的過程。

關於需求分析，能夠先看看下面的一幅圖：

這個過程能夠形象化爲「Y」，「需求分析」的過程就是經歷圖中的「1 –> 2 — >3」，把「用戶需求」轉化爲「產品功能」。

「Y」的越上面越是解決方案，越下面越是背後的目的。「1-用戶需求」，大多表現爲用戶的解決方案，每每是很差的，但好的「3-產品功能」必定是從用戶需求轉化而來，而不是憑空而來。

so，「聽不聽用戶」都是一個意思，更準確的說是「聽用戶的，但不要照着作」。同時，也不要誤解「創造需求」，你創造的只能是知足用戶需求解決方案——產品功能，而不是用戶需求。

1–>2，經過問「Why」，逐步概括，2–>3，經過問「How」，逐步演繹。過程當中都要用到各類輔助信息，好比數據、競品、行業等。

把「2-產品需求」追溯到「4-馬斯洛需求」的過程是可選的，畫爲虛線，只是爲了這個理論的完備，若是感興趣，每一個產品需求總能挖到馬斯洛的層面。

「2-產品需求」的點如何選擇，咱們到底應該挖到那個層面上，做爲產品需求，取決於公司和產品的定位。

PS：關於需求分析，關於「Y理論」，蘇傑還有一篇更詳細的「Y理論」，跳轉連接:http://iamsujie.com/1000/1017/

需求分析和技術分析的區別：

技術分析：「樹幹————樹枝————樹葉」，即將大問題拆分爲小問題，而後發現難點，逐一攻克。

需求分析：首先「樹葉————樹枝————樹幹」，而後「樹幹————樹枝————樹葉」的分析過程，即「分————總——-分」過程。

核心思想：即不能漏掉提煉用戶需求的這個過程，另外一方面也不能只停留在本質上。

知足需求的三種方式：

以前講過，需求來源於理想與現實的差距，減少這種差距，就有以下三種方式。

①提升現實

即咱們最多見也最經常使用的辦法：開發某種產品，但也是最笨的辦法；

②下降理想

還記得之前那個著名的「暗室滴水試驗」嗎？永遠不要忽視心理暗示的力量，「打預防針」、「醜話說在前頭」聽得不要太多；

③轉移需求

引導用戶去關注其餘事物，或者這麼說：人的行爲都是需求驅動，想改變，須要將更強烈的需求給用戶，而不是糾結於原來的需求。

 

二、給需求作一次「DNA檢測」

整個檢測過程能夠用以下的這幅示意圖來表示：

 

如上圖所示，咱們先把用戶需求轉化爲產品需求，而後一步步肯定每一個產品需求的基本屬性、商業價值、實現難度、性價比等。

其中，基本屬性，能夠結合Google的測試分析法：特質+組件，來進一步思考；連接：http://www.cnblogs.com/imyalost/p/6593817.html

①把用戶需求轉化爲產品需求

通過以前的需求採集等過程，如今咱們有不少需求，接下來就是整理需求，建議一個項目組或團隊裏，採用統一的記錄方式，好比Word、excel等。

接下來，「明確咱們的價值」。建議團隊成員一塊兒開展一次「頭腦風暴」，對需求有個全面的瞭解，而後每一個人分一塊，將其轉化爲產品需求，最後記錄在一塊兒。

咱們要明確一點：用戶需求和產品需求是多對多的關係，可能用多個功能來知足一個用戶需求，也可能用一個功能知足多個用戶需求，甚至多個產品需求知足多個用戶需求，並無一一對應的關係。

固然，通常而言咱們採集整理後的產品需求不少，因此在需求轉化中，須要「忍痛」作一輪篩選，把明顯不靠譜的用戶需求剔除，固然，其中的尺度本身把握。

 

②肯定需求的基本屬性

固然，產品需求須要一直維護，能夠指定一我的維護，或者共享模式，你們一塊兒維護。需求總有一些「基本屬性」，能夠見下圖：

編號：做爲需求的惟一標識，方便指明需求，快速查找

提交人：必填，提交人是PD，有充分的義務理解原始的用戶需求

提交時間：輔助信息，記錄提交人什麼時候提交該需求

模塊：通常而言，根據人類記憶特色，產品由5±2個模塊比較合理，若是超過，就要考慮增長一個基本屬性叫「二級模塊

名稱：用簡潔的短語描述需求，要給用戶提供什麼樣的功能，好比：黑名單

描述：用來具體的描述名稱中的功能是什麼意思，描述只須要說明此功能作什麼，無須解釋怎麼作；注意語言的無歧義性、完整性、一致性和可測試性等

提出者：用戶需求提出者，有疑惑時便於進一步追溯

提出時間：原始需求提出時間，區別於提交時間，這是個輔助信息

BUG編號：可選，通常來講，產品的某些BUG也能夠視爲需求，固然，也能夠用其它方式管理BUG

 

③需求種類

說到需求種類，能夠看看下面這個表格所示：

分類：除了上面的表格內容以外，還包括不少非功能性需求，好比性能、可培訓、可維護、可擴展......有不少需求更是爲了公司其餘業務部門同事作的。

層次：把需求分爲「基礎、擴展（指望需求）、增值（興奮需求）」三層，理論依據參照KANO模型。

其實，對需求的種類劃分沒這麼絕對，取決於不少因素，好比商業目的變了，或者功能類型變動，都會有影響。

《人人都是產品經理》的做者蘇傑有這樣的解釋：

雪中送炭：指產品的基本功能，對用戶很重要，產品缺了這個功能，就沒法操做使用；

錦上添花：非必須的功能，用戶有時會用到，能夠更便於用戶使用；

 

④、分析需求的商業價值

一個公司作任何產品，一個產品作任何需求，最終都是要知足必定的商業目的，不管是直接仍是間接產生的效益。

因此，需求的商業價值是最關鍵的內容，值得咱們用不一樣的指標來判斷衡量，以下面的表格所示。

重要性：能夠參考時間管理裏面「重要與緊急」的概念（推薦一本書：《高效能成功人士的七個習慣》）。

緊急度：從時間維度上判斷這個需求是否迫切，以及作或不作對產品的影響。

持續時間：一個產品是有生命的，需求也是，有的很長，有的很短（好比「雙11」）。

商業價值：或者稱爲商業優先級，是對上述幾種商業價值指標的綜合評判，這點是整個需求列表中最重要的一部分。

 

⑤需求的實現難度

這一點，特別是對於開發童鞋來講，就是工做量化，能夠從如下幾點來講：

工做量：即人力成本、額外的硬件成本、其餘資源的消耗等。

開發量：需求實現難易程度，開發的時間成本（通常來講，大多的公司開發人員都比較忙。。。）等。

PS：固然，還有運維童鞋的部署維護資源投入，測試童鞋的測試所需時間、人力成本等等。

 

⑥性價比

性價比=商業價值÷實現難度

決不能由於某個需求實現難度很小就立刻去作，也不能由於另外一個需求實現難度大而不作。

說到這裏，想起以前發生在我建的技術交流羣的一件事：

事情是這樣的：有位在鬥魚性能測試組的大神，某天他提了一個問題，其實用糾結這個詞來形容更好，問題就是：鬥魚有10%的用戶用的WindowsXP系統，並且瀏覽器

是IE8及如下，這樣就致使了他們的兼容和性能問題比較明顯，可是這10%的用戶爲鬥魚提供了20%的收益，因此，這個需求，必須實現，但難度又很大。。。。。。

上面這件事，從商業價值考慮，是必需要作的，但實現難度較大，開發量可能比較大，因此又回到了性價比這個問題。

因此，關於性價比這個話題，還要綜合多方因素來考慮。