產品經理的核心技能之一就是撰寫需求文檔，問題來了，產品經理怎么寫，才能寫出一份優(yōu)秀的需求文檔呢？本文作者便分享了自己日常寫需求文檔的結構，不妨一起來看看。

為什么寫這個主題

在我初為產品的時候，也參考過不少需求文檔。有的需要將原型轉成圖片貼在需求文檔里，我認為這比較低效，不適合我；有的需要在axure里寫所有的邏輯，包括業(yè)務流程圖、數(shù)據(jù)流程圖等，axure里對于流程圖和文字排版并不友好，我參考過一段時間，后來還是覺得太低效，不能專注于文檔的輸出。最終選擇的方式是在依賴語雀去寫文檔，非常高效。

有的公司里會用釘釘，用釘釘文檔其實也可以，但是我感覺體驗沒那么好，不管是操作還是界面都沒有那么舒服。

需求文檔作為產品的其中一項核心技能，那么如何能夠結構化地寫出高水平的需求文檔呢？

寫了將近5年，我在不斷地完善我的需求文檔模板，讓我不再為怎么寫需求文檔而煩惱，提升了我的工作效率。

下面分享我日常工作寫需求文檔的結構，希望能對你有幫助。

核心邏輯是什么

我認為一份需求文檔有2個重點，一是核心邏輯，一是原型。

核心邏輯是你要在短暫的需求評審會議上深刻地講出來的，并且會上的小伙伴聽了之后能夠清晰知道整個需求的邏輯。

而且我認為需求評審會議一定是先講核心的邏輯再講原型。邏輯一定是先行的。直接講原型，聽的小伙伴估計10個9個都會懵逼。我也聽過不少同事是直接講原型的，效果很差，作為一位產品我也聽不懂會議。另外，人的精神總是會分散的，我們需要在會議的最前面把最重要的邏輯講清楚了，原型其實也是圍繞核心邏輯展開，能夠把握核心，看原型也更好理解了。

原型也是不可或缺的重要一部分。

它是核心邏輯的具象，非常多細節(jié)，我們要在原型里盡可能描述清晰需求，不遺漏需求，考慮縝密。這不僅是我們邏輯能力的體現(xiàn)，更能夠減少開發(fā)過程中的卡點——因考慮不周全而開發(fā)不順暢或者延期等。總的來說，這個意義重大。

如果僅憑大腦在每次寫文檔時，費盡心思去枚舉需要考慮的點，這會很費勁，工作效率低，在文末也總結了寫原型文檔的技巧希望能夠對你有所幫助。

我們先來看看整個需求文檔的結構。

從下面開始進入主題。

一、需求背景

在這個位置寫我們的需求背景，也就是這個需求產生的業(yè)務背景。注意把關鍵的業(yè)務矛盾描述出來。如果需求有很多點，建議把較大的需求點的矛盾點都描述出來。這樣的話，技術看起來會很清晰需求為何而做。對技術講多點業(yè)務，這對做需求是作用很大的，技術越是理解，對需求的理解偏差越小。

二、需求分析

1. 現(xiàn)業(yè)務流程

描述現(xiàn)在的的業(yè)務流程，便于自己梳理需求以及技術后面看也會比較好理解需求。

2. 競品調研

如果是做一個新產品，往往需要做競品調研。將你的調研結果放上來，整個方案的說服力增加不少。

3. 總結

通過對現(xiàn)業(yè)務流程的分析以及競品調研，你可以得到一個直指本質的結論——業(yè)務到底要什么。這個本質你其實也可以找業(yè)務確認一下，這樣做之后基本你不會遇到做錯需求的情況。

注意：

1. 現(xiàn)業(yè)務流程和競品調研都不是必須的，但至少得有一個比較好。
2. 我還看到過不少人需求分析會寫需要考慮什么內容，例如：需要考慮中臺是否支持這個操作、需要考慮某業(yè)務方是否能接受操作多了一個步驟。其實這些都是方案里面需要考慮的點，我認為并不能算在需求分析里面。需求分析更多是求得需求本質。

三、方案概要

在這里寫上你的方案概要，這個概要是基于你的可行方案寫出來的。在這個時候其實你已經跟業(yè)務溝通過了，得到了溝通共識得到的結論。別人看到這個位置的時候已經能夠很清晰地看到你想要怎么做，接下來在聽你講的時候腦子里就會帶著方案概要聽下去。而你也可以很自然地展開下面的方案內容。

四、方案內容

1. 核心邏輯

總的來說，在核心邏輯這個模塊，更多是圖文結合地將你的核心邏輯表達出來。我常用的圖有以下類型的圖。

1）業(yè)務流程圖

有新的業(yè)務流程圖時可以放在此模塊。這個部分不是必須的，按需寫。

2）數(shù)據(jù)流程圖

相關數(shù)據(jù)流程圖可以放在這里。當你做多了需求，你不從數(shù)據(jù)角度去分析一下流程，其實你會覺得有點太表面了，可能會有疏漏。當你把數(shù)據(jù)流程也梳理清晰了，那么會很踏實。這個部分不是必須的，按需寫。

3）功能流程圖

主要針對比較細致復雜的功能，通過梳理功能流程圖，減少疏漏，也有助于技術理解流程。與業(yè)務流程圖的區(qū)別是，業(yè)務流程圖主要針對業(yè)務方的工作的流轉，功能流程圖主要是針對功能的邏輯，例如：登錄的功能流程圖。

4）架構圖

在做比較大的系統(tǒng)時需要將產品架構寫清楚，有助于你和技術理解系統(tǒng)。這個部分不是必須的，按需寫?？赡苓€有其他的圖，大家按需添加。

2. 原型

在此附上原型鏈接。

3. 非功能需求

• 查詢性能要求；
• 并發(fā)要求；
• 風控要求；
• 接口開放要求；
• 穩(wěn)定要求；
• 時效要求；
• 等等。

4. 規(guī)劃

如果有清晰的規(guī)劃可以寫在這里?？赡苡兄诩夹g在設計數(shù)據(jù)庫表的時候提前考慮未來的規(guī)劃。

5. 需求變更記錄

將需求的變更記錄寫在這里。

6. 其他

其他的什么都可以寫在這里。例如，評審會議的目標可以寫在這里，需求的最后期限可以寫在這里，等等。

到這里需求文檔就已經結束了。還有不少同學不知道怎么寫原型的文檔，下面開始講解此部分。

五、原型撰寫方法

1. 核心邏輯

我們通過分析與總結，其實頁面主要就是這幾部分組成：查詢條件、字段、操作、權限。這是我們整個團隊的邏輯思考成果，有很大的價值。在看toB老人家（王戴明老師）的書籍《saas產品經理從菜鳥到專家》時，我也看到他講述原型是怎么寫的，基本和我上一個團隊想的是一樣的。

所以大家真的要相信自己，大家想出來的東西其實是差不多的，那么差別在哪里？我認為是執(zhí)行，也有執(zhí)行速度，迭代速度。其實大家腦袋是差不多的，就是你想了之后有沒有執(zhí)行，有沒有快速迭代下去。

2. 原型文檔邏輯

3. 原型文檔案例