Первые годы я думал, что совету директоров достаточно показать график с растущим количеством легаси. Я приносил красивые схемы зависимостей, список из четырёхсот открытых задач и оценку рефакторинга в девять месяцев. Мне вежливо кивали и спрашивали: а в следующем квартале это можно? Тогда я понял простую вещь. Внутри инженерной команды технический долг звучит как жалоба, а на языке бизнеса он звучит как риск, и этот риск можно посчитать.
Главный сдвиг случился, когда я перестал говорить про качество кода и начал говорить про скорость и деньги. Не «у нас плохая архитектура», а «вывод новой функции вырос с трёх недель до трёх месяцев, и вот почему». Не «нужен рефакторинг», а «мы тратим сорок процентов времени команды на починку того, что уже работает, вместо того чтобы делать то, за что нам платят». Как только речь пошла о скорости вывода продукта, разговор из технического мгновенно стал управленческим.
Помню конкретный случай с платёжным модулем в одной из компаний, где я работал. Каждая новая платёжная интеграция занимала всё больше времени, потому что логика расползлась по десяткам файлов и никто не решался тронуть общий код. Мы посчитали честно: за год на доработки ушло почти вдвое больше часов, чем планировалось, а один сбой в пятницу вечером стоил нам больше, чем весь квартальный бюджет на рефакторинг. Вот эту цифру я и принёс на совет. Она изменила разговор быстрее любых технических аргументов.
Дальше я выработал для себя несколько правил подачи. Первое: одна страница, никакого жаргона, никаких слов вроде «монолит» и «связанность» без расшифровки. Второе: три сценария вместо одной пугающей картинки — что будет, если ничего не делать, что будет при постепенных вложениях и что будет при быстрой, но рискованной переработке. Третье: метрики, понятные финансисту, например стоимость одного инцидента, процент времени на поддержку старого, срок выхода функций на рынок и текучесть разработчиков. Четвёртое: всегда называть цену бездействия, а не только цену решения.
Ещё один приём, который у меня хорошо сработал: говорить о техническом долге как о кредите. Бизнес отлично понимает кредиты. Мы взяли его, чтобы быстро выйти на рынок, и теперь платим проценты — только не деньгами банку, а скоростью и нервами команды. Иногда эти проценты выгодны, и это нормально. Мой посыл совету директоров был не «давайте всё перепишем», а «давайте решим, какие проценты мы готовы платить дальше, а какие пора гасить». Такая рамка снимает защитную реакцию и превращает спор в планирование.
Советую читателям не ждать большого кризиса, чтобы завести этот разговор. Начните вести простой учёт: сколько времени уходит на доработки против новых функций, сколько стоили последние инциденты, где команда признаётся, что боится трогать код. Через месяц у вас будет не эмоция, а история с числами. И обязательно свяжите её с продуктовой стратегией: если в планах удвоение нагрузки или новые рынки, покажите, где именно текущее состояние станет тормозом. Генеральный директор не обязан любить архитектуру, но он обязан реагировать на риск для выручки.
Чего точно не стоит делать — так это пугать и шантажировать. Формулировки в духе «всё рухнет» или «нам нужно полгода без релизов» обычно приводят к обратному эффекту: вас перестают звать на такие встречи. Гораздо сильнее работает честный размен: мы вкладываем вот столько, получаем вот такую скорость и вот такое снижение рисков, а вот здесь мы сознательно откладываем. Признание, что не весь долг нужно гасить, повышает доверие к вам как к руководителю, а не понижает его.
В итоге технический долг перестал быть для меня темой, о которой неловко говорить с бизнесом. Это обычный управленческий параметр: есть риск, есть стоимость, есть выбор. Как только вы научитесь переводить свою инженерную боль в язык денег и сроков, совет директоров станет вашим союзником, а не аудиторией, которой нужно что-то доказывать. А теперь вопрос к вам: какой аргумент или какая цифра лучше всего помогли именно вам достучаться до руководства и превратить технический долг в общий управленческий разговор?
Главный сдвиг случился, когда я перестал говорить про качество кода и начал говорить про скорость и деньги. Не «у нас плохая архитектура», а «вывод новой функции вырос с трёх недель до трёх месяцев, и вот почему». Не «нужен рефакторинг», а «мы тратим сорок процентов времени команды на починку того, что уже работает, вместо того чтобы делать то, за что нам платят». Как только речь пошла о скорости вывода продукта, разговор из технического мгновенно стал управленческим.
Помню конкретный случай с платёжным модулем в одной из компаний, где я работал. Каждая новая платёжная интеграция занимала всё больше времени, потому что логика расползлась по десяткам файлов и никто не решался тронуть общий код. Мы посчитали честно: за год на доработки ушло почти вдвое больше часов, чем планировалось, а один сбой в пятницу вечером стоил нам больше, чем весь квартальный бюджет на рефакторинг. Вот эту цифру я и принёс на совет. Она изменила разговор быстрее любых технических аргументов.
Дальше я выработал для себя несколько правил подачи. Первое: одна страница, никакого жаргона, никаких слов вроде «монолит» и «связанность» без расшифровки. Второе: три сценария вместо одной пугающей картинки — что будет, если ничего не делать, что будет при постепенных вложениях и что будет при быстрой, но рискованной переработке. Третье: метрики, понятные финансисту, например стоимость одного инцидента, процент времени на поддержку старого, срок выхода функций на рынок и текучесть разработчиков. Четвёртое: всегда называть цену бездействия, а не только цену решения.
Ещё один приём, который у меня хорошо сработал: говорить о техническом долге как о кредите. Бизнес отлично понимает кредиты. Мы взяли его, чтобы быстро выйти на рынок, и теперь платим проценты — только не деньгами банку, а скоростью и нервами команды. Иногда эти проценты выгодны, и это нормально. Мой посыл совету директоров был не «давайте всё перепишем», а «давайте решим, какие проценты мы готовы платить дальше, а какие пора гасить». Такая рамка снимает защитную реакцию и превращает спор в планирование.
Советую читателям не ждать большого кризиса, чтобы завести этот разговор. Начните вести простой учёт: сколько времени уходит на доработки против новых функций, сколько стоили последние инциденты, где команда признаётся, что боится трогать код. Через месяц у вас будет не эмоция, а история с числами. И обязательно свяжите её с продуктовой стратегией: если в планах удвоение нагрузки или новые рынки, покажите, где именно текущее состояние станет тормозом. Генеральный директор не обязан любить архитектуру, но он обязан реагировать на риск для выручки.
Чего точно не стоит делать — так это пугать и шантажировать. Формулировки в духе «всё рухнет» или «нам нужно полгода без релизов» обычно приводят к обратному эффекту: вас перестают звать на такие встречи. Гораздо сильнее работает честный размен: мы вкладываем вот столько, получаем вот такую скорость и вот такое снижение рисков, а вот здесь мы сознательно откладываем. Признание, что не весь долг нужно гасить, повышает доверие к вам как к руководителю, а не понижает его.
В итоге технический долг перестал быть для меня темой, о которой неловко говорить с бизнесом. Это обычный управленческий параметр: есть риск, есть стоимость, есть выбор. Как только вы научитесь переводить свою инженерную боль в язык денег и сроков, совет директоров станет вашим союзником, а не аудиторией, которой нужно что-то доказывать. А теперь вопрос к вам: какой аргумент или какая цифра лучше всего помогли именно вам достучаться до руководства и превратить технический долг в общий управленческий разговор?