Разработчик приходит к руководству и говорит: «Нам нужен рефакторинг». Руководство слышит: «Мы хотим потратить деньги и ничего не выпустить». Дальше — тишина, новый спринт с новыми фичами и ещё один слой технического долга сверху.
Привет, я — Артем Герасимов, владелец SimpleOne SDLC. Сегодня поговорим о том, где именно ломается этот перевод и как его починить — не на уровне теории, а на уровне конкретных разговоров с CEO и стейкхолдерами.
Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.
Почему бизнесу техдолг до лампочки
Разработчик и CEO смотрят на одну и ту же ситуацию — и видят разные риски. Команда боится, что скоро что-то сломается, релизы замедлятся, поддержка станет дороже. Директору важнее, что пока продукт работает и приносит деньги.
Кроме того, во многих компаниях бизнес и разработка физически разделены и общаются только через бэклог. Разработчики знают, что всё плохо, но не понимают, к кому идти. К бизнесу? Кажется, нет. К сервис-менеджеру? Тоже непонятно. В итоге обратная связь не поступает наверх, а техдолг молча копится.
При этом не всегда техдолг означает, что что-то пошло не так. Здесь важно разграничить два сценария: это может быть осознанная инвестиция, когда команда понимает, что делает фичу быстро и не идеально, чтобы успеть закрыть сделку или выйти на рынок. При этом есть план: когда и как это будет исправлено, какие риски допускаются. Такой техдолг — нормальная часть разработки.
Но есть и неосознанный техдолг, когда «выйдем на MVP, потом перепишем», но никто не фиксирует ни намерение, ни сроки, ни стоимость переработки. Когда MVP выходит, времени на исправление нет, контекст потерян — и переписывать становится в разы дороже. Именно с этим сталкивались мы сами при разработке продукта: последние полгода во многом ушли на то, чтобы адаптировать то, что было быстро сделано на старте и не подошло для масштабирования.
Если ваш продукт сейчас на стадии MVP и вы только накапливаете первый долг — подробнее о том, как не попасть в ловушку "потом перепишем" — читайте в нашей статье на Хабре
Важно отличать осознанный техдолг от неосознанного и уметь показать бизнесу, что сейчас нуждается во внимании, чтобы разработка в итоге не оказалась в тупике, когда придется бесконечно поддерживать легаси и переписывать код.
Переводим на язык денег
Первый вопрос, который возникает у тимлида: с чего начинать разговор — с конкретной боли или с системной картины? Зависит от момента. Если продукт сейчас активно продаётся — лучше не ждать, пока всё системно сломается, и подсвечивать проблему сразу. Если продукт на паузе — можно позволить себе сформировать более полную картину.
Но в обоих случаях работает одно правило: конкретика убедительнее абстракции. «Этот модуль тормозит релизы на три дня» — это аргумент. «Мы в долговой яме» — это метафора, которую каждый интерпретирует по-своему.
Вот как это может звучать в разговоре с CEO:
«Модуль биллинга написан три года назад под 500 клиентов. Сейчас у нас 3000. Каждый релиз, который затрагивает биллинг, занимает на 4 дня больше из-за ручного тестирования — автотесты не покрывают новую логику.
Четыре дня задержки × средний доход от фичи 800 тысяч рублей в месяц = мы теряем примерно 100 тысяч за каждый релиз. Рефакторинг займёт три недели, окупится за два релиза.»
Это не про «код некрасивый». Это про деньги.
Бизнес понимает деньги — значит, нужно говорить на языке денег. Попытка объяснить проблему через стори-поинты или «замедление разработки» почти всегда проигрывает. Есть три категории потерь, которые поддаются хотя бы приблизительной оценке.
Замедление выпуска
Если команда боится лезть в кодовую базу, каждый релиз занимает больше времени. Это легко посчитать: возьмите среднюю стоимость дня команды, умножьте на задержку — и вы уже говорите не о «технических проблемах», а о конкретной строке в бюджете.
Пример:
Команда из пяти разработчиков, средняя стоимость человеко-дня — 15 000 рублей. Каждый релиз задерживается на три дня из-за хрупкого модуля.
Восемь релизов в год — это 8 × 3 × 5 × 15 000 = 1,8 млн рублей только на задержки.
Без учёта того, что конкурент выпустил ту же фичу раньше.
Риск отказа под нагрузкой
Если в коде есть место, которое не рассчитано на большой поток пользователей, сервис может упасть именно в момент пиковой нагрузки — в распродажу, на демо крупному клиенту, в день запуска кампании.
Допустим, сервис приносит 2 млн рублей в день. Час простоя — 250 тысяч. Вероятность отказа из-за известной проблемы в коде — допустим, 10% в месяц.
Ожидаемые потери: 250 000 × 0,1 = 25 000 рублей в месяц. Звучит немного? Но если простой затянется на 4 часа (а это реалистично для нагруженного сервиса без автофейловера) — уже миллион.
Плюс отток клиентов, который посчитать сложнее, но он не нулевой.
Потолок роста
Если архитектура не масштабируется, в какой-то момент придёт крупный клиент — а вы не сможете его обслужить в нужные сроки или вообще. Упущенная сделка — это вполне конкретная сумма, которую коммерческий директор назовёт сам, если правильно поставить вопрос.
И кстати: стоит ли вообще употреблять слово «техдолг» в разговоре с бизнесом? Скорее нет — оно воспринимается как что-то технически непонятное и финансово неприятное одновременно.
Аналогия, которая работает: почему нельзя писать код без ошибок? По той же причине, по которой нельзя строить дом без усадки — это часть природы процесса. Вопрос в том, как с этим работать.
Отдельный вопрос — как ставить техдолг в бэклог рядом с бизнес-фичами. Универсальных систем оценки много, но в большинстве компаний приоритизацией всё равно занимается человек, и делает это субъективно. Рабочий подход: синхронизировать два понятия — потери от нерешённого долга и потенциал новой фичи. Когда речь идёт о плановой, не срочной задаче, часто есть смысл совместить её с исправлением сопутствующего техдолга. Разработка займёт больше времени, но в перспективе это меньше рисков и меньше проблем.
Именно так мы поступили с управлением статусными моделями в нашем продукте: не стали разделять фичу и рефакторинг, сделали всё вместе — и получили чистый результат вместо ещё одного слоя долга.
Что делать, если разговора не получается
Не ждать отдельного «окна» для рефакторинга — скорее всего, оно не откроется само. Вместо этого встраивать исправление техдолга в текущие задачи: если берёте фичу, которая касается проблемного модуля — договоритесь, что сделаете её чуть дольше, но заодно подчистите.
Поэтому мы в системе управления разработкой SimpleOne SDLC сделали так: система позволяет выстроить прозрачность на уровне платформы, чтобы технические команды работали внутри системы, а стейкхолдеры видели агрегированную картину через портал — без доступа к задачам разработки, но с понятными метриками. Скорость релизов, накопленный долг по направлениям, динамика velocity — всё это можно сделать читаемым для человека, который думает в категориях бизнеса, а не спринтов.
Если и этот разговор не клеится — остаётся два варианта, и оба несовершенны.
Первый: ждать, пока ситуация станет настолько очевидной, что бизнес сам придёт к команде. Это рискованно — можно не дождаться, а дождаться инцидента.
Второй: встраивать исправление техдолга в задачи, не выделяя его отдельной строкой. Взяли фичу в проблемном модуле — договорились внутри команды сделать её чуть дольше, но заодно подчистить. Это не обман: работа сделана, продукт стал лучше. Но это и не идеал — потому что руководство не видит реальной картины, не может принимать взвешенные решения о рисках, и долг продолжает накапливаться там, куда фичи не заходят.
Поэтому этот путь — не стратегия, а временный выход, когда все остальные двери закрыты. Если вы им пользуетесь, стоит хотя бы фиксировать внутри команды: что исправлено, где ещё проблема, сколько это стоило. Не для отчёта — для себя, чтобы когда разговор всё-таки состоится, у вас были данные, а не ощущения.
В целом, нетехническим стейкхолдерам незачем заходить в систему управления разработкой — и платить за их лицензии тоже незачем. Но им нужна картина: что происходит, где риски, как движется работа.
***
А вам удается объяснить руководству, в чем проблема техдолга?
