」人人都是產品經理--蘇傑「讀書筆記（需求分析）

06-02

發現一個問題，然後設法將其轉化為一個任務來解決

產品的廣義概念：可以滿足人們需求的載體。我的理解則更直白一點：產品就是用來解決某個問題的東西。

1需求採集方法：「需求採集人人有責」，從而「儘可能多地採集」（先開放式問題，為後者收集具體的封閉式問題）

「數據分析」：數據分析是如何轉化為商業價值的。整體的思路是：在對產品足夠熟悉的基礎上，先做出方向性的假設，再提取相應的數據並分析，得到一些現象，最好是之前沒發現的現象，然後嘗試解釋，接下來做用戶調研修正解釋，最終指導產品發展方向。
「調查問卷」：調查問卷通常封閉式問題比較多，適合大用戶量的信息收集，但不夠深入，一般只能獲得某些明確問題的答案，調查問卷不是考試卷，不適合安排問答題
「用戶訪談」：用戶訪談的提綱通常是開放式問題，無論是網上還是線下，作答時間最好不要超過 10 分鐘，否則很多人看一眼就被嚇跑了。開篇一般放一些簡單的不需思考的問題；很想知道的內容，需要思考的，較適用於我們心裡還比較疑惑的時候去尋找產品的方向，適合與較少的訪談對象進行深入的交流
二手需求採集工具——單項需求卡：理念就是：產品的需求工作不只是需求分析人員的事，而是涉及產品的每個干係人的義務，至少得參與「採集」的過程，理想的狀態是產品的所有干系人都參加過「需求採集」的培訓，然後在日常工作中養成主動提交需求給產品人員的習慣，但實際很難做到，所以作為專業的需求分析人員，就應該盡量降低同事們，比如銷售、服務、技術人員提交需求的成本，也是節省我們自己的時間。

現場調查：說簡單一點就是打入「敵人」內部，和客戶一起工作一段時間，深度了解需求。它是一種典型的定性分析，持續時間長，從幾小時到幾個月，既能聽到用戶怎麼說，也能看到用戶怎麼做，不過受眾面極其狹窄，一次只有一個，要特別小心被「非典型」用戶帶到溝里去。
AB 測試：基於大用戶量比較合適，比如有一個按鈕不知道是放頁面的左邊好，還是右邊好，而我們有 10 萬用戶，那就先隨機挑選少量的用戶發布這個按鈕，1000人放左邊，另外 1000 人放右邊，然後過一段時間分析結果，再決定剩下的 98%用戶該怎麼辦。很明顯，這也是讓用戶直接參与了設計，這樣低成本的方法讓很多傳統行業的同學羨慕不已
日記研究：互聯網新興的個人應用比較適合，某個新產品出來以後，很多業內的朋友都會去嘗試，然後寫一些使用體會，但作為產品設計者在看這些日記的時候，要明白日記的作者往往是同行，而不是主流用戶。
卡片分類法：我們把產品的各種需求寫在便利貼上，讓用戶一起討論並完成分類。這能讓你深入了解用戶是怎麼給產品劃分模塊的，用戶認為這個網站應該是什麼結構。因為產品設計人員的思維和用戶的思維通常不一樣，這也就導致了如果是產品設計師來單方面決定網站結構的話，很可能導致用戶理解的困難，所以卡片分類法能讓最終的產品更加符合用戶的心理模型。
自己提需求：這是最簡單的方法。每一個靠譜的產品都會有一群粉絲用戶，不用你去找他們採集需求，他們也會給我們驚喜，主動提出很多需求，作為產品的主人，我們好意思還沒有用戶了解產品么？產品要用才能感覺出好壞，特別是自己做的產品。產品做多了，我們隨便看看別人做的產品，總能一下子挑出很多問題，提出很多需求，反過來看自己的產品越看越完美，這一定有問題，所以必須用自己的產品，最好是發動認識的人都來用。

2需求分析過程：產品經理要「聽用戶的但不要照著做」，必須「明確我們存在的價值」是「把用戶需求轉化為產品需求」，這一過程即需求分析過程。

產品經理要通過「給需求做一次 DNA 檢測」，來「確定需求的基本屬性」、「分析需求的商業價值」、「初評需求的實現難度」，從而計算出需求的「性價比」。

用戶需求 VS.產品需求

用戶需求：用戶自以為的需求，並且經常表達為用戶的解決方案。

產品需求：經過我們的分析，找到的真實需求，並且表達為產品的解決方案。

需求分析：從用戶提出的需求出發，找到用戶內心真正的渴望，再轉化為產品需求的過程。需求分析是「首先：樹葉——樹枝——樹榦，其次：樹榦——樹枝——樹葉」的分析過程，所以說完整的需求分析是一個「分-總-分」的過程。

3用戶研究：針對所有有這個痛點的用戶進行研究發現規律得到印證

明確目標
選擇采集方法
制定採集計劃
執行採集
資料整理
然後進入下一步的需求分析階段

4滿足需求的三種方式

之前我們說過，需求來源於理想與現實的差距，那麼減小這個差距就有三種方式：

改變現狀：是我們最常用的，去開發某種產品，但也是最笨的辦法。
降低理想：不要忽視精神的力量，什麼「打預防針」、「醜話說在前頭」這類句子想必大家都經常聽到。
轉移需求：因為人類的注意力是有限的，所以引導用戶去關注其他事物，他就會覺得這個差距沒那麼可憎了。我們也可以說，人的行為是需求驅動的，想改變人的行為，可以尋找更強烈的需求展現給他，而讓他不再糾結於原來的需求

5把用戶需求轉化為產品需求：我們先把用戶需求轉化為產品需求，然後一步步確定每個產品需求的基本屬性、商業價值、實現難度、性價比等。

模塊：一般來說，根據人類記憶的特點，產品有 5±2 個模塊比較合理，如果超過 7 個，你就要考慮重新劃分，甚至增加一個基本屬性叫「二級模塊」。

6需求種類知多少

然後，需求的提出者需要自己辨別一下這個需求的種類，為後續的商業價值判斷提供一些輔助信息。我們嘗試過幾個維度，如表 2-5 所示：

分類：可以分為「新增功能、功能改進、體驗提升、Bug 修復、內部需求」等。

其實產品需求遠非我們直接可以想到的功能需求，還包括了很多非功能需求，比如：性能、可培訓、可維護、可擴展……有很多需求不是為終端用戶做的，而是為銷售、服務、測試團隊的同學做的。

通常來說「產品功能需求+產品非功能需求 = 產品需求」，而「產品需求+市場需求+開發需求+測試需求+服務需求+…… = 產品包需求」，對這些概念感興趣的同學可以去查閱「需求管理」相關的資料。

層次：把需求分成「基礎、擴展（期望需求）、增值（興奮需求）」三層，理論依據參見KANO模型17 （KANO 模型以東京理工大學教授狩野紀昭（Noriaki Kano）的名字命名，是一種對顧客需求或者說對績效指標的分類，通常在滿意度評價工作前期作為輔助研究模型，KANO 模型的目的是通過對顧客的不同需求進行區分處理，幫助企業找出提高企業顧客滿意度的切入點。）

7分析需求的商業價值

商業價值，或者叫商業優先順序，是對上述幾種商業價值指標的綜合評判。這一條是整個需求列表中最核心的部分，這裡的判斷直接影響著產品未來的方向。有時候我們還在列表裡增加一列「商業價值描述」，通俗點就是這個需求的賣點是什麼，可以給用戶提供什麼價值，對公司又有什麼幫助

8初評需求的實現難度:絕對不能因為某個需求的商業價值很大就馬上去做，也不能因為另一個需求的商業價值不大就不做。

首先:簡化為人力成本，即工作量，其他資源的消耗，比如額外的硬體成本，我們會發現只有極少數的需求會有這樣的問題，不具有普遍性，所以碰到的時候都做特例處理。

其次:我們把工作量再簡化為開發量。我經歷的項目，各類人力資源有：產品、開發、測試、服務等。但一般情況下，團隊里產品人員資源相對富裕，測試資源可以調配，服務資源可以臨時補充，所以開發資源經常成為瓶頸。於是，我們一般評估每個需求的開發工程師工作量來表徵其實現難度，這背後的道理是以團隊里的瓶頸資源為評估基準（如表 2-7 所示），大家視自己團隊的情況靈活應用。

開發量是非評估不可的，我把它叫做「初評」，允許誤差，並且會要經驗豐富的人來評估，通常是技術經理，或者系統分析師、架構師./。這裡的評估一般用「人天」作為單位，某個需求需要「1 人天」意味著需要 1 個人做 1 個工作日。

9性價比啊性價比:我們已經做了需求採集，把用戶需求轉化為產品需求 ，知道了某個需求的基本屬性、種類、商業價值、開發量，現在似乎應該開始寫文檔、幹活了，但經驗告訴我們不是這樣的：絕對不能因為某個需求的實現難度很小就馬上去做，也不能因為另一個需求的實現難度大就不做.

性價比 = 商業價值÷實現難度（簡化為開發量）

10需求 PK:活下來的永遠是少數

按產品線劃分的團隊對產品本身是有利的，產品經理權力更大，可以按照自己的想法做，資源有保證，產品規劃不容易被動改變。此外，各種職能的員工之間溝通順暢，單線領導，開發的頭、測試的頭等都向產品經理負責。

按職能線劃分的團隊對多個產品間的資源共享有利，可以讓資源流向更需要的地方，保證對核心產品的投入，但是效率不高，由於產品規劃的決策需要在更高層面上敲定，單個產品的發展速度會有所降低。此外，資源戰爭可以把「鯰魚效應 18(鯰魚效應即採取一種手段或措施，刺激一些企業活躍起來投入到市場中積极參与競爭，從而激活市場中的同行業企業。其實質是一種負向激勵，是激活員工隊伍之奧秘。 )兩種組織結構，給我「一攻一守」的感覺，產品在創業期的時候，需要全速發展，必然是產品線結構，產品經理帶頭往前沖。而當公司里有多個產品慢慢成熟之後，就多用職能線來更充分地利用資源.

11準備出發：把需求打個包

項目管理的內容：做項目，終極目標就是：多快好省，即範圍大、時間短、品質高、資源省。

我們把產品需求列表按照「性價比」從大到小排序過了么？從上往下看，每一行後面都還對應著一個「工作量」，現在我們只要做一個簡單的加法，一行又一行地從上到下依次納入項目，能做多少，一目瞭然，我們把這個動作叫「需求打包」，而對這些需求的整體描述，也就是商業需求文檔里的功能說明了。

第一，「需求打包」最好打包類似的功能點。是否類似取決於需求的基本屬性，這是「確定需求的基本屬性」那一節里做的事情。一般來說業務上邏輯關係密切的需求才會包含在一個項目里.

第二，需求依賴，功能互相之間有依賴關係。那些只能先做的功能，應該在產品需求列表裡註明；功能與人力資源之間的依賴關係也會經常存在，比如有些功能只能由團隊里的特定成員來做。

第三，需求的粒度大小問題。商業價值很高的功能，如果細分的話，我們會發現其中也有價值相對低的部分，所以需求的粒度應該盡量細，前提是細化引起的管理成本上升在可接受的範圍內，給個生活中的例子幫助理解：大開間辦公區域里的燈，不可能用一個開關控制，也不可能每一個開關只控制一盞燈。具體細到多少，要根據具體情況具體分析。我們的經驗是，在需求列表裡出現的任意一行，工作量最好不要超過「5 人天」。

戰場：產品會議

12BRD 怎麼寫，都包含哪些內容

項目背景：我們在哪裡？為什麼要做這個項目，解決什麼問題，可以列出一些數據說明項目的必要性。

商業價值：我們去哪裡？最關鍵的重點！大老闆們最感興趣的，做了這個項目以後有什麼價值，一定要說在點子上。一般我們還會預測一下相關數字的變化，提出這個項目的商業目標。

功能需求描述：我們怎麼去？通過做哪些事情來達到目標，把打好包的需求描述一下，可以用功能列表的形式表達，但最好能畫出業務邏輯關係。當然我們也經常會搞點技巧性的東西，比如故意加入一些讓老闆砍的需求，希望老闆砍完之後心有愧疚不好意思再砍我們真正想做的東西，這有點類似談判技巧里的玩意，大家可以試試，但不要在這上面太花心思了。

非功能需求描述：提一下重要的非功能需求，如果有的話。

資源評估：第二個重點！大老闆們要看成本，他們在了解達成項目的目標需要多大的花費以後，才能做出決策。

風險和對策：有的項目會有一些潛在風險，這個時候不妨拋給老闆們看一下，並且給出自己的對策，說不定你覺得是很大的麻煩，在老闆那裡一句話就可以搞定。而且由於信息的不對稱，我們無法了解某些功能是否會與公司將來的戰略衝突，這時候提出來也是讓老闆們把一下關。