雖然標準的文檔在一定程度上能夠在這些內容表述清楚，通過原型具現出來。但是切記，這些還是需要根據當前公司文化來，按需輸出。一味追求所謂標準的需求文檔，不去思考為什么這樣寫，寫這些的意義是什么，反而落了下層。

這次寫這個其實也算是有感而發，起因是一個產品朋友小李向我吐槽，他在一個創業團隊，公司正在從探索期向成長期度過。原來的測試工作都是小李和研發相互協同的，也就是他們各自客串下測試。

后面公司慢慢向成長期過度，員工從10個演變成了50多號人，其他城市也有分公司，加起來快100號人，研發人員也就從2人變成了近10人。因為業務發展迅速，要全力負責業務線上的事情，就招了個測試。之后便是他們找我吐槽的原因。

小李給我說，測試來的第一周，給了他第一個任務，就是熟悉業務，了解公司當前的運營模式，以及基本功能。隨后便帶著他去見了每一個部門相關對接人，甚至帶到兄弟部門去認識下部門的領導。希望后面有問題可以直接有效的溝通，不然后面公司在擴展下，這種機會就很少了。

隨后也帶到了研發那里，一一介紹，給研發表示，這是新來的測試，以后大家就是工作上的一家人我，畫外音就是讓研發不要刁難測試。

就這樣過了2周，小李覺得半個月時間基本的業務和一些功能應該熟悉了，那么就開始對相關功能就行上手測試吧。

這個時候小李他們的公司也在瘋狂的擴展，并且還是獲得了融資，這使得小李的工作更忙了。但是小李還是和她約好時間，進行相關功能的對接。

對接的時候，小李拿著草圖給測試，進行了相關的講解。想讓他根據草圖和上面的文字先進行簡單的測試。但是測試老說，沒有文檔測試不了。

小李說當時他很困惑，雖然當初很多功能都是idea，直接在會議室假設出來，但是之后去探索驗證之后，很多都完善到草圖上了。他就直接給他說那些草圖就是就可以直接完成測試。

后面測試就直接懟了小李，說你這是草圖，根本就不是需求文檔。小李就直接說，原來公司處于探索業務，變換的很快，都是根據草圖來進行研發的，這個草圖上都有，為什么不能作為測試依據？

那時，兩人爭得不可開交，爭到最后，測試就說她來自己寫一份，說小李根本不是產品。

小李說到這里我也是吃驚了，畢竟都說出這樣的話了，連忙問小李草圖上有哪些東西，小李表示上面很多是手繪的原型和注釋，以及后續方向，并且上面也簡單的寫了公司的業務方向以及后期如何做這些內容。

還因為怕看不懂，專門還整理了，整理之后還給研發他們看，他們都說沒問題，他也不知道問題出在哪里。

后面我也想了想這個問題，真的是沒有需求文檔而引起的嗎？寫個需求文檔他的標準是什么？

需求文檔的作用

工作中，對于產品寫需求文檔還有個很常見的事情就是，我們花了大量的時間，將產品所有細節都推敲的完畢，都仔仔細細的寫在了需求文檔上面，甚至寫完后還反復和研發、業務部門核對了，確保沒有問題之后，交付給了相關干系人。結果他們因為工作安排，時間緊湊要么就沒看，要么就簡單的看了幾眼就放在了一邊。這個無疑是打擊我們。

但是這個好處是十分的明顯：

• 后期研發中出現了什么問題，這個鍋產品肯定不背。為什么？研發自己不看文檔，文檔里面寫的清清楚楚，這個地方要這樣處理，是你們自己不根據文檔來研發。
• 如果出現了人員的離職或者是新增，那他可以通過需求文檔快速的了解項目。減少他的熟悉時間。

換個角度，不寫需求文檔。那就是我們可以從作出決定，快速的推進至研發階段。等于開完會就直接開工，而不需要將所有細節都寫的清清楚楚。

有種說法，人無完人，事無巨細。但是這個對研發團隊要求很高，首先團隊必須具備作出決定的能力，其次大家要有相同的行為準則和職業素養，這個就體現在相關代碼規范、設計規范、原型規范上。

因為如果配合出現了失誤，包括功能和功能之間的不協調，ui配色和尺寸的不統一。那么就直接涼了。

寫需求文檔的作用是什么

需求文檔的作用主要就是為了保證目標一致性，讓研發或是其他配合人員能夠清晰的了解我們在做什么，了解當下我們需要解決的問題、面對的場景是什么，對于成功的定義是什么。

總結起來就是只要寫出的東西，弄夠幫助團隊成員，作出正確的結果的東西，那就是需求文檔，需求文檔沒有標準，只有溝通。

我不希望約束的說，需求文檔這樣寫才對，你那樣寫不對。我認為需求文檔對于個人來說，想這么寫就這么想，想那樣寫就那樣寫。但是對于工作，還是根據公司要求來，畢竟吃飯嘛。

但是，不管是寫需求文檔還是說需求文檔，我還是認為包含下面這些信息，對于團隊，還是個人都還是有很大的好處。

1. 問題和方案；
2. 證明問題和方案；
3. 成功的定義；
4. 場景；
5. 功能描述。

第一：問題和方案

人與人之間有著明顯的差異性和共同性，更別說不同職位了。前端、后端、測試、UI、產品、運營等職位，對于相同的事物和問題都會有著自己的見解和解決方案，并且因為職業壁壘原因，常會雞同鴨講，這是最常見的。

（工作中例子太多了，產品要增加個功能，直接給研發說，結果研發說沒必要。這就是很典型的研發不知道說在什么樣子的背景下，遇見的這個問題。）

我們首先要明確這個新增加的功能要解決了什么問題。其中包括了簡要的背景，這個背景可以說一句話，例如：支付成功人數很低。也可以說相關的用戶調研、市場反饋、數據趨勢等，用于證實這個功能或產品是我們團隊要做的。

第二：證明問題和方案

我們需要證實兩個東西：一個是問題，一個是方案。

要給其他人說明這個問題是真實存在的，而不是我想當然的。因為職業問題，很多研發或者是其他的部門的人都會認為（不絕對哈，但確實有這樣現象），產品是技術部門的“門面”，“吹拉彈唱”樣樣都會。讓人誤以為產品經理是個只會“吹?！钡摹敖浑H花”。

但確實行業內，包括當初我自己出現過隨隨便便寫個我認為的問題，而沒去證實他，之后草草丟給研發。

方案，也是同樣的問題，不去窮舉，不去關注相關競品的解決方案，也就推進到研發階段。我想這也大家都會經歷的一個過程。

同樣我能夠想象到出，當我們經歷多了之后，簡簡單單說一個方案之后，這個方案真的可能是最優方案，畢竟天才和蠢材說出相關的解決方案，前者是經歷過很多失敗的方案之后說的，后者可能是運氣好，正好說中罷了。叫他說出其中緣由，那就漏底了。

第三：成功的定義

我們要清晰的告訴其他人，這個功能對于成功的定義是什么。

這里的成功有兩個意思：成功的研發出來；這個功能推出后取得的效果。

成功的研發出來這個很好理解，就是還原度，百分之一百的還原出功能。只有保證這個功能能夠百分之一百的還原，我們才能通過市場、通過用戶去驗證這個功能或說這個方案是否成功。不然對于團隊和我們來說就是，資源浪費。

我們要將成功進行定義，只有這樣才能得到有效的反饋。不然我們無法確認得到的結果，到底是成沒成功。

第四：場景

場景說產品工作中最重要的東西，自始至終貫穿整個產品的一生。我這里不在過多闡述，文末我會發個我使用的場景還原方式。

第五：功能描述

功能描述包含的了很多東西，如：業務、流程、反饋、架構等，如果是文檔的還會包括原型、狀態、迭代記錄等問題。

我們需要讓其他人了解業務的流程，讓每一個人清晰的知道，我們的業務環節。就像我們說的，如果你們團隊很強大，幾乎人人都是業務方面的小能手，那么你覺得還需要相關圖嗎？

反之，我們為了能夠清晰的表述業務，不一定要去畫精美的圖來表示，只要能夠理解，寫個1234都可以。

我們需要讓其他人了解當前產品的架構，不管是信息還是功能，這樣能夠盡可能的復用，減少開發成本。不然研發不清楚，瓜兮兮的跑去寫代碼，結果要寫完了發現，這尼瑪其他模塊有，可以直接調用或者是改一下就能用。

現在寫出來了還不能用（開發：代碼耦合度高）只能去改原來的，那么確實是很尷尬。

所以可以告知用戶，這個功能在原產品上是存在的或是已經實現過了，因為代碼真的不像我們說的，這個功能很簡單，隨便加一個字段就行。

最后

其實小李那些草圖里面的內容確實是包含所有需求文檔有的東西，只是相對于所謂的需求文檔，沒成體系罷了。也不是說那個測試的問題，我只是覺得太過去追求所謂的需求文檔，反而不知道需求文檔的真實目的。

雖然標準的文檔在一定程度上能夠在這些內容表述清楚，通過原型具現出來。但是切記，這些還是需要根據當前公司文化來，按需輸出。一味追求所謂標準的需求文檔，不去思考為什么這樣寫，寫這些的意義是什么。反而落了下層。

補充一點的就是，大部分研發都不喜歡開會，特別是那種你在這三四十頁的需求文檔，一開就開幾個小時那種。先不說他們記不記得住，這個開會的成本是真的高。

所以我推薦產品在開會前計算下每次開會的成本是多少（計算方法是，每一個參會人的小時工資之和），開會不要隨意的開，每一次開會都是耐心的挑戰、資源的挑戰。

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

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

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