Выбор правильных метрик для вашего проекта

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

Текущая фаза:
Объявлены результаты. Смотрите хронологию .

Изложите свою проблему

Прежде чем приступить к выбору метрики, убедитесь, что вы хорошо понимаете проблему, которую пытаетесь решить. Будьте как можно более конкретными.

  • «Объединение запросов на получение нашей документации занимает слишком много времени. Авторы сдаются и уходят».
  • «Мы видим, что слишком много проблем открыто, чтобы помочь понять коды ошибок».
  • «Наш конвейер CI/CD ненадежен. Слишком много тестов терпят неудачу по плохо понятным причинам».
  • «На наших еженедельных встречах люди кажутся сварливыми».

Разработать гипотезу

Ищите причину и следствие. Что может быть причиной описанной вами проблемы? Имейте в виду, что проблемы могут иметь несколько или частично совпадающие причины.

  • «Объединение запросов на включение в документацию по адаптации занимает так много времени, потому что у нас нет четкого руководства по стилю. Рецензенты либо откладывают рассмотрение PR, потому что не знают, что делать, либо обсуждают с участниками форматирование».
  • «Пользователям приходится открывать проблемы, потому что они не могут найти информацию о кодах ошибок в документации».
  • «Наши тесты CI/CD терпят неудачу, потому что мы сталкиваемся с ограничениями плана и тайм-аутами нашего провайдера».
  • «Люди раздражаются на наших еженедельных встречах, потому что встречи проводятся в 5:30 утра по их часовому поясу».

Предложить решение

Можно ли решить эту проблему с помощью новой или более качественной документации ?

  • «Если бы у нас было руководство по стилю, коммиттеры могли бы проверить его перед отправкой своих запросов. Рецензенты будут знать, что проверять. Рецензентам и авторам не придется спорить о форматировании, тоне и стиле».
  • «Если бы у нас была документация по кодам ошибок, пользователи могли бы найти ответы там, а не открывать проблемы».
  • «Хм, не похоже, что лучшая документация решит нашу проблему CI/CD».
  • «Мы могли бы начинать каждую встречу с шутки-тук-тук! Создание сборника шуток поможет нам начинать наши встречи с улыбки».

Получите конкретику

Можете ли вы количественно оценить проблему?

  • «Что на самом деле означает фраза «объединение PR занимает слишком много времени»? Два месяца? Две недели? Как долго участники будут ждать проверки, прежде чем сдаться?»
  • «Сколько проблем, связанных с кодами ошибок, являются «слишком многочисленными проблемами»?»
  • «Хммм… насколько сварливым может быть «слишком сварливый»?»

Проверить измеримость

Как бы вы проверили предложенную метрику? Можно ли его легко и точно измерить? Зависит ли измерение от того, кто его проводит?

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

Добавьте дополнительный показатель

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

  • «Более длинные PR требуют больше времени для рассмотрения; у нас должны быть разные пороги для разных размеров ОР. Мы хотим измерить время, необходимое для слияния малых, средних, крупных и гигантских PR».
  • «Мы могли бы проверить, сколько посещений получает наша документация по кодам ошибок, и посмотреть, коррелирует ли это число с меньшим количеством открытых проблем».

Выберите период времени

  • «Мы считаем, что две недели — разумный срок для объединения малых и средних ОР; и все ПР должны быть объединены в течение месяца. Поэтому мы будем проводить измерения каждые две недели».
  • «Не имеет смысла ежедневно обновлять количество проблем, связанных с кодами ошибок, поскольку обычное время решения проблемы составляет одну неделю. Мы будем измерять его еженедельно».

Назначать цели

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

  • «Если бы мы достигли нашей цели по закрытию каждого нового заказа менее чем за месяц, это было бы успехом. Если бы наше среднее время закрытия крупных заявок сократилось на две недели, это было бы огромным успехом».
  • «В идеале мы не должны видеть новых проблем, связанных с ошибками. Но мы бы сочли наш проект успешным, если бы увидели снижение на 50% количества открытых проблем, связанных с ошибками».