TL：DR？ 精…这里：
技术编写者在其业务中使用的基本标准/惯例/惯例是否可以从中学习，以创build适当的IT文档并随时间维护文档？
在为员工内部IT使用和外部使用编写各种文档的同时，我们的员工在文档编制方面都有自己独特的风格。
从我们的质量文件和受控文件中抽取出来，IT已经利用SOP，WI和用于IT质量文件的各种forms的各种模板。 这些文档虽然不一定对于IT部门的日常运作有用，但可以帮助员工和公司解决IT人力资源问题，合规性等问题，而且通常写得很好，定义明确，并至less遵循质量部门的模板和文档标准（如版本控制，ECN等）
但是我们实际的IT文档写作仍然缺乏真正的规范/标准。 有些会使用第三方工具，如ScreenSteps，其他人只需使用Word，并创build一个简单的轮廓，如：
- 打开
app- 点击“启动全球热核战争”
- …
- 利润
内部IT文档实际上更糟糕 ，根据员工或顾问在当时是否足够轻松自己的记忆或基于他们select的编辑（vi，word，excel，powerpoint，napkin，内部维基）而言。 问题出现在员工离开或休假时，甚至连基本信息都被搞混了。 有时只有文件date是数据是否仍然相关的指标。
虽然一个简单的轮廓，实际的截图，甚至全高清video都很好，我们没有一个真正的IT技术作家的工作人员，不禁觉得我们缺乏这方面。
我们是否可以用我们自己的标准来编写我们的文档以及经批准的模板？ 是的，但为什么重新发明轮子？ 如果这样的标准和惯例已经存在于技术作家的“行会”中，我们最好遵循这些惯例，以便我们的文件清晰，简明和专业。
为了避免被告知“ Google It ” ，我确实查看了显示一些格式化操作的站点，虽然SF Q： IT Documentation Platforms帮助寻找处理写作的平台和软件，但并没有讨论是否真的有标准行业。
因此，在招聘或外包给技术作家之前，技术作家是否有一些基本的标准/惯例/惯例可以从中学到，以创build适当的IT文档并随时间维护文档。
写作是一门学科。
我已经完成了很多工作 ，而且我还有很多基础知识，因为没有经过培训的人可以在没有文档的情况下获得工作。 时间已经显示出我所产生的文件将会被读取，永恒TL的书架上将会出现什么; DR。 这实际上是写任何东西的头号规则：
内部IT文档的观众是我们自己的。 和系统pipe理员？ 当我们达成文件，特别是内部文件，我们正在寻找：
关于系统背景的五段解释将被忽略，有利于下面的清单，因为我们匆忙，我们只需要完成。 如果在那里的警告， 如果你做了一些步骤，它会消除所有的备份是跳过了文本块，也许它应该有一些注意力的格式，或者可能包括在清单也是。
这种types的文档都是关于描述一种做事的方式。 对于一个没有经过培训的人来说，这是最容易的，因为大多数情况下只是写下一系列的步骤。 根据我的经验，良好的stream程文档具有以下特点：
您需要这样做，以便查看清单，并且至less需要在页面上（或点击一下）已经在第一级的故障排除步骤。
如果您曾经查看Microsoft知识库文章，那么这是一个熟悉的格式：摘要，修复，详细信息，受影响的系统。 这是有原因的。
这比处理文档更复杂，因为您必须将决策树编码到文档中。 一个简单的清单可能是不够的，但一个分支清单，一个使用链接到其他清单，是相当可行的。 这种文档与stream程文档一样适用于相同的规则：
一个故障排除指南可以是一个大的select你自己的冒险故事，或者可以成为一个系统出了问题，什么修复了一切的大项目列表。
这是一种最难制作的types，因为它被devise成参考材料，只有被新人引用，才会围绕着他们刚刚走过的这个复杂的东西。
build筑文档是为什么文档。 这就是为什么这个系统正在被使用，而不是这个系统，他们是如何与这个系统连接的，以及这个连接是如何工作的。 当你知道你的生产configuration是什么样子的时候，它就是你应该编写的文档，并且在更改时进行更新。
格式明智，我不得不听从这个专家。
良好的文档也不仅仅是他们的模板和格式，统一的外观很好，并且提高了可读性，还需要一些其他的东西。
养成熟悉的文件，你必须确保它仍然是好的。 版本1.17的清单可能不适用于版本1.26，更新的时间。 Rote清单需要最新的更新，因为即使最小的用户界面变化可以扔掉整个事情。
每周花 10分钟去翻阅文档，找出需要清理的东西，可以做出令人惊叹的事情。
build筑文档需要由知道系统的人员定期检查。 正如我所提到的，这些文件很less被使用，但是当你确实需要这些文件时，这些文件非常有用。 您不希望在3年前迁移到Windows时描述校园打印服务集群如何与NetWare连接在一起的文档。
这是最难得到的，因为它在很大程度上取决于您存储文档的位置。
我们告诉任何由ServerFault提出问题的人是什么？
你已经尝试了什么？
紧随其后
Google上最受欢迎的解决scheme解决了您的问题。 也许你应该尝试一下。
我们search我们的文档，我们不去书架。 文档存储库需要像Google一样可search，否则我们只需要转到Google。
中央餐巾库是一个文档不好的地方，至less如果它没有在线索引（它不会）。 一个简单的维基更好，因为其中大部分至less包括基本的文本search。 一个更好的系统是允许search除了全文以外的标签以更好地将search集中到目标区域上的系统。
如果您正在使用支持标签的文档资料库， 请将您的标签标准化 。 只要看看ServerFault的标签列表，看看为什么。 用户不必记住vmware的八种排列组合，只是为了find他们正在寻找的东西。 这将需要偶尔的重新努力。