我所工作的组织越来越成熟，随着成长的到来，需要更好的文档。
今天，它是一个目录，维基，OneNotes大杂烩，并没有任何标准化的forms或内容，标签，甚至知道在哪里寻找什么项目。 每个团队都是不同的，甚至团队中的个人也不一定遵守任何团队标准。
我不是在寻找具体的产品或build议什么要标准化。 我也对大型组织/企业正在使用的标准更感兴趣。
技术文档有许多ISO标准，列在en.wikipedia.org/wiki/Technical_documentation上 。 维基百科的文章暗示，这些是特定于某些行业，（实际的ISO标准不容易在公共领域AFAIK）… …
对于软件开发，例如IEEE 12207也pipe理文档。
但是，内部文件的整个事情往往是大多数组织希望做任何专门为他们工作，而不是遵循外部标准。
在试图强制执行标准之前，如果在以下情况下您已经完全超越了曲线：
而作为一个IT部门，而不是试图创build和/或强制执行任何特定的标准，通过提供一个良好的内部search引擎
我不了解任何行业标准，但是我对内部文档的最佳体验是在一个有专门团队负责支持和pipe理文档基础设施的组织中。 但他们不负责编写所有的文档。
他们使用的系统恰好是一个维基，但任何单一的事实来源都应该起作用。 我甚至可以说它应该本地支持版本控制。 没有任何东西可以让我们忍受不了人们用Word发送文档多个专用于文档更新日志的页面。 如果您需要当前版本的副本，则应该很容易以PDF格式从源文件导出。
大部分团队都有高科技写作背景。 他们负责开发通用文档types的模板。 他们会帮助其他团队开始编写自己的文档。 他们会审核人们正在创build的文档，并可能会针对风格/一致性进行编辑。 这是光荣的。
说实话，编写好的文档需要时间和精力。 没有什么魔法工具可以让你轻松。 特定系统的中小企业必须愿意为其各种系统/项目编写（并保持更新）文档。
我不能说特别大的组织，但最多只有一个规模，提出一个组织合理的标准，并在合理的范围内执行，以便所有这些文档都在一个平台上，最好是一个有访问控制和search的平台能力是一个巨大的进步。
至于合法的标准和标准的做法，我发现这篇文章详细说明了你可能如何开发自己的，以及可能需要考虑的因素，以及引用相关的ISO标准。
我相信这就是所定义的标准，所以这只是为了制定适合您组织需求的标准。