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

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

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

Поэтому метрики для меня - инструмент перевода. Их задача простая: назвать обе цифры и закрепить за каждой владельца.

Метрика - это договор

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

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

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

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

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

Первая цифра: сколько ИТ стоит

Три контура показывают, куда уходят деньги функции и сколько из них превращается в результат.

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

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

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

Вторая цифра: сколько стоит, когда не работает

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

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

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

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

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

Восьмой контур - не мой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Природа этих потерь разная.

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

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

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

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

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

Что из этого вырастает на уровне всей компании - в тексте "Лес вырублен. Цели выполнены. Реальность потеряна".