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