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

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

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

Поэтому задача метрик для меня никогда не сводится к отчётности. Их смысл в другом: сделать ИТ читаемым для бизнеса.

Что такое метрика в моём понимании

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

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

Рядом с метриками живут индикаторы. Метрика отвечает на вопрос "как мы работаем". Индикатор отвечает на вопрос "что происходит прямо сейчас".

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

Без методологии метрика остаётся мнением. С методологией она становится фактом.

За что бизнес платит и что он получает

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

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

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

Стоимость. Смотрю на ФОТ по контурам, инфраструктуру и лицензии, аллокации, стоимость продукта или сервиса. Бизнес должен видеть не просто "бюджет ИТ", а стоимость конкретного канала, продукта или технологического сервиса. Только тогда разговор о затратах становится предметным.

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

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

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

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

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

Каждый контур - ответ на конкретный вопрос бизнеса: что происходит с деньгами компании в этой точке.

Как это работает внутри команды

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

Я смотрю влияние на выручку, маржу и риск. Руководители контуров смотрят на то же самое в своих зонах ответственности. Тимлиды, в своих. И только дальше появляются операционные цифры: скорость релиза, инциденты, утилизация.

Одна логика на всех. Разный масштаб.

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

Это и есть метрика команды. Не для контроля, а для честного разговора.

Когда цифры зелёные, а результата нет

Когда система измерений выстроена - очень быстро становится видна одна неприятная вещь: команда может выполнять план на 100%, соблюдать сроки, закрывать ошибки, а бизнес-результата при этом не будет.

Разница простая. Одно дело, что сделано: выпустили 10 фич в срок, закрыли 200 задач за квартал. Другое дело, что реально изменилось в бизнесе: выросла конверсия, сократилось время оформления, снизилось число обращений в поддержку.

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

Поэтому смотрю на оба вопроса: что мы сделали и что от этого изменилось в бизнесе. Без первого непонятно, как работает команда. Без второго непонятно, зачем.

Задачи "в стол": симптом, а не приговор

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

Важно понимать природу этих потерь. Она разная.

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

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

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

Основной вывод

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

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

В этом и состоит задача метрик. Не отчитаться, а сделать ИТ прозрачным.