Всем привет! Меня зовут Илья Есейкин и я IT-управленец среднего звена, веду небольшой (пока) Telegram-канал о цифровой зрелости бизнеса. Это моя первая статья на Habr — пишу о том, что видел изнутри: несколько компаний, разные отрасли, реальные кейсы. Стараюсь обойтись без корпоративного глянца и универсальных рецептов. Если тема откликается — буду рад обратной связи в комментариях.
Есть фраза, которую многие из нас слышал во всех компаниях, отрасли разные, но фраза всегда звучала примерно одинаково: «Ну сделайте пока так, потом переделаем нормально». Она произносится обычно, когда дедлайн завтра, бюджет кончается, а продукт надо показать на демо. И именно из таких моментов, помноженных на годы, состоит то, что принято называть техническим долгом — не абстрактная IT-проблема, а вполне конкретный список управленческих выборов, сделанных под давлением обстоятельств.
Как это устроено изнутри
Механика всегда одна. Бизнес давит — нужно запустить до конца квартала. Архитектура подождёт. Документацию напишем потом — всё равно её никто не читает, кроме того, кто её написал. Переделать то, что работает криво, но работает — тоже потом, сейчас не до этого. Главное, чтобы запустилось.
И оно запускается. Все довольны, квартал закрыт.
Проходит год, два, пять. Система незаметно обрастает костылями — каждая новая доработка натыкается на предыдущее «временное» решение, обходит его, добавляет свой слой поверх. Разработчики, которые это строили, давно ушли. Документации нет. Остался один человек, который «примерно помнит, как оно работает», и это единственная живая нить к пониманию того, что происходит внутри системы.
И вот в этот момент бизнес приходит к IT с простым запросом: нужна новая фича, она ускорит процесс, увеличит конверсию, сократит время обработки — нужное подчеркнуть. В ответ IT говорит: "не можем". Не потому, что это для них сложно и не потому, что нет ресурса, а потому что под этим запросом лежит проблема, которая не даст новой функции нормально заработать. Три года назад что-то сделали быстро, на время — временное заработало и осталось навсегда. Потом поверх него сделали ещё одно временное, потом ещё. Сейчас это слоёный пирог из решений, каждое из которых кто-то когда-то считал промежуточным, и чтобы добавить новую функцию, нужно сначала разобрать несколько слоёв этого пирога — а это уже не одна кнопка и не одна неделя работы.
Бизнес удивлён. IT устал объяснять. Обе стороны правы — и обе в тупике.
Кто реально берёт кредит
Когда бизнес приходит к IT с вопросом «почему так медленно и так дорого» — он не хочет слышать про архитектуру, про накопленные проблемы и про сложность того, что было построено раньше. Он хочет одного: чтобы это быстро переделали, потому что вы же специалисты, вам за это и платят. И в этом нет ничего удивительного — кроме одного неудобного факта: этот механизм, который теперь так сложно переделать, бизнес сам же и согласовывал. Просто в тот момент никто не думал о последствиях, потому что нужно было закрыть квартал.
Технический долг не появляется сам. Его создают конкретные люди в конкретные моменты — когда на встрече говорят «запускаем как есть, потом разберёмся», когда на нормальную проработку не выделяют ни времени, ни бюджета, потому что «это же просто техническая история», когда на вопрос «а что будет через два года с этим решением?» отвечают «не забивай голову, сделай чтобы работало, дальше допилим». Каждое такое решение — это кредит. Без договора, без графика погашения, без понимания, сколько это будет стоить через три года. Просто берут — и забывают.
IT этот кредит не брал. IT его обслуживает.
И здесь важно понять механику: чем дольше долг существует, тем дороже его обслуживание. Первый год — небольшие неудобства. Третий год — задача, которая должна была занять две недели, растягивается на три месяца, потому что никто не понимает, как всё это связано внутри. Пятый год — команда тратит большую часть времени не на развитие, а на поддержку того, что давно пора было переделать, и каждый новый запрос от бизнеса встречает в ответ усталое «мы не можем». Не потому, что не хотят. Потому что система физически не позволяет двигаться быстро.
Именно поэтому технический долг — это не IT-проблема. Это финансовый инструмент с очень высокой процентной ставкой, которую бизнес платит годами, часто даже не осознавая, что именно он оплачивает.
Выгоревшая команда — это не HR-проблема
Технический долг имеет ещё одно измерение, о котором редко говорят вслух, — человеческое. Пока бизнес и IT выясняют, почему новая функция занимает три месяца вместо двух недель, внутри команды происходит кое-что похуже медленной разработки.
Представьте, каково это — приходить на работу каждый день и заниматься одним и тем же. Не развивать продукт, не решать интересные задачи, а латать то, что когда-то сделали на скорую руку и что с тех пор никто не решился переделать нормально. Каждый новый запрос от бизнеса встречает уже знакомое препятствие — очередной слой из старых решений, который нужно сначала обойти, прежде чем двигаться дальше. Люди технически компетентны, они понимают, как должно быть устроено, но работают в системе, которая физически не позволяет делать это правильно. Это изматывает сильнее любой высокой нагрузки.
Выгорание команды чаще всего списывают на переработки, токсичную атмосферу или низкие зарплаты. Но я видел команды, где люди были готовы уволиться все и одновременно — не потому что мало платили и не потому что плохо обращались, а потому что годами делали одно и то же, не двигаясь вперёд, и не понимали, зачем вообще всё это. Когда человек не видит смысла в том, что делает и не понимает, куда это ведёт — никакой корпоратив и никакой ДМС этого не компенсирует.
И здесь снова возникает вопрос управленческой ответственности. Приоритеты меняются несколько раз в неделю, задачи бросаются на полпути ради чего-то «более срочного», планирования нет вообще или оно существует формально — люди работают в режиме постоянного переключения, каждое из которых съедает ментальный ресурс. В конце дня у каждого ощущение, что ничего не доведено до конца, хотя весь день был занят. Это и есть выгорание — не от объёма, а от хаоса, который транслируется сверху вниз и становится нормой.
Команда горит не потому, что слабая. Она горит потому, что не видит берега и не понимает, куда грести.
Что с этим делать
Честный ответ — не быстро и не легко. Но начинается всё с двух вещей, которые не требуют ни больших бюджетов, ни сложных методологий.
Первое — измерить. Не по ощущениям, а в цифрах: сколько времени команда тратит на поддержку того, что уже существует, и сколько остаётся на развитие нового. По данным Gartner и Computer Economics, в среднем по рынку компании тратят 65–66% IT-ресурсов на поддержку существующего — и это уже считается нормой. Когда цифра уходит за 75–80%, IT фактически перестаёт развивать бизнес и полностью переходит в режим выживания. Если вы никогда не считали это соотношение — считайте, что вы управляете машиной, не зная, сколько в ней топлива.
Второе — перестать переобуваться в середине исполнения плана. Большая часть хаоса, который выжигает команды, рождается не из сложности задач, а из постоянной смены приоритетов. Зафиксируйте горизонт хотя бы на две недели и не меняйте его без серьёзного основания. Это звучит банально — но именно это отличает руководителя, которому доверяют, от кричащей и суетящейся головы, которую боятся.
Технический долг не исчезнет сам и не рассосётся после одного спринта. Но осознанные решения — принятые заранее, с пониманием их стоимости, а не в пятницу вечером под давлением — постепенно меняют картину. Сначала команда начинает понимать, куда она гребёт. Потом появляется берег.
Вместо заключения
Технический долг вашей компании — это список всех решений, принятых перед дедлайном, под давлением обстоятельств. Каждое из них казалось разумным в тот момент. Но ни одно из них не было бесплатным.
Посчитайте, сколько времени ваша команда тратит на поддержку того, что «временно» запустили несколько лет назад. Это и есть процентная ставка по вашему кредиту.
Комментарии (17)
parakhod_1
06.04.2026 11:24С одной стороны бывает и так. Не очень хорошо.
С другой стороны может быть ещё хуже если во всём слушать исключительно инженеров. Лет восемь назад меня позвали консультировать одну американскую компанию - у их андроидной команды были проблемы. С точки зрения бизнеса были проблемы, они отставали от иоса по фичам почти на код. Куча фич запихивалась как временные решения через webview (это не воспринималось как tech debt, скорее как уступка от разработчиков «ну раз уж вам так сильно надо»).
А чем была занята команда из семи разработчиков? Они уже четвёртый месяц писали супер-продвинутый логгер. Который идеально в архитектурном плане должен был логить в пятнадцать мест идеально собранную телеметрию из идеально сконструированного приложения (хоть учебник по жабе по нему пиши) которое они до того рефакторили уже полтора года.
На реальные фичи у них просто не было времени.
А в той компании начальство было ультралиберальных взглядов, поэтому в каждой команде была полная демократия. И инженеры (андроидные) выбрали тот путь, который они считали верным.
Ну я отчёт написал, конечно. Но не думаю что он кому-то понравился.
Esei Автор
06.04.2026 11:24Спасибо за комментарий, очень ценно, что это - жизненная история.
Я бы тут со своей стороны отметил, а точнее - разделил бы «ультралиберальные взгляды» и отсутствие управленческого контроля. Я не могу сказать точно: меня там не было. Был ли это ультралиберализм или просто руководство не очень хотело погружаться в то, чем заняты инженеры - а это, в свою очередь, управленческий риск.Доверять инженерам, конечно, нужно, но и одним глазом приглядывать за тем, что они реально делают и какая у этого бизнес-ценность, тоже необходимо. Иначе они в построении своих «космических кораблей» очень сильно могут оторваться от бизнес-видения руководства и целей компании.
parakhod_1
06.04.2026 11:24Вас бы туда и не взяли. И меня бы туда не взяли бы на работу. За одно лишь употребление слова «контроль».
Там история именно в стиле управления была, руководство свято верило в демократию на всех уровнях. У них даже самые мелкие решения принимались голосованием.
Esei Автор
06.04.2026 11:24Если это работало и приносило прибыль, то я снимаю шляпу: управленческие навыки такого уровня «бирюзовости» мало у кого есть.
parakhod_1
06.04.2026 11:24Начиная с некоторого размера любой бизнес превращается в говно, которое не тонет, и надо крайне сильно постараться чтобы его утопить.
Я не знаю как у них было раньше, но на тот момент они занимали приличную долю в цифровизации американской системы школьного образования (я на называю компанию, но вычислить при желании можно), и откровенно катались как сыр в масле, даже при достаточно поганом качестве самого продукта.
zgwerby
06.04.2026 11:24Делайте хорошо. Плохо не делайте.
Переобуваться в прыжке - плохо. Но клиент всегда прав.
Костыли на костылях - плохо. Деньги здесь и сейчас - хорошо.Проблема не в том, что эти банальности никто не знает.
Проблема в том, что реальный заказчик живёт в одном мире. Разработчики живут в другом мире. И эти миры редко когда пересекаются, а мир клиента у руководства превалирует над миром разрабов. И мало кто может интегрировать первое во второе.Esei Автор
06.04.2026 11:24И вот тут вы поднимаете очень важный и злободневный вопрос о подготовке IT-управленцев, которые должны не просто ходить и следить за инфраструктурой и за тем, чтобы ничего не падало, а контролировать ресурсы, заботиться о своей команде, для бизнеса подсвечивать все «скрытые места» - зоны, где IT может принести дополнительную ценность или предотвратить риски.
Ведь ключевая задача IT-директора - донести до бизнеса важность работы инженеров, аналитиков, тестировщиков и всех причастных. Нужно изменить сложившееся у топ-менеджмента впечатление, что IT - это лишь обслуживающий персонал, а бизнес (как заказчик со своими требованиями) - «истина в последней инстанции». При этом апеллировать к несостоятельности отдельных требований бизнеса не только можно, но и нужно - в конструктивном ключе, с предложением альтернативных решений.
Вы абсолютно правы: на рынке пока не так много талантливых управленцев, способных интегрировать одно в другое. Именно в этом и заключается настоящий IT-управленческий талант - быть проводником из мира "цифры" в мир бизнеса, ну или наоборот)
japanxt
06.04.2026 11:24К техдолгу нужно относиться с "терпением", как это делает бизнес. Если бизнесу не надо, значит и тебе не надо, будь проще, это не твой код, а бизнеса. А если все таки хочется сделать свою жизнь на проекте более комфортной, то нужно научиться вшивать в оценку на выполнение продуктовых задач время на погашения технического долга. Ну и естественно с бизнесом надо уметь говорить о техдолге, продавать необходимость его погашения.
Esei Автор
06.04.2026 11:24«Ну и естественно с бизнесом надо уметь говорить о техдолге, продавать необходимость его погашения.».
Вот эта ваша фраза - великолепное, лаконичное отражение главной мысли описаной в статье, спасибо!
dkuzminov
06.04.2026 11:24Добавлю от себя. В банковской сфере топ-менеджмент полагает, что контролирует финансовый долг: в конце концов это он подписывает разрешение на его увеличение, или стоит за мерами по урезанию расходов. То есть о том, какие финансовые долги у организации, топ-менеджмент доподлино знает из отчетности. В их головах прочно укореняется: то о чем я не знаю, не существует... А кто-нибудь приходит к ним с отчетами о техническом долге?..
frostsumonner
06.04.2026 11:24Есть тех.долг, а есть ТЕХ.ДОЛГ. Без костылей жить не получится, но надо знать меру. Нельзя размножать плохие решения, но изолировать их. Если у вас личный кривой аналог кафки, который используется в 100 мест, то это полбеды - если у вас 100 разных кривых аналогов кафки, то это фатально. Если у вас есть 10 говносервисов и вы пишите 11 такой же, то в ближайший год вы напишите еще 10. И это больше зависит от разработки.
Отдельно скажу про код ревью: пока код не влит его менять супер дешево. Какой нить мр на 1000 строк можно за день полностью переписать. После влития уже за неделю. После релиза уже месяц. Так что на код ревью надо реально делать ревью.
sergey-gornostaev
06.04.2026 11:24Самый действенный способ борьбы с этим, который я видел - это техдир, способный разговаривать напрямую с учредителями/акционерами и доносить до них цену решений мидл-менеджмента. Каждый раз, когда менеджеры говорят «Ну сделайте пока так, потом переделаем нормально» им надо подсовывать на подпись бумажку, в которой описаны последствия этого решения и принятие ими рисков, а после регистрировать техдолг с планируемой датой закрытия. Когда менеджер будет рапортавать руководству об успешном запуске новой фичи, информировать руководство, что запуск произошёл ценой возникновения техдолга, по которому менеджер риски принял и обязался устранить в такой-то срок. Когда не устранил, и произошёл срыв сроков или сбой, поднимать подписанные бумажки, показывать бенефициарам и объяснять, кто виноват.
Правда, чаще техдиры спорить с менеджментом не желают или даже сами становятся частью этой проблемы, а менеджеры не работают в одной компании достаточно долго, чтобы успеть пострадать от последствий своих решений.
Esei Автор
06.04.2026 11:24Сергей, вы абсолютно правы: суровая правда жизни в том, что действительно таких техдиров - крайне мало. Но если он такой есть, то и бизнесу, и IT‑командам живётся намного легче и спокойнее!
Ну, а дальше мы переходим к вопросам: где таких найти, как оценить квалификацию, чтобы она соответствовала вот такому портрету, и как схантить?)sergey-gornostaev
06.04.2026 11:24Думаю, с такими работает только репутация. Их ищут и нанимают только по знакомствам, а оценивают только по отзывам.
Если же всё-таки нанимаем с улицы человека, который должен будет обеспечить достойный уровень управления техдолгом, то надо смотреть на его поведение на собеседовании. Если человек продаёт себя и обещает золотые горы, то и в работе он будет делать так же, скорее всего. Если задаёт неудобные вопросы и ставит условия, возможно, перед нами нужный вариант. Однозначно, что у нанимающей стороны должно быть признание проблемы с техдолгом, желание это исправить и готовность работать с неудобным человеком.
Если бы я был владельцем бизнеса, у которого по непонятным мне причинам хронические технические проблемы, то привлёк бы внешний аудит для анализа ситуации и кадровое агентство для найма человека, способного взяться за разгребание конюшен. Очевидно, в таких ситуациях нельзя полностью полагаться на менеджмент, при котором проблема возникла, они могут быть не заинтересованы в её исправлении.
MaksimusDecius
Хорошая статья. Одна из тех, которую бизнес никогда не захочет читать, потому что не виноваты и неудобно :)
Esei Автор
Максим, большое спасибо за оценку!У меня всё же есть надежда, что взор бизнеса упадёт на одну из таких статей (если их будет достаточно много), и хотя бы один из руководителей топ-уровня, пусть даже не большой компании, попытается разобраться в том, о чём я написал, и от этого станет немного легче всем - и ему самому, ведь IT станет работать быстрее и качественнее, и его подчинённым всех уровней, ведь их начнут понимать и, соответственно, к их мнению начнут прислушиваться.
Ну, а на тему неиспользования экспертизы, я думаю, я ещё напишу.