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

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

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



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



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


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


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


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


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



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


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


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


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


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


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



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


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


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



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


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


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


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

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


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


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


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


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


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



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


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

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


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


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



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


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

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


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



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

Источник: https://habr.com/ru/company/yandex/blog/443900/#habracut

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

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

CMake — это кроссплатформенная система автоматизации сборки проектов. Эта система намного старше, чем статический анализатор кода PVS-Studio, при этом ещё никто не попробовал применить его к ко...
В последнее время стараюсь раз в неделю скачать и посмотреть новую мобильную игру, и про себя отметил что у многих проектов плохо реализованы — отзывчивость интерфейса, микроанимации, пропущены л...
Сегодня язык Go широко используется для разработки распределённых и высоконагруженных приложений. Мы собрали для вас подборку видео, в основном с наших митапов, в которых разбираются преимуще...
Одной из «киллер-фич» 12й версии Битрикса была объявлена возможность отдавать статические файлы из CDN, тем самым увеличивая скорость работы сайта. Попробуем оценить практический выигрыш от использова...
Сегодня мы поговорим о перспективах становления Битрикс-разработчика и об этапах этого пути. Статья не претендует на абсолютную истину, но даёт жизненные ориентиры.