編輯導讀：一份好的需求文檔往往是項目成功的先決條件，對一個產品經理或項目經理來說就顯得尤為重要。但在實際工作中，很多產品經理都一昧追求所謂標準的需求文檔，不去思考為什么這樣寫，寫這些的意義是什么。本文作者從需求文檔的目的出發，對其底層邏輯進行了深入分析探討，希望能夠給你帶來一定的啟發。

01 產品經理的事兒，怎能算抄

年前寫了《需求文檔：沒有標準、只有溝通》這片關于需求文檔的內容，但是說實話更多的是感受而非思考，這次主要是學習底層邏輯，通過底層邏輯真正的思考需求文檔這東西；

需求文檔是我們工作中接觸最多，寫的最多，花樣最多的文檔，沒有之一。

為什么說沒有之一，首先說說他的展現形態。有ppt版、word版（文檔）、excel版、axuer版、墨刀版、幕布版等豐富的展現形式。其次內容上需求文檔還要分c端、b端、g端，最后還有可能根據交付人不同而進行不同的調整。所以說需求文檔是寫的最多，花樣最多的文檔。

所以就在這樣的前提下，寫需求文檔似乎就成了許多產品經理們老大難的問題。獨自寫需求文檔時發現不了問題，一旦遇到要與其他人協同，需要交付給他們需求文檔，這時心態立馬就到“爆炸邊緣”了。

各種問題都涌現，我的結構對不對？該這樣寫嗎？需求文檔該如何寫？等等問題就出來了。

在這里插一句表揚，表揚咱們產品經理的優點，就是不懂就百度。所以每當大家遇見困難，都能自覺帶著各自的疑問去百度，尋找解決方案。但我們又常因為百度出五花八門的答案，又一臉懵逼，最后只能懵懵的跟著這些“答案”抄“作業”把需求文檔寫完。

最后本以為寫完就ok了，又發現這次寫的需求文檔又和上次的不一樣。emmm….都是我寫的為什么不一樣？我是不是我查的姿勢沒對啊。

面對這樣的情況我們只能是越查越頭疼，于是乎，算了直接找個模版或者是別人的需求文檔套一下，不一樣就不一樣吧。至此，我們走上了模版流產品經理，在這個流派中我們原則是，遇事不決，模版庫學，模版不夠，百度來湊。

我只想說，這樣不對（很有天賦），這樣是學不到東西的（你已經入門了）。哈哈，其實產品經理的職責就有解決問題，如果你能用這些方式解決了問題，這就是一個好方法，這是不容置疑的事。但是我們需要通過表層看他們的底層邏輯才行，這樣我們才能升級。

02 透過需求文檔的表層看他的底層

在大部分咱們搜索需求文檔時，咱們得到的答案一般如下：

1. 傳達產品開發需求（我不管，我就是要，按照我的邏輯可以搞定。）
2. 保證各部門溝通有理有據（這是誰的鍋，別亂丟）
3. 產品質量控制有具體標準（小老弟你看，你當初自己確認沒問題，你現在…..）
4. 便于交接工作（來，老弟我走后，這口鍋你要拿穩了）
5. 等等（產品經理在外，要學會保護自己…）

這些內容其實我們只需要簡單的搜一搜就都知道了。但卻存在一個致命問題，那就是每次借鑒完畢后，過段時間就忘了，又不知道該如何學，又需要重新打開百度或是自己的模版庫去借鑒。長此以往，對于我們來說，我們確實收獲了快速解決問題的能力，但是卻丟失了產品經理最重要的東西，探索，挖掘問題的思維和能力。不說本末倒置，但確實對我們不利。

因此，我們需要學會在現有答案中去挖掘答案深層次的底層邏輯，在了解事物底層邏輯之后，就會發現事物的變化都遵循著底層邏輯，例如：能量守恒，萬有引力。面對底層邏輯，我們理解起來會存在一定的困難，但底層邏輯就好比一個公司的愿景，它將是這個公司前進方向和價值體現，只有我們需要不停的逼迫自己去思考，不停的杠自己，最終提煉出它的底層邏輯，那時咱們將會通向羅馬。

用樹來比喻，我們直視樹時，眼里多數只關注這樹的樹葉，當我們刻意觀察時，能看見樹的樹枝。如果我們聚焦目光再次觀察，咱們會想到它的樹干。到這里時大部分人就停下思考，說出樹干上長樹枝，樹枝上長樹葉，所以樹干是影響樹生在的原因。

但是我們都知道這不是真正準確的事實，樹還有樹根，我們還需要用工具挖開腳下的泥土，發現這棵樹的樹根，在才是真正的底層。

為什么樹根是底層？，而樹干不是？樹干壞死了這個樹也不沒了嗎？這里會忽視一個問題，樹干枯萎了，不代表這個樹沒了，只要樹根健全，那么這這顆樹的樹干就算枯萎了，也會枯樹發芽的情況。如果樹根壞死了，那么這顆樹再怎么的高大，健壯，對于這顆樹來說死亡是一定的事。

所以觀察一棵樹不要光看“樹葉”、“樹枝”、“樹干”，我們還要去挖掘它的“樹根”來看。

03 解決方案是客觀存在的，不要隨意主觀使用

事物的發展是非線性的，都會經歷一個個起伏，但事物發展也都遵循它的底層邏輯。就像一個樹，就算這顆樹長得如何奇怪，但樹一定是向上生長的。如果你要質疑，說有些樹是斜著或是橫著生長的。我只想說，那是因為你看待這顆樹的角度不對，如果你關注的是它離開地面的位置，就會發現他們始終是向上生長的。

在很多寫需求文檔相關內容的文章中，多數文章都會提及讓大家按照文章中的需求文檔標準來寫。讓大家誤以為跟著文章中的規范和標準來就沒有問題，隨即大家也就根據文章中的需求文檔規范和標準來依葫蘆畫瓢了。至于為什么這樣寫？這樣寫的用處是什么？等問題就不去考慮，潛意識認為文章里的標準就是標準，跟著寫就對了。

但是這樣完全是誤會大部分作者的想法，這類作者更多是想體現他們寫需求文檔的思路，希望大家可以相互探討，尋求進步。而不是直接炒一炒就ok 的事情。

比如下面我提供的這個需求文檔規范：

1. 使用說明
2. 修訂記錄
3. 版本記錄
4. 版本說明
5. 全局規范
6. 功能列表
7. 角色列表
8. 權限列表
9. 框架圖
10. 流程圖
11. 原型圖
12. 非功能需求
13. 人員安排
14. 特別說明

大家覺得如何？看著在這份需求文檔規范，可能會有人覺得很細致，很好，想要直接使用，問有沒有模版等。

但是我在這里提醒大家需要注意，有經驗的產品經理是不會太過隨意的使用其他人的需求文檔。而是根據公司、項目、人員等配置來靈活的調整需求模塊。

直接使用會存在很多弊端，如整個項目就三個人，還需要使用說明嗎？這個產品就做個計算功能，以后再也不迭代的，需要修訂、版本記錄嗎？這產品就一個頁面，那需要角色和權限列表嗎？

帶入這樣的場景會發現，似乎需求文檔中很多模塊都不需要。但是有時候就是只有2個人的產品也還需要復雜的需求文檔，那么到底什么時候用什么樣的需求文檔到底依據的是什么？我想說是底層邏輯。

04 底層邏輯需要先找相同之處

大部分產品常說的底層邏輯指的是業務邏輯，數據邏輯等邏輯流程。而我想說的底層邏輯是事物各自遵循的規則。例如：萬有引力、能量守恒等。因為這樣我們看待問題的時候就可以更加的貼切本質，從思路上打開新的天窗。

借用劉潤老師的話：底層邏輯就是揭開表面不同看到背后的相同，找到變化后沒變的東西。在這層沒找到共同之處，再往下挖掘。在這句話中揭露底層邏輯的一個本質之一。不同的表面都背后的相同。

帶入需求文檔中，我們可以看見每一個模塊都是不同的，雖然他們都不相同，但他們遵循的底層邏輯一定是相同的。這時我們需要思考每個模塊來找尋他們的不同之處和相似之處。

1. 使用說明：需要我們準確說明該文檔涉及的范圍，做一定的范圍指導（不是所有的東西我都管ok？)，說明能給誰看，不能給誰看（傻子們不要亂傳出去），并且解釋文檔中一些專業名詞，避免出現認知差異，還需要對文檔中的一些名稱進行定義說明，比如，名詞：我去年買了個表；含義：去年我去買了一塊手表；歧義：我去你xxx；
2. 修訂記錄：告知查閱人每一次編輯負責人是誰，避免找不對人（那個傻子修改了我的原型？憑什么修改為的原型？腦子是不是有?。?，記錄每次修改內容，方便回檔，讓每一次修改都變的有憑有據，更加的謹慎，而不是“我想…. 、我覺得…..”（嘴強王者）
3. 版本記錄：清晰讓所有人了解當前線上版本和線下版本情況，了解每個版本的負責人是誰，針對版本問題可以統一的進行反饋（指定誰是這次的背鍋俠）
4. 版本說明：我們在什么情況下，遇見了什么問題，那我們這次用什么方法 解決了這個問題。幫助其他人快速了解版本情況。
5. 全局規范：告知所有人我們遵循的規則是什么，要如何避免文檔內容參差不齊而溝通困難。
6. 功能列表：記錄我們會涉及哪些平臺，有什么樣的模塊和功能。對于一些功能我們有什么特別的要求和限制。以及最后我們大概的開發周期是多久。
7. 角色列表：告知我們整個系統內涉及的角色有好多個，能不能創建角色？每個角色他們能做什么事情。
8. 權限列表：枚舉出我們系統中可以使用的權限有多少，可以讓使用者快速了解哪些能做哪些不能做。
9. 框架圖：快速掌握產品的整體框架
10. 流程圖：展示各個細節上的業務邏輯以及數據邏輯，明確每個產品模塊是如何運作或協同的。
11. 原型圖：將抽象的功能具現化，變成可視化頁面，讓大家了解我們做的產品是什么樣子的。
12. 非功能需求：清晰表述特別的要求，如性能要求（負載均衡、響應時間）、安全要求（防火墻、非對稱加密）、復用要求（模塊化低耦合高內聚）等。
13. 人員安排：指明每個模塊、每一個時期誰是負責人，當出現問題之后，可以及時聯系干系人，提高效率。
14. 特別說明：將產品中涉及風險和需要注意的地方進行表述，避免大家觸及風險，造成不必要的損失。

呼，寫了這么多，那么咱們思考下，他們的相同的地方是什么？似乎每個模塊的使用場景中都存在兩個或以上的角色，都是交代、說明一些事實 。這些事實，要么讓你避免什么問題，要么是讓你遵循規則或是指導你出現問題后應該及時找誰處理等。

從這些角度開來需求文檔的底層邏輯看起來是溝通。用需求文檔代替我們需要面對面溝通問題。使用需求文檔減少我們溝通時間，提升了我們的效率（不用面對面去溝通，省下來的時間去做其他的工作）。

我們換個角度，現在我們大多數使用敏捷開發的方式進行產品開發，在敏捷開發中我們很少看到十分詳細的需求文檔，更多都是一個簡單的原型就進行開發，甚至有時沒有實體文檔，就一句話、一個白板畫就進行開發，并且還能夠在短時間內完成上線。

面對這樣的情況，不管是一句話還是就一個原型他們都是需求文檔，但說需求文檔的底層是溝通，就顯得十分牽強，因為日常交流也是溝通啊，所以說一句話就是需求文檔？這樣的后果就是強行上升到哲學的問題，我們下面在繼續思考。

我們再從其他方向入手，從它們的形態開始思考，為什么會存在那么多ppt、word、excel等形態的需求文檔。他們的相同的地方是什么。和其他使用ppt、word、excel等工具的內容又有什么相同的地方？

根據這樣的思路我發現其實他們都只是一種承載的工具而已，我們甚至可以用紙筆來寫，用腦子來記。所以拋開這些工具，我們的目的只是在于記錄。記錄需求文檔的使用說明，記錄產品原型的樣子，記錄規范，記錄負責人等等，所以需求文檔的底層邏輯之一就是記錄。

但是這里體現出一個問題。在敏捷開發中似乎也不存在記錄啊，老板開頭一句話我們就直接干、我們開發的時候也沒有文檔來記錄，大家都是直接面對面溝通開發。在這些真實的場景下，需求文檔的底層邏輯又不成立了。

我只想說對于這些只是形式上的記錄，不能因為沒有實體文檔記錄而說沒有需求文檔。但確實這樣看來光一個記錄并不能代表需求文檔的底層邏輯，那么還需要另外的東西。

05 相同屬性+不同差=底層邏輯（本質定義）

柏拉圖有個小故事，柏拉圖曾說人是二足無毛的動物。然后第歐根尼就帶了一只拔光羽毛的雞到講學的地方，說：「這就是柏拉圖的『人』」。同時亞里士多德說：「人是理性的動物」。在兩位大佬的話我們可以發現，我們除了相同的屬性，還需要一個他們不同的地方。

需求文檔和其他用相似工具記錄的內容來講，他們的相似之處在于記錄，用不用等形式記錄內容，那他們不同之處是什么？是工作，需求文檔是記錄工作的內容？我看不是，工作中也有很多需要記錄的問題，所以不是所有的文檔叫需求文檔。

記錄需求，需求文檔是記錄需求的內容？我看也不覺得準確，因為除了需求，需求文檔中還記錄很多東西，如說明、限制、人員、修改記錄等，最后再三思考，我暫時認為，需求文檔的底層邏輯是（我下定義了）記錄有歧義的內容（交流正確的內容）。

為什么？記錄這個我們不再說了，這個是內容的底層邏輯，所有內容都需要我們進行記錄（交流），不管是線上，線下還是腦子里面，都是需要我們記錄（交流）的，這就是他們共同的屬性。

那為什么是有歧義的內容了，是因為我將他們帶入了日常開發的場景中，很多時候不是所有的內容都需要進行文檔記錄，我們可以采取口頭溝通的形式就能達到效果，所以并不是全都需要文檔記錄。那么是在什么情況下才需要記錄了？那就是預防事故（預防背鍋）。

不管是文檔說明，功能列表，原型樣式還是業務邏輯，我們都會去記錄、去做可視化的頁面還有詳細的標注，那是因為我們怕出現意外。這里的意外是指因為每個人認知不同，看待問題的方向不同，而造成大家按照自己的想法來進行工作。

例如短信驗證碼是多少問的問題，運營覺得4位簡單，研發覺得8位安全，而產品經理覺得6位即可，即相對安全也方便快速記憶。像這樣有歧義（需要確認）的地方我們將進行記錄（交流），以便后續做的時候都按照這個來。

所以需求文檔的底層邏輯上：記錄有歧義的內容（交流正確的內容）

06 通過底層邏輯思考需求文檔的表面

在知道需求文檔的底層邏輯是記錄有歧義的內容后，我們就可以很好的思考那些模塊是我們需要的，那些是不需要的。

例如：大家都知道項目背景和需求背景，是不是我就可以暫時不寫文檔說明？咱們的團隊很小只有幾個人，是不是代表著我們需求文檔只需要一個原型就可以？研發十分清楚系統覺得和邊界，我們是不是就可以不要角色相關的信息，把時間拿出來用戶討論其他有歧義的功能？面對公司太坑，是不是我可以將文檔私下記錄，工作中全靠腦袋給研發輸出，最后離職時沒有文檔交付而報復（雖然不對，但是也有這種情況）？

所以理解需求文檔的底層邏輯后，面對豐富的需求文檔模版我們是不是有了更好的選擇？

作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）

本文由 @Wcof 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議。