產品專業技術文檔怎麼寫

㈠ 申報科技項目時 技術關鍵及技術路線應如何寫

技術關鍵就是你項目中最核心和最關鍵的技術，需要你們特別需要注意的關鍵點。技術路線可以理解為技術方案、工藝流程。
我看你還是應該請人幫你寫才對，申報材料也不是給你說這么一個概念就能寫好的。

㈡ 技術文檔誕生記 | 完整的技術寫作流程是怎樣的

如果你有過 Technical Writer 實習或工作經歷，那麼對技術寫作的流程應該已經了解。當然，在很多大公司里，你參與的很可能只是這個流程的某一個環節。例如，你只負責寫，或者只負責 review，或者只負責文檔架構。相比之下，在創業公司里，可能會參與多個環節。

如果你是尚未畢業而且也沒有相關實習經歷的在校生，或者已經工作但有意轉行做 Technical Writer 的小夥伴，那麼可能對技術寫作流程仍存疑惑，或者一知半解。

不同公司技術文檔流程的劃分可能略有差異，但從本質上來看，則大同小異。無論你在這個流程中的哪個環節，從宏觀上了解整個流程有助於讓你的認識更加清晰，也有助於在有需求時從容地承擔其它環節的工作。

這里跟大家分享一個完整的技術文檔寫作流程，你只需記住六個單詞即可。如下圖所示：

再說明一下，你從工作中已經了解或即將接觸慎嘩拆的技術寫作流程不一定與上圖完全一致，但一個完整的流程一般都會涵蓋這些內容，區別多半是主觀劃分而已，這一點不必拿出「大家來找茬」的精神死磕哦~

准備階段的工作主要包括以下幾點：

在寫文檔之前，需要明確文檔需求。你要了解為什麼要寫這篇文檔，寫這篇文檔是為了達到什麼目的。

也要明確文檔受眾。受蘆凱眾不同，內容就很可能不同。比如，面向開發人員和非開發人員/普通用戶的文檔，在內容的組織上就會不同。

還要界定文檔范圍。思考並確定這篇文檔需要覆蓋哪些內容或模塊，以及不會涉及哪些內容。這樣在之後搜集資料的時候就會有所側重，寫的時候也不會模糊不定。

有過技術文檔寫作經歷的小夥伴一定會深有同感，如果不理解某個東西，那麼給它寫文檔簡直太痛苦。

那麼當遇到一個讓你毫無頭緒的陌生主題時，該如何盡量避免這種痛苦呢？當然就是盡最大可能去理解了。

可是具體該如何做呢？簡言之，即搜集資料。那又該如何搜集資料呢？筆者認為，可以從以下幾點著手：

1）對比較有代表性的同類產品或相似產品的相關文檔進行調研，看看別人的文檔是怎麼做的。

在一無所知的時候，借鑒他人的經驗做法不失為一種好的選擇。通過對幾家產品的文檔進行對比，你就可以對自己要寫的文檔建立一個大致的框架。

需要注意的是，借鑒不是照搬，只用於提供思路；產品不同，文檔的結構規劃也會有差異。

2）採用最有效的方法盡力搜集與所寫文檔相關的各種資料。

搜集的資料經過 Technical Writer 的摘刪組織，很可能就會成為發布文檔的一部分。

搜集資料的方法有很多，像網路搜索、調查問卷、訪談、實驗，以及郵件討論、報告、技術文章等等。到底該使用哪種方法要具體寬棗分析，需要你根據文檔需求、Deadline、已有資料的豐富程度等因素，來選擇能快速而准確地搜集到所需資料的方法。

有些主題的寫作，通過網路搜索可能幾乎無法給你提供任何幫助。即便是這類內容，你也可以從開發人員那裡獲得一些資料，可以根據自己的需求請他們協助提供資料，抑或是通過內部系統中的開發說明和討論獲取所需信息。

對於軟體類的產品文檔，即便有了一些技術資料，也往往需要 Technical Writer 自己使用一遍，從而對操作步驟有一個直觀的理解，獲得文檔寫作的一手資料。

當資料搜集得差不多的時候就可以組織這篇文檔的具體結構了，之前對相似產品的調研或許可以在此時助你一臂之力。

對於常見的產品使用指南，一般按照安裝或使用的順序進行組織；對於其它一些非指南類的文檔，也應遵循一定的順序或邏輯。

此外，還需考慮該文檔是否需要配圖，是否需要使用表格。如果需要配圖，明確是需要他人協助提供，還是需要自己完成。畫一個較復雜的圖也是一件蠻耗時的事情，花費的時間也需考慮在內。

有了詳細的文檔架構之後，就可以進行下一步的寫作了。

如果做好了前幾步的工作，寫作將變得非常簡單，你只需把相應的內容准確地填到文檔架構中。在這個過程中，你需要寫一個個段落或者具體的操作步驟。這是一個反映你的語言和寫作功底的時刻。

有的 Technical Writing 書籍中說到，在寫文檔的時候不必在意語法、措辭和標點，認為這些細節應該在 Revision 階段完善。

我對此有不同的看法。一個合格的 Technical Writer 本身應該有良好的語言功底，像語法、措辭和標點這種最基礎的細節本就不該成為一個需要單獨解決的問題。規范的語法、得體的措辭、正確的標點應該已經成為一種不需要額外付出精力、也幾乎不會佔用額外時間的寫作習慣。

如果寫作的初稿比較粗糙，有許多需要修改的小細節，這必定會增大 review 時的工作量和時間成本，從而延緩文檔流程。

或許，對於有精細化分工、每個人只負責一個小環節的大企業，可以採用這種方法。但是，對於快速發展、需要文檔敏捷開發的創業公司，這種就不適用了。

寫完文檔第一稿後，一般都需要進一步修改完善。這里的 Revision 指的是 review 之後的修改，所以這一步也可以叫作： Review & Revision 。

那麼需要誰來 review 呢？技術文檔通常需要請其他小夥伴進行兩種 review，即：

收到 reviewer 的反饋之後，Technical Writer 需要及時作出判斷和修改，有不明確的地方需和 reviewer 討論確定。改完之後，再請 reviewer 看一下。如果又發現了新的問題，那麼還需要再次修改。這個 review - revise 的過程可能會反復幾次，很正常。

當然，在請他人 review 之前，Technical Writer 也可以先自己 review 一遍，盡量避免低級錯誤，不浪費他人的時間。

哈哈，問題又來了~通常，剛寫完一篇文章的人是很不情願再去看自己寫的東西的，此時就可以使用一些語法拼寫檢查的小工具來協助你了。

我在之前的一篇文章 Technical Writer 日常工作中好用的小工具 中有推薦，有需要的小夥伴可以戳鏈接去瞅瞅~

如果你覺得自己足夠細心，根本不需要小工具來協助你，我佩服你的能力，但還是建議用一下小工具。因為，你可能也會有狀態不好的時候，有疲勞打盹的時候，有不知道自己寫了一堆什麼鬼東西的時候……不要跟自己和小工具過不去。

等文檔定稿之後，就可以在平台上發布了，一般很容易操作。不同的公司的文檔發布平台也會不一樣，Technical Writer 使用的寫作工具也不一樣。

文檔發布之後，並不代表著結束。根據我的工作經歷，即便是已經發布的文檔，也依然有可能存在問題，無論是大公司還是小公司的文檔。例如：未發現的文字錯誤、失效的鏈接、與最新的產品已不匹配的描述和步驟等。Technical Writer 需要及時跟進產品動態，以便及時更新文檔。

寫技術文檔不是一勞永逸的，只要產品在更新，就需要 Technical Writer 一直維護下去。

以上分享的是一個完整的技術文檔從零到有的過程。日常工作中，有時不需要從頭開始，而只是對原有文檔的增刪修改，那就可以省去一些相應的環節。

如果你也是一枚 Technical Writer，也期待聽到你對技術寫作流程的見解，歡迎留言交流哦~

Reference:

你可能想讀 ：

Technical Writer 日常工作中好用的小工具
技術翻譯需要有 Technical Writer 的 sense
深度解析關於技術翻譯的六個認知誤區
如何讓你的內容輸出更加專業更有設計感？
書單 | 有哪些技術傳播從業者必知必看的書籍？
有哪些適合技術傳播從業者關注的優質博客？（一）
有哪些適合技術傳播從業者關注的優質博客？（二）
經驗分享 | 來自 11 位 Technical Writer 前輩的職業發展建議（上篇）
經驗分享 | 來自 11 位 Technical Writer 前輩的職業發展建議（下篇）
英語技術文檔的標題到底該大寫還是小寫？
如何使用正則表達式批量添加和刪除字元？
Markdown：寫技術文檔、個人博客和讀書筆記都很好用的輕量級標記語言
如何為 Markdown 文件自動生成目錄？
技術寫作實例解析 | 簡潔即是美
兩分鍾趣味解讀 Technical Writer
若脫離理解，直譯得再正確又有何意？
優質譯文不應止於正確，還要 Well-Organized
寫在入職技術型創業公司 PingCAP 一個月之後
揭秘 Technical Writer 的工作環境 | 加入 PingCAP 五個月的員工體驗記

-END-

㈢ 專利技術交底書如何寫應該注意哪些問題

1.專利技術交底書的要求：
1)應清楚、完整地寫明發明或實用新型的內容；
2)使所屬技術領域的普通技術人員能夠根據此內容實施發明創造；
3)使所屬技術領域的普通技術人員相信本發明確實可以解決現有技術不能解決的問題。2.專利技術交底書的內容:
1)發明創造的名稱；
2)所屬技術領域；
3)背景技術描述，據申請人所知，已有技術有何優缺點，對其存在的問題或不足客觀地進行評述；
4)發明創造的目的或任務，說明所要解決的技術問題；
5)清楚完整的敘述發明創造的技術方案；
對於機械產品的發明創造應詳細說明每一個結構零部件的形狀、構造、部件之間的連接關系、空間位置關系、工作原理等；
對於電器產品應描述電器元件的組成、連接關系；
對於無固定形狀和結構的產品，如粉狀或流體產品，化學品、葯品，應描述配方、製造工藝條件和工藝流程等；
對於方法發明，應描述操作步驟、工藝參數等；
6)與現有技術相比，本發明所具有的優點和效果，例如性能的提高、成本的降低等。
7)附圖：實用新型必須提供附圖，附圖中零件可注標號，不需尺寸和參數標注。
8)最佳實施例（可與第5部分合寫）：
對於產品的發明創造應描述產品構成、電路構成或者化學成分，各部分之間的相互關系，工作過程，操作步驟；對於方法發明應寫明步驟、參數、工藝條件等，可提供多個實施例。

㈣ java 項目需求文檔要怎麼寫

5.在線預覽、分享更便捷

在摹客中在線撰寫或上傳的產品需求文檔，可通過鏈接快速分享給團隊成員，團隊成員獲得鏈接後可自由查看，當產品需求文檔有修改時，團隊成員仍可通過鏈接查看最新版本。

使用摹客等高效便捷的產品文檔撰寫工具，可以簡化產品文檔撰寫流程，提升產品經理的文檔撰寫能力，讓產品經理事半功倍。

總結

產品需求文檔作為產品開發團隊的重要溝通文檔，文檔的質量好壞會直接影響到各部門是否能夠明確產品的功能和邏輯。一份簡潔易懂、邏輯清晰的產品需求文檔，可以讓團隊溝通更加高效，從而有效提高產品開發團隊的工作效率。