困在家裡，每天起床 - 開早會 - 開項目會議 - 刷牙洗臉 - 看文檔郵件 - 開項目會議 - 循環往復直至睡覺，不胖都難...
每天干的最多的就是溝通、看文檔，最經常遇到的也是在溝通過程中對文檔的各種“Diss”。今天抽點時間，總結下寫文檔的思路，希望對大家有點啟發。
在寫文檔之前
大家很容易在網上看見各種眼花繚亂，格式規整，精美無比的文檔，顯得很專業。不可否認，這種文檔但凡誰第一眼看見，都會覺得很專業。但是，文檔的矛盾往往是在細節review和溝通中才會爆發的。
所以，文檔主要是搞定看的人。
給研發看的文檔
從日常溝通頻率來看，產品和研發之間關於文檔的矛盾最多，先來盤它。
一. 先講故事
我是從研發轉做產品的，搞研發的，多半邏輯思維比較強，喜歡剖析事物的本質（這個事情本質上...）、引經據典（我見過的產品沒這麼做的...）、列舉可能性（當xx情況下，萬一...）等等等。
產品經理如果直接搭話，後果就是在邏輯的靈魂拷問中敗下陣來。
那麼面對這種情況，我總結的原因有幾種：
直接寫產品功能。這種就是變相的告訴研發，別BB，按我說的做。
文檔描述的文字不嚴謹，前後概念定義不相同，需求範圍邊界不清晰，約束條件不講明。任何一個細節的點被抓住，整個文檔的嚴肅性就沒了，開始迎接各種挑戰。
過多用技術化的語言來寫文檔，以為研發能看懂。這種僅適用於技術功底較深的產品經理，否則進入對方的絕對領域就是找虐。
寫給研發看的文檔，最重要是說明為什麼要做和做什麼。多講講故事。
在任何大小溝通之前，先準備好一兩個典型故事，最好出自典型客戶需求或者經典案例，開門見山的和研發聊一下我們的實際需求和業內情況。一個好的產品經理，自己就是個故事大王，應該儲備大量的案例、行業見解和解決方案。這些故事不會引起別人反感的原因在於：故事都是第三方的，不是自己的；而溝通中最怕上來就講自己的觀點，“我”和“你”是對立面，“他”不是。
二. 再說策略
明確了需求和要解決的問題，不要一上來就直接給出解決方案。原因很簡單：
你給的方案技術不可行。研發直接給你打上一個“外行指導內行”的標籤。
你給的方案在目前市場或者產品中沒有競爭力。這個最可怕，直接關係到大家對你能力的判斷。
你給的方案太初級，是個人就能想到。敷衍了事，無解。
講故事獲得共情後，要進一步獲取信任，把業界情況、自身目的和限制、初步決策的原則說清楚。
很多時候，排到計劃裡的解決方案往往是修改了若干次之後的結果，這和網上設計師的作品被甲方來回修改並沒有太大區別。首先，我們要認識到，解決方案的修改是無法避免的，但是為了讓方案儘可能落地，產品經理需要比任何人都思考的更多：
業界經驗如何解決這個問題，有哪些不同的做法。
我們目前的條件如何，包括但不限於：時間、人力資源、已規劃已執行的產品計劃是什麼樣子的。
和研發、市場等同學溝通完之後初步的可行性分析。
（非常重要）如果不做會有什麼不能接受的後果。這一點是為了進一步搞清楚這個需求的核心問題是什麼。
最後的最後，給出的不是方案，而是擬定方案的選擇策略。沒有這個策略為大前提，後面細節的討論會經常漫無邊際的展開，3個小時的會不是夢。
三. 做好細節
前面兩點如果能很好的落實下去，影響文檔質量的就是各種細節。這個問題沒有捷徑，就是花時間仔細做，反覆推敲。我把經常會遇見的問題列舉出來，引以為戒：
一個人寫的文檔，基本沒有統一的格式，每次都是隨性發揮。
產品概念隨便定義：前後名稱不統一，用非業界常規的命名，用冗長晦澀的文字去解釋。
在正規文檔裡畫一些自創的圖例。
流程圖或交互圖不完整，用另外的文字去做“補充說明”。
細節規則沒有，以為大家都知道。
文檔不檢查不推敲，留了一堆邏輯漏洞和錯別字。
文檔存儲的位置飄忽不定，網盤、wiki、本地文件、三方應用到處都有它的身影。
如果上述問題你都沒中招，那麼你寫的文檔應該堪稱典範；但如果想都做好，你唯一無法缺失的就是時間。
文檔需要時間，不要壓縮時間來提前交付文檔，這樣後續扯皮的時間會更多。
四. 定稿前多溝通
在產品經理編寫的各種文檔裡，基本上都需要其他角色的意見作為輸入，如果一個文檔發佈前都是出自自己的經驗和理解，那會是什麼天都不知道。
輸出一份任何一份正式的文檔，都可以劃分為兩個階段：草稿階段和打磨階段。
草稿階段的文檔，形式不限媒介不限，以最快速度最有效的和相關人溝通討論。沒必要約正式的會議，避免大家過於扣細節。
打磨階段的文檔，需要你把之前草稿階段的成果進一步揉碎了消化了滿滿撰寫，反反覆覆推敲。
文檔類型的選擇和精力分配
從我個人經驗以及產品經理圈子的實際情況來看，目前尚未發現能從頭到尾輸出完美文檔的人，這是資源限制和能力限制的必然結果。
如何選擇合適的文檔，分配多少精力，主要看你的團隊情況：
微型集中型團隊
如果團隊很小，一起辦公，大家技能樹比較均衡，那麼文檔最好的形式就是產品本身。每天輸出一個版本的產品，最直接能反應出你的產品文檔應有的結果。
中小型集中型團隊
如果團隊規模較大，有明確的職責分工，那麼就要根據實際情況來選擇：
如果團隊缺少行業經驗，那麼把用戶需求、競品分析、成熟的領域模型編寫的細緻點。
如果缺少明確的需求來源或者復刻某個競品，那麼把功能需求和交互文檔寫的細緻點。
如果團隊磨合比較好，產品有固定的輸出套路，那麼把功能需求和數據模型定義好就可以開工了。
...
這也是為什麼並沒有什麼統一的的文檔規範的原因。企業為了生存下去，活法不一樣，糾結形式本身首先就慢人一步了。當然，這和注重細節並不衝突。
產品經理的日常功課型文檔
除了在產品研發過程中常用的用戶需求文檔、功能需求文檔、交互文檔、產品Roadmap及計劃、產品驗收文檔等，還有一些文檔需要輸出，也可以視作對產品能力的鍛鍊。
產品運營（運行）情況：驗證產品是否達到預期目標，PMF有沒有問題，接下來的改進目標是什麼。
產品市場及客戶反饋：產品市場是否有變化，客戶的反饋渠道建立及問題分析，產品和競品的跟蹤比較。
產品定義的重新思考：未來五年、十年，目前的產品會有什麼樣的趨勢變化，有沒有實驗性質的功能需要嘗試。
產品的包裝：當把產品輸出給客戶、經銷商、老闆、親人朋友時，它是什麼樣子。
說真的，寫出無懈可擊的文檔產品經理缺的只是時間，你說呢？
祝疫情期間，大家每天都能多輸出5份文檔，god bless U.
本文由作者@我是仔仔俠 在PMCAFF社區發佈，轉載請註明作者及出處。
閱讀更多 PMCAFF產品經理社區 的文章
