假如你有過 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-