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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Анализ кода CUBA Platform с помощью PVS-Studio

Для Java программистов существуют полезные инструменты, помогающие писать качественный код, например, мощная среда разработки IntelliJ IDEA, бесплатные анализаторы SpotBugs, PMD и другие. Всё это уже используется в разработке проекта CUBA Platform, и в этом обзоре найденных дефектов кода я расскажу, ...

[Из песочницы] Подготовка к промышленному производству ДО-РА

1. Транспортировка образцов после ядерной катастрофы на АЭС Фукусима в Японии и задумывался в виде гаджета – персонального дозиметра-радиометра работающего с одноименным ПО – DO-RA. Проект DO-RA DO-RA.com был рождён в марте 2011 г. Soft на любом смартфоне под мобильные ...