Как мы измеряем качество и эффективность разработки документации. Предыстория и основы. Доклад Яндекса

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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



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



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


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


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


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


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



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


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


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


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


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


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



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


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


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



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


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


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


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

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


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


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


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


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


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



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


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

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


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


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



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


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

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


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



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

Интересные статьи

Интересные статьи

В декабре мы провели очередную HolyJS, и поначалу видеозаписи её докладов были доступны только для зрителей, а теперь открыты для всех. Для Хабра мы традиционно сделали подборку из 10 доклад...
В первый день весны (или пятый месяц зимы, кому как) закончилась подача заявок на KnowledgeConf — конференцию про управление знаниями в IT компаниях. Признаться, итоги Call for Papers превзош...
В 2018-м App Store и Google Play исполнилось 10 лет. За это десятилетие некоторые приложения, начинавшиеся как маленькие стартапы, разрослись в гигантские проекты — а по пути преодолели множе...
Всё старое в один прекрасный день снова становится новым. Наступает время, когда даже опытные программисты наступают на те же грабли. Невозможно перечислить все «неписаные правила» любой дисципли...
Сегодня язык Go широко используется для разработки распределённых и высоконагруженных приложений. Мы собрали для вас подборку видео, в основном с наших митапов, в которых разбираются преимуще...