站長資訊網運營人工作中的一部分就是將需求反饋給產品經理，并確保需求能夠解決當前問題。那么如何讓產品經理正確理解我們要的需求是什么樣的、達到什么效果呢？筆者有兩個思路——準確理解需求&準確表達需求。
由于目前自己主要從事供給運營方面的工作，主要是配合地面團隊，協助商戶，共同賦能我們的核心業務。這其中免不了經常對接地面團隊，承接他們的產品需求，并將這些需求梳理后對接給PM。由于之前產品管理方面的經驗并不足，這次也算是一個學習的機會。
以終為始，既然要和PM對清楚需求，那么在我這個工作場景中就存在兩個關鍵點：準確理解需求；準確表達需求。
一、準確理解需求
地面團隊能力模型側重市場營銷，因此他們所提出的需求更多是具體場景下的操作，比如查詢XX店過去一年的經營數據并支持導出等。
這些都是一些碎片化的功能點，是事件。我們肯定不能將這些直接轉述給PM，因為這并不是一個合格的需求。
為了更好地理解需求，我創建了一個表格，表格中主要分五部分，分別為使用對象、使用場景、需求分類、需求描述、需求詳情。
1. 使用對象
地面團隊提出的產品需求，主要分兩種。一種面向內部協作工具，比如bd后臺；一種面向商家運營工具，比如商家中心等。兩種產品的使用對象是不一致的，前者是內部人員，后者是商家。
確定使用對象不僅可以協助我們后面思考用戶使用場景，還可以幫我們過濾掉一些產品需求，因為有些需求涉及到商家等敏感數據，這類需求要過濾掉。
2. 使用場景
解決完“對象”，下一個就是“問題”。使用場景指的就是需求背后所解決的問題，還是剛才的例子，“查詢XX店過去一年的經營數據并支持導出”，這個需求背后的使用場景就是地面團隊需要后臺提供經營數據查詢和導出。
3. 需求分類
需求分類可以有助于我們快速歸納整理地面團隊的需求。需求分3類，分別為數據需求，功能需求和交互需求。
- 數據需求包括新增/修改字段計算邏輯等。
- 功能需求最多，概括起來就是查詢、導入、導出。注冊、文件上傳等都屬于導入。
- 交互需求包括頁面功能區分布及功能點（事件）串聯邏輯。
4. 需求描述
描述就是基于使用場景（問題）后給出的解決方案，如新增某某功能點等。
5. 需求詳情
詳情即地面團隊所反饋給我們的“需求”，但是我們需要按照操作流程+功能點（事件）的形式闡述出來。這樣做是方便PM能夠更好地理解我們的需求。
借助這個梳理結構，我們基本可以快速理清地面團隊的產品需求，然后和PM進行對接。
當然，當我們自身是需求發起方的時候，我們也可以按照這種形式進行梳理，邏輯清楚后寫出來的需求文檔也更有可讀性和實操性。
二、準確表達需求
關于如何準備表達需求，我想很多朋友和我接下來寫的內容一致，那就是寫出一份好的需求文檔。因為我們畢竟不是PM，直接輸出PRD文檔未免有些大題小做，我們倒是可以借助PRD的書寫格式和邏輯來規整我們自己的需求文檔，以此更好地表達我們的需求，避免增加溝通成本。
需求文檔不同的公司都會有不同的書寫要求：以我們公司為例，大家常用的需求文檔共分五個部分，分別為需求描述、需求詳情、預計收益、優先級備注、開發進度。
1. 需求描述
如前文所說，描述就是基于使用場景（問題）后給出的解決方案，如新增某某功能點等。這點是為了讓PM能夠迅速定位自己要做什么，有一定的畫面感，接下來的溝通會更效率一些。
2. 需求詳情
為了更好地講述需求，我們常通過背景+需求內容的組合闡述。背景解答我們在什么樣的場景下誕生了這個需求，而需求內容一定要結合流程和功能點進行描述。
舉一個例子：
后臺增加回答任務項目，可展示任務詳情。這個需求并不明確，首先它不是詳情，只是一個描述。詳情需要結合功能點來說。正確的表述應該是任務基礎信息包括XXX，輸入項包括XXX等。
需求詳情書寫的過程中盡可能配圖，這樣有助于提升畫面感，增設或修改的功能點通過序號1、2標識出來也會更加形象。
3. 預計收益
這點主要是給PM做優先級排序用的，常規下我們任何一個需求都是為了提升核心業務去做的，無論是收入還是利潤，無論是短期見效還是長期見效。盡量將預計收益量化出來也有助于我們自身判斷需求的合理性。
4. 優先級排序
在我們內部合作的時候，這項是PM給填寫的，只不過我們作為需求的發起方也可以給出自己的預估優先級，供PM參考。為了拉齊認知，我們常規用重要性和緊急性進行分配，如重要不緊急、緊急且重要等。
5. 開發進度
同樣也是PM來填寫的，只不過放在這里有助于我們判斷項目進展階段，把控整體節奏。
需求文檔是一個對自身想法梳理加工呈現的過程，它需要溝通，但是是需要帶著邏輯和PM溝通，否則懷揣一腔熱血盲目去聊，浪費時間且沒有效率。
作者：吾運營，公眾號：吾運營
