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