直接說過什麼是需求，已經需求的挖掘，這次一起說說需求管理。
需求管理
- ① 漫畫去了解去 【到底怎麼得到“真實”的用戶需求？】
引一段國內翻譯的韓國漫畫
這是韓國的漫畫，如果沒看過的，可以仔細看下，這個故事：一個禿頭大叔自以為是的故事，我需要一個房間來“學習”，他認為是“學習”，把所有的房間改成了自習室，如果單純的把房間的名字改成自習室也就可以了，但是他把房間中最重要的一個物件，換成了桌椅板凳，這肯定是不舒服的對吧，結局可以看到，直接倒閉了。一起思考下下面的幾個問題。
1.大叔的賓館為什麼會倒閉
大家都是從20多歲走過來，我已經30多歲啦。肯定知道賓館是為什麼倒閉的。
2.真實需求是什麼？
大叔我們學習晚上會熄燈，馬上該期末考試了，想找個24小時亮燈的地方。之前說過用戶需求：用戶，場景，任務，目標。如果能好好理解下。可能真實需求不是他理解的學習。不是拿著書本各幹各的書的學習
3.紛繁世界裡有大量的需求，包括真需求，偽需求，因為需要產品經理用自己的判斷去甄別，選擇需求。
4.延伸思考
為什麼要選擇需求？用戶需求都是真的需求太多，做不完呀怎樣選擇需求怎樣拒絕需求怎麼給需求排期
- ② 需求管理需要先解決的問題
只需要從2個方面去考慮：需求真偽，需求優先級。
- ③ 真偽需求
一起看看共享小馬紮。用戶：等公交車的人。場景：累了找地方休息。目標：休息一下。任務：做了一個小馬紮一定要通過這個方式嗎？公交車頻次是15分鐘。坐不了幾分鐘。如果坐10分鐘1毛錢，它的成本什麼時候收的回來，做公交車才1塊錢，坐小馬紮也是1塊錢，有人願意坐嗎？所以在這個場景下，尤其是圖片裡面已經下雨了，誰會在上面坐。這肯定是個偽需求。
如果是在火車站，站票比較多，可能這個共享小馬紮就可以，下車的時候退回來，上車的時候掃一下。很多需求看真還是偽需要通過很多的面去看。
- ④ 如何區別真偽需求
剛才那個共享小馬紮的分析方式就是按照下面這3個點來分析的。
- ⑤ 場景，來辨別真偽需求
同樣的需求在不同的場景下可能是真需求也可能是偽需求：剛才小馬紮，在火車上可能就是真需求，在公交站可能就是偽需求。
1.社交產品做加好友功能【人與人之間的聯繫】 ---真
2.諮詢產品端做加好友功能【單向的點對點的獲取信息，單向對我聯繫，通過關注/訂閱的功能】 ---偽
- ⑤ 時機，來辨別真偽需求
同樣的需求在不同的實際下可能是真需求，也可能是偽需求，對的時間幹對的事情。二維碼這個東西其實早就出來了。為什麼現在才做。設備問題算一個。網絡通信的速度。人的信用，安全的問題。
1.2012年前做手機支付 ---偽
2.2015年做手機支付【目前很多人用支付寶都是用花唄】 --真
- ⑥ 需求痛點程度，來辨別真偽需求
同樣的需求 針對不同的用戶痛點程度就是不一樣的。
1.相親結婚 -- 對30+女性來說很痛
2.相親結婚 -- 對30+南翔來說只能癢
出一個【包結婚套餐】，對女性來說可能更真，對男性來說可能是偽需求。男的30+歲才結婚和女的30+歲結婚對家庭的訴求程度是不一樣的。對男的開玩笑：老光棍。跟女的開玩笑：單身。明顯感受區別就不一樣的。對於不同標籤的用戶對同一件事的程度是不一樣的。找到最痛的用戶，好推廣，抓住了這波人，很好做下一波事情。做需求的時候，受眾群體，一般是大量的，而不是做小眾群體。
沒有絕對的真偽需求的分界線！重點是理解目標用戶的真實訴求，結合場景和時機綜合判斷需求是否在當下為真需求。 一些直播平臺，土豪給主播打賞幾百萬都是有的，開發個刷火箭的功能也要不了幾百萬吧，幾萬塊錢就夠了吧。
（二）需求研究方法 - 優先級判斷
- ① 介紹
優先級（priority）是一種約定，優先級高的先做，優先級極低的後做。需求優先級的判斷，可以幫助確認後續開發階段什麼需求先做，什麼後做。如果一個公司老闆不給你排優先級就是耍流氓。如果你什麼都是緊急的，對於執行團隊來說，什麼都是不緊急了。一定要對開發團隊一個合理的優先級，如果沒有合理的優先級去驅動項目的話，這樣做的項目是沒有效率的。不能說什麼都緊急，什麼都不緊急，一定要做合理的判斷，要做一定的約定。優先級就是一個排序。一個一個，兩兩相比，時序的一個表格，給開發。
- ② 為什麼要判斷優先級
因為資源有限！開發就5個人，打滿傷害也就是996，但是時間依然是有限的！在有限的時間，開發資源，金錢等資源條件下我們需要用最簡單的產品邏輯來驗證商業模式。
- ③ 優先級判定的基本影響因素
兩兩要素的對比優先級的時候，一定是個綜合的，而不是某一項的對比。
- ④ 企業層面-公司戰略
與公司戰略相關的程序直接影響需求的優先級。
新聞資訊客戶端【基本戰略目標是以內容吸引用戶，穩定用戶】
1.需求一：專題內容【用戶更想看到的內容】 --- 高
2.需求二：導購內容 --- 低
- ⑤ 企業層面-產品生命週期
好的產品進入衰退期的時間特別特別的晚。不同的生命週期相同的需求也有不同的優先級。
- ⑥ 需求優先級的金字塔模型
- ⑦ 用戶層面-緊急重要四象限
不同的人 選擇可能是不一樣的。必須要考慮一些點，未來跟別人PK，增加一些砝碼。
- ⑧ 用戶層面 - 場景分析
在不同的場景下，需求的優先級會有差異用戶量越大，頻次越高或滿意度越低的需求則優先級更高。
- ⑨ 用戶層面 - 用戶等級分析
需要優先滿足大部分用戶的訴求，尤其是核心用戶的訴求。
遊戲平臺的裡面針對消費比較高的用戶，有專屬的VIP客服專員。定製特殊道具，身份的象徵。
- ⑩ 用戶層面 - 從可用到易用
涉及影響可用性的需求，優先級更高
音樂客戶端的播放功能 - 高音樂客戶端的社交功能 - 低
- ⑪ 技術層面 -開發成本
開發的難易成都也會影響需求的優先級難易程度的影響因素有，技術實現難度，投入人力成本，投入資金成本等。開發成本是上面幾種層面後，最後需要考慮的。小公司，自建雲，會存在較大的技術實現難度，若使用已有的公有云產品，雖每年支付服務費，但性價比更高。
（三）需求管理
- ① 介紹
需求挖掘，需求分析，到形成需求清單，並將需求實現的過程。在分析階段需確認需求的優先級，並進行簡單的需求分類，形成可存檔的文件。
- ② 需求池
把蒐集來的需求經過分析後，將確認需要實現的需求，放入一個可統一管理的地方。可以使用EXCEL，公司內部管理系統，Xmid等多種方式進行記錄。
- ③ 需求池撰寫要求
- ④ 需求表達
描述一個需求，單需求池內的記錄可以簡化，不要求寫出需求的具體執行方案。
- ⑤ 需求池的覆盤
產品經理應該培養習慣，定期如季度進行，原需求池規劃的覆盤，看已經規劃的需求是否完成，完成的需求實際效果如何，以便於更好的調整需求規劃。
（四）再來談談老闆需求
- ① 介紹
老闆的需求，都是職場的技巧。包括正式的任務或非正式的聊天中提到的內容。
- ② 場景
- ③ 老闆的考慮
戰略相關，個人喜好有關。
- ④ 已有需求匹配
- 他提出的內容是否在需求池中。
- 目前的優先級排序
- 是否已經有排期
- ④ 怎麼辦
- 老闆公開場合提出的內容，需儘快給出公開跟進反饋，如果合理，儘快實現。
- 老闆其餘昌河提出的內容，需進行跟進，給出產品的分析解決方案，不一定是實現。
- 老闆提出的內容與戰略直接相關，則需優先處理。
- 老闆提出的內容與個人喜好相關，且此需求優化成本較低，建議優先處理。
- 老闆提出的正好是需求池的低優先級需求，則根據其他因素判定後，決定是否要提前。
- 老闆提出需求是需求池中高優先級但還未排期的需求，儘快實現。
- ⑤ 總結
- 老闆需求終歸也是需求來源的一種。
- 產品經理以需求分析的基本方法進行分析。
- 重點考慮老闆的立場及他對資源的掌控情況。
- 學會妥協【TRADE OFF】，職場人太多人吐糟老闆，這不行，那不行，適當的妥協才能實現未來某項堅持可以實現。不要太自我，最後為這個產品買單的還是老闆。
PS：其實需求管理就是根據分析出來的一條一條需求之後，查看真偽需求，優先級判定，形成對應的需求池。跟任何人PK，只要不踩到底線讓一讓沒有關係。很多時候跟項目經理進行PK的時候一些需求在下個版本，但是老闆過來說這個需求很重要需要這個版本上，光明正大的可以拿著老闆的尚方寶劍找項目經理來說了，逼項目經理加班，或者延遲一天發佈。
