Всем привет! Меня зовут Илья Есейкин и я IT-управленец среднего звена, веду небольшой (пока) Telegram-канал о цифровой зрелости бизнеса. Это моя первая статья на Habr — пишу о том, что видел изнутри: несколько компаний, разные отрасли, реальные кейсы. Стараюсь обойтись без корпоративного глянца и универсальных рецептов. Если тема откликается — буду рад обратной связи в комментариях.
Есть фраза, которую многие из нас слышал во всех компаниях, отрасли разные, но фраза всегда звучала примерно одинаково: «Ну сделайте пока так, потом переделаем нормально». Она произносится обычно, когда дедлайн завтра, бюджет кончается, а продукт надо показать на демо. И именно из таких моментов, помноженных на годы, состоит то, что принято называть техническим долгом — не абстрактная IT-проблема, а вполне конкретный список управленческих выборов, сделанных под давлением обстоятельств.
Как это устроено изнутри
Механика всегда одна. Бизнес давит — нужно запустить до конца квартала. Архитектура подождёт. Документацию напишем потом — всё равно её никто не читает, кроме того, кто её написал. Переделать то, что работает криво, но работает — тоже потом, сейчас не до этого. Главное, чтобы запустилось.
И оно запускается. Все довольны, квартал закрыт.
Проходит год, два, пять. Система незаметно обрастает костылями — каждая новая доработка натыкается на предыдущее «временное» решение, обходит его, добавляет свой слой поверх. Разработчики, которые это строили, давно ушли. Документации нет. Остался один человек, который «примерно помнит, как оно работает», и это единственная живая нить к пониманию того, что происходит внутри системы.
И вот в этот момент бизнес приходит к IT с простым запросом: нужна новая фича, она ускорит процесс, увеличит конверсию, сократит время обработки — нужное подчеркнуть. В ответ IT говорит: "не можем". Не потому, что это для них сложно и не потому, что нет ресурса, а потому что под этим запросом лежит проблема, которая не даст новой функции нормально заработать. Три года назад что-то сделали быстро, на время — временное заработало и осталось навсегда. Потом поверх него сделали ещё одно временное, потом ещё. Сейчас это слоёный пирог из решений, каждое из которых кто-то когда-то считал промежуточным, и чтобы добавить новую функцию, нужно сначала разобрать несколько слоёв этого пирога — а это уже не одна кнопка и не одна неделя работы.
Бизнес удивлён. IT устал объяснять. Обе стороны правы — и обе в тупике.
Кто реально берёт кредит
Когда бизнес приходит к IT с вопросом «почему так медленно и так дорого» — он не хочет слышать про архитектуру, про накопленные проблемы и про сложность того, что было построено раньше. Он хочет одного: чтобы это быстро переделали, потому что вы же специалисты, вам за это и платят. И в этом нет ничего удивительного — кроме одного неудобного факта: этот механизм, который теперь так сложно переделать, бизнес сам же и согласовывал. Просто в тот момент никто не думал о последствиях, потому что нужно было закрыть квартал.
Технический долг не появляется сам. Его создают конкретные люди в конкретные моменты — когда на встрече говорят «запускаем как есть, потом разберёмся», когда на нормальную проработку не выделяют ни времени, ни бюджета, потому что «это же просто техническая история», когда на вопрос «а что будет через два года с этим решением?» отвечают «не забивай голову, сделай чтобы работало, дальше допилим». Каждое такое решение — это кредит. Без договора, без графика погашения, без понимания, сколько это будет стоить через три года. Просто берут — и забывают.
IT этот кредит не брал. IT его обслуживает.
И здесь важно понять механику: чем дольше долг существует, тем дороже его обслуживание. Первый год — небольшие неудобства. Третий год — задача, которая должна была занять две недели, растягивается на три месяца, потому что никто не понимает, как всё это связано внутри. Пятый год — команда тратит большую часть времени не на развитие, а на поддержку того, что давно пора было переделать, и каждый новый запрос от бизнеса встречает в ответ усталое «мы не можем». Не потому, что не хотят. Потому что система физически не позволяет двигаться быстро.
Именно поэтому технический долг — это не IT-проблема. Это финансовый инструмент с очень высокой процентной ставкой, которую бизнес платит годами, часто даже не осознавая, что именно он оплачивает.
Выгоревшая команда — это не HR-проблема
Технический долг имеет ещё одно измерение, о котором редко говорят вслух, — человеческое. Пока бизнес и IT выясняют, почему новая функция занимает три месяца вместо двух недель, внутри команды происходит кое-что похуже медленной разработки.
Представьте, каково это — приходить на работу каждый день и заниматься одним и тем же. Не развивать продукт, не решать интересные задачи, а латать то, что когда-то сделали на скорую руку и что с тех пор никто не решился переделать нормально. Каждый новый запрос от бизнеса встречает уже знакомое препятствие — очередной слой из старых решений, который нужно сначала обойти, прежде чем двигаться дальше. Люди технически компетентны, они понимают, как должно быть устроено, но работают в системе, которая физически не позволяет делать это правильно. Это изматывает сильнее любой высокой нагрузки.
Выгорание команды чаще всего списывают на переработки, токсичную атмосферу или низкие зарплаты. Но я видел команды, где люди были готовы уволиться все и одновременно — не потому что мало платили и не потому что плохо обращались, а потому что годами делали одно и то же, не двигаясь вперёд, и не понимали, зачем вообще всё это. Когда человек не видит смысла в том, что делает и не понимает, куда это ведёт — никакой корпоратив и никакой ДМС этого не компенсирует.
И здесь снова возникает вопрос управленческой ответственности. Приоритеты меняются несколько раз в неделю, задачи бросаются на полпути ради чего-то «более срочного», планирования нет вообще или оно существует формально — люди работают в режиме постоянного переключения, каждое из которых съедает ментальный ресурс. В конце дня у каждого ощущение, что ничего не доведено до конца, хотя весь день был занят. Это и есть выгорание — не от объёма, а от хаоса, который транслируется сверху вниз и становится нормой.
Команда горит не потому, что слабая. Она горит потому, что не видит берега и не понимает, куда грести.
Что с этим делать
Честный ответ — не быстро и не легко. Но начинается всё с двух вещей, которые не требуют ни больших бюджетов, ни сложных методологий.
Первое — измерить. Не по ощущениям, а в цифрах: сколько времени команда тратит на поддержку того, что уже существует, и сколько остаётся на развитие нового. По данным Gartner и Computer Economics, в среднем по рынку компании тратят 65–66% IT-ресурсов на поддержку существующего — и это уже считается нормой. Когда цифра уходит за 75–80%, IT фактически перестаёт развивать бизнес и полностью переходит в режим выживания. Если вы никогда не считали это соотношение — считайте, что вы управляете машиной, не зная, сколько в ней топлива.
Второе — перестать переобуваться в середине исполнения плана. Большая часть хаоса, который выжигает команды, рождается не из сложности задач, а из постоянной смены приоритетов. Зафиксируйте горизонт хотя бы на две недели и не меняйте его без серьёзного основания. Это звучит банально — но именно это отличает руководителя, которому доверяют, от кричащей и суетящейся головы, которую боятся.
Технический долг не исчезнет сам и не рассосётся после одного спринта. Но осознанные решения — принятые заранее, с пониманием их стоимости, а не в пятницу вечером под давлением — постепенно меняют картину. Сначала команда начинает понимать, куда она гребёт. Потом появляется берег.
Вместо заключения
Технический долг вашей компании — это список всех решений, принятых перед дедлайном, под давлением обстоятельств. Каждое из них казалось разумным в тот момент. Но ни одно из них не было бесплатным.
Посчитайте, сколько времени ваша команда тратит на поддержку того, что «временно» запустили несколько лет назад. Это и есть процентная ставка по вашему кредиту.
