方法論：產品經理，如何更加高效高質量輸出需求？
零基礎學產品，BAT產品總監帶，2天線下集訓+1年線上課程，全面掌握優秀產品經理必備技能。 瞭解詳情
釋放雙眼，帶上耳機，聽聽看~！
00:00
00:00
18年，在做年度覆盤時，回顧了自己過去一年的產品工作，發現了幾個共性的問題，其中有一個就是：需求場景考慮不全面，開發過程中還會有需求變更。很不巧，開發GG們最討厭的就是需求頻繁變更。作為一個有強烈求生欲的產品，這個問題真的不容輕視啊~因此不禁問自己：你真的會寫需求嗎？換一種問法就是：產品經理，如何更加高效高質量輸出需求？
前言：閱讀須知
在開始進入正文之前，先對內容做一些概要說明，若未能滿足你的閱讀需求，可自行繞過，避免造成不必要的時間浪費，引起身心不適哈哈~~
（1）適用人群
作為一個2年級產品新生，認知邊界肯定有一些侷限性，建議閱讀人群為：-1~2年的產品經理。產品前輩們可隨意，當然歡迎提出寶貴的批判意見。
（2）解題思路
針對自己存在的這個問題，進行現狀、成因的深入思考，以更好地對症下藥，提出一些粗淺的解決辦法。
（3）內容說明
寫該文章的初衷，主要是為了給自己一個答案，在解決寫需求中的問題做一些沉澱，分享出來是希望志同之士一起探討成長。文章涉及面較為廣泛，因篇幅和個人時間有限，僅做框架梳理，不做深入展開，內容概要見下圖：
1. 現狀
這一部分解答是什麼。還是圍繞目標：高效、高質量輸出需求。那麼不高效、不高質量的需求是什麼樣子的？
1.1 寫需求不高效
不高效比較好理解，很容易想到一點就是：憋半天沒寫出幾句話哈哈。通過長時間的暗中觀察哈哈，身邊厲害的產品經理，寫需求基本都是信手拈來的。
為啥能這麼快？
得到的回答是：都是套路！在這裡，我們不妨拆解下，你就可以發現，可用套路的一些蛛絲馬跡。從寫需求整體用時來看：包括了需求調研時間長和需求編寫時間長。
（1）需求調研時間
完整的需求調研應該包括：業務訴求調研、競品調研、系統實現調研。
① 業務訴求調研
需求的來源方很多，比如老闆、使用者、業務部門，業務調研是為了深入瞭解業務的訴求，以便更好實現業務目標。比如做電商的，業務目標可以為GMV。
② 競品調研
是基於產品目標、滿足客群去鎖定直接競爭對手、潛在競爭對手，然後開展具體的產品調研，可包括：產品功能調研、產品迭代方向、盈利模式等，這部分調研可大可小，視具體需求而定。
③ 系統調研
對系統現有能力的瞭解，介面欄位有哪些、前中後臺的資料如何傳輸、儲存怎麼樣？產品需要關注的原因是：寫出的需求能更好地落地，不過不是重點。這部分一般看產品所處階段，從0到1，可能看得不多。後續迭代優化的，需要多看看。
（2）需求編寫時間
為啥別人寫一個需求，蹭蹭蹭三五下就完成了，而你還在吭哧吭哧寫半天？其實，前面的需求調研很關鍵。要是寫需求也有二八法則的話，需求編寫佔20%。需求編寫用時可以包括如下3個部分：
① 需求方案設計
用什麼樣的方案滿足使用者的需求，以保證業務目標的達成？這個偏向戰略層和範圍層，比如：抖音：記錄美好生活，其實通過短視訊解決使用者碎片時間消磨問題（僅代表個人見解）。
② 需求流程設計
完成一個閉環任務，需要使用者走進什麼樣的流程？比如患者去醫院的看病流程：掛號–候診–問醫生–出診斷結果–繳費–取藥。
③ 線框圖繪製
前端頁面互動部分的繪製，這很好理解了。
1.2 需求質量不高
這個部分，可能相關同學最直觀感受就是：需求根本沒法看啊：義正言辭、慷慨激昂、長篇大論，卻不知所云！需求寫得好不好，產品經理應該具備一個敏銳的意識就是：當開發經常來找你瞭解需求，這個時候，你該反思自己需求編寫問題了。
個人理解：需求質量高不高，可以分為以下兩個部分：場景缺失及文件可讀性差，對於是否更好滿足使用者需求，這裡不討論。
（1）場景缺失
這個部分可以看出一個產品的內功是否深厚了。我理解這裡的場景包括：業務場景和系統場景。
① 業務場景缺失
產品功能經常考慮不完整，導致後面變更需求。比如說：漏了一個未登入使用者的展示狀態；比如說，漏了使用者優惠券過期之後，前端介面的引導
② 系統場景缺失
有些系統實現場景考慮不完全，也是開發經常找的一些點。缺失範圍可能為：系統頁面互動、資料互動、判斷邏輯、異常處理。
（2）文件可讀性差
正如章節所說的，一些常見的現象是：文字太多、邏輯太亂、語義表述不清、沒有區分人群針對性得編寫。
2. 成因
這個部分，解答為什麼。其實上面的問題列清楚之後，再進一步思考，很容易知道為什麼造成這樣。寫需求基本可以有三大組成部分：搞懂問題、找到合適的解決辦法、將辦法寫出來。
因此下面的點可能是導致問題出現的原因：
2.1 搞不清楚問題的本質
其實搞懂一個問題的本質，談何容易，因為這個跟每個人的教育程度、社會閱歷、認知水平密切相關，這都是硬傷，除了提升認知水平，真的沒有根本的解決辦法。不過為啥還值得拿出來一說呢？因為這些套路，可以降低你去快速一個問題的費力度。
所以，在短時間內搞不清楚，其實是缺乏有效的調研辦法，對於這個問題，曾經做過一些思考、整理，一會說。（網上其實也一大把，關鍵你自己去不去找，找到後適不適用）
2.2 找不到合適的解決辦法
瞭解了問題之後，還需要知道怎麼做，否則也只能說紙上談兵。在這裡造成問題的細分原因如下：
（1）無清晰的目標
寫需求的時候，目標不明確，要解決使用者的核心痛點是啥，價值主張不清晰，將無從下手。如果這個目標（大餅）沒畫好，大傢伙為啥給你做需求呢？。往大里說：比如阿里巴巴，讓天下沒有難做的生意。往小裡說：這個頁面需要提升使用者的點選購買率。
（2）無明確的優先順序
想做的太多，很容易決策困難，眉毛鬍子一把抓是很容易犯錯的。因此市場反饋未知、資源有限情況下，快速迭代試錯的敏捷開發流，是一個很好的指導思想。從0到1，考慮mvp。從1到100，考慮當下產品階段、業務目標最需要解決的問題。
（3）無合適的載體
知道目標及優先順序之後，困擾產品經理的可能還有：滿足使用者需求的介質選定。微信公眾號、小程式、還是app？這個決策也是依賴於對使用者、業務的深入思考。
2.3 場景缺失原因
這個問題導致的原因很簡單：就是對業務、使用者、系統的不瞭解以及經驗不足導致的。
2.4 文件可讀性差原因
主要分兩個點：沒有區分閱讀人群和資訊呈現形式差。
（1）沒有區分閱讀人群
產品經理的PRD，將會給到前端開發、後端開發、測試、設計師幾類同學閱讀。文件本身也是一個產品，每一方的需求點都是不同的，如果沒有差異化滿足他們，可讀性當然就不會好到哪裡去。
（2）資訊呈現形式差
為啥需求文件是一些規範的框架，其實是有意識地提升單位行間距輸出的觀點密度。框架內的內容就得靠產品經理陳述了，基本上是產品經理組織資訊並且表達出來的能力不足導致的。
3. 解決辦法
前面的廢話說了很多哈，承蒙不棄，能看到這裡。其實主要是為了幫助大家更好理解辦法是怎麼給出來的。來點實際套路吧：
寫需求前：
3.1 專案調研思路
下面展開又是一篇文章：
3.2 選定解決辦法
找解決辦法的思路，其實在前面闡述問題原因的時候，已經說過了，適用才是王道。這裡可以參考使用者體驗五要素裡面的幾個維度去思考。
- 戰略層：確定為什麼做
- 範圍層：確定做什麼
- 結構層：確定整體的業務流程
- 框架層：確定互動原型圖
- 表現層：視覺的呈現，UI
（可能描述得不準確，求輕怕~~）
寫需求時：
（1）場景缺失問題
1）業務場景層
首先的要了解使用者的痛點及人群（通過調研）、產品的目標。這樣在產品設計的時候，更容易去拆分場景去設計功產品功能。可以拆解為：
- 同一個使用者在不同的場景下面，有時間維度、地域維度、登入狀態維度等，舉個例子：讀書app，需要滿足使用者在白天和晚上的閱讀需求；
- 不同使用者群體在同一個場景，在從會員等級、客群區分、任務狀態上，產品如何滿足群體個性化需求，等等~~找個時間可以歸歸類。
2）系統場景層面
注意考慮如下幾個方面：
（2）資訊表達形式
1）整體思路就是
在資訊內容傳遞上，視訊＞圖片＞文字。
2）需求規範
- 有側重描述：前後端、測試和設計關注重點，對於設計同學，可單建一個文件說明。
- 背景（痛點）、需求實現、需求價值——文字
- 需求管理——表格
- 需求範圍——表格
- 需求流程——VISO圖
- 頁面互動及邏輯——Axure或者墨刀，線框圖
3）需求型別及表示式
- 資料類：報表需求、埋點需求，側重表字段來源、加工邏輯及更新邏輯；
- 後端類：側重欄位定義、判斷邏輯；
- 前端類：側重互動邏輯、展示邏輯。
好了，以上都是一本正經地胡說八道，希望對大家有幫助！
作者：大熊，15年畢業於華南理工大學，有運營和產品經歷，現負責金融大資料產品：個性化推薦、智慧搜尋及AI智慧客服。個人微信公眾號：大雄背起行囊。
本文由 @大熊 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議
