我聽過很多支持“不寫產品需求文檔”的理由：“某產品用戶那么多，他們整個團隊沒有一份完整的（產品）需求文檔”；“我們追求效率，不用文檔”； “文檔寫了也沒人看”……

首先要搞清楚的問題是：“什么是產品需求文檔？”

就公司內部而言，可能存在各種各樣的文檔：產品需求文檔（Product Requirements Document, PRD）、市場需求文檔（Market Requirements Document, MRD）、產品策略文檔（Product Strategy Document）、產品路線圖（Product Roadmap）、產品更新文檔（Product Release Note）、客服產品文檔……有的公司可能每種都有（甚至一種文檔有好幾個互相沖突的版本^^），有的公司可能一種文檔都沒有。

上面這些文檔，每種文檔都跟“產品”有一定關系，但是每個文檔有各自的側重點：

“產品需求文檔”描述產品應該是什么樣子。產品文檔的目的是準確無誤地描述產品的功能、特性、行為。在某些公司，產品需求文檔還包括產品的界面要求和用戶體驗要求，有的公司則將這些內容分布在不同的文檔中。

“市場需求文檔”描述產品的機會（opportuinity）和市場需求。產品需求文檔描述能夠滿足市場需求的產品。

“產品策略文檔”描述一段時間后，產品該走向什么方向。“產品路線圖”描述實現“產品策略”的路徑、步驟。“產品需求文檔”描述每一步驟過程中某一具體版本的產品應當是什么樣子。“產品更新文檔”是產品更新時，用來說明本次更新內容的文檔。“客服產品文檔”則側重客服如何解答用戶提出的產品相關的問題。

搞清楚了這些文檔的關系后，“要不要寫產品需求文檔”這個問題的答案已經很清楚了。不難看出：“產品需求文檔”是“市場需求文檔”的延伸，是產品策略文檔和產品路線圖的具體落實，同時，產品需求文檔是產品更新文檔、客服產品文檔和測試文檔的來源、標準。

從產品設計團隊、研發團隊、測試團隊的工作協作方式而言，撰寫“產品需求文檔”也是有必要的。

如前所述，產品文檔的目的是準確無誤地描述產品的功能、特性、行為。在某些公司，產品需求文檔還包括產品的界面要求和用戶體驗要求。產品經理撰寫產品需求文檔的過程相當于將整個產品的每一個功能、每一種行為進行梳理的過程。通常而言，設計產品的過程中，人們是按照完整、按完美次序完成一系列操作的流程進行思考的。而撰寫文檔的過程中，則需要考慮到如果用戶進行某個“意料之外的操作怎么辦”（相信我，用戶肯定會這樣的）。“撰寫需求文檔”這個過程本身就能發現產品設計中的問題。

對產品開發團隊而言，產品需求文檔是開發團隊的“藍圖”，產品開發團隊嚴格依照這份“藍圖”完成產品的每一個功能、行為。口頭傳達這些需求當然可以，但是你可以想象這樣一個場景：一個工程師在施工現場，對每一個施工者口頭傳授“你在這兒安一個水龍頭”、“沿著這堵墻走線”、“這堵墻水泥標號再高一點”……整棟樓也能建成，可能建完第二層，就沒人記得第一層是怎么回事兒了。以“追求效率”作為不寫“產品需求文檔”的理由基本上是出于想象，接下來面臨的是無數類似于“當時是怎么設計的來著”（“這間房的電線是怎么走線的？”）這種災難。

對測試團隊而言，“產品需求文檔”是測試用例的來源、產品能否通過測試的標準。測試團隊拿到產品后測什么、怎么才算通過，這兩個問題的答案都在產品需求文檔中：按照需求文檔的描述的功能和行為測，符合需求文檔要求算通過。測試工作我參與的不多，理解不深，但大致是這樣的。

就團隊協作而言，在團隊規模小時，“產品需求文檔”的重要性可能還不那么明顯——畢竟，溝通成本還不高甚至溝通還不算成本。但是當團隊到了一定規模，且具有人員流動性之后（這幾乎是必然的），“產品需求文檔”的作用就明顯了。設想一個場景，產品設計人員不在時（睡覺、休假、離職，或者死了），又沒有產品需求文檔，除了讓研發人員一行行查代碼，還有什么方式能夠獲知某個開關的默認值、某個數值的初始值、某個排序操作的具體規則？

有產品需求文檔，不一定能開發出好的產品，但是沒有產品需求文檔……只能說，做出好產品也不是不可能吧。

至于“文檔寫了也沒人看”的問題，我還在考慮，等我考慮好了再說吧。不排除長時間考慮不好的可能性。