devops 技术_在DevOps时代雇用技术作家

devops 技术

对于企业来说，通常将技术作者的角色排除在DevOps讨论之外。甚至市场部也加入了一些以DevOps为先的组织的讨论 -那么为什么不写作者呢？

我们行业对技术作家的要求不高。文档是事后的想法。公司在项目生命周期结束时向承包商承包技术写作。角落被切开。同样，技术作家对行业的要求也不高。对角色的期望因公司而异。两种情况都导致技术作家被排除在DevOps讨论之外。

随着您组织的DevOps实践日趋成熟，是时候重新审视技术作家的角色了。

重铸DevOps的技术作家

我还记得我当时写的第一个敏捷项目之一，那时候我还在写技术文档。团队中的其他一位作者很难理解我们必须写出并非100％完整的产品这一事实。那些日子已经一去不复返了。谢谢您，DevOps和敏捷。

现在是组织重新审视他们如何聘请技术作家的时候了。丢掉您的瀑布技术作家的职位描述。对。现在。我一直将技术作家分为运营技术作家和软件开发技术作家，后者分别记录基础设施和软件开发技术作家。作家来回奔波。但是，找到具有软件开发和运营基础的技术作家可能会对在DevOps团队中担任技术作家职位有所帮助。

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的技术编写者角色？请分享评论。

翻译自: https://opensource.com/article/19/11/hiring-technical-writers-devops

devops 技术