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

Меня зовут Алексей Чеканов, я CTO в Циан. Я расскажу, что такое хорошие и плохие метрики, в чём можно измерять эффективность IT.

Когда метрики — полезные

Метрики в компании нужны не только руководству: они могут помогать в работе и командам в IT. Я перечислю несколько таких положительных эффектов от метрик в компании.

Говорим на одном языке. У каждого участника процесса в IT — руководителей направлений, PO, тимлидов и команд — есть свои приоритеты, и порой сложно прийти к каким-то общим знаменателям, понятным всем. Метрики могут стать глобальными ориентирами, которые позволят синхронизировать приоритеты.

Что такое хорошо, а что такое плохо. Действительно, как дать команде понять, что её работа выполнена хорошо? Субъективные размытые оценки могут только запутать и дезориентировать. С помощью метрик мы даём ответы в цифрах на эти вопросы.

Допустим, нам важно, чтобы наше приложение работало стабильно. Но что значит «стабильно», как сделать, чтобы понимание стабильности было одинаковым и у руководителей, и у разработчиков, которые будут её добиваться? Ввести метрику. Например, пусть это будет метрика crash-free users, и можно установить её целевое значение — скажем, не меньше 99%. Это уже конкретная цифра, на которую можно равняться.

Следим за процессами. Метрики — это удобный способ контроля над процессами без погружения в детали. Например, когда мы внедряли функциональные тесты в качестве альтернативы unit-тестам (они позволяли дёшево и просто покрывать сложные бизнес-сценарии за меньшее количество усилий), нам было важно оценивать, как идёт внедрение изменений в 40 командах, и при этом не тратить на это много времени. Для этого мы задействовали метрику количества функциональных тестов и unit-тестов нарастающими итогами. По скорости прироста функциональных тестов и снижения скорости прироста unit-тестов эта метрика позволяет судить как новый процесс приживается.

Ещё с её помощью можно посмотреть в разрезе команд, где эти изменения ниже, чем в других, и уже предметно разбираться, почему новые правила не заходят. Правда, после того, как мы убедимся, что новый процесс завёлся, потребность в метрике отпадёт: иначе она может превратиться в «метрику тщеславия» (о том, что это такое, я подробнее расскажу ниже).

Переход к саморазвитию. Одно из ключевых преимуществ использования метрик в IT — можно задавать команде конечные цели (например, при внедрении девтестинга в качестве метрики ввести требование, чтобы не мене 50% задач тестировали сами разработчики), а не просто забрасывать их задачами по своему усмотрению. Это позволяет перейти от директивного управления командами на другой уровень управления через целеполагание. Имея перед глазами требуемый результат, команды могут сами для себя определять, как, в каком порядке и какие задачи им нужно решить. У тимлида и разработчиков появляется больше свободы для распределения своего времени, и в итоге в выигрыше и сами команды, и руководители.

Неправильные метрики

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

- Метрика не отвечает целям компании. У нас в Циан был такой случай: одна из команд работала во внутреннем стартапе, и её основная цель — найти product-market fit. Наша команда должна была бежать быстро: генерировать гипотезы и проверять пилоты. А мы требовали от неё выполнения стандартных метрик: например, нагружали их метриками количества ошибок и скоростью их исправления. При этом, как правило, такие эксперименты проводятся на ограниченной аудитории (а значит, импакт ошибок значительно меньше). И даже более того, эксперимент может откатиться как неуспешный и исправление всех багов будет пустой потерей времени.

- Метрики рассчитывают без учёта контекста. Оторванная от реальности метрика ни о чём не скажет, более того — может ввести в заблуждение. Например, мы хотим сравнить эффективность труда двух разработчиков. Вроде бы очевидно: чем багов меньше, тем специалист работает лучше… Но ведь люди могут быть в разных условиях: один пишет проект с нуля, и у него всё красиво и хорошо, а второй — легаси, и его работа — сплошное минное поле. Метрика должна учитывать контекст. Иначе если просто смотреть на количество багов, не принимая во внимание эти отличия, то можно сделать ошибочные выводы о неэффективности второго разработчика.

- Разработчикам не разъяснили пользу метрики. Например, просто установили ключевым показателем частоту релизов. Тогда команде не очень понятно, зачем достигать этих показателей, что это даст ей самой и компании в целом, соответственно, и мотивации их добиваться со всем рвением — нет. Так что разработчикам проще подстроиться под формальное соблюдение метрик. Если положено, к примеру, выкатывать 20 релизов в месяц, то сотрудники вскоре будут дробить свои релизы на более мелкие и искусственно увеличивать их количество для статистики, чтобы оставаться в зелёной зоне. При этом они вряд ли станут вникать, откуда взялось число 20. В результате цель метрики не будет достигнута.

- Метрика зависит от множества внешних факторов. Невозможно понять, влияют ли на неё действия команд. В нашей практике такой случай тоже есть. У нас была обобщённая метрика скорости ответа сайта. Её рассчитывают как среднее время до события dom interactive всех страниц, отнормированных по частоте запросов к этой странице. И если эта метрика пошла вниз, то стоило больших усилий разобраться, в чём причина — это бэк, фронт, проблема последней мили или что-то ещё. Сейчас эта метрика осталась, но только для меня и в качестве «общего градусника по больнице», а в командах вместо неё используем набор метрик, основанный на Core Web Vitals отдельно по каждому сервису.

- Метрика не приносит пользу. То есть метрику-то посчитать можно, но результаты нам не пригодятся. Типичный пример — количество тестов, который я упоминал ранее. Метрика количества функциональных тестов становится бесполезной: увеличивающееся количество тестов ничего не говорит о качестве нашего продукта. Можно ведь сделать больше, ещё больше тестов, но ничего не наловить. Получается такая «метрика тщеславия», искусственно раздутая, но совершенно бестолковая. А вот если подойти к метрике вдумчиво и начать учитывать количество найденных при этом багов, то из результатов можно уже извлечь полезные данные для анализа.

- Метрику неправильно рассчитывают, и она даёт искажённые результаты. Мы тоже не избежали этой ошибки, когда поначалу вводили метрику time to market. Не сразу мы разобрались, с какого места считать время разработки: там же несколько стадий. Сперва решили вести отсчёт от того момента, когда задача появлялась в бэклоге. Но потом оказалось, что иногда из-за разных приоритетов её разработка могла откладываться, а мы-то уже это время считаем. В результате было сложно выделить именно нужный отрезок времени и на его основе рассчитывать эффективность. Тем не менее, мы не стали отказываться от этой метрики, просто изменили подход — теперь мы отсчитываем время, когда уже взяли задачу в активную работу.

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

В нашей работе был пример и такой ошибки. Когда я ставил цель по лимиту на количество критических инцидентов несколько лет назад. Тогда уровень инцидентов был высоким — до 20 в месяц. Понятно, что такое положение дел было плохим, и я задал сразу желаемую цель — не больше 4 инцидентов в месяц. Цель поставили как годовую, и за этот отрезок времени она оказалась недостижимой. Так я попал в ловушку. С одной стороны, команда видела в итогах невыполненную цель, не понимала, как сейчас можно достичь таких показателей, и демотивировалась. С другой — я уже не мог снизить планку в таком чувствительном для нас вопросе.

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

Кстати, важно отличать метрику недостижимую от труднодостижимой, но всё же реальной. Во втором случае она, напротив, вполне может стать дополнительной мотивацией для команды собраться и «прыгнуть повыше». Такой вот эффект челленджа.

- Метрика волатильная. Выбирать метрику, значение которой часто меняется — плохая практика. Здесь можно вернуться к прошлому примеру про количество инцидентов. Сейчас, когда уровень инцидентов низкий, значение этой метрики уже не показывает тренд, а лишь незначительно колеблется от месяца к месяцу. В какой-то месяц — 1 инцидент, в следующий — 3, затем 2… По такому поведению метрики вы уже не можете сказать, в моменте у вас всё хорошо или плохо — нужны измерения за более длительный период.

Полезные метрики оценки IT, которые мы используем

Про вредные метрики мы поговорили, самое время перейти к полезным. Я расскажу о том наборе метрик, который считаю важным и сам использую в работе. Они помогают понять, что в IT в компании всё идёт хорошо. Для контекста: у нас в Циан работают 250 разработчиков и тестировщиков (40 команд). Так что вряд ли эти метрики пригодятся маленькому стартапу.

Итак, эти полезные метрики можно разделить на три категории:

• сервисные — как работает наш продукт, выдерживает ли он SLO;

• процессные — оценивают эффективность IT;

• ресурсные — показывают состояние команд и людей (спойлер — это самые ненадёжные метрики).

Рассмотрим их более пристально.

Сервисные метрики

• uptime — отношение успешных запросов к общему числу запросов на бэк;

• сrash-free users — доля пользователей, у которых мобильное приложение ни разу не упало за неделю;

• скорость отрисовки экранов — время отрисовки экранов на клиенте в разбивке по платформам;

• SLO по исправлению критичных багов — скорость исправления багов и инцидентов уровня крит и мейджор.

Про сервисные метрики ещё добавлю лайфхак: при установке целевых значений обращайте внимание, в каком перцентиле вы на них смотрите. Я для себя вывел, что смотреть в 100 перцентиле — плохая практика, потому что в этом случае так у вас будет отсутствовать бюджет ошибок. Например, вы хотите достичь скорости отрисовки экрана меньше чем за 2 секунды. Такая цель будет просто невыполнима, и вы не увидите положительных или отрицательных изменений. Поэтому большинство таких метрик я рассматриваю в p50, p90 и p99 перцентилях. Это позволяет получить более полную картину.

Процессные метрики

• количество критичных инцидентов на проде — да, та самая метрика. Показывает, сколько критов случилось за определённый период времени;

• change fail rate — отношение количества найденных ошибок к зарелизенным задачам. Вместе с предыдущей метрикой они позволяют понять, насколько наши IT-процессы способны поставлять качественные продукты;

• time to market — время от момента, когда проект взяли в работу, до его релиза;

• deployment frequency — количество выпущенных задач с кодом за 4 недели, делённое на количество разработчиков, сделавших эти задачи. Ведь нам, помимо качества, важно ещё оценивать и скорость, с которой мы бежим, а также насколько быстро мы способны выпускать новые продукты. А ещё — понимать, что не накапливаем незарелизенные изменения в долгоживущих ветках.

Ну и возвращаясь к извечному вопросу «как оценивать разработку». У меня есть пара метрик, которые позволят оценивать её КПД:

• delivery time — время от перевода задачи в ревью до её появления на проде. По ней мы понимаем и таргетируем дополнительное время на CI/CD процессы, призванные обеспечить надлежащее качество при высоком темпе разработки;

• reopen rate — количество переоткрываемых задач на этапе тестирования.

Ресурсные метрики

Основная цель этих метрик — отобразить здоровье команд. Звучит просто, но на деле это самые сложные для сбора метрики, а также самые зашумлённые. В отличие от сервисных и процессных метрик, здесь приходится получать данные через различные опросы сотрудников. Утомлять специалистов бесконечными опросами тоже нежелательно, поэтому мы пришли к практике проведения пульс-опросов. В течение недели спрашиваем в Slack по одному вопросу, относящемуся к одной метрике, со шкалой оценки 1–4. Поставить оценку просто и уже вошло в привычку. Вот для примера вопросы из блока понятности и принятия продуктовых целей команды:

• Прогресс по целям продукта в команде понятен и прозрачен. Мы всегда понимаем, где мы сейчас находимся относительно целей и почему.

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

С помощью таких опросов мы собираем данные о знании и об отношении людей к таким темам, как:

• общие IT-цели;

• продуктовые цели команды;

• процессы внутри команды;

• техническое развитие;

• актуальность технического стека;

• работа гильдий.

Напомню, что из-за особенностей сбора такие метрики имеют разброс, так что тут важен не столько абсолютный показатель, сколько тренд в течение длительного времени.

Вместо заключения

Какого-то универсального полезного набора метрик не существует — так или иначе. Подбирать их вам придётся с учётом особенностей разработки в вашей компании.

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

• Но как и у любого инструмента, у метрик есть свои ограничения. Остерегайтесь прихода к карго-культу — подумайте о том, что вы хотите измерять и зачем, прежде чем вводить какой-либо показатель.

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

И всё же: не бойтесь прибегать к метрикам, пользуйтесь ими в IT. Задавая цели и начиная измерять свою работу и работу команд с помощью метрик, вы даёте командам большую степень свободы. Они переходят с уровня задач на уровень целей и сами уже начинают думать, как им к этим целям прийти, и решают, что для них более важно. А это уже качественно другой и более эффективный подход к разработке, чем директивное управление. В конце концов, хороший руководитель должен стремиться к росту команды до состояния, когда ему достаточно давать общую картину и стратегические цели, а не расписывать таски в Jira.