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

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

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

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

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

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

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

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

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

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

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

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

Любая трансформация, это стресс. Люди сопротивляются. Никто не хочет менять привычные условия.

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

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

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

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

В одной из компаний на одном разработчике держалась вся B2B-платформа. Классическое бутылочное горлышко. Он уехал в отпуск без связи. Платформа упала. Потери измерялись десятками миллионов рублей.

Это не HR-история. Это история про финансовый риск, который никто не посчитал заранее.

Я всегда перевожу концентрацию знания в деньги:

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

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

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

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

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

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

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

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

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

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

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