随着组织逐渐成熟的DevOps实践，是时候让技术写手成为团队中更大的一部分了。企业通常会将技术作者的角色排除在DevOps讨论之外。甚至营销部门也加入了一些以开发为先的组织的讨论，那么为什么作者不加入呢?
图片来源 WOCinTech Chat. Modified by Opensource.com. CC BY-SA 4.0我们的行业对技术写手的要求不够高。文档是事后才想到的。在项目生命周期结束时，公司将技术写作外包给承包商来走捷径。同样地，技术作家对其行业也没有提出足够的要求。对该职位的期望因公司而异。这两种情况都导致技术作者被排除在DevOps讨论之外。
随着组织逐渐完善的DevOps实践，是时候重新审视技术作者的角色了。
为DevOps重新编写技术文档
还记得我参与的第一个agile项目，那时还在写技术文档。团队中的另一位作者很难理解这样一个事实:必须写一个不是100%完整的产品。那些日子一去不复返了。感谢，DevOps和agile。
现在是组织重新考虑如何雇用技术写手的时候了。现在，扔掉瀑布式的技术作家的工作描述。我总是把技术写手分为运营技术写手和软件开发技术写手。运营技术写手负责编写基础架构文档，软件开发技术写手负责编写软件开发文档。作家们来回穿梭。但是，找到一个具有软件开发和操作基础的技术作家可以帮助在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进行创作。作为开发模型的内容即代码支持与cms互操作性的静态网站生成器，如Jekyll和Hugo。
无论选择什么方向来发布文档，做前期工作都是很重要的。从概念的一个小证明开始。尝试使用工具和工作流程。让开发团队参与到初始过程中，以获得他们对正在构建的新发布模型的反馈。确保记录发布工具和工作流，就像对DevOps工具链所做的那样。
DevOps技术作家的时间到了
DevOps为组织带来的文化和技术转变意味着需要更多经验丰富的技术作家。正如将开发人员和系统管理员带入了DevOps时代，技术作者也应该这样做。
组织如何调整DevOps的技术写手角色?请在评论中分享。
