Alex.Miller
New member
Год назад я сидел на совещании с замдиректора по продукту и слушал, как он с раздражением говорил: «А зачем нам тратить два спринта на то, что уже работает? Давайте лучше новые фичи». Я понимал его логику — бизнес думает категориями быстрых денег, а технический долг для него абстракция. Но если не действовать, через полгода система начнёт падать в пиковые нагрузки, а каждый баг будет стоить дороже, чем рефакторинг. Мне нужно было объяснить это так, чтобы через месяц он сам включил техдолг в roadmap.
Первое, что я понял: нельзя говорить про техдолг на языке кода. Фразы вроде «у нас кривая архитектура микросервисов» или «тестовое покрытие упало до 30%」 для бизнеса звучат как бормотание. Я начал переводить всё в деньги и сроки. Вместо «модуль биллинга написан неочевидно» я говорил: «Из-за сложности модуля каждый новый платёжный метод занимает две недели разработки вместо трёх дней, и мы теряем около 400 тысяч рублей в квартал на упущенной марже». Когда цифры стали понятными, разговор наконец начал двигаться.
Второй приём, который сработал, — аналогия. Я сказал директору: «Представьте, что вы открыли магазин. В первый год вы быстро поставили полки, чтобы начать продавать. Но к третьему году вы понимаете, что полки скрипят, товар падает, а ремонт откладывали. Вы можете выбирать: либо сейчас выделить неделю на ремонт, либо через месяц магазин закроется из-за обрушения. Технический долг — это именно те скрипучие полки в вашем коде». Он, конечно, не вселил ужас, но усмехнулся и кивнул — значит, понял.
Дальше я предложил конкретный план, а не абстрактные призывы. Я выделил три категории техдолга: критический (блокирует новый функционал или создаёт риски для данных), умеренный (замедляет разработку, но не катастрофически) и косметический (красивости, которые можно отложить). Затем я показал, что если каждый спринт выделять 20% времени на критический долг, через два квартала скорость разработки вырастет примерно на 35%. Это я посчитал по данным наших трекеров задач — у меня были цифры, а не ощущения.
Ещё один важный момент: я не пытался убедить бизнес, что техдолг — это зло, которое надо уничтожить. Я объяснил, что это нормальная часть разработки. В IT невозможно написать идеальный код с первого раза, и это нормально. Важно не то, есть ли долг, а то, управляем ли мы им осознанно. Когда я сказал это, сопротивление резко снизилось — люди перестали чувствовать, что я обвиняю их команду в некомпетентности.
В итоге через три месяца техдолг стал строкой в квартальном отчёте, и замдиректора сам спрашивал на демо: «А что по техническим долгам на этот спринт?». Это был момент, когда я понял: задача разработчика — не просто писать код, а быть переводчиком между техническим и бизнес-миром. Если вы умеете говорить на языке денег, сроков и рисков, вас услышат. А если нет — будете вечно просить время, которого у бизнеса никогда не бывает.
А как вы объясняете технический долг в своих командах? Может, у кого-то есть хитрые приёмы, которые реально работают? Делитесь в комментариях, мне самому интересно!
Первое, что я понял: нельзя говорить про техдолг на языке кода. Фразы вроде «у нас кривая архитектура микросервисов» или «тестовое покрытие упало до 30%」 для бизнеса звучат как бормотание. Я начал переводить всё в деньги и сроки. Вместо «модуль биллинга написан неочевидно» я говорил: «Из-за сложности модуля каждый новый платёжный метод занимает две недели разработки вместо трёх дней, и мы теряем около 400 тысяч рублей в квартал на упущенной марже». Когда цифры стали понятными, разговор наконец начал двигаться.
Второй приём, который сработал, — аналогия. Я сказал директору: «Представьте, что вы открыли магазин. В первый год вы быстро поставили полки, чтобы начать продавать. Но к третьему году вы понимаете, что полки скрипят, товар падает, а ремонт откладывали. Вы можете выбирать: либо сейчас выделить неделю на ремонт, либо через месяц магазин закроется из-за обрушения. Технический долг — это именно те скрипучие полки в вашем коде». Он, конечно, не вселил ужас, но усмехнулся и кивнул — значит, понял.
Дальше я предложил конкретный план, а не абстрактные призывы. Я выделил три категории техдолга: критический (блокирует новый функционал или создаёт риски для данных), умеренный (замедляет разработку, но не катастрофически) и косметический (красивости, которые можно отложить). Затем я показал, что если каждый спринт выделять 20% времени на критический долг, через два квартала скорость разработки вырастет примерно на 35%. Это я посчитал по данным наших трекеров задач — у меня были цифры, а не ощущения.
Ещё один важный момент: я не пытался убедить бизнес, что техдолг — это зло, которое надо уничтожить. Я объяснил, что это нормальная часть разработки. В IT невозможно написать идеальный код с первого раза, и это нормально. Важно не то, есть ли долг, а то, управляем ли мы им осознанно. Когда я сказал это, сопротивление резко снизилось — люди перестали чувствовать, что я обвиняю их команду в некомпетентности.
В итоге через три месяца техдолг стал строкой в квартальном отчёте, и замдиректора сам спрашивал на демо: «А что по техническим долгам на этот спринт?». Это был момент, когда я понял: задача разработчика — не просто писать код, а быть переводчиком между техническим и бизнес-миром. Если вы умеете говорить на языке денег, сроков и рисков, вас услышат. А если нет — будете вечно просить время, которого у бизнеса никогда не бывает.
А как вы объясняете технический долг в своих командах? Может, у кого-то есть хитрые приёмы, которые реально работают? Делитесь в комментариях, мне самому интересно!