Разработчик дороже меня окупился за три недели

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

Проблема

Обычно ИТ-команду измеряют в закрытых задачах, утилизации и количестве релизов. Но совет директоров покупает не утилизацию. Он покупает:

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

Если CIO отвечает за часть P&L, то и на команду он смотрит через эту призму. Это не значит, что люди превращаются в строчку в таблице. Это значит, что ошибка в найме, потеря ключевого сотрудника и зависимость критичного процесса от одного эксперта имеют прямую цену. И CIO обязан эту цену видеть.

Найм: дорогой человек может быть самым дешёвым решением

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

Я смотрю на другое:

• сколько стоит задержка продукта без этого человека / роли
• сколько выручки теряет компания за каждый месяц промедления
• какой темп изменений мы получаем с ним и без него

В Ингосстрахе я нанял разработчика, который стоил дороже меня. За три недели он сделал MVP для B2G-сегмента. В итоге это решение выросло в продукт, который компания монетизирует до сих пор.

Дорогой найм - это не расход. Это инвестиция с понятной окупаемостью.

Удержание - это управление риском

Любая трансформация - это стресс. Люди сопротивляются. Никто не хочет менять привычные условия. Я работаю через личные разговоры с ключевыми людьми и неформальными лидерами. Объясняю смысл изменений, не ограничиваюсь распоряжениями. Там, где это нужно, иду глубже, на линейный уровень. В таких историях недостаточно формальной коммуникации. Нужно, чтобы сотрудники поняли не только что меняется, но и зачем, и как это отразится на их работе.

При жёсткой пересборке оргдизайна и смене системы мотивации нам вместе с HR BP и IT BP удалось удержать 95% коллектива. Драйв шёл и от борда, и от меня, но результат в таких историях всегда командный.

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

Концентрация риска на людях

В одной из компаний на одном разработчике держалась вся B2B-платформа. Классическое бутылочное горлышко: bus factor равен единице. Он уехал в отпуск без связи. Платформа "легла", а команда не смогла быстро её поднять: сбой был в модуле, который знал только этот разработчик. И это не HR-история - это кейс про финансовый риск, который никто не посчитал заранее. Поэтому я всегда перевожу концентрацию знания в деньги::

• какие процессы держатся на одном человеке
• сколько стоит день простоя этого процесса
• есть ли второй, кто может подхватить

Инвестиции в обмен знаниями / центры экспертизы / гильдии, документацию и "вторые номера" - это не бюрократия. Это защита финансового контура.

Соотношение поддержки и развития

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

Через системную проработку процессов, внедрение приоритизации и выстраивание контура поддержки по ITIL картина изменилась: поддержка 20–30%, развитие 50–60%, инновации 5–10%.

Если команда растёт не из-за роста продукта, а из-за роста сложности, это один из самых дорогих видов технического долга. Он маскируется под загруженность и объективную перегрузку. На самом деле бизнес в этот момент финансирует удержание прошлого.

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

ИТ-команда - это не просто центр затрат. Это контур, от которого зависят скорость изменений, устойчивость процессов и стоимость технологических решений.

Пока вы измеряете команду в закрытых задачах, вы управляете ресурсом. Когда измеряете её в стоимости задержки и цене риска, вы управляете капиталом.

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

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