酷播亮新聞
近期一直在梳理 需求收集、需求評審流程， 恰好自己帶的起點學院就業班鄰近畢業答辯，也要模擬需求評審過程，就寫一寫關於這方面的心得吧。 針對評審要注意的事項，我梳理了8個問題，和大家一起聊聊我的理解。
今天要講的，也是看蘇杰《人人都是產品經理》的一段描述所想到的：在阿里，產品經理如果要開展自己的項目，要定期整理需求， 專門召開立項評審會，帶著自己的需求和解決方案“過會”，向資源部門爭取資源 。
而在這樣的評審會上坐著的，都是各實施部門的老大，本著資源合理利用的原則，通常他們會很犀利地提出各種問題和質疑，這就要求產品經理充分理解自己的需求 ，做足準備，否則很容易就被“PK”掉，不受重視。
儘管很多公司沒阿里那麼嚴格，一般都能做到專人專用；但產品經理作為項目的主負責人，還是有必要在收集需求、評審需求時，把控需求的合理性，判斷需求的價值，從而 保證開發實現的需求是有意義的——這對產品經理而言是必要的，也是很高的要求。
那麼具體來說如何做到呢？ 本文整理了8個問題，分別是：
- 為什麼要做這件事？ 不做會“死人”嗎？
- 你的目標是用戶目標還是我們的目標？ 這類用戶對我們的優先級是什麼？
- 你的需求有普遍性麼？ 能代表多少？ 怎麼採樣的？
- 這個規劃未來1年是什麼樣？ 實現規劃路徑如何？
- 這麼多需求，你打算組建多少人的團隊？ 都需要什麼能力？ 怎麼分工？ 如果只給你2個人怎麼辦？ 如果只做一件事，最重要的是什麼？ 怎麼做？
- 能否給出項目效果是否達成的量化指標？ ROI是多少？
- 這個產品，實際路上會遇到的最大問題是什麼？ 打算怎麼解決？ 需要大家怎麼配合你，你打算如何說服大家幫你？
- 你預計要佔用多少開發資源？ 如何給技術人員帶來成就感和成長？
如果都能客觀清晰有條理地回答出來，能通過評審也就八九不離十了。 下面就談談我的理解：
1、為什麼要做這件事？ 不做會“死人”嗎？
這個問題用來評估需求的重要度。 也就是 要描述清楚需求的原因 ，如果不做，是否會帶來損失。 回答這樣的問題，一方面可以站在用戶角度，描述我們發現用戶在特定場景遇到的困難是什麼，這個困難不解決，短期有什麼影響，長期有什麼影響；另一方面可以站在客戶角度 ，描述客戶對我們提出了什麼要求，如果無法滿足會造成什麼經濟損失；再一方面可以站在內部人員的角度，描述日常工作的執行效率問題，如果不提升，會損失哪些機會成本。
2、你的目標是用戶目標還是我們的目標？ 這類用戶對我們的優先級是什麼？
這個問題用於確認做這件事是為了滿足KPI，還是滿足用戶需求。 就算是為用戶考慮，也要權衡是為哪個層級的用戶服務。
C端產品，用戶一般是金字塔形式分層，如果是免費產品，需要更多考慮金字塔底層的使用體驗，因為他們是根基；如果是付費產品，則需更多考慮付費用戶，也就是偏頂層的 體驗，因為他們是收入來源。
當然， 滿足“我們的目標”，也並不代表是不對的 ，通常這種目標就是銷售目標，B端商業變現目標，滿足這類“客戶”的商業價值，有時候對企業而言優先級則是最高的。
3、你的需求有普遍性麼？ 能代表多少？ 怎麼採樣的？
這個問題要求產品經理 說清需求來源和判斷過程。 產品經理採集需求的來源很多，可以是通過用戶反饋後台，或者運營反饋的用戶問題，或者是一些調研問卷，再或者是通過用戶行為數據。 那麼在需求整理時，就要講清楚哪些需求是反饋收集的，反饋人數有多少，這些反饋是否能對應到用戶行為數據，數據的來源是怎麼計算的，是否能推導出有更多人有同樣 的需求等等。
舉個例子，假設很多用戶反饋說希望App支持夜間模式，但開發夜間模式成本很高，這時你就可以在App中先做一個調節亮度的“偽夜間模式”，觀察用戶點擊行為，假設每天 有大量用戶啟動時調節了亮度，就能初步證明夜間模式功能的存在價值。
4、這個規劃未來1年是什麼樣？ 實現規劃路徑如何？
這個問題要求產品經理很清楚自己提的需求，未來的發展路徑規劃。 開發最忌諱的是一次性需求，做完了就完了，沒有可複用性 。 當然也不是所有需求都要持續維護，實際做的時候，產品經理可以對某個項目提出一些“假設”，這種假設可以是功能使用次數，可以是用戶反饋數，可以是產生價值數。 對需求的未來規劃，可以是“分叉”的，比如當數據大於一定量級，用戶正向反饋增加，帶來的商業價值增加，可以繼續增加功能，持續優化，反之則可以考慮轉換方向， 或者調整策略，或者直接下線。
5、這麼多需求，你打算組建多少人的團隊？ 都需要什麼能力？ 怎麼分工？ 如果只給你2個人怎麼辦？ 如果只做一件事，最重要的是什麼？ 怎麼做？
這個問題要求產品經理對開發、設計、測試的實現成本有一定估算 。 可以不用了解具體的實現方式，但需要根據自己的經驗和理解，評估出團隊成員人數和分工。 具體評估是要綜合考慮： 業務邏輯的複雜度，前台頁面的數量，上線時間，第一版質量要求等情況 。 後半句問題，則是從資源利用率最大化，和風險控制角度出發，反向要求產品經理能夠給出需求最核心的點， 也就是MVP方案 ，以便在項目產生風險時，能快速應對。
6、能否給出項目效果是否達成的量化指標？ ROI是多少？
這個問題要求產品經理對項目結果負責 。 提出需求前，產品經理就要對需求能達成的效果有明確的數據指標預估，尤其在資源有限的前提下，每個資源都是“成本”，實施方可以認為是“投資人”，肯定 追求的是最大投資回報率。
舉個例子，假設我們要上線一套分銷系統，允許用戶在購買完商品後，分享給好友，好友一購買，就能給分享人返利，好友也能獲得返利。 這時就要計算：分銷系統的開發人力成本（人/天）、上線後預估日購買次數（收益）、日分享次數、每分享購買率（收益）、日返利金額（成本）等指標。 當然為了跟踪方便和目標明確，也可以抽出其中1-2個關鍵指標，持續觀察，比如日銷售額和日毛利。
7、這個產品，實際路上會遇到的最大問題是什麼？ 打算怎麼解決？ 需要大家怎麼配合你，你打算如何說服大家幫你？
這個問題要求產品經理不僅要描述需求的優點，更要認識到可能產生的風險 。
這些風險可能是：
- 人力風險（團隊磨合、人員變更、水平高低不同等）
- 技術風險（存儲成本、IO壓力、安全加密、防刷機制等）
- 內部風險（臨時需求變更、需求方離職、產品經理經驗不足等）
- 外部風險（政策風險、額外成本、競爭對手壓力等）
羅列可能的風險後，必須給出對應的解決方案，讓大家了解到你不僅對目標明確，還明確達到目標的多條路徑。
至於說服的的方法，也是有策略的，有的需要正面回應，有的需要藉助外力，有的需要擺出事實，有的需要描繪願景，總之這個時候就考驗產品經理分析問題，解決問題的能力 了。
8、你預計要佔用多少開發資源？ 如何給技術人員帶來成就感和成長？
這個問題是第5個問題的細化版本，通常互聯網產品佔用研發資源是最大的，而研發人員最關心的可能不是支持了什麼業務、滿足了什麼需求， 而是這些需求實現後，對他們而言有什麼收穫 。
這種收穫，可能是精神層面的，比如用戶的正向反饋，比如給公司帶來了收入，比如提升了品牌影響力，但這些相對較弱；也可能是物質層面的，比如績效獎金，但 這些相對持續時間較短。
而實際對技術人員影響最大的， 還是技術水平的提升，還是遇到復雜問題並解決問題的快感 ，這些就是對自身能力的肯定。 因此，建議產品經理了解一些技術解決方案， 可以針對需求中的技術風險重點說明 ，從而提升大家解決問題的積極性。
至此，全部8個問題也就分享完了，當然，實際評審時，不同公司側重點肯定各有不同，但產品經理無論如何都要對每個需求深入理解，做到有理有據地說服大家跟你 幹！ 產品經理的成就感也就體現在此 ！ 我也在這條路上努力著，與你共勉！
#專欄作家#
申悅，微信公眾號：互聯網悅讀筆記（ID：pmboxs），人人都是產品經理專欄作家，36氪產品總監，起點學院優秀導師。
本文原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自 Unsplash ，基於 CC0 協議