It互聯網項目經理，如何書寫出色的技術文檔？

我即將被提拔為項目經理，但是每次寫文檔，我都會感覺很痛苦，感覺半天寫不出一個字來，如何提高呢？請大家指教下！

BRD文檔通常是向高層彙報使用，層通常關注的是產品的潛在市場、盈利模式等關鍵問題，而對產品細節不會太多的在意，所以在撰寫BRD時要注重高層領導關注的問題。

BRD文檔內容框架？（框架並不固定，具體問題具體分析）

1.項目背景

目前市場上相關方向產品的發展情況、用戶體量、利潤空間等。項目背景的目的是解答公司高層為什麼要做個產品的疑惑。

2.產品規劃

通過用戶、場景、需求等多個維度以及競品分析、用戶調研闡述產品的規劃目標，可以大概描述產品功能及產品形態，不用進行細節化的描述（大Boss不care）。

3.運營目標

關於產品成型後，如何進行產品運營，獲取用戶及市場份額。可以參照以後類似產品或相關成果產品的運營經驗進行描述。

4.盈利模式

老闆最關注的一點，產品上線後如何掙錢，能掙多少錢。通過盈利模式的判斷，來決定產品是否值得做，值得付出多大的資源去做。

5.成本與收益

也算是老闆比較關係的問題，如果公司已經存在多條產品線，老闆會根據產品的成本劃分人力、物力等資源。

6.風險與應對

產品可能會遇到什麼樣的風險，如果遇到風險應該如何應對。讓老闆瞭解產品未來發展過程中可能遇到的問題以及解決方案，讓老闆知道我們對產品準備是否充分。

總結：

BRD文檔中具體內容根據不同公司或者不同產品的要求，所寫的內容會有所不同，還是要具體內容具體分析。只要抓住核心點即可：告訴老闆產品為什麼做？做什麼？如何做？好處是什麼？

技術文檔無非是以下八個方面：

1. 技術方案2. 解決的技術或業務痛點3. 技術選型4. 介面定義5. 資料庫表結構 6. 流程圖、時序圖

7. 說明一些具體實現時可能出問題的細節。

8. 響應狀態碼匯總。如果向技術棧添加了新框架、新模式、新工具，要同時針對這些新東西更新公司代碼規範。

首先說明的是，不要囉裏巴嗦一大堆，說當今市場如何，滿足了什麼市場需求，解決了什麼市場痛點，這不是技術文檔裏要出現的，技術文檔只是為了方便工程師交流、形成技術沉澱、有問題方便追溯；也不要為了迎合領導說一些場面話，技術文檔是為了方便溝通交流，廢話不要說。

其次要說明的是，針對以上每個方面要堅持一個原則簡明扼要、言簡意賅。

總之能用十個字說清楚的，就不要廢話一堆說十一個字。盡量運用簡單辭彙，不要用太複雜的句式，也不要用太多的修辭。字數越少閱讀效率越高，辭彙句式越簡單越容易理解。技術方案簡單說明，針對當前需求要採用的技術方案。此處點明關鍵點即可，不必連篇累牘，因為下文還要從其它幾個方面分別闡述。如果只是一篇簡單的介面說明文檔，此處可省略。解決的技術痛點或業務痛點

此處說明當前的技術棧在實現當前這些需求的困難，以及新的方案會帶來的優勢。

如果不添加新的技術棧，也不引入新的技術方案，此部分可省略。技術選型如果引入了新的技術棧或技術方案、開發模式，可以此部分說明，最好另附文檔簡單說明如何使用及入門，最好讓不懂新方案或技術的同事讀過文檔就能立即應用並開發。如果有網路通訊、http請求、rpc等，參數需要加密或簽名/驗簽的可在此處說明。介面定義此處分別按以下幾方面說明如果是RESTful或http介面，要包含：URL: method:

Content-Type:

User-Agent:功能：如果是RPC介面，要包含：介面名：介面方法名：參數：返回：功能：不論是哪種類型的介面，都要包含以下內容：

介面功能描述：

各參數名稱、參數類型、是否必須、參數合法性條件、參數的業務意義，最好建一個表格描述返回值對象屬性名稱、屬性類型、各屬性是否必須、屬性的業務意義，最好建一個表格描述返回值對象最好包含一個響應狀態碼，整型或字元串都可以，用來標識此次訪問的處理結果。資料庫表結構簡要說明資料庫表的業務意義、表名、各欄位類型、欄位名、是否必填、長度、是否需要建索引、各欄位的業務意義等最好建一個表格描述流程圖、時序圖針對每一個業務，尤其是關鍵業務，畫出流程圖或時序圖說明業務處理流程、步驟，以及系統各部分之間的關係。說明一些具體實現時可能出問題的細節

此處說明一些應用新的技術棧時可能遇到的問題、業務實現時應注意的問題等響應狀態碼匯總整篇文檔出現的所有響應狀態碼匯總於此

嘗試多去看看組織或他人的文檔，從文檔中學習，發現自己知識體系和結構上缺乏的內容，再有針對性的進行相關知識的學習，相關書籍的閱讀和理解。

寫的再爛也要先從願意寫，不斷寫起步，你只要開始寫就有了可以持續改進的基礎。老是糾結在寫不出來無法寫上，再多思維和方法都沒有用。

個人認為題主想寫出好的技術文檔，我們要從幾個方面去考慮：1.你本身的工作習慣和專業技術背景，為什麼職場從很多企業都喜歡白紙的應屆生是因為沒有那麼多不好的工作習慣，另外你的專業技術背景能否滿足現有你寫文檔的需求。如果答案都是否就需要多做鍛煉來提升寫作技能，勤練筆，如果是邏輯拆分的問題就要勤思考；專業技術背景的問題要靠多讀書。2.你所在公司的技術文檔撰寫規範這個內容體現在你需要去找一些技術文檔應用端的朋友他們認為的好文檔來研究。看看你為什麼寫不出來的差距和原因。並且主要要了解你們公司對於文檔的要求和固定樣式。

3.使用和查看文檔工程師以及上級的習慣。

投其所好，才能得到大家的喜愛

和題主的情況差不多，分享下自己的心得，那就是不斷地寫，強迫自己寫，寫得多了就自然比以前好得多，熟能生巧。

個人經驗是，先明確目錄，然後根據項目情況填充內容。

很多人寫文檔在找標準，找模板，我一開始也這樣，後來發現寫著寫著都不知道自己到底為什麼要寫文檔了。所以我覺得首先要明確自己為什麼寫？寫給誰看？寫什麼？兒不用糾結說寫得怎麼樣，重在你要表達的東西能讓別人看明白。這樣就簡單了，從目的出發，心裡知道自己要表達什麼就可以了。一開始想不出寫什麼，那就要表達什麼就寫什麼，然後寫寫改改，就能拼出來了，嘗試，寫過之後才知道。

先打框架，再填充內容。

多看，多寫。

問下，項目經理需要寫什麼技術文檔？