作者：Vaijayanti Nerkar 和 Priya Shetye，BMC Software

几年前，当 BMC Software 决定进军 SaaS 市场时，该公司开始投资开发基于云的产品。20多年来，BMC Software 产品都是典型的本地产品，因此，我们的文档策略以提供本地模型的信息为中心。当我们进入基于云的市场时，我们很快意识到我们需要一个新的 SaaS 产品战略。向 SaaS 的转变在安装、升级策略、补丁策略等方面带来了很多变化。因此，制定特定于 SaaS 产品的文档策略变得很重要。我们可以看出，这将与我们使用了 20 多年的产品大不相同。

1. SaaS 和本地策略之间有什么区别？

发布周期是 SaaS 和内部部署世界之间的主要区别之一。SaaS 世界中的发布周期要短得多。我们每个季度都会发布一个主要版本。因此，发布是快节奏和敏捷的。发布积压比以前更受客户驱动。云产品不是通过“电子产品下载”方式“发货”的。产品支持策略也发生了变化。由于整个发布过程中的这些关键变化，我们需要通过适应新的运作方式来做出响应。我们必须在多个层面优化文档流程。

2. 过程中发生了什么变化？

从内部部署到 SaaS 的转变带来了流程和思维方式的重要变化。让我们首先看看文档过程中发生了什么变化。

文档版本控制——随着 SaaS 策略的到来，大多数客户现在自动升级到当前版本。很少有客户有例外，并且仅比当前普遍可用的版本晚一个版本。SaaS 支持政策现在声明我们只支持当前和以前的版本。因此，我们不再需要维护旧版本的文档空间。基于云的产品只有两个实时文档版本，即“当前”和“以前”。

术语更改——SaaS 版本引入了一些新术语，这些术语不仅需要在文档中吸收，而且需要在教育、支持、DevOps 等其他功能中吸收。由于升级和补丁被推送给客户，服务包变成了推送版本，版本升级变成了版本更新等等。让所有利益相关者和职能部门使用相同术语的最初努力是巨大的。最终，新条款被采纳并在过去几年变得更加稳定。

利益相关者互动——很少有新的利益相关者加入到我们的互动中。DevOps 和技术营销就是这样的利益相关者。DevOps 和技术出版团队需要在发布的各个里程碑期间紧密配合。例如，在主要版本发布前大约一个月，DevOps 团队需要通知客户即将发布的版本，并在高层沟通将随其交付的功能。为此，文档团队需要创建一个预览主题，DevOps 团队将其与发布日历一起发布给客户。技术营销和产品管理组织成为关键的利益相关者，因为我们需要获得价值实现用例并在相关产品文档中详细说明它们。

与支持团队的互动变得非常重要。他们被视为我们的第一位客户，他们为文档提供了一些重要的输入。我们已经实施了“文档验证”流程，支持团队通过执行该版本中交付的用例中涉及的任务来测试文档。不向他们提供指向文档或其他自助材料的直接链接。如果他们需要帮助，在执行任务时的任何时候，他们都会像客户一样搜索信息，并确认信息可找到且完整。这有助于我们针对任何不准确之处收紧文档。

3. 内容有什么变化？

不仅仅是流程上的改变，内容上也做了很多改变。从内容模型到可交付成果的类型，我们改进了很多东西。

内容模型更改——对于 SaaS 产品，客户不执行安装和升级任务。它由服务提供商（在我们的例子中是 BMC）负责。因此，安装和升级部分已从内容模型中弃用。我们添加了有关入职（onboard）和发布预览的部分。随着我们开始提供大量应用程序内帮助，我们基于文本的文档开始变得更精简。入门主题成为最重要的主题之一，因为在发送给新客户的订阅电子邮件中添加了该主题的直接链接。我们翻新了文档主页为该产品提供的主要用例和其他学习资源（如社区、视频播放列表、知识文章等）提供快速入口点。

富媒体焦点——我们的 SaaS 产品是新时代的产品，具有直观的用户界面。因此，我们开始转向“展示”而不是“讲述”。我们实施了应用程序内帮助，添加了更多丰富的媒体内容，例如视频、工作流或流程图以及教程。我们的愿景是通过富媒体传递 50% 的内容，而不是默认使用基于文本的文档来传递信息。

语气和相关变化——由于更多地关注富媒体和自助，我们带来了语气的变化；它从正式变得更具有对话性。我们标记章节和标题的方式发生了变化。我们的主题变得更加以目标为导向，而不是基于功能。例如，以前很常见的标题是管理批准或处理批准。现在，我们对标题进行了更深思熟虑，并尝试让用户了解标题本身的目标，例如自动化自我批准、为任务配置自我批准等。

4. 挑战

向 SaaS 战略的转变带来了一些挑战。最大的挑战是围绕改变作家的心态。我们希望作者避免默认使用基于文本的文档。因此，用户体验计划或文档计划成为重要的工件。该计划帮助作者为给定的用例确定正确的可交付成果。作者根据用例所迎合的角色分析信息需求，然后确定信息的传递方式，是通过视频、自助流程还是基于文本的文档。经过全面分析后，他们将范围缩小到正确的信息传递模式。

我们还需要投入大量时间对我们的写作团队进行 SaaS 产品培训，了解它们如何作为独立产品工作、它们的集成点是什么，或者它们如何作为解决方案工作。我们还就用于提供自助服务的新工具对团队进行了培训。

在应对更短的发布周期时，我们不想在可交付成果的质量上妥协。因此，我们提出了一些创造性的方法来优化质量流程，例如文档验证和创建用户体验计划。例如，我们开始对一些在发布周期早期完成的用例进行验证过程，同时将交叉产品用例保持在发布结束时。这帮助我们在不影响质量的情况下减少了发布结束时的工作量。

5. 接下来的旅程

当我们实施新流程时，我们开始非常依赖于跟踪客户反馈。我们需要确保流程和质量检查对每个人都适用。

我们已经收到了很多关于我们的一些可交付成果的积极反馈，例如教程、图表和视频。我们会定期跟踪收到的客户对基于文本的文档的评论。对于标记为“无用”的主题，我们确保调查无效的内容并即兴创作主题以使其更加以用户为中心。

客户满意是我们的口头禅，我们有很多制衡机制来确保我们走在正确的道路上。

作为一个团队，我们学会了每季度交付一次发布文档，我们接下来的步骤是寻找支持双周产品发布的方法并改进我们的流程，以便我们满足质量和客户满意度，并继续我们的 SaaS 之旅。

英文原文：

https://www.infomanagementcenter.com/doc-strategy-for-saas/