Warm_Irina266
New member
Когда я впервые пришёл в компанию как тимлид, я обнаружил код, написанный в 2014 году, который никто не трогал и не понимал. Каждая новая фича стоила в три раза дольше, чем ожидал бизнес. Я пытался объяснить коллегам из отдела продаж, что мы платим за этот долг каждый спринт — но в ответ слышал: «Когда вы закончите с этим долгом, у нас будет прибыль, а не сейчас». С тех пор я понял: говорить о долге на языке кода бесполезно. Нужен язык денег и рисков.
Нажать чтобы Перейти на сайт
Мой первый успех начался с того, что я собрал статистику за полгода. Сколько багов из-за техдолга упало в продакшен, сколько инженерных часов ушло на обходные решения, сколько раз клиенты жаловались на ту же проблему. Я превратил это в таблицу с двумя колонками: «Что происходит сейчас» и «Что будет через год, если не действовать». Бизнес впервые увидел не абстракции, а конкретные цифры в рублях и потерянных заказах.
Я начал просить не «выделите два спринта на рефакторинг», а формулировал запросы через стоимость. Например: «Модуль авторизации падает раз в неделю. Каждый инцидент стоит нам 400 тысяч рублей в компенсациях и упущенной выручке. Закрыть этот долг нужно 3 недели работы двух разработчиков. ROI — 1200%». Когда ты говоришь на языке возврата инвестиций, CFO перестаёт считать тебя «разработчиком, который отнимает время на игрушки».
Ещё одна стратегия, которая сработала у меня в последнем проекте: я предложил «квоту долга». Каждый релиз содержит 20% задач по снижению техдолга. Бизнес понял, что это не остановка разработки, а страховка. Когда через квартал скорость релиза выросла на 35%, а количество критических багов упало вдвое, скептики замолчали. Ключевое слово здесь — «релиз». Не «мы перепишем всё с нуля», а «мы станем быстрее и надёжнее при том же объёме задач».
Узнать подробнее →
Я никогда не пытаюсь убедить бизнес в том, что технический долг «важен сам по себе». Это не работает. Работает привязка к их метрикам: время до выхода на рынок, стоимость поддержки, удовлетворённость клиентов, рост выручки. Технический долг — это не инженерная эстетика, это операционный риск, который можно измерить, и когда ты измерил, договориться становится легче.
А вы сталкивались с ситуацией, когда бизнес не хотел слышать о техдолге? Как вы в таком случае пробивали стену непонимания — через цифры, через инциденты или через личные отношения с руководством? Поделитесь опытом в комментариях, мне важно услышать разные подходы.
По теме советую почитать: Автоматизация бизнес-процессов: с чего начать без хаоса
Нажать чтобы Перейти на сайтМой первый успех начался с того, что я собрал статистику за полгода. Сколько багов из-за техдолга упало в продакшен, сколько инженерных часов ушло на обходные решения, сколько раз клиенты жаловались на ту же проблему. Я превратил это в таблицу с двумя колонками: «Что происходит сейчас» и «Что будет через год, если не действовать». Бизнес впервые увидел не абстракции, а конкретные цифры в рублях и потерянных заказах.
Я начал просить не «выделите два спринта на рефакторинг», а формулировал запросы через стоимость. Например: «Модуль авторизации падает раз в неделю. Каждый инцидент стоит нам 400 тысяч рублей в компенсациях и упущенной выручке. Закрыть этот долг нужно 3 недели работы двух разработчиков. ROI — 1200%». Когда ты говоришь на языке возврата инвестиций, CFO перестаёт считать тебя «разработчиком, который отнимает время на игрушки».
Ещё одна стратегия, которая сработала у меня в последнем проекте: я предложил «квоту долга». Каждый релиз содержит 20% задач по снижению техдолга. Бизнес понял, что это не остановка разработки, а страховка. Когда через квартал скорость релиза выросла на 35%, а количество критических багов упало вдвое, скептики замолчали. Ключевое слово здесь — «релиз». Не «мы перепишем всё с нуля», а «мы станем быстрее и надёжнее при том же объёме задач».
Узнать подробнее →Я никогда не пытаюсь убедить бизнес в том, что технический долг «важен сам по себе». Это не работает. Работает привязка к их метрикам: время до выхода на рынок, стоимость поддержки, удовлетворённость клиентов, рост выручки. Технический долг — это не инженерная эстетика, это операционный риск, который можно измерить, и когда ты измерил, договориться становится легче.
А вы сталкивались с ситуацией, когда бизнес не хотел слышать о техдолге? Как вы в таком случае пробивали стену непонимания — через цифры, через инциденты или через личные отношения с руководством? Поделитесь опытом в комментариях, мне важно услышать разные подходы.
По теме советую почитать: Автоматизация бизнес-процессов: с чего начать без хаоса