Рассказывает Светлана Каюшина, руководитель отдела документирования и локализации.

Наш отдел документирования прошел несколько этапов развития. Сначала был технический писатель, выполнявший задачи отдельного заказчика. Потом образовалась группа технических писателей, которая решала ограниченный набор задач. Сейчас у нас большой производственный отдел — он полностью удовлетворяет потребности компании в документировании.

На каждом этапе изменялись требования к работе отдела и появлялись новые метрики для измерения качества документации и сервиса по предоставлению услуг документирования. Метрики помогают нам улучшать продукт, процессы и качество, а также вовремя информируют о сбоях.

Первые метрики

Первый технический писатель понадобился Яндексу для документирования технологии, которой пользовались почти все разработчики. Информацию о ней передавали друг другу устно, поэтому часть неизбежно терялась или искажалась.

Документацию написали, заказчики были довольны, поэтому мы решили освоить другие направления. Начали с описания сервисов, которые критически важны для бизнеса: ими пользуется много сотрудников компании.

На начальном этапе заказчики ставили нам задачу задокументировать технологию. Единственной метрикой было наличие документации: она либо написана, либо нет. Когда технический писатель был один, качество оценивал сам заказчик. Когда писателей стало больше, к заказчикам присоединились консультанты по сервису, а мы проверяли качество документации внутри отдела.

Поток задач постоянно увеличивался, поэтому возникла проблема с поддержанием единого уровня качества. Экспертная оценка довольно субъективна, а нам хотелось, чтобы она была независимой.

Кроме того, заказчики приходили с задачами разной сложности: например, зафиксировать информацию, которую знал один человек, или описать сложную технологию для разработки наших внешних продуктов.

Всё это создавало определенные проблемы, поэтому нам понадобилась система приоритезации задач и оценки качества документации.

Метрики внутренней документации

Мы начали собирать отзывы внутренних заказчиков и читателей, которые использовали документацию для решения своих задач. Например, заказчик мог сказать нам, что перестал 10 часов в неделю консультировать коллег и теперь продуктивнее делает основную работу.

У читателей мы спрашивали, насколько хорошо документация помогает им решать задачи. Отслеживали посещаемость: сколько пользователей в неделю обращается к документам. Если больше определенного числа, значит, документ стоит поддерживать.

Этот метод требовал существенных затрат и прямого выхода на заказчика. В условиях массового использования документации он оказался слишком дорогим и слабо применимым. Поэтому когда мы перешли к разработке документации для внешних пользователей, появились проблемы.

Аудитория выросла, у нас не было к ней прямого доступа. Мы отслеживали отзывы в соцсетях и запросы в техподдержку, но этого было недостаточно. Пришлось строить гипотезы, кто наш пользователь, чтобы максимально удовлетворять его потребности. Для оценки поведения пользователей и эффективности продукта мы использовали Яндекс.Метрику.

Развитие системы метрик для внешней документации

Задачи бизнеса почти не менялись, но появилось новое условие: мы должны были успевать подготовить документацию к официальному релизу. Теперь нам требовалось укладываться в сроки.

Мы продолжали использовать прежние метрики, но к ним добавились посещаемость сервиса документации и отказы. Отслеживали их как для сервиса в целом, так и по отдельным документам.

Технические писатели для улучшения качества документации использовали дополнительные данные:

• анализ поведения пользователей на сервисе,
• тепловую карту кликов,
• вебвизор,
• оценку поисковых запросов и т.д.

Дальше мы перешли к этапу массового производства и стали сервисом по предоставлению услуг документирования.

Метрики массового производства документации

На этом этапе у заказчиков и руководства появились новые требования к отделу документации.

Заказчики интересовались сроками выполнения и оценкой трудоемкости задач. Например, они спрашивали, почему мы пишем документ две недели, а не два дня. При этом от нас ждали высокого качества.

Руководство интересовалось обоснованием затрат. Чтобы нанять в отдел человека, мы должны были это аргументировать. Например, мы могли показать измеримую пользу документа, если он решает проблемы не пары пользователей, а нескольких тысяч, и уменьшает нагрузку на техподдержку.

Наших статистических метрик уже не хватало, чтобы отвечать на эти вопросы.

В условиях массового производства у нас есть несколько основных задач:

1. документировать технологии,
2. успевать к релизам,
3. обеспечивать высокий уровень качества.

Это требует комплексного подхода ко всему, чем мы занимаемся.

Кроме того, мы, как сервис, должны оценивать качество своих услуг. Нам нужно понимать, насколько пользователи удовлетворены и какую выгоду приносит документация высокого качества.

Чтобы разработать новую систему оценки, мы провели исследование и проанализировали большое количество источников: всего нашли 136 метрик. Кроме того, что их слишком много, не все из них легко измерить и не все нам нужны. Поэтому мы выбрали метрики, которые подходили под наши условия.

Нас интересовали следующие аспекты оценки:

1. Проектные и бизнес-метрики — показатели эффективности качества сервиса в целом. Они нужны для повышения удовлетворенности заказчика и для прогнозирования ресурсов отдела на выполнение всех задач.
2. Метрики оценки качества документов для повышения удовлетворенности пользователя.

При выборе метрик мы учитывали сложность и стоимость расчета метрики. Еще для нас важно, чтобы суть и подсчет метрики были понятны людям, которые не погружены в нюансы нашего производственного процесса.

В итоге из 136 метрик мы выбрали 20, а потом разделили их на четыре группы. Данные по метрикам мы выводим на дашборды, которые доступны любому сотруднику компании.

В следующей части статьи мы более подробно расскажем о метриках разработки и поддержки документации и как мы их считаем. Подпишитесь на новые комментарии — мы обязательно расскажем в них о выходе следующей части доклада.