Рассказывает Светлана Каюшина, руководитель отдела документирования и локализации.
Наш отдел документирования прошел несколько этапов развития. Сначала был технический писатель, выполнявший задачи отдельного заказчика. Потом образовалась группа технических писателей, которая решала ограниченный набор задач. Сейчас у нас большой производственный отдел — он полностью удовлетворяет потребности компании в документировании.
На каждом этапе изменялись требования к работе отдела и появлялись новые метрики для измерения качества документации и сервиса по предоставлению услуг документирования. Метрики помогают нам улучшать продукт, процессы и качество, а также вовремя информируют о сбоях.
Первые метрики
Первый технический писатель понадобился Яндексу для документирования технологии, которой пользовались почти все разработчики. Информацию о ней передавали друг другу устно, поэтому часть неизбежно терялась или искажалась.
Документацию написали, заказчики были довольны, поэтому мы решили освоить другие направления. Начали с описания сервисов, которые критически важны для бизнеса: ими пользуется много сотрудников компании.
На начальном этапе заказчики ставили нам задачу задокументировать технологию. Единственной метрикой было наличие документации: она либо написана, либо нет. Когда технический писатель был один, качество оценивал сам заказчик. Когда писателей стало больше, к заказчикам присоединились консультанты по сервису, а мы проверяли качество документации внутри отдела.
Поток задач постоянно увеличивался, поэтому возникла проблема с поддержанием единого уровня качества. Экспертная оценка довольно субъективна, а нам хотелось, чтобы она была независимой.
Кроме того, заказчики приходили с задачами разной сложности: например, зафиксировать информацию, которую знал один человек, или описать сложную технологию для разработки наших внешних продуктов.
Всё это создавало определенные проблемы, поэтому нам понадобилась система приоритезации задач и оценки качества документации.
Метрики внутренней документации
Мы начали собирать отзывы внутренних заказчиков и читателей, которые использовали документацию для решения своих задач. Например, заказчик мог сказать нам, что перестал 10 часов в неделю консультировать коллег и теперь продуктивнее делает основную работу.
У читателей мы спрашивали, насколько хорошо документация помогает им решать задачи. Отслеживали посещаемость: сколько пользователей в неделю обращается к документам. Если больше определенного числа, значит, документ стоит поддерживать.
Этот метод требовал существенных затрат и прямого выхода на заказчика. В условиях массового использования документации он оказался слишком дорогим и слабо применимым. Поэтому когда мы перешли к разработке документации для внешних пользователей, появились проблемы.
Аудитория выросла, у нас не было к ней прямого доступа. Мы отслеживали отзывы в соцсетях и запросы в техподдержку, но этого было недостаточно. Пришлось строить гипотезы, кто наш пользователь, чтобы максимально удовлетворять его потребности. Для оценки поведения пользователей и эффективности продукта мы использовали Яндекс.Метрику.
Развитие системы метрик для внешней документации
Задачи бизнеса почти не менялись, но появилось новое условие: мы должны были успевать подготовить документацию к официальному релизу. Теперь нам требовалось укладываться в сроки.
Мы продолжали использовать прежние метрики, но к ним добавились посещаемость сервиса документации и отказы. Отслеживали их как для сервиса в целом, так и по отдельным документам.
Технические писатели для улучшения качества документации использовали дополнительные данные:
- анализ поведения пользователей на сервисе,
- тепловую карту кликов,
- вебвизор,
- оценку поисковых запросов и т.д.
Дальше мы перешли к этапу массового производства и стали сервисом по предоставлению услуг документирования.
Метрики массового производства документации
На этом этапе у заказчиков и руководства появились новые требования к отделу документации.
Заказчики интересовались сроками выполнения и оценкой трудоемкости задач. Например, они спрашивали, почему мы пишем документ две недели, а не два дня. При этом от нас ждали высокого качества.
Руководство интересовалось обоснованием затрат. Чтобы нанять в отдел человека, мы должны были это аргументировать. Например, мы могли показать измеримую пользу документа, если он решает проблемы не пары пользователей, а нескольких тысяч, и уменьшает нагрузку на техподдержку.
Наших статистических метрик уже не хватало, чтобы отвечать на эти вопросы.
В условиях массового производства у нас есть несколько основных задач:
- документировать технологии,
- успевать к релизам,
- обеспечивать высокий уровень качества.
Это требует комплексного подхода ко всему, чем мы занимаемся.
Кроме того, мы, как сервис, должны оценивать качество своих услуг. Нам нужно понимать, насколько пользователи удовлетворены и какую выгоду приносит документация высокого качества.
Чтобы разработать новую систему оценки, мы провели исследование и проанализировали большое количество источников: всего нашли 136 метрик. Кроме того, что их слишком много, не все из них легко измерить и не все нам нужны. Поэтому мы выбрали метрики, которые подходили под наши условия.
Нас интересовали следующие аспекты оценки:
- Проектные и бизнес-метрики — показатели эффективности качества сервиса в целом. Они нужны для повышения удовлетворенности заказчика и для прогнозирования ресурсов отдела на выполнение всех задач.
- Метрики оценки качества документов для повышения удовлетворенности пользователя.
При выборе метрик мы учитывали сложность и стоимость расчета метрики. Еще для нас важно, чтобы суть и подсчет метрики были понятны людям, которые не погружены в нюансы нашего производственного процесса.
В итоге из 136 метрик мы выбрали 20, а потом разделили их на четыре группы. Данные по метрикам мы выводим на дашборды, которые доступны любому сотруднику компании.
В следующей части статьи мы более подробно расскажем о метриках разработки и поддержки документации и как мы их считаем. Подпишитесь на новые комментарии — мы обязательно расскажем в них о выходе следующей части доклада.
