文档和本地化部门负责人Svetlana Kayushina说。
我们的文档部门经历了几个开发阶段。 首先是一名技术作家，他执行单个客户的任务。 然后，组成了一组技术作家，解决了一组有限的任务。 现在我们有一个大型的生产部门-它完全可以满足公司在文档方面的需求。
在每个阶段，部门工作要求都发生了变化，并且出现了新的指标来衡量文档质量和提供文档服务的服务。 度量标准可以帮助我们改善产品，流程和质量，并及时告知失败情况。
第一指标
Yandex需要第一位技术作家来记录几乎所有开发人员使用的技术。 有关它的信息是通过口头形式相互传递的，因此不可避免地丢失或扭曲了一部分。
编写了文档，客户感到满意，因此我们决定精通其他领域。 我们从对业务至关重要的服务的描述开始：它们被许多公司员工使用。
在初始阶段，客户为我们设定了记录技术的任务。 唯一的衡量标准是文档的可用性：它是否为书面文件。 当一个技术作家独自一人时，质量由客户自己评估。 当有更多的作者时，服务顾问也加入了客户的行列，我们检查了部门内部文档的质量。
任务流在不断增加，因此在保持单一质量水平方面存在问题。 专家评估是相当主观的，但是我们希望它是独立的。
此外，客户提出了各种复杂性的任务：例如，捕获一个人知道的信息，或描述开发我们的外部产品的复杂技术。
所有这些都带来了某些问题，因此我们需要一个用于确定任务优先级和评估文档质量的系统。
内部文档指标
我们开始收集内部客户和使用文档解决他们的问题的读者的反馈。 例如，一个客户可能告诉我们，他每周停止10个小时向同事咨询，而现在他的主要工作效率更高。
我们问读者文档如何帮助他们解决问题。 跟踪的出勤率：每周有多少用户访问文档。 如果超过一定数量，则该文档值得支持。
这种方法需要大量成本并直接与客户接触。 在大量使用文档的情况下，事实证明它过于昂贵且适用性很差。 因此，当我们开始为外部用户开发文档时，就会出现问题。
受众已经增长，我们无法直接访问它。 我们跟踪了有关社交网络和技术支持要求的评论，但这还不够。 为了尽可能满足用户的需求，我不得不建立关于用户的假设。 为了评估用户行为和产品性能，我们使用了Yandex.Metrica。
开发用于外部文档的度量系统
业务目标变化不大，但是出现了新情况：我们必须设法为正式版本准备文档。 现在我们需要按时完成任务。
我们继续使用以前的指标，但是向其中添加了文档服务的出勤率和拒绝率。 为整个服务和单个文档都对它们进行了跟踪。
技术作家使用其他数据来提高文档质量：
- 分析用户在服务上的行为，
- 点击热图，
- 网络浏览器
- 评估搜索查询等
然后，我们进入了批量生产阶段，并成为提供文档服务的服务。
文档量产指标
在此阶段，客户和管理层对文档部门有新的要求。
客户对任务的时间安排和评估很感兴趣。 例如，他们问为什么我们要写文档两周而不是两天。 同时，他们期望我们提供高质量的产品。
管理层对成本合理性感兴趣。 为了雇用一个人到部门，我们不得不争论这一点。 例如，如果文档解决的不是几个用户的问题，而是数千个问题的解决，并且减轻了技术支持的负担，那么我们可以证明它可以带来可观的收益。
我们的统计指标不再足以回答这些问题。
在批量生产的情况下，我们有几个主要任务：
- 文件技术
- 跟上发布，
- 提供高质量的产品。
这需要对我们所做的一切采取综合方法。
另外，作为服务，我们必须评估我们的服务质量。 我们需要了解用户的满意度以及高质量文档带来的好处。
为了开发新的评估系统，我们进行了一项研究并分析了许多来源：共找到136个指标。 除了它们太多的事实之外，并非所有元素都易于测量，我们也不需要全部。 因此，我们选择了适合我们条件的指标。
我们对评估的以下方面感兴趣：
- 设计和业务指标是整个服务质量有效性的指标。 他们需要提高客户满意度并预测部门的资源以执行所有任务。
- 记录质量评估指标以提高用户满意度。
在选择指标时，我们考虑了计算指标的复杂性和成本。 对于我们而言，重要的是，度量标准的本质和计算方法对那些不熟悉我们生产过程细微差别的人也应该清楚。
结果，我们从136个指标中选择了20个，然后将它们分为四个组。 我们在公司的任何员工都可以使用的仪表板上显示指标数据。
在本文的下一部分中，我们将更详细地描述文档开发和支持的指标以及我们如何考虑它们。 注册以获取新评论-我们将在其中向您介绍报告下一部分的发布。