起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識互聯網產品經理能力矩陣：基本能力之文檔能力
編輯導語：文檔能力可以說是互聯網產品經理的基本要求能力，文檔能力的重要性不言而喻，本篇文章作者詳細地講述了文檔能力的基本內容等，一起來學習一下，希望對你有幫助。
記憶中第一次聽到文檔，應該還是在大學時期跟師兄的交流中。
大學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 協議。
是這樣了，從各個方面來說都是好記性不如爛筆頭，雖然不是真的寫，但是思維邏輯羅列下來就會比頭腦里清晰很多（ps只有我是被作者的名字吸引進來的嗎
不只是你，我也被吸引了
來自產品小白的肯定，反手一個關注
客氣，客氣
用好文檔確實能降低溝通成本，因為很多時候團隊需要信息同步。
沒錯了，說千遍不如寫一遍