人人都是產品經理--讀書筆記(2)--需求

產品經理的工做和其餘人最大的不一樣是：產品經理是作本身想作的，而不是作別人想作的。

什麼是需求？需求的本質是問題，問題的本質是理想與現實的差距。知足需求，就是解決問題，拉近理想與現實的距離。
因此：
分析需求就是分析問題；
帶團隊就是帶領你們一塊兒解決問題；
帶項目就是按必定順序去解決問題；
戰略就是考慮要解決哪些大的方面的問題等等。

用戶與客戶的區別：
用戶就是使用產品的人；
客戶就是買了產品的人。
例如，你到超時買泡麪，對於超市來講，你是超市的用戶，同時也是超市的客戶；對於泡麪廠商來講，超市是泡麪的客戶，你是泡麪廠商的用戶。
廣義的用戶則包含全部的用戶、客戶、以及和產品相關的人。

設計產品的原則：以用戶爲中心

以老闆爲中心
在一些小的創業公司，老闆每每是最熟悉業務的人，也最瞭解需求，不少需求都是老闆憑經驗想出來的，可是這些需求每每都很是有效。所以，對於這些公司來講，老闆是他們很是重要的用戶。

產品的用戶不少，知足全部用戶的需求是不可能的，所以要知足最重要的用戶。具體知足哪些用戶，是跟產品的戰略和商業目標相關的。

建立人物角色：
建立一個虛擬的人物，補充我的信息、產品的使用習慣、用戶目標、商業目標等。有形的人物角色不必定給建立的人本身看，而是有新人進團隊的時候，能夠快速瞭解相關的用戶，理解產品。對於不多關注細節的老闆來講，也能夠經過人物角色快速瞭解用戶和產品。

用戶研究方法，能夠經過兩個維度：
定性(瞭解)，定量(驗證)
目標和觀點(說)，行爲(作)

定性的說，例如，用戶訪談；
定量的說，例如，調查問卷；
定性的作，例如，可用性測試；
定量的作，例如，數據分析。

用戶訪談
用戶數量少，每一個用戶的時間長，一般用於新品預研，或者對數據分析結果進行背後的調研。
可能存在的問題：
1 用戶說的和作的不一致
解決方法：
創造和用戶交互的場合，讓用戶一邊說一邊作；
區分用戶說的事實(我作了什麼，步驟如何等)和觀點(我以爲，我認爲等)
2 樣本少，可能形成誤差
解決方法：
在訪談報告中把可能的因素都寫進去
增量訪談方式，每次增長訪談，觀察結論是否有變化，若是有，則繼續增長訪談，直到沒有變化爲止
3 用戶太強勢，將咱們帶偏
時刻牢記訪談的目的，隨時往正道上引導
4 咱們太強勢，將用戶帶偏
時刻牢記訪談的目的，管好本身的嘴

調查問卷
調查問卷和用戶訪談的區別：
用戶訪談一般是開放式問題，調查問卷一般是封閉式問題；
用戶訪談的用戶數比較少，調查問卷用戶數很是多；
用戶訪談與訪談對象的交流比較深刻，調查問卷問題不深刻，只是得到某些明確的問題的答案。
可能存在的問題：
1 樣本與目標羣體存在誤差
解決方法：
儘量選擇更多不一樣類型的樣本；
在報告中標明數據的獲取方法和來源；
將篩選條件做爲問題放入調查問卷，調查完以後再將這部分人羣篩選出來。

2 樣本數量過少

3 問題不要有引導性，注意問題答案的順序

可用性測試
準備一些任務，讓用戶經過使用產品來完成所要求的任務，而後組織者在旁邊觀察用戶的操做，並將發現的問題記錄下來。測試結束以後，會詢問用戶的主觀見解和感覺。
問題：
1 作的太晚，沒有時間解決問題
2 以爲太麻煩，或者太專業，因此就沒作
3 告知被測者，這個測試目的是測試產品，而不是測試用戶，讓被測者不要有心理壓力
4 測試前，告知被測者測試中要作的事情，大概持續時間；測試時，不要給被測者提示，同時可讓被測者將本身的思考過程說出來；測試後，給被測者發一份小禮品，還能夠將測試總結髮給被測者。

數據分析
對用戶使用產品所產生的操做日誌、網頁訪問日誌等進行統計分析，挖掘背後的緣由。

一手需求和二手需求
一手需求是產品經理直接從用戶那邊獲取到的需求，二手需求是公司的銷售、老闆或運營提出的需求；
一手需求一般是產品主動提出來的需求，像是生孩子，二手需求一般是被動接受的需求，像是養孩子；
產品剛剛建立的時候，一般一手需求比較多，而當產品已經運營了一段時間以後，可能就會有愈來愈多的銷售那邊提過來的二手需求。

需求採集
單項需求卡片模板(用於讓非產品的人提出需求)
需求編號
需求類型：功能需求、非功能需求
來源(who)：誰提出的
場景(where、when)：產生該需求的時間、地點
描述(what)
緣由(why)：爲何會有這樣的需求
驗收標準(how)：如何確認這個需求被知足了
需求重要性權重(how much)
需求生命特徵(when)：需求的緊急程度，需求的持續性
需求關聯(which)：和需求關聯的人、其它業務和需求、設備、系統等
參考材料
競爭者對比

其它需求採集方法
現場調查
AB測試：發佈一個新功能，先讓少數人使用，看看這些人的反應
日記研究：新產品發佈後，研究其餘人寫的關於產品的日記

聽用戶的，可是不要照着作

需求分析
用戶需求：用戶本身提出來的需求，其實更多時候是用戶本身的解決方案
產品需求：通過分析以後獲得的需求，表達未產品的解決方案
需求分析是從用戶需求中挖掘出用戶背後真正要解決的問題，並轉換爲產品的解決方案。
用戶的解決方案->用戶需求->產品需求->產品的解決方案
因此需求分析是一個由外到內，再到外的過程。
爲何不直接去實現用戶本身提的需求？若是隻考慮短時間利益，則能夠這樣作，可是考慮到長期利益，則必定要站在用戶角度，去解決用戶真正的問題。

需求分析過程：
1 用戶需求轉換爲產品需求，肯定產品需求的基本屬性
2 分析商業價值
3 初評實現難度
4 計算性價比

需求的基本屬性
編號
提交人
提交時間
模塊
名稱
描述
提出者
提出時間
bug編號

鮎魚效應：一個團隊慢慢穩定以後，團隊成員積極就會下降，這時候須要利用鮎魚效應，引入競爭機制和獎勵機制，提升團隊成員積極性。

BRD：商業需求文檔(Business Requirement Document)：
項目背景
商業價值
功能需求
非功能需求
資源評估
風險和對策

作需求的一個原則：寧肯只把一小部分功能作的很完美，也不要把不少功能作的不完美。