編輯導語：文檔能力可以說是互聯網產品經理的基本要求能力，文檔能力的重要性不言而喻，本篇文章作者詳細地講述了文檔能力的基本內容等，一起來學習一下，希望對你有幫助。

記憶中第一次聽到文檔，應該還是在大學時期跟師兄的交流中。

大學4年計科，跟文檔相關的最多也就是代碼注釋，所以本能地把文檔當做不必要的繁文縟節。

直到工作后，成了背鍋俠，才慢慢意識到文檔的重要性。

一、為什么要寫文檔

記得多年前的一個大型緊急項目，第一次體驗了什么叫做先評審后需求。

在公司高層的壓力下，產品團隊被迫在只有框架流程圖和幾頁原型圖的情況下，強行完成了需求評審。

技術團隊完成評估和分工后，項目已經進入實質性的開發階段。按理說這個時候應該更加注重項目的跟進和協調溝通，但是leader仍然還是堅持要求我們跟隨開發節奏完成PRD。

其實當時很難理解，甚至于消極抵觸。

但到了多年之后，才逐漸明白了這么做的意義在哪。

除了產品崗位，各個工種或多或少都會涉及到各種專業的文檔。

怎么寫好文檔，值得研究。知道為何而寫，更值得深思。

1. 輔助思維

一個人的思維很難做到面面俱到。

我們在打造一個產品時，往往是由點到線，由線及面。

當若干條邏輯交織在一起，就不太容易找到邏輯的影響與關系，更不容易發現漏洞與疏忽。

做好文檔工作，既能夠時刻保持方向的正確性，也能夠細致地對細節進行思考與判斷。

一個人的思維更難做到一成不變。隨著時間的推移、信息的增加，對待同一款產品，甚至同一個需求，我們也很難保證認知和想法的前后統一。

做好文檔工作，能夠幫助我們在思維上保持一致性。

2. 降低溝通

當我們做小項目、小需求的時候，一人一嘴尚能應付。

但當我們面對規?；男枨蠛痛罅咳肆r，光靠溝通肯定很難解決問題、完成產品。

文檔的又一重要作用就在于，能夠作為項目的指導意見客觀呈現，而避免無窮無盡的溝通陷阱。

我記得上面提到的項目，做到第二期時有人員調整，很多新人進入團隊。

因為他們對第一期版本以及項目背景不熟悉，所以產品團隊還需要再做一次信息同步工作。這個時候文檔就起到了關鍵作用，一份完善細致的文檔，就可以極大地降低溝通成本。

3. 留據溯源

一位產品前輩曾經告誡過，“做好產品文檔工作，能夠避免90%的矛盾與沖突”。

都說口說無憑，文檔的又一個重要作用，就是能夠明確記錄己方的真實歷史行為。一旦出現問題或者發生誤會，好的文檔就是能夠幫助產品經理。

雖然在個人的認知里面，很多產研矛盾更像是小孩子為了雞毛蒜皮的事斗嘴，而不粘鍋的工作風格也很難有所作為。但如果確實可以避免不必要的麻煩，又何樂而不為呢。

4. 知識傳承

文檔的又一個重要作用，就是能夠進行知識的歸檔與傳承。

一個團隊里面，每一個人都有自己的想法與風格。如果產出只是為了自己看，那文檔就少了很多意義。

現在很多公司都會自建wiki，目的之一就是在于文檔能夠標準化的產出，并且被歸檔被存儲。

二、要寫哪些文檔

正所謂，產品文檔寫不好，不如辭職開淘寶。常規認知中，產品的主要產出文檔就是原型圖與PRD了。

但除了這些，很多環節仍然也是需要文檔產出的。

1. BRD與MRD

一個比較全面的產品經理，實際需要涉及到的文檔還會包括BRD和MRD兩種文檔。

BRD（商業需求說明）一般是在項目開始之前，對項目的商業目標和價值進行分析。

其主要受眾就是負責人、投資人、核心干系人。

其本身就是概括性地闡釋，做什么、怎么做、投入、產出等問題，幫助上頭做決策。

MRD（市場需求說明）一般是在項目啟動前，對整個市場的調研、分析與總結。

其主要說明三個問題，即市場是什么、客戶要什么、別人有什么。最終幫助企業結合自身實際，得出自己做什么的結論。

一般情況下這類文檔“輪不到”產品來做，因為這更偏向于是公司決策層的活兒。

但是這并不意味著產品經理可以忽視這兩種文檔，相反，產品經理的個人價值可以直接體現在這兩種文檔。

具體的市場相關內容，我們將在后續的市場相關文章中詳細介紹。

2. 需求池

需求池是產品團隊進行需求管理的有效手段，主要對需求進行記錄歸檔、分析判斷、進度跟進、反饋等處理。

PRD重點在于需求的具體方案，需求池的重點在于需求的狀態呈現。

產品與橫向團隊溝通的主體都是需求，所以需求池不應該僅僅是產品團隊內部工具，也應該是產品工作的對外展示看板。

具體的需求相關內容，我們將在后續的相關文章中詳細介紹。

4. 通知與確認

另一種非傳統意義上的文檔，就是產品工作中的通知與確認了。

這種文檔往往通過IM、郵件的方式進行，一般比較隨意。

單獨拎出來說，是因為他們實際上很容易挖坑。

通知主要是重要節點的信息同步，確認主要是重要階段的多方“確權”。

需求方不買賬的情況時有發生，拋開具體工作的細節，很多時候都是因為需求確認問題造成的。

需求確認是必要環節，明確需求是什么，產品怎么做，雙方簽字畫押，才能保證對齊，才能杜絕后期扯皮。

很多時候因為各種原因，產品不作需求確認，往往做了一堆事，還讓自己成了背鍋俠。

通知不到位也是造成麻煩的主要原因。

產品推進并不只是產研團隊的事，還會包括到相關的各個部門。

一旦信息不同步，準備不充分，就容易造成很多問題。

通知與確認很難作為傳統文檔進行維護，但是對日常工作卻有著關鍵性的作用，不可忽視。

5. 其他

產品經理還會使用到很多其他文檔，這里就不一一羅列了。

三、怎么寫文檔

同樣都是互聯網企業，每家公司都有著自己的業務模式、企業文化。

同樣是產品經理，每一個人都有著自己的思維方式、工作風格。

現實的矛盾在于，我們經常因為條條框框，抹殺個性與差異。

又經常因為個體差異，影響執行的統一。寫文檔和寫需求一樣，都需要考慮向什么人在什么場景提供什么東西到達什么目的。

1. 標準文檔

原型、PRD是產品最常用到的文檔，而這種標準文檔往往最需要規范化管理。

這種文檔更講究內容的邏輯與結構性，就像講故事一樣，講得亂、講不全，都會對讀者造成困擾。

而且，文檔本身也需要考慮傳承性，就像前面所說的，如果產品文檔僅僅是為了悅己，那就少了意義。

另外，文檔在管理上也需要有標準規范，小到命名與目錄，大到版本與系列，都需要有具體要求。

標準文檔的規范，在各個團隊各個個體間，都會存在差異，有用即可，不作贅述。

2. 非標文檔

電影《中國合伙人》中有一句臺詞，學英語不僅僅是學習如何表達，更重要的是學習英語背后的思維。

產品寫文檔也一樣，很多時候不應該拘泥于文檔的形式，更應該側重于思維的組織與呈現。

之前在做某個新項目時，線下部分需要根據客流情況，以此來制定推廣和物料計劃。

因為行業整體還處于初級階段，無法直接獲得客流信息，所以只能靠自己去搜集。當時的做法是：

第一步，明確方式。直接獲取行不通，但可以間接通過相關領域的商戶情況獲取。

商戶通常聚集在商業體、寫字樓，所以通過商戶聚集指數，也能夠間接反饋客戶的聚集程度。

所以目標就變成了，通過相關商戶分布，間接獲取線下客流分布。

第二步，獲取信息。因為信息結構不標準，所以很難直接在地圖上搜到商戶分布情況。

但是有專門的B2C撮合平臺，已經幫忙整理了很多商戶信息。

于是選擇了幾個比較大型的平臺，通過爬蟲把所有信息都盡可能收集到本地。

第三步，信息清洗。因為各個平臺的數據結構并不統一，且存在很多紕漏。

所以拿到的商戶數據并不能夠直接使用，需要批量對數據進行簡單清理。簡單來說就是合并、統一、去重、去錯。

第四步，信息呈現。最終的商戶信息收到之后，就可以直接導入到地圖工具進行展示了。

通過一些基本的參數調整，就可以得到如下的分布圖。而團隊也根據該圖，制定了詳細的推廣計劃并最終完成線下獲客。

上述主要是從思維到執行，簡單描述了一個文檔執行的實例。

這種文檔，并不是上述所說的任何標準產品文檔模板。而在繁雜的產品工作中，也經常會遇到各種非標的問題。

四、總結

工欲善其事，必先利其器。產品文檔作為產品經理主要的產出，需要大家足夠重視，充分打磨。

本文由 @綿竹縣吳彥祖 原創發布于人人都是產品經理。未經許可，禁止轉載。

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