之前講過需求采集的事兒，需求采集了很多，但從哪裡着手？使用者幫我們想好了怎麼做，照使用者說的做嗎？
關于這一點，《人人都是産品經理》的作者蘇傑，用了這樣一個title：聽使用者說但不要照着做。
1、明确我們的價值
對于采集的需求，首先要明确的知道，一個是使用者需求，一個是産品需求，這中間的轉化過程，就是這篇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/
需求分析和技術分析的差別：
技術分析：“樹幹————樹枝————樹葉”，即将大問題拆分為小問題，然後發現難點，逐一攻克。
需求分析：首先“樹葉————樹枝————樹幹”，然後“樹幹————樹枝————樹葉”的分析過程，即“分————總——-分”過程。
核心思想：即不能漏掉提煉使用者需求的這個過程，另一方面也不能隻停留在本質上。
滿足需求的三種方式：
之前講過，需求來源于理想與現實的差距，減小這種差距，就有如下三種方式。
①提高現實
即我們最常見也最常用的辦法：開發某種産品，但也是最笨的辦法；
②降低理想
還記得以前那個著名的“暗室滴水試驗”嗎？永遠不要忽視心理暗示的力量，“打預防針”、“醜話說在前頭”聽得不要太多；
③轉移需求
引導使用者去關注其他事物，或者這麼說：人的行為都是需求驅動，想改變，需要将更強烈的需求給使用者，而不是糾結于原來的需求。
2、給需求做一次“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%的收益，是以，這個需求，必須實作，但難度又很大。。。。。。
上面這件事，從商業價值考慮，是必須要做的，但實作難度較大，開發量可能比較大，是以又回到了成本效益這個問題。
是以，關于成本效益這個話題，還要綜合多方因素來考慮。
轉載請注明出處，商用請征得作者本人同意，謝謝！！！