IT 技術作者是否使用了標準/約定？
TL：博士？好吧……這裡：
除了僱用或外包給技術作家之外，是否有技術作家在其行業中採用的基本標準/慣例/實踐可以從中學習，以便創建適當的 IT 文件並隨著時間的推移維護該文件？
在為員工的內部 IT 使用和外部使用編寫各種文件時，很明顯，我們的員工在文件方面都有自己的風格。
從我們的質量文件和受控文件中提取，IT 使用了 SOP、WI 的各種模板以及用於 IT 質量文件的各種表格。這些文件雖然不一定對 IT 內部的日常運營有用，但確實可以幫助員工和公司解決 IT 人力資源問題、合規性等問題，並且通常寫得很好、定義明確，並且至少遵循質量部門的模板和文件標準（如版本控制、ECN 等）
但是我們實際的 IT 文件寫作仍然缺乏真正的約定/標準。 有些人會使用 ScreenSteps 之類的 3rd 方工具，而其他人則只需使用 Word 並創建一個簡單的大綱，例如：
- 打開
app- 點擊“開始全球熱核戰爭”
- …
- 利潤
內部 IT 文件實際上更糟糕，基於員工或顧問當時認為足以記錄他們自己的記憶或基於他們選擇的編輯器（vi、word、excel、powerpoint、餐巾紙、內部 wiki）的任何內容。當員工離開或休假時，問題就出現了，甚至連基本資訊都被弄得亂七八糟。 有時只有文件日期是數據是否仍然相關的指標。
雖然簡單的大綱、實際的螢幕截圖，甚至完整的高畫質影片都很好，但我們沒有真正的 IT 技術作家，不禁認為我們在這方面缺乏。
我們可以為我們的文件制定我們自己的標準以及批准的模板嗎？是的，但為什麼要重新發明輪子？如果技術作家的“公會”中已經存在這樣的標準和慣例，我們最好遵循這些慣例，以便我們的文件清晰、簡潔和專業。
為了避免被告知**“ Google It ”**，我確實查看了一些顯示一些格式化實踐的網站，雖然這個 SF Q：IT 文件平台有助於找到處理寫作的平台和軟體，但它沒有討論內部是否真的有標準行業。
那麼，除了僱用或外包給技術作家之外，是否有技術作家在其行業中採用的基本標準/約定/實踐可以從中學習，以便創建適當的 IT 文件並隨著時間的推移維護該文件？
寫作是一門學科。
我已經做了很多，而且我已經掌握了一個未經培訓的人可以得到的盡可能多的基礎知識，而文件不是我工作的首要部分。時間向我展示了我製作的文件實際上會被閱讀，以及永恆 TL;DR 的書架上會發生什麼。這實際上是寫任何東西的第一條規則：
了解你的聽眾。
內部 IT 文件的受眾是我們自己。和系統管理員？當我們獲取文件，尤其是內部文件時，我們正在尋找：
- 可出租
- 簡短的
- 切中要害
- 帶我到我要去的地方
系統背景的五段解釋將被忽略，而支持它下面的清單，因為我們很著急，我們只需要完成它。如果那裡的警告是，如果您不按順序執行某些步驟，它將刪除所有備份是在跳過的文本塊中，也許它應該有一些引起注意的格式，或者可能包括那個位在清單也是。
過程文件
這種類型的文件都是關於描述做某事的方式。對於未經培訓的人來說，這是最容易製作的，因為大多數情況下它只是寫下一系列要遵循的步驟。根據我的經驗，良好的流程文件具有以下特點：
- 包含一個清單。
- 該清單與執行清單的時間和原因的簡短摘要位於同一頁面上。
- 在清單下方或連結頁面上，有一份較長的文件，描述了清單背後的理論和可能遇到的變化。
您需要它以便有要遵循的清單，並且如果需要，至少頁面上已經存在第一級故障排除步驟（或點擊即可）。
如果您曾經查看過 Microsoft 知識庫文章，那麼這是一種熟悉的格式：摘要、修復、詳細資訊、受影響的系統。這是有原因的。
故障排除指南
這比流程文件更棘手，因為您必須將決策樹編碼到文件中。一個簡單的清單可能還不夠，但是一個分支清單，一個使用到其他清單的連結的清單，是非常可行的。與流程文件相同的規則適用於此類文件：
- 簡明扼要，不要把你的讀者淹沒在細節中。
- 清楚決策點是什麼以及後續行動的去向。
- 保存架構文件的深入技術背景資料。
故障排除指南可以是一個大的選擇你自己的冒險故事，也可以是一個大的項目符號列表，列出系統出現的所有問題以及修復它的原因。
架構文件
最難製作的單一類型，因為它被設計為參考資料，只有那些想要了解他們剛剛走進的這個複雜事物的新人才會參考。
架構文件是為什麼文件。這就是為什麼使用這個系統而不是那個系統的原因，它們是如何與另一個系統連接的，以及是什麼使這種連接以它的方式工作。這是您應該在知道生產配置後立即編寫的文件，並在進行更改時進行更新。
格式明智，我必須聽從專家的意見。
好的文件也不僅僅是它們的模板和格式，統一的外觀很好並且確實提高了可讀性，它還需要一些其他的東西。
定期更新
養成閱讀你已經擁有的文件的習慣，以確保它仍然是好的。1.17 版的清單可能不適用於 1.26 版，是時候更新了。死記硬背的清單需要最多的更新，因為即使是最小的 UI 更改也可能使整個事情變得混亂。
每週花 10 分鐘來查看文件並確定需要清理的內容可以做一些很棒的事情。
架構文件需要由了解系統的人定期審查。正如我所提到的，這些是很少使用的文件，但在您確實需要它們時非常有用。您不希望在 3 年前遷移到 Windows 時描述校園列印服務集群如何與 NetWare 連接在一起的文件。
可發現的
這是最難做到的，因為它在很大程度上取決於您儲存文件的位置。
我們告訴任何通過 ServerFault 提出問題的人是什麼？
你已經嘗試過什麼？
緊隨其後的是
Google 上的熱門搜尋解決了您的問題。也許你應該試試。
我們搜尋我們的文件，我們不去書架。文件儲存庫需要像 Google 一樣可搜尋，否則我們將直接使用 Google。
Central Napkin Repository 是存放文件的好地方，至少在它沒有線上索引的情況下（而且它不會）。一個簡單的 wiki 更好，因為它們中的大多數至少包括基本的文本搜尋。更好的系統是除了全文之外還允許搜尋標籤以更好地將搜尋集中在目標區域上的系統。
如果您正在使用支持標籤的文件儲存庫，請標準化您的標籤。有時只需查看 ServerFault 標記列表即可了解原因。使用者不必為了找到他們正在尋找的東西而記住vmware的八種排列方式。這將需要偶爾進行重新標記。