企业通常将技术文档撰写员的角色排除在 DevOps 讨论之外。甚至营销部门也加入了某些 DevOps 优先组织的讨论——那么为什么不包括撰写员呢？
我们的行业对技术文档撰写员的要求不够。文档编制是事后才考虑的事情。公司在项目生命周期结束时将技术文档写作外包给承包商。质量被降低。同样，技术文档撰写员对行业的要求也不够。对该角色的期望因公司而异。这两种情况都导致技术文档撰写员被排除在 DevOps 讨论之外。
随着您的组织使其 DevOps 实践日趋成熟，现在是时候重新审视您的技术文档撰写员的角色了。
为 DevOps 重新塑造您的技术文档撰写员
我记得我参与的第一个敏捷项目之一，那时我还在编写技术文档。团队中的另一位撰写员很难理解我们必须编写关于尚未 100% 完成的产品的文档。那些日子已经过去了。感谢 DevOps 和敏捷。
现在是组织重新审视他们如何聘请技术文档撰写员的时候了。抛弃您瀑布模型的技术文档撰写员职位描述。立刻。马上。我一直将技术文档撰写员分为运维技术文档撰写员（负责记录基础设施）和软件开发技术文档撰写员（负责记录软件开发）。撰写员在两者之间来回切换。但是，找到一位具有软件开发和运维基础的技术文档撰写员，对于为您的 DevOps 团队配备技术文档撰写员职位可能很有帮助。
DevOps 意味着您可能需要更改您的标准“企业技术文档撰写员”职位描述。例如，比以往更重视软件和运维文档编制经验，因为这种灵活性只会对您的团队有所帮助。对于那些具有使用 Twiki 或 Atlassian Confluence 等工具创建更模块化在线文档的经验的撰写员来说，情况也是如此。
DevOps 还要求技术文档撰写员能够充分参与。如果撰写员期望在他们参与之前功能就已完成，那么他们将无法再增加价值。寻找具有推动文档编制工作经验的撰写员。您的目标应该是找到一位可以减少依赖性的技术文档撰写员，您可以将其插入交付周期的各个部分。在招聘时，这可能说起来容易做起来难。我能给出的唯一建议是跳出传统技术文档撰写员角色的框架，并准备为此付费。
在为您的 DevOps 团队寻找技术文档撰写员时，另一个要寻求的技能是协作平台管理。将这项职责添加到您的技术文档撰写员职位描述中，可以将开发人员待办事项列表中的一项非关键任务移除。
DevOps 技术文档撰写员应与您引入的开发人员和其他项目团队成员采用相同的入职路径。让他们访问他们需要记录的系统，这些系统在与其他人相同的构建的沙箱中运行。
衡量 DevOps 世界中技术文档撰写员的成功，需要一些新的含义。您可以将您的在线文档与分析联系起来以跟踪读者人数。您还需要以跟踪开发人员工作的方式来跟踪技术文档撰写员的工作。文档也有错误。
改造您的文档编制流程
技术文档编制必须采取更注重工具链速度的方法，以跟上 DevOps 的步伐。在高速 DevOps 世界中，重新思考文档发布已经有一些停顿和开始。
由 CA（现为 Broadcom 的一部分）提出的名为 DocOps 的运动将技术文档编制和 DevOps 实践结合在一起，但该概念背后的原始团队似乎已经转移了方向。这项努力失败了，但我仍然建议在线研究它。您将在搜索结果中获得 CA.com 文档子站点。它在 Atlassian Confluence 上运行，具有 CA 品牌和其他自定义设置。它已从更传统的 Webhelp 和 PDF 文档格式迁移到与它们支持的应用程序分离的文档。虽然开发团队和文档编制仍然需要与发布同步，但它们在维护和更新方面并不像以前那样相互依赖。
内容即代码对于您转向更友好的 DevOps 文档策略也具有价值。它使用软件工程实践来支持内容重用。它打破了传统的内容管理系统 (CMS) 模型；它使用 Git 进行内容版本控制，技术文档撰写员和其他内容作者使用 Markdown 进行创作。内容即代码作为一种开发模型，支持 Jekyll 和 Hugo 等静态网站生成器，并与 CMS 具有互操作性。
无论您选择哪种文档发布方向，重要的是要做好前期工作。从小型概念验证开始。试验工具和工作流程。让您的开发团队参与到初始过程中，以获得他们对您正在构建的新发布模型的反馈。确保记录您的发布工具和工作流程，就像您对 DevOps 工具链所做的那样。
DevOps 技术文档撰写员的时代已经到来
DevOps 给组织带来的文化和技术转型意味着经验丰富且职位合适的技术文档撰写员可能会有更多工作要做。正如您将开发人员和系统管理员带入 DevOps 时代一样，对您的技术文档撰写员也这样做。
您的组织如何调整技术文档撰写员的角色以适应 DevOps？请在评论中分享。
1 条评论