TL:DR？好吧...这里：
除了聘请或外包给技术作家之外，技术作家在其行业中是否采用一些基本标准/惯例/实践可供学习，以便创建适当的 IT 文档并长期维护该文档？
在为我们的员工编写内部 IT 使用和外部使用的各种文档时，很明显我们的员工在文档方面都有自己的风格。
从我们的质量文档和受控文档中提取，IT 部门使用了各种 SOP、WI 模板和用于 IT 质量文档的各种表格。这些文档虽然不一定对 IT 部门的日常运营有用，但确实可以帮助员工和公司解决 IT 人力资源问题、合规性等问题，而且通常写得很好、定义明确，并且至少遵循质量部门的模板和文档标准（如版本控制、ECN 等）。
但我们实际的IT文档写作还缺乏真正的惯例/标准。 有些人会使用第三方工具（例如 ScreenSteps），其他人则仅使用 Word 并创建一个简单的大纲，例如：
- 打开
app- 点击‘发动全球热核战争’
- ...
- 利润
内部 IT 文档实际上更糟糕，基于员工或顾问当时认为足以唤起他们自己记忆的内容或基于他们选择的编辑器（vi、word、excel、powerpoint、napkin、内部 wiki）。当员工离职或休假时，问题就出现了，他们甚至需要匆忙弄清楚最基本的信息。 有时仅文件日期可以表明数据是否仍然相关。
虽然简单的大纲、实际的截图、甚至全高清视频都很好，但我们并没有真正的 IT 技术作家，不禁认为我们在这方面有所欠缺。
我们能否根据已批准的模板为我们的文档制定自己的标准？可以，但为什么要重新发明轮子呢？如果技术作家“行会”中已经存在此类标准和惯例，我们最好遵循这些惯例，以便我们的文档清晰、简洁且专业。
为了避免被告知“去谷歌上查询“，我确实查看了一些显示格式实践的网站，而这个 SF Q：IT 文档平台帮助寻找处理写作的平台和软件，但并没有讨论该行业是否真正存在标准。
那么，除了聘请或外包给技术作家之外，技术作家在其行业中是否采用一些基本的标准/惯例/实践可供学习，以便创建适当的 IT 文档并长期维护该文档？
答案1
写作是一门学科。
我做了很多，我已经掌握了尽可能多的基础知识，即使没有受过训练的人也不需要将文档作为我工作的重中之重。时间告诉我，我编写的文档实际上会被阅读，哪些文档会被放在永恒的书架上（TL;DR）。事实上，这是写作的首要规则：
了解你的听众。
内部 IT 文档的受众是我们自己。那么系统管理员呢？当我们查阅文档（尤其是内部文档）时，我们正在寻找：
- 可定位
- 简短的
- 说到点子上
- 带我去我要去的地方
系统背景的五段解释将被忽略，取而代之的是下面的清单，因为我们很着急，我们只需要完成它。如果那里的警告如果你不按顺序执行某些步骤，它将删除你所有的备份在那段被跳过的文本块中，也许它应该有一些引人注目的格式，或者可能也将该部分包含在清单中。
流程文件
这种类型的文档主要描述做某事的方法。对于未经培训的人来说，这是最容易编写的，因为它主要只是写下一系列要遵循的步骤。根据我的经验，好的流程文档具有以下特点：
- 包含一份清单。
- 该清单与清单运行的时间和原因的简短摘要位于同一页面上。
- 在清单下方或链接页面上，有一份较长的文档，描述了清单背后的理论以及可能遇到的变化。
您希望有一个可供遵循的清单，并且如果需要的话，页面上至少已经有第一级故障排除步骤（或只需单击一下即可）。
如果您曾经看过 Microsoft KB 文章，就会发现这是一种熟悉的格式：摘要、修复、详细信息、受影响的系统。这是有原因的。
故障排除指南
这比流程文档更棘手，因为您必须将决策树编码到文档中。一个简单的清单可能不够，但分支清单（使用指向其他清单的链接）是相当可行的。与流程文档一样，此类文档适用相同的规则：
- 尽量简洁，不要让读者被细节淹没。
- 明确决策点是什么以及后续行动的去向。
- 将深入的技术背景资料保存到架构文档中。
故障排除指南可以是一篇大型的“选择您自己的冒险故事”，也可以是一份列出系统发生的所有问题及其解决方法的项目符号列表。
架构文档
这是最难制作的类型，因为它被设计为参考材料，只有新人才能理解他们刚刚接触的这个复杂事物。
架构文档是“为什么”文档。它说明了为什么使用这个系统而不是那个系统，它们如何与另一个系统连接，以及是什么让这种连接如此运作。这是您在知道生产配置是什么样子后应该立即编写的文档，并在进行更改时进行更新。
就格式而言，我必须听从专家的意见。
好的文档不仅仅是模板和格式，统一的外观很好，确实提高了可读性，它还需要一些其他的东西。
定期更新
养成检查现有文档的习惯，确保其仍然完好无损。1.17 版的检查表可能不适用于 1.26 版，是时候更新了。死记硬背的检查表需要更新，因为即使是最小的 UI 更改也会使整个事情发生混乱。
投入10分钟一周检查文档并找出需要清理的东西可以带来惊人的效果。
架构文档需要由熟悉系统的人员定期审查。正如我所提到的，这些文档很少使用，但在您真正需要它们时非常有用。当 3 年前迁移到 Windows 时，您不会想要描述校园打印服务集群如何与 NetWare 连接在一起的文档。
可发现
这是最难做到的，因为它在很大程度上取决于在哪里您正在存储您的文档。
我们会告诉那些带着疑问来到 ServerFault 的人什么呢？
你已经尝试过什么了？
紧接着
Google 上的热门搜索结果解决了您的问题。也许您应该尝试一下。
我们搜索文档，而不是去书架。文档库需要像 Google 一样可搜索，否则我们就会去 Google。
中央 Napkin 存储库不适合存放文档，至少如果它没有在线索引（而且它不会有）。简单的 wiki 更好，因为大多数 wiki 至少包含基本的文本搜索。更好的系统是允许搜索标签和全文，以便更好地将搜索集中在目标区域。
如果你正在使用支持标签的文档存储库，标准化标签。只需查看 ServerFault 标签列表即可了解原因。用户不必记住VMware只是为了找到他们正在寻找的东西。这将需要偶尔重新标记。