需求文檔是産品經理日常工作輸出最重要的文檔，需求文檔是在寫什麼？應當包含什麼内容？

弄清這個問題，首先要明确需求文檔的讀者是誰，讀者要從需求文檔中獲取到哪些内容，讀者的不同影響到需求文檔的組織形式，而組織形式又依賴于産品經理自身的習慣，不可一概而論。

以下是我理解的需求文檔該是什麼樣子的，抛磚引玉，供大家探讨。

需求文檔最重要的讀者首先是産品經理自己，無論是需求實現前用需求文檔講述需求的實現思路，實現時按需求文檔進行設計、研發、測試，還是需求上線後回顧需求文檔進行複盤總結，都是依照産品經理寫的需求文檔。其次的讀者才是負責需求實現的設計師、研發人員、測試人員以及其他産品經理。

按我的習慣，需求文檔會包含以下五個部分的内容。

一、需求變更日志和版本疊代記錄

第一部分是需求變更日志和版本疊代記錄。需求從提出到最終上線，中間必然經曆一些需求變更或方案調整，因而需要有變更日志來記錄這些變更。

需求變更日志并不隻是寫需求新增或減少了哪些功能，而是更仔細些。

例如：需求中的A功能點，原來打算用方案一實現，但考慮到資源、現實場景的限制，改為用方案二實現，這個也要寫，雖然從結果上看仍然是實現了需求中的A功能點，但從過程上看，方案一到方案二的轉變，是産品經理思考的升級，也是對資源限制更深的考慮。

此外還應記錄清楚需求是因什麼原因變更，變更前後是什麼樣子，可能會産生哪些影響，以便後面查找細節。

而版本疊代記錄，除了包括對需求中功能的版本疊代，還應包括産品經理對這個需求思考路徑的疊代。

需求中功能的版本疊代，這個大家比較熟悉，不贅述，主要想說明下産品經理對需求思考路徑的疊代是什麼？為什麼要這麼做？

之前提過，産品經理很大的工作是在做決策，因此決策質量很重要，而決策質量需要通過不斷地優化決策思考路徑來提高，産品經理應該記錄自己對需求的思考過程，對過程進行不斷總結和優化。

另外，将這些思考的過程展示出來及與其他同事讨論，可以跳出自己固有的思維模式，兼容并包。

所以我一直認為産品經理在處理一個需求時，其思考路徑、決策依據應該公開透明，能夠讓所有參與需求的人都能夠可查看、可探讨（來自瑞·達裡歐，有興趣的朋友可以去看看他的《原則》）。

那麼，我輸出需求變更日志和版本疊代記錄的過程是怎樣的呢？

按我的習慣，在輸出一個需求文檔的時候，會先按當下我能考慮的情況先寫一個Beta版，這時候我将它命名為V0.7版本，然後隔一天我再重新思考，看自己昨天寫的需求文檔，這時能發現很多不足的地方，那就從頭開始改一遍，标明需求有哪些變更，這時的版本是V0.8版本。

下一步找其他産品經理向他講述一遍這個需求文檔或在組内組織一次需求評審，綜合意見，再修改一遍，标明需求有哪些變更，這時的版本是V0.9版本，最後再找開發測試設計的同學進行需求評審，從開發測試設計的角度對需求的實現做一遍修改，标明有哪些變更，形成最終的版本V1.0。

這樣下來，一份需求文檔能夠包含産品經理對一個需求實現方案完整的思考過程，其中不僅有自己思考的升級，還有從研發、測試、設計等各個角度對實現方案的調整補充，是針對這個需求，在當前的資源限制、背景約束下最好的實現方案。

有了需求變更日志和需求版本疊代記錄，不僅可以做到需求的實現邏輯實現思路可溯源，完整記錄整個需求從被提出到上線多個版本，期間的産品思路、實現邏輯有了哪些變化，産品經理可時常回顧拿來參考，産品團隊可針對大的需求做針對性複盤，也可提供給後來接手工作的産品經理了解需求的完整疊代過程。

二、背景&方案&價值

背景、方案和價值，是需求文檔的核心，是任何需求在進入到實現階段前一定要想清楚、一定要反複探讨的部分。

需求是背景下的需求。這裡的背景，需要寫明白的内容可包括但不限于當前産品所處行業的現狀，産品/功能模塊所處的狀态、目标，開發團隊的資源限制、技術限制等。

最開始做産品經理時，體驗其他産品的一些功能，不免吐槽，這裡怎能這樣做？應該那樣做啊，要是我的話一定能比他做得更好，諸如此類。

到後來做産品的經驗見長，才明白任何一個需求都受限于當時的背景狀況、資源限制，抛開這些背景談實現都是扯淡，産品經理要做的是在當前背景下，找到最佳的實現方案。因此，梳理需求背景是産品經理對當前資源現狀的考量，是實現需求的第一步。

方案是背景下需求的實現方案。既然需求會受到資源現狀的限制，那麼方案也必然有所不同，甚至可能會有折中妥協，會有不完整的方案。有時需求本身就是試驗性質的，是為了快速測試效果，那麼在方案上選擇一些實現簡單、開發難度較小的方案也就不足為奇了。

在寫方案時，可以按照「用戶-場景-問題-方案」這個框架簡要寫明實現方案，也就是什麼樣的用戶在什麼樣的場景下遇到了什麼問題，提供的解決方案是什麼——這裡要求方案要經過提煉，能夠通過一句話說清楚。

價值是指實現這個需求能夠帶來什麼樣的價值，包括用戶價值和業務價值，用戶價值是指實現這個需求能夠給用戶帶來什麼樣的價值，例如提升用戶的使用體驗等；業務價值是指實現這個需求能給産品的業務帶來什麼樣的價值，例如提升用戶留存或者提升業務收入等。

需求不一定要同時提供用戶價值和業務價值，也不一定兩個價值都需要為正（例如帶來很大的業務價值而犧牲很小的用戶價值也是可以的），具體需要依據産品當前的狀态來考慮，但不能帶來價值的需求一定是有問題的。

此外，在思考需求能夠産生什麼價值時，同時要思考的是以什麼數據指标來評估這個價值，也就是需求上線後效果的好與壞要有量化的指标。不一定所有的需求都能夠找到量化的效果指标，但一定要盡量找到這個指标。隻有需求的效果能夠被衡量，産品才能夠往更優的方向疊代。

三、業務邏輯&流程說明&功能需求詳述

第三部分主要是需求實現的部分，我把它劃分為業務邏輯、流程說明和功能需求詳述。

業務邏輯部分描述的是需求中涉及到的數據流向和用戶流向，特别是需求涉及到多個系統時，數據和用戶在系統之間如何交互的（這部分的内容偏複雜，後面再單獨寫下我的理解）。

目前針對業務邏輯部分，我主要的輸出是多通道的泳道圖來描述系統間的交互。這裡應該特别注意的是在說明數據流向時要兼顧考慮正常流程和異常流程，以及在說明用戶流向時要考慮清楚需求邊界。

此外，需求的複雜程度不同，可能還會包含頁面流程圖、頁面結構圖等。

功能需求詳述就是常說的原型。

我目前的習慣，在需求文檔的早期版本不喜歡輸出高保真的原型，而是傾向于用低保真原型加文字描述的方式來說明需求中的功能實現。

功能需求詳述以需求中的頁面為單位，分為原型圖、需求說明和交互說明三個部分。

原型圖對需求涉及的每個元素進行标注；需求說明針對原型圖中的标注進行文字說明，包括字段邏輯、按鈕邏輯、頁面邏輯等；交互說明則是針對一些非邏輯的交互進行說明，例如某些字段、需要突出顯示，頁面變化時需要怎樣的特殊效果等等。

四、相關文檔的集合

日常工作中，時常出現想要找需求的某個相關文檔時，四處搜索，浪費很多時間的情況，為此我形成了一個習慣，就是把需求文檔作為一個所有相關文檔的集合。如埋點文檔、設計稿、接口文檔、測試用例文檔、開發相關的鍊接、上線後的數據等，都以鍊接的形式整理在需求文檔中，這樣每次需要找需求的相關文檔，都可以從需求文檔中快速找到。

五、需求上線後的數據

凡是需求，必然要有驗證效果的數據，而從每一個失敗與成功的需求中不斷總結和反思，是産品經理成長的重要途徑。如上文所說，産品經理應該保持開放透明，那麼就意味着産品經理對于需求輸出的實現方案，最終結果無論是好是壞，都應該将效果數據按實際公開，這既能夠促使産品經理自己不斷改進産品思路，也能夠讓參與需求的相關同事了解自己的工作成果，增加他們的參與感與成就感。

以上便是我理解的需求文檔應該包含的一些内容，可能過于繁雜，具體還是要根據每個人自己的工作習慣做取舍，僅供參考。

希望能幫到你。

本文由 @Isaac 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,