Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
52 lines (41 sloc) 9.34 KB

Конспект митапа Мини-гипербатон Метрики эффективности документации

Ссылка на программу мероприятия

Александр Лебедев (Философт) Оценка трудозатрат на написание документации

  • Документация для бизнеса – это черный ящик, нужно уметь обосновать сроки и трудозатраты.
  • “Пирамида Лебедева” - известные характеристики будущей документации: срок, объем, комплектность (эти характеристики относятся к продуктам), уровень, качество, сложность предмета, сложность документации и требования к приемке (эти характеристики относятся к проекту).
  • Зачастую не все из этих характеристик известны заранее, тогда можно применить индуктивный (знаем уровень качества, сложность продукта) или дедуктивный подход (если известны только срок и комплектность).
  • В случае индуктивного подхода мы делим докумен на части, секции, страницы, этапы его разработки (сбор информации, написание, ревью) и строим диаграмму Ганта, оцениваем все этапы.
  • Если не удается – просим посмотреть систему, продукт, делим его на сценарии.
  • В дедуктивном подходе идем от договора, перечисляем все виды документов и делим на имеющихся писателей.
  • Сроки нужны не только для обоснования, но и для организации работ, планирования.
  • Оценку нужно грамотно продать и защитить.

Ссылка на презентацию.

Светлана Каюшина, Юрий Никулин, Антон Литвинов (Яндекс) Как измерить качество документации и эффективность ее разработки

  • Метрики – это не самоцель, они призваны улучшать продукт и сообщать о сбоях.
  • В Яндексе менялись условия разработки документации, начиная с одного писателя на внутреннюю документацию и до массового потока документирования (сейчас в отделе 37 писателей).
  • После выхода на массовое производство потребовалось делать обоснование для менеджеров, соглашение об уровне качестве сервиса (метрики как SLA).
  • Проанализировали текущий опыт и выделили 136 метрик, которые можно измерять. Много. Выбрали подходящие под свои реалии.
  • Обязательно считайте стоимость расчета метрики, если она выше, чем затраты ресурсов на документацию – не используйте. Например, мерять процент ошибок затратно.
  • Все данные метрик по командам и документам выводятся на публичных дэшбордах в отделе.
  • Нет метрик по людям, это не соревнование. Не KPI.
  • Метрики, которые они используют, берутся из нескольких источников. Во-первых, это Яндекс Метрика, просмотры, клики, тепловые карты, вебвизор. Во-вторых, это метрики из Яндекс.трекера (трекер задач) и в-третьих, фидбек от пользователей (КСАТ), форма комментариев и т.д.
  • В Яндекс.Трекере берутся метрики по 1. времени принятия задачи (документа) в работу 2. количество дней на выполнение 3. время, проведенное в бэклоге (техдолг). 4. метрики по отдельным этапам задачи – сбор информации, написание, ревью.
  • Меряют общий показатель + 50-й и 80-й персентиль.
  • Для визуализации используют js библиотеку.
  • Для метрик по фидбеку пользователей поставили дополнительное условие – снизить количество бесполезного фидбека, когда пользователи пишут в форме смайлики, точки, пропуски.
  • Меняют поисковость, ищут и находят. Как? С помощью краудсорсинг ресурса Яндекс.Толока (где внешние пользователи за небольшие деньги делают задания по разметке страниц, картинок, текстов). Там создают задания, например, “Найди в документации как решить такую-то задачу”, отметь за сколько кликов и времени, “Найди ошибку в документации”.
  • С результатами работают, чтобы упростить поиск документов, передвигают секции, улучшают поисковую выдачу.
  • До этого было 29 процентов бесполезного фидбека (сентябрь 2017), стало – 10 процентов к октябрю 2018. Целевой показатель – не более 20.
  • Если растет, идет несколько итераций с наиболее “бесполезными”.
  • Меряют точность – это доля сообщений, когда пишут о том, что в справке уже есть и полноту – это доля сообщений, когда пишут о том, чего в справке нет.
  • Меряют доступность форм обратной связи с помощью Толоки, создают задание “Оставь сообщение об ошибке в форме”, медиана по доступности.

Ссылка на презентации

Анастасия Агеева (Intel) Автоматизация выгрузки данных из Веб-Аналитики

  • Раньше выгрузки из Google Analitics вытаскивались перловыми скриптами + макросы в Excel, затем их нужно было соединять с данными из внутренних систем, метаданными Drupal (топики в документах), данными о скачиваниях и т.д. за тот же период.
  • Решили настроить автоматические выгрузки и матчинг отчетов в единый UI.
  • Подняли SQL базу, Решение сделали на основе Google Analytics API, MS Integrations Services, SQL запросов, MS Reporting.
  • Теперь строится отчет во внутренней системе “Профиль продукта”: топ 20 самых просматриваемых топиков, топ скачиваний документов, статистика по каждому документу и секциям внутри документа, удобно для справочной документации, можно поменять расположение секций в документе.
  • Обратная связь пользователей (КСАТ) по категориям, по срезам, по средним просмотрам.
  • Как это помогло: оказалось, что есть большая доля пользователей, которые скачивают справку в PDF, хотя от PDF хотели отказаться, а вот ZIP почти никто не скачивает, его теперь делают только для мажорных версий.
  • Также это правильно распределить топики и секции по структуре документов, поднять более популярные секции вверх, сделать их более искабельными.

Ссылка на презентацию

You can’t perform that action at this time.