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

Говорить я буду исключительно про продуктовые IT-компании.

Начнём с определения:

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

То есть метрика это показания прибора, когда вы едете на машине, скорость, обороты двигателя, температура масла это всё метрики.

Для бизнеса, команды, сотрудника смысл примерно такой же — текущие показатели успешности, эффективности, полезности всего бизнеса и его подразделений.

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

Бизнесовые метрики

И так, начнём с метрик бизнеса, по сути денег.

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

Наша основная метрика лежит на поверхности, это чистая прибыль, если у нас есть прибыль — уже хорошо, если она растет — еще лучше, если растет быстрее рынка и/или быстрее конкурентов — прекрасно. Получается уже составная метрика: значение прибыли + ее изменение во времени, Достаточно ли одной такой метрики? Ну, бенефициару, не очень погруженному в бизнес, вероятно, может быть достаточно (“деньги мне приносите, без разницы как, и больше, БОЛЬШЕ!”), но людям больше в бизнес погруженным такой информации будет недостаточно — они будут потеть холодным потом, не вполне понимая какие риски контору окутывают и какие у них перспективы, и задаваясь вопросами: “Будет ли прибыль в следующем квартале больше и будет ли вообще?”, “А через год?”, “Всё ли мы правильно делаем?”, “Не утопят ли нас конкуренты через пару лет?” и т. п., в общем полный швах, работа вслепую и сплошные нервы. Давайте в этом месте приложим список ходовых бизнесовых метрик:

LTV (Lifetime Value): общая прибыль с одного клиента за все время сотрудничества.
Выручка на сотрудника (Revenue per Employee): общая выручка, деленная на число работников.
Выручка (Revenue): общий объем поступлений за период.
Прибыль (Чистая/Валовая): разница между доходами и затратами.
Рентабельность (ROI): показатель того, насколько доход превышает расходы, например, эффективность вложений в маркетинг.
ROE (Return on Equity): это коэффициент рентабельности собственного капитала, который показывает, сколько чистой прибыли получает компания на каждый вложенный рубль.
EBITDA: прибыль до вычета процентов, налогов, износа и амортизации.
ARPU: показывает выручку, которую компания в среднем получает с одного пользователя продукта за конкретный период времени.

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

Зачем всё это считать?

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

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

Возвращаясь к аналогии с автомобилем, если вы профи, то вам нужно больше данных. Современный болид Формулы 1 оснащен более чем 300 датчиками, которые генерируют миллионы точек данных в секунду. Вся эта информация передается в реальном времени инженерам на пит-лейн через систему телеметрии для максимизации скорости и предотвращения поломок.

Топ-менеджмент современной крепкой компании это как команда Формулы 1 и используй они всего 1 метрику чистой прибыли вряд ли компания смогла бы остаться на плаву.

Давайте пойдём дальше.

HR-метрики

Оценивают эффективность работы с персоналом.

Текучесть кадров: процент уволившихся сотрудников от общего штата за период.
Стоимость закрытия вакансии: расходы на поиск и наем одного специалиста.
Выработка на одного сотрудника: отношение выручки к количеству штатных единиц.

Маркетинговые метрики

CTR (Click-Through Rate) — показатель кликабельности объявлений.
CPC (Cost Per Click) — стоимость одного клика по рекламе.
BR (Bounce Rate) — процент пользователей, которые ушли с сайта сразу после первой страницы.
CR (Conversion Rate) — коэффициент конверсии посетителей в целевые действия (заявки, покупки).
CPL (Cost Per Lead) — стоимость привлечения одной заявки или контакта потенциального клиента.
CAC (Customer Acquisition Cost) — итоговая стоимость привлечения одного платящего клиента.
ROMI (Return on Marketing Investment) — окупаемость маркетинговых инвестиций.

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

Продуктовые метрики

Напомню, что сегодня мы говорим только о продуктовых IT-компаниях, соответственно, продукт — это краеугольный камень нашего бизнеса, то что мы продаём нашему клиенту. У одной компании может быть много продуктов. Разумеется работу продуктов нужно — глядя на экран смартфона (если наш продукт живёт в мобильном приложении) и в бизнесовые показатели мы только косвенно можем понять хороший ли у нас продукт и в правильном ли направлении он развивается — возможно, продукт у нас херовый, но мы умудрились первыми выйти на рынок и поэтому пользователи страдают, но всё таки продолжают “есть кактус”. Чтобы глубже понять состояние наших продуктов есть специализированные продуктовые метрики:

Retention Rate — доля вернувшихся пользователей за период.
DAU / WAU / MAU — количество уникальных пользователей, проявивших активность в приложении или на сайте за день/неделю/месяц.
Churn rate (отток клиентов) — это процент клиентов, прекративших пользоваться услугами компании за определенный период. Высокий уровень оттока напрямую снижает прибыль и сигнализирует о проблемах с качеством продукта или конкуренцией. Метрика ключевая для SaaS, телекома и подписочных сервисов.

Основная формула расчета:

NPS (Net Promoter Score) — это индекс потребительской лояльности, который показывает, насколько клиенты готовы рекомендовать вашу компанию, продукт или услугу своим знакомым.

Метрика основана на одном ключевом вопросе: «Оцените по шкале от 0 до 10 вероятность того, что вы порекомендуете нас другу или коллеге?».

Разумеется это тоже далеко не все придуманные продуктовые метрики.

Что такое фреймворк HEART?

HEART — это аббревиатура, которая расшифровывается как happiness (счастье), engagement (вовлеченность), adoption (принятие), retention (удержание) ,task success (успех задачи). Это в общем-то широко используемый набор метрик, упакованных в характеристики, которыми можно хорошо “простучать” продукт, если использовать его на достаточно значительном промежутке времени. Давайте разберем значение каждой буквы подробнее.

Счастье (Happiness)

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

Вовлеченность (Engagement)

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

Принятие (Adoption)

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

Удержание (Retention)

Удержание означает сохранение существующих пользователей в течение определенного времени. Это время может составлять неделю, месяц или год – все зависит от продукта. Простым примером удержания может быть количество активных пользователей за определенный период, которые присутствуют на сайте N времени. Это также может быть отток (неудача в удержании). Если ваша команда запускает новую фичу, удержание показывает уровень успеха этого обновления с точки зрения пользователя.

Успех задачи (Task success)

Успешность задачи связана с теми областями программного обеспечения, которые ориентированы на выполнение (например, поиск или поток загрузки). Примерами этого показателя могут быть эффективность, результативность и количество ошибок.

Источник: https://productlab.ru/blog/heart-framework

Метод AARRR

Еще один фреймворк, помогающий управлять продуктом через метрики.

Каждое действие клиента можно разложить по полочкам. Именно в этом и заключается сила AARRR — процесс делит путь пользователя на пять последовательных этапов: Acquisition (привлечение), Activation (активация), Retention (удержание), Revenue (доход) и Referral (рекомендации).

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

Этап 1. Acquisition — Привлечение

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

Задача этого этапа — понять, откуда приходят пользователи, сколько это стоит и насколько эти каналы эффективны. Без этого невозможно объективно оценить работу маркетинга и выбрать те точки роста, которые действительно работают, а не просто «греют воздух».

Какие метрики важны на этапе привлечения:

Количество новых посетителей за период (неделя, месяц).
Стоимость привлечения одного клиента (CAC — Customer Acquisition Cost).
Конверсия из показа в клик (CTR).
Конверсия из клика в переход на сайт.
Доля органического трафика vs платного.
Вовлеченность по каналам (глубина просмотра, отказ от дальнейших действий).

Фреймворк AARRR помогает увидеть это сразу. Привлечение ради галочки — не работает. Важно не просто привести клиента, а привести своего клиента.

Этап 2. Activation — Активация

Клиент пришел. Что дальше?

На этапе активации важно, чтобы человек не просто зашел, а почувствовал ценность продукта. Не на словах, а на опыте. Чтобы у него возникло: «О! Это мне подходит» — именно в этот момент и происходит первая настоящая связь между клиентом и вашим продуктом.

Активация может выглядеть по-разному: регистрация, подписка на рассылку, добавление товара в корзину, скачивание файла, просмотр трех страниц каталога. Все зависит от того, что именно вы считаете «сигналом вовлечения». Главное — определить, что для вас значит “клиент активировался”.

Какие метрики важны на этапе активации:

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

Привлечь внимание — половина дела. Но если человек не почувствовал ценность продукта в первые минуты — вы его теряете. Именно на этапе активации происходит главное: переход от интереса к доверию.

Активация — это как первое свидание. Впечатление формируется быстро, а шансов на второй шанс может и не быть.

Этап 3. Retention — Удержание

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

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

Какие метрики важны на этапе удержания:

Retention Rate — доля вернувшихся пользователей за период.
DAU / WAU / MAU — ежедневные, еженедельные и ежемесячные активные пользователи.
Частота повторных визитов или заказов.
Уровень оттока (churn rate).
Поведение подписчиков: кликают ли по рассылке, реагируют ли на push-уведомления.

Маркетплейс Wildberries активно инвестирует в инструменты возврата клиентов. Вот как выглядит их система удержания:

Push-уведомления с персональными подборками.
Персонализированные скидки на товары из вишлиста.
Автоматические email-цепочки с напоминаниями о незавершенных заказах.
Геймификация в приложении: бонусы, промокоды, акции с таймерами.

Удержание — это про отношения с клиентом, а не про цифры. Но именно цифры помогут вам понять, насколько эти отношения живые.

Этап 4. Revenue — Доход

Если вы привлекли клиента, активировали его и смогли удержать — пора задать главный вопрос: а зарабатывает ли продукт?

Доход — это не только выручка. Это понимание, как именно продукт приносит деньги, через какие действия клиента и с какой маржой. Вы можете иметь тысячи пользователей, но при этом не пройти в точку безубыточности. Или, наоборот, сдержанно расти, но держать здоровую экономику.

Какие метрики важны на этапе дохода:

ARPU (Average Revenue Per User) — средний доход на пользователя.
AOV (Average Order Value) — средний чек.
LTV (Lifetime Value) — сколько приносит клиент за все время жизни.
CAC (Customer Acquisition Cost) — стоимость привлечения клиента.
Payback Period — срок окупаемости затрат на привлечение.
Количество оплат / подписок / апгрейдов.

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

Фреймворк AARRR позволяет не просто считать выручку, а понимать, откуда она приходит, какие каналы эффективны, какие сегменты платят чаще, а какие — “висят балластом”.

Монетизация — это момент истины. Если на этом этапе ничего не происходит, все до него было иллюзией.

Этап 5. Referral — Рекомендации

Самый надежный способ расти — когда вас рекомендуют. На этом этапе важно понять: насколько люди готовы рекомендовать продукт другим. И не по принуждению (например, за бонус), а потому что действительно считают его полезным, удобным, достойным доверия.

Это уже не маркетинг — это показатель продуктовой зрелости. Если сарафанное радио работает, значит, прошлые этапы воронки AARRR пройдены честно и эффективно.

Какие метрики отслеживаются:

NPS (Net Promoter Score) — насколько клиенты готовы рекомендовать ваш продукт.
Количество упоминаний в соцсетях, на форумах, в отзывах.
Привлеченные по реферальным ссылкам или промокодам.
Количество переходов и регистраций из личных рекомендаций.
Вирусный коэффициент (сколько новых пользователей приводит один текущий).

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

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

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

Рекомендации: как внедрить фреймворк AARRR в работу

Чтобы фреймворк AARRR не остался просто теорией, его нужно встроить в ежедневную работу продукта, маркетинга и продаж.

Выберите один этап, который сейчас «проседает» больше всего. Например, у вас хорошие регистрации, но мало возвратов — значит, начните с ретеншена. Постепенно можно охватить все пять.
Не считайте все подряд. На каждом уровне важно выбрать 1–3 ключевых показателя, которые действительно отражают поведение клиента. Лучше меньше, но регулярно отслеживать и обсуждать.
Решения «на глаз» — главный враг роста. Если кажется, что «клиенты нас любят», но рекомендации не растут — это звоночек. Работайте с аналитикой, сравнивайте цифры с прошлыми периодами и бенчмарками.

Источник: https://productlab.ru/blog/aarrr-model-voronka-prodazh

Технические метрики

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

Вот такое определение выдаёт ИИ:

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

Мне подходит)

Я бы поделил их на 2 класса:

Сугубо технические метрики: время отклика (latency), трафик (RPS), количество ошибок (Error rates) и использование ресурсов (память, процессор), SLI по ошибкам, latency и доступности, покрытие автотестами.

Не уверен что нужно тут что-то дополнительно расписывать, но учитывая что все путают SLI с SLO и SLA эти показатели распишу.

SLI (Service Level Indicator) — это конкретный измеряемый показатель: например, доля успешных HTTP-запросов или время отклика (latency);
SLO (Service Level Objective) — это целевое значение или диапазон для метрики SLI: например, 99.9% всех запросов должны обрабатываться менее чем за 300 мс.
SLA (Service Level Agreement) — это юридическое или бизнес-соглашение с клиентом, включающее штрафы за невыполнение SLO: например, если SLO доступности падает ниже 99.9%, мы возвращаем клиенту 10% от месячной оплаты.

Источник: https://slurm.io/blog/metriki-sli-slo-sla

Что значит “SLI по ошибкам, latency и доступности”:

SLI по ошибкам — это доля “пятисоток” в потоке запросов, иногда имеет смысл мерить и “четырёхсотки”;
SLI по latency — доля “тормозящих” запросов, порог после которого запрос стоит считать тормознутым выбирается индивидуально, но, как известно, если задержка в UI больше 300 мс, то пользователь её замечает;
SLI по доступности — более низкоуровневое понятие, доля времени когда инфраструктура работает и что-то возвращает;
Code Coverage — процент кода, покрытого автотестами; это отдельная тема для разговора, но если коротко, но чаще всего увеличения процента покрытия позитивно влияет на скорость разработки и качество продукта, пожалуй, про это нужно написать отдельный пост.

Все эти показатели заметно влияют на пользовательский опыт и косвенно на бизнес-результаты.

DORA (более близкие к операционке метрики):

Частота развертывания (Deployment Frequency — DF): как часто код успешно деплоится в продакшн. Высокая частота указывает на меньший размер изменений и снижение рисков.
Время выполнения изменений (Lead Time for Changes — LTFC): время от фиксации кода (commit) до его успешной работы на проде. Измеряет скорость цикла разработки.
Время восстановления сервиса (Mean Time to Restore — MTTR): время, необходимое для восстановления обслуживания после сбоя или инцидента.
Частота отказов при внесении изменений (Change Failure Rate — CFR): процент деплоев, вызвавших сбой, требующий немедленного исправления (например, откат, патч).

Мне еще нравится:

Rework rate (RR): доля незапланированных развертываний, вызванных инцидентами в production окружении.

Это скорее метрики процесса разработки: DF, LTFC зависят больше от того как выстроена доставка ценности на прод, однако, и они и, тем более, MTTR, CFR и RR сильно зависят как качества работы команд разработки, вовлеченности, порога входа, документации. В общем метрики комплексные, позволяющие дать много пищи для размышлений.

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

Метрики команды разработки

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

Что делать с неэффективными командами это тема для отдельной статьи, здесь же давайте рассмотрим метрики, по которым можно понять что с командой что-то не так:

Cycle Time (время цикла): время от начала работы над задачей до ее завершения, зависит от процесса, но большие нетипичные значения могут указывать на то, что задачи застревают на одном или нескольких этапах.
Lead Time (время выполнения): время от появления идеи или заявки до момента, когда она попадает к пользователю, не видел когда эта метрики бывает полезна — идеи появляются постоянно, оформляются как задачи, чтобы не забыть и могут висеть в бэклоге долго, но метрика довольно популярная. В общем я не вижу в ней большой ценности, но вероятно, тоже зависит от процесса.
Velocity (скорость команды): объем работы (обычно в Story Points), который команда закрывает за интервал времени, могут быть выбросы в зависимости от объективных факторов, но, по опыту, если метрика постоянно сильно скачет, то какая-то проблема точно есть, правда не факт что серьёзная.
Bugs Reopen Rate: частота возврата задач на доработку после их «закрытия», чаще всего указывает на проблемы с постановкой задач и/или качеством, но всегда нужно разбираться в конкретной ситуации.
Time in Status: сколько времени задачи проводят на каждом этапе работы, иногда выбивающееся из нормы значение это просто неаккуратное обращение с багтрекером, но бывают и проблемы серьёзнее, например, когда задачи застревают на ревью. В общем может указывать где сейчас bottleneck.
Bug Escape Rate: доля багов, которые прошли через разработку, тестирование и code review — и всё равно попали в прод. Считается как: (баги в проде / все найденные баги) × 100%. Высокий показатель говорит о слабом покрытии тестами, формальном ревью или недостаточном QA. Отдельно стоит категоризировать баги по severity: один P0-баг в проде важнее десяти косметических.
Team Happiness Index: регулярные опросы о настроении и удовлетворенности процессами, командная работы сводит вместе людей, которые друг друга не выбирали, так что люди могут друг другу не подходить, кроме того, могут не нравиться задачи, процессы, решения руководства, инструменты и т. п.; конечно, кто-то сам придёт и расскажет о своих проблемах, но кто-то и не захочет этого делать, опросы не решают полностью эту проблему, но всё же дают немного больше информации, особенно если они анонимные.
Incident Rate — кол-во P0/P1 инцидентов за период

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

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

Лично у меня есть несколько мнений по поводу работы команд:

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

В общем, работайте над эффективностью ваших команд, а метрики вам в этом могут помочь.

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

Метрики работы инженеров

Спускаемся дальше…

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

И при этом надо же как-то оценивать ребят, опираясь не на субъективные суждения, а на факты.

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

Короче, инженерные метрики ругают как сами инженеры, так и менеджеры.

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

И всё равно большинство компаний их используют, особенно крупных.

Почему? Потому что нет выхода.

Предположим конкретный тимлид или EM может думать: “Зачем мне эти метрики?”…

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

В общем нужна система координат: возможность количественной оценки.

Но и субъективная оценка менеджера не должна уходить.

Это самая сложная тема, и с этими метриками всегда больше всего проблем. поэтому и оценивать показатели стоит более скрупулезно

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

Velocity (Скорость команды): объем работы (обычно в Story Points), который инженер закрывает за некий интервал времени, чаще всего за спринт.
Rework Rate (Доля возвратов): объем работы, который пришлось переделывать из-за неверных решений.
Defect Density (Плотность дефектов): количество багов на единицу…вот тут сложно, меряют на задачу, на МР, на определённый объём кода, но это не репрезентативно — с одной стороны можно читить, с другой — кто-то может получить много багов на очень сложном участке и эту сложность в метрику никак не включить, и это я еще оставляю за скобкам потенциальную необходимость “сделать очень быстро”, что тоже может приводить к багам, но не указывать на слабость скилов инженера. Я больше склоняюсь к мере “N багов на story point”, если под SP мы будем понимать единицу сложности задачи, которая может как коррелировать так и не коррелировать с объемом кода и затраченным временем.
Соблюдение дедлайнов (On-time Delivery Rate): своевременность выполнения поставленных задач и этапов проектирования. Место ярости и скорби. Это совсем другая история, но! дедлайн не может быть выставлен сверху — команда выставляет его сама. Конечно, он может быть подвергнут сомнению и обсуждению, но последнее слово всегда должно быть за командой!
Cycle Time: время от взятия задачи в работу до ее полного завершения.
Review Response Time: время, за которое инженер берет чужой Pull Request на проверку после запроса.
Качество комментариев к PR: процент содержательных замечаний на ревью, которые привели к улучшению архитектуры или исправлению скрытых багов. Считать сложно, но с применением ИИ норм, однако и с ним оценка всё равно субъективная.
План/Факт (Sought vs Done): соотношение количества взятых Story Points (или задач) к фактически закрытым к концу отчетного периода (например, спринта).
Точность оценки (Estimation Accuracy): Разница между первоначальной оценкой задачи инженером и реальным временем, затраченным на ее реализацию. Если оценивать в SP, то может быть не применима.
PR Size: количество измененных строк (additions + deletions) в одном pull request. Негласный стандарт — до 400 строк, идеал — до 200. Большие PR плохо ревьюятся: ревьюер устает, теряет контекст и начинает апрувить формально. Маленькие PR проходят быстрее, легче откатываются и проще понимаются в будущем. Если PR неизбежно большой (например, рефакторинг), помогает разбивка на коммиты с понятными сообщениями или стэкинг PR (один поверх другого).

Важный нюанс: автоматически сгенерированный код (миграции, proto-файлы) лучше исключать из подсчёта — иначе метрика искажается.

On-call Response Time: время от момента срабатывания алерта до начала реакции инженера на дежурстве. Обычно измеряется в минутах и фиксируется системами типа Grafana On-call или OpsGenie. Если дежурного “вызванивает” сапорт, то, соответственно, время от начала “вызванивания” до реакции.

Нормативы зависят от SLA: для P0-инцидентов типичная цель — ответ за 5–15 минут. Метрика отражает не только личную дисциплину, но и качество самих алертов: если инженер игнорирует или долго разбирается — возможно, алерты неинформативны или их слишком много (alert fatigue). Поэтому рядом всегда смотрят на процент ложных срабатываний и MTTR.

“Оценка 360” или perfomance review. Самое неприятное. Субъективная качественная оценка коллегами. В контексте этого пункта неоднократно сталкивался с ужасами: коллеги топят друг друга из-за личной неприязни и старых обид, цели компании, команды и т. п. уходят на второй план; и еще один частый кейс: некий индивид преисполнился собственной значимостью и считает всех вокруг дураками и бесполезными людьми, отчего на ревью кошмарит всех вокруг, правда таких людей легко вычислить — они ставят негативные оценки всем или почти всем.
Есть и другая грань: по умолчанию все друг друга хвалят. Если нет негативного фона то все ставят коллегам хорошие оценки, даже если хвалить в общем-то не за что…просто чтобы быть хорошим.
Знаю компании, которые полностью отказываются от практики performance review и из неколичественных метрик оставляют только мнение руководителя, но это тоже неполноценно, всё же лучше иметь несколько мнений.
Еще одна проблема в том что эти performance review отнимают кучу времени у всех участников процесса.
Я предлагаю таки применять этот метод, но вместе с ИИ, положительную оценку принимать за норму, а в каждый негативный отзыв погружаться отдельно. Причём можно сразу принять что одна умеренно негативная оценка может считаться статистическим выбросом. По крайней мере можно попробовать так жить.
Если перед 360 компания фактически перестаёт работать на несколько недель, а по результатам люди ловят кучу негатива, то лучше такое не использовать.

А теперь рассмотрим ситуацию, когда у кого-то плохие показатели и/или хреновая оценка по perfomance review.

Главное не начинать кошмарить человека без предварительного разбора ситуации.

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

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

Метрики работы IT-менеджеров

Частично как и для инженеров, performance review и даже сами показатели немного пересекаются. Главное отличие от инженерных метрик: большинство показателей менеджера косвенные и измеряются через состояние команды, а не личные действия. Хороший менеджер невидим в метриках — его команда просто стабильно поставляет и не выгорает. Поэтому метрики команды конечно отражают работу всей команды, но ответственен за них и за результат работы прежде всего руководитель. Туда же и технические метрики в зоне ответственности команды и косвенно продуктовые и даже бизнесовые показатели. Нужно понимать что конкретное IT-подразделение, развивающее, например, какой-то продукт влияет на него больше всех: больше маркетологов, продактов, бизнес-аналитиков и др., ну и конкретный руководитель этого подразделения — точка входа и ответственной лицо первого порядка. Но, конечно, обвинять техруководителя в неудачах бизнеса никто не должен — это общая проблема.

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

Attrition Rate — кто уходит и как часто. Текучка, метрика неоднозначная, но если в подразделении случается массовый исход, то стоит присмотреться.
Time-to-Hire — скорость закрытия вакансий. То же самое, метрика неоднозначная, возможно, кандидаты действительно неподходящие, но бывает что менеджер думает: “Либо “звезда”, либо никто. С кем-то слабее придётся возиться, а пока вакансия не закрыта можно этим прикрываться”, и пофиг что бизнесу от этого хуже, краткосрочно и в перспективе. К сожалению, довольно распространенный кейс.
Employee Satisfaction (eNPS) — готовность рекомендовать компанию как работодателя, руководитель на это влияет непосредственно.

Вообще, метрик, как обычно, много, но я выделяю эти 3, остальные кажутся уж очень условными и субъективными.

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

Общие советы

Почти любую метрику можно оптимизировать за счет другой. Например, Velocity растет — падает качество. Bug Escape Rate снижается — замедляется поставка. Иногда это допустимо, иногда нет.

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

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

Ищите первопричину, а не симптом. Метрика говорит «что происходит», но не «почему». Высокий attrition — это следствие. Причина может быть в менеджере, компенсации, культуре, отсутствии роста. Без диагностики реакция на метрику будет неверной.

Разделяйте сигнал и шум. Одна точка данных — не тренд. PR Review Time вырос на этой неделе — может, все были на встречах. Реагируйте на устойчивые паттерны, а не на разовые выбросы.

Не используйте метрики для сравнения людей. Особенно инженерные: velocity, commits, PR count. Разные задачи, разный контекст, разная роль в команде. Сравнение по таким числам разрушает доверие и стимулирует игру в метрики вместо реальной работы.

Итого

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

Тем не менее само по себе значение ничего не говорит. Attrition 18% — это хорошо или плохо? Зависит от индустрии, страны, стадии компании, того что было год назад. Метрика ценна только в контексте: относительно бенчмарка, тренда или цели.

Лонгрид-шпаргалка про метрики