AndrewHome
New member
Когда я впервые пришёл к директору с фразой «надо отрефакторить», то услышал прямой вопрос: «А деньги где?» Тогда я обиделся, потому что говорил про качество кода, архитектуру и будущую поддержку. Но бизнес не покупает чистый код. Он покупает скорость, предсказуемость и меньше рисков. С этого момента я начал переводить технический долг на язык, который понятен руководителям.
Технический долг — это не абстрактная метафора, а почти финансовый инструмент. Представьте кредитку с огромным процентом: каждый костыль позволяет быстро закрыть задачу сегодня, но завтра команда платит временем на багфиксы, долгими релизами и страхом трогать рабочий код. Бизнес отлично понимает проценты, упущенную выгоду и стоимость простоя. Значит, и рефакторинг нужно показывать не как «уборку», а как снижение этих платежей.
В одном проекте у нас была функция, которая по оценке должна была занимать три дня, а по факту растягивалась на три недели. Причина — legacy-код, который никто не решался менять. Мы посчитали, что примерно треть спринта уходит на обходные пути, ручные проверки и переделки. Я пришёл к продукту не с просьбой «дать месяц на рефакторинг», а с расчётом: «Мы вернём до 30 процентов времени команды на новые функции и снизим риск ночных инцидентов». После двух месяцев аккуратной работы релизы ускорились, а количество горящих правок заметно упало.
Главный совет: говорите метриками, а не эмоциями. Время до релиза, число hotfix, стоимость инцидента, скорость onboarding новых разработчиков, частота повторных багов — всё это можно показать в динамике. Не обещайте «идеальный код». Лучше скажите: «Если не трогать этот модуль, через полгода доработка будет стоить столько-то и займёт столько-то. Если вложимся сейчас, сэкономим вот эту сумму и получим вот такой запас скорости».
Ещё важно не просить рефакторинг отдельным большим блоком, если культура компании к этому не готова. Я стараюсь встраивать его в продуктовые задачи. Например, при доработке платежей сначала выносим проблемный участок, а потом добавляем новую функцию. Так бизнес получает результат здесь и сейчас, а команда постепенно уменьшает долг. Сопротивление почти исчезает, когда люди видят не «мы переписываем код», а «мы делаем следующую фичу быстрее и безопаснее».
Полезно найти союзника среди продукта или финансов. Покажите, как технический долг бьёт по их KPI: срываются сроки, клиенты ждут, поддержка тонет в обращениях. Иногда помогает простая таблица «до и после»: сколько времени тратили, сколько стали тратить, сколько инцидентов было, сколько осталось. Если результат не фиксировать, следующий раз вам поверят меньше. А если фиксировать, рефакторинг перестаёт быть верой и становится управленческим решением.
Я давно перестал считать рефакторинг самоцелью. Это инвестиция. Если не могу объяснить, какую боль снимаю и сколько денег или времени возвращаю, значит, мне рано идти к бизнесу. Но когда разговор идёт через потери, риски и упущенную выгоду, отношение меняется. Технический долг перестаёт быть «проблемой программистов» и становится общим вопросом эффективности компании.
А как вы доносите ценность рефакторинга до руководителей? Какие метрики, истории или расчёты помогли вам убедить бизнес, что чистота кода — это не расход, а способ зарабатывать больше? Поделитесь опытом, вместе мы сделаем технический долг понятным для всех.
Технический долг — это не абстрактная метафора, а почти финансовый инструмент. Представьте кредитку с огромным процентом: каждый костыль позволяет быстро закрыть задачу сегодня, но завтра команда платит временем на багфиксы, долгими релизами и страхом трогать рабочий код. Бизнес отлично понимает проценты, упущенную выгоду и стоимость простоя. Значит, и рефакторинг нужно показывать не как «уборку», а как снижение этих платежей.
В одном проекте у нас была функция, которая по оценке должна была занимать три дня, а по факту растягивалась на три недели. Причина — legacy-код, который никто не решался менять. Мы посчитали, что примерно треть спринта уходит на обходные пути, ручные проверки и переделки. Я пришёл к продукту не с просьбой «дать месяц на рефакторинг», а с расчётом: «Мы вернём до 30 процентов времени команды на новые функции и снизим риск ночных инцидентов». После двух месяцев аккуратной работы релизы ускорились, а количество горящих правок заметно упало.
Главный совет: говорите метриками, а не эмоциями. Время до релиза, число hotfix, стоимость инцидента, скорость onboarding новых разработчиков, частота повторных багов — всё это можно показать в динамике. Не обещайте «идеальный код». Лучше скажите: «Если не трогать этот модуль, через полгода доработка будет стоить столько-то и займёт столько-то. Если вложимся сейчас, сэкономим вот эту сумму и получим вот такой запас скорости».
Ещё важно не просить рефакторинг отдельным большим блоком, если культура компании к этому не готова. Я стараюсь встраивать его в продуктовые задачи. Например, при доработке платежей сначала выносим проблемный участок, а потом добавляем новую функцию. Так бизнес получает результат здесь и сейчас, а команда постепенно уменьшает долг. Сопротивление почти исчезает, когда люди видят не «мы переписываем код», а «мы делаем следующую фичу быстрее и безопаснее».
Полезно найти союзника среди продукта или финансов. Покажите, как технический долг бьёт по их KPI: срываются сроки, клиенты ждут, поддержка тонет в обращениях. Иногда помогает простая таблица «до и после»: сколько времени тратили, сколько стали тратить, сколько инцидентов было, сколько осталось. Если результат не фиксировать, следующий раз вам поверят меньше. А если фиксировать, рефакторинг перестаёт быть верой и становится управленческим решением.
Я давно перестал считать рефакторинг самоцелью. Это инвестиция. Если не могу объяснить, какую боль снимаю и сколько денег или времени возвращаю, значит, мне рано идти к бизнесу. Но когда разговор идёт через потери, риски и упущенную выгоду, отношение меняется. Технический долг перестаёт быть «проблемой программистов» и становится общим вопросом эффективности компании.
А как вы доносите ценность рефакторинга до руководителей? Какие метрики, истории или расчёты помогли вам убедить бизнес, что чистота кода — это не расход, а способ зарабатывать больше? Поделитесь опытом, вместе мы сделаем технический долг понятным для всех.