最重要的8大內容「產品經理需求文檔包括哪些內容」

• 需求文檔每家公司的要求和格式都不盡相同，每個產品經理也都有自己的習慣和方法，一味想歸納出一種適合各種公司環境和不同開發節奏的「普世模板」，未必能達到預期的價值；
• 需求文檔中的大部分內容可能是相對同質的，把大量篇幅放在重複性的地方不如抓重點，多總結點心得和遇過的坑；
• 直接給出一個模板講不太清楚（且能搜到的模板有很多），具體舉例說明在書寫範圍上又不可控，所以想找到一個「取巧」的表達方式。

需求文檔結構圖

1. 用戶是誰。寫需求文檔其實跟做產品有些相似，要了解你的閱讀用戶是誰。上圖中分成了兩個顏色，其中紅色部分的目標用戶是PM，可以是你的產品總監也可以是其他領導，目的是輸出產品調研、分析、推演的過程和結論。當然部分內容不是必須出現在需求文檔中的，因為它們可能在產品方向討論、用戶分析調研和需求分析等環節就已經確定了。所以具體怎麼書寫還是要看自己公司的情況。而紫色部分是給主要使用者：研發、UI、測試、項目或者運營同學看的，這部分作為說明、實施部分一般都需要包含，且要達到完整、清晰、易懂。

2. 項目背景。筆者剛從業時項目背景總是一筆帶過，覺得這是很虛的東西沒人看。作為執行層面，這部分確實沒有什麼價值。可如果PM真的想要進階商業能力，從整個產品甚至生態的維度去考慮方案和機會的話，項目背景就一定要認真寫，起碼要認真思考、認真總結。這部分需要解釋的有兩個地方：

• 行業：行業是一個組織化的概念，像出行、健康、零售等這些都屬是行業，一般情況下的產品業務分析，最高維度的抽象差不多就到這了。要了解或思考的關鍵問題是：行業中有哪些角色？它們之間的關係是什麼樣的？市場政治經濟環境如何？行業的變化規律是什麼（可以對比國外，也可以參照相似的行業）？以及有哪些可能的機會？
• 市場：市場是相對行業低緯度的橫向概念，需要考慮的是規模，上下游關係，平台和應用分別是什麼，是否有同質和差異化等問題。

3. 目標與預期。設立目標和預期是為了保證方向明確，並在產品上線後根據預期可以比對、驗證效果。

• 目標：需要找到可以反映目標的可量化關鍵指標，如果目標不止一個，目標和指標的設定就要有優先級的意識。且一定要明確最關鍵的一個指標。
• 預期：若是完全新的產品和功能，要根據調研結果進行量化估算；若是已有產品的優化改進，則要列出當前的數值和推演後預期的數值。

4. 業務架構和產品架構。這不是需求文檔中必須包含的部分，但是能夠讓PM從更高的角度去思考業務和產品，同時可以鍛煉抽象和理解本質的的能力。

5. 方案概述。這算是一個提升閱讀體驗的部分。如果需求文檔太長，直接描述具體細節會讓閱讀者理解成本提高。在文章具體展開前，整體的講述方案並列出涉及的職能範圍，可以讓閱讀者有整體概念的同時有方向性的分配注意力。

6. UI元素+功能交互。這裡是筆者積累的一個寫作經驗，即將需求的結構按照類似「MVC框架」來實現。好處一是修改方便：若修改了UI只需要改UI部分，修改了交互也不用去改關聯的UI；二是這種書寫方式跟研發的實現方法較吻合，經驗上看研發一般也都比較喜歡。拿「外賣成單後的履約進度tips」舉例：

• 1、 UI元素：
• 1）icon：…
• 2）文案：…
• 2、 功能交互：
• 1）出現時機：
• 2）消失時機：
• 3）過渡動畫：
• 4）狀態切換邏輯：
• 5）點擊交互邏輯：

7. 接口人說明。跟方案概述中的」涉及範圍「相呼應的部分，可以在每個模塊/頁面前加一個接口人表格，這樣的好處時可以減少組織間的溝通成本，同時也會給你自己省出很多協調的時間。

8. 市場運營計劃。這是一個非必現的部分。但是好的PM一定是懂運營和市場，並會利用相關資源的。產品出生後怎麼養、怎麼包裝推廣很重要，所以一定要在方案計劃時就有所考慮。

最後，是要多溝通。再好的文檔也只是一個工具，不能只有售前沒有售後”服務”。充分的溝通不僅可以確保協作方理解的一致，也能夠增加團隊的凝聚力和積極性，最終獲得事半功倍的效果。