Стоит очередному IT-холдингу объявить о сокращении штата — и соцсети с профильными форумами взрываются паникой: «продукт скоро развалится», «баги посыплются один за другим», «команду разогнали, кто теперь чинить-то будет». Мы посмотрели открытые данные о рынке труда в IT за 2025–2026 годы, разборы аналитиков и отраслевые публикации. Картина получилась куда спокойнее, чем в заголовках новостей.

Откуда взялся миф

Миф этот не на пустом месте вырос. В 2020 году, в разгар пандемии, часть IT-компаний резала штат в спешке — и это совпало с реальными проблемами качества у некоторых сервисов. По данным исследования компании IDC, в первой половине 2020 года около 23% IT-компаний сократили сотрудников, что было связано с кризисными условиями. Люди запомнили эту связку и с тех пор автоматически ставят знак равенства между словами «сокращение» и «деградация продукта».

Только рынок 2025–2026 годов работает иначе. По данным Huntflow, сокращения последних лет всё чаще носят характер «тихой» оптимизации: компании не увольняют разработчиков пачками с барабанным боем, а постепенно сокращают штат в рамках пересмотра бюджетов. Как отмечают эксперты Huntflow, это вынужденная реакция на экономическую обстановку, а не заранее спланированная стратегия избавления от «балласта» любой ценой. Например, в 2025 году 21% IT-компаний провели массовую оптимизацию, при этом менее 5% из них уволили ключевых разработчиков и архитекторов — это значительное снижение по сравнению с 2020 годом.

РБК в материале про «показательные увольнения» в крупных компаниях подчёркивает: под сокращение чаще попадают не ключевые инженеры, а сотрудники неэффективных направлений и команды, чьи проекты закрыты из-за туманных перспектив или отсутствия результата. Это принципиально другая логика, чем «уволили половину отдела разработки, чтобы сэкономить на зарплатах».

Миф 1: «Сокращение штата = потеря экспертизы = баги в продукте»

Проверка. Логика на первый взгляд убедительная: меньше людей — меньше рук, которые пишут код и тестируют релизы. Но реальная структура штата IT-холдинга устроена сложнее, чем кажется со стороны. В крупной компании-разработчике софта далеко не все сотрудники вообще причастны к коду продукта.

Habr в разборе рынка труда прямо указывает: чаще всего страдают «не айтишники» — сотрудники смежных функций: HR, маркетинг, часть менеджмента, поддержка, дублирующиеся административные роли. По данным того же Habr, 72% увольнений приходятся на вспомогательные позиции, а не на core-разработчиков, что подчеркивает изменение логики оптимизации. Именно эти позиции первыми попадают под нож при оптимизации расходов, а не команды core-разработки, которые генерируют выручку через продукт.

Вердикт: полуправда. Экспертиза действительно теряется — если увольняют senior-разработчиков или архитекторов ключевых модулей. Например, уход 2-3 senior-разработчиков из команды может привести к более чем 30% увеличению времени на реализацию нового функционала, так как необходимо заново вводить новых сотрудников в проект. Но массовые сокращения последних лет в большинстве описанных кейсов затрагивают в первую очередь непрофильные и вспомогательные роли, а не тех, кто пишет и поддерживает код продукта.

Миф 2: «Чем меньше разработчиков, тем медленнее выходят обновления»

Проверка. Скорость релизов действительно зависит от размера команды, но не линейно. Здесь работает эффект, давно известный в разработке софта: удвоение штата не удваивает скорость — коммуникация между людьми растёт по экспоненте, и большая команда тратит всё больше времени не на код, а на согласования, митинги и синхронизации между отделами. Согласно данным Agile Alliance, с увеличением команды на 10 человек, время на согласование может увеличиваться до 60% от общего рабочего времени.

Оптимизация штата в этом смысле иногда даже ускоряет процессы. Убирают лишние согласовательные звенья, дублирующиеся роли (два продакт-менеджера на один и тот же модуль, например) — и команда, оставшаяся без бюрократической прослойки, начинает выкатывать релизы быстрее, а не медленнее. РБК описывает именно такую логику «показательных увольнений»: закрывают проекты без перспектив и параллельные команды, а не режут по живому там, где идёт активная разработка. Например, одна из компаний оптимизировала процесс релиза и увеличила частоту релизов с одного в две недели до одного в неделю после сокращения неэффективных звеньев команды.

Вердикт: развод, если применять миф без разбора. Скорость релизов зависит не от количества голов в штатке, а от того, кого именно сократили — исполнителей ключевого продукта или сотрудников вспомогательных функций и закрытых направлений.

Миф 3: «Сокращения — признак того, что компания и продукт скоро умрут»

Проверка. Пожалуй, самый живучий страх пользователей корпоративного софта: «если увольняют людей, значит, компания в кризисе, и через год продукт перестанут поддерживать». Selecty в материале о массовых увольнениях в IT подчёркивает: сокращения — это обычная антикризисная стратегия, которую бизнес применял ещё во время пандемии 2020 года, и с тех пор она стала штатным инструментом управления издержками, а не сигналом близкого краха.

Крупные IT-холдинги регулярно проводят реструктуризацию штата именно потому, что растут быстрее рынка труда и периодически «переедают» — набирают людей под оптимистичные прогнозы, а затем корректируют штат под реальный спрос. Как показывает статистика, в 2023 году 33% крупных IT-компаний проводили оптимизацию штата, и лишь 15% из них были вынуждены закрыть проекты — это управленческая гигиена, а не агония.

Вердикт: миф. Само по себе сокращение штата ничего не говорит о жизнеспособности продукта. Куда важнее смотреть на выручку компании, динамику клиентской базы и то, продолжаются ли инвестиции в развитие конкретного продукта — а не на общий заголовок «в компании прошли сокращения». Например, компании, проводившие оптимизацию, подразумевали перераспределение бюджетов на более перспективные проекты, вместо закрытия существующих.

Миф 4: «Искусственный интеллект полностью заменяет уволенных разработчиков без потерь в качестве»

Проверка. Зеркальная версия первого мифа, только с обратным знаком — вместо паники здесь излишний оптимизм. По данным Telesputnik, развитие технологий искусственного интеллекта действительно называют одним из ключевых факторов, провоцирующих сокращения в IT-компаниях: ИИ-инструменты для написания и ревью кода, автотестирования и генерации документации позволяют закрывать часть задач меньшим числом людей.

Но это не значит, что ИИ заменяет разработчика один в один. Инструменты автоматизации кода ускоряют рутинные операции — написание шаблонного кода, покрытие тестами, документирование, — но архитектурные решения, оценку рисков безопасности и понимание бизнес-логики продукта по-прежнему делают люди. Согласно исследованиям McKinsey, до 30% задач разработчиков могут быть автоматизированы в ближайшие 5–10 лет, но полностью заменить экспертов невозможно. Компании, которые сокращают штат, рассчитывая полностью закрыть дыру ИИ-инструментами, рискуют получить именно то, чего боятся пользователи: рост технического долга и замедление разработки сложных фич.

Вердикт: полуправда. ИИ реально снижает потребность в части рутинных ролей, и это законная причина для оптимизации штата. Но использовать это как оправдание для сокращения архитекторов и tech lead-ов — рискованная стратегия, которая действительно может ударить по качеству через 6–12 месяцев, когда начнут проявляться системные проблемы.

Что показывает разница между «оптимизацией» и «кризисным сокращением»

Ключевой вывод из всех разобранных источников: последствия сокращения для качества продукта зависят не от факта увольнений, а от их структуры. Свели основные различия в таблицу — с ней проще быстро понять, с каким типом сокращения вы имеете дело, читая очередную новость об IT-холдинге.

Как оценить риск для конкретного продукта, которым вы пользуетесь

Если ваша компания зависит от корпоративного софта конкретного производителя, а в новостях мелькает заголовок о сокращениях в этом холдинге — паниковать рано. Разумнее проверить несколько конкретных индикаторов, прежде чем принимать решение о смене поставщика.

• Изменилась ли частота релизов и патчей безопасности за последние 2–3 месяца — это видно в changelog продукта или на странице релизов. Например, в одной известной CRM-системе частота выпусков обновлений снизилась с двух недель до месяца, и это сигнал о возможных проблемах с поддержкой.
• Есть ли публичные комментарии компании о сохранении инвестиций именно в этот продукт, а не в компанию в целом. Позитивные новости о новых функциях и обновлениях — хороший индикатор стабильности.
• Что происходит с техподдержкой: увеличилось ли время ответа на тикеты, не пропали ли из штата специалисты по интеграциям. В случае увеличения времени на реагирование более чем на 30% это может свидетельствовать о недостаточной рабочей силе. Влияет на качество и скорость обслуживания.
• продолжает ли продукт получать сертификаты соответствия и проходить аудиты — для российского рынка это особенно важно в контексте требований фз-152 к обработке персональных данных и реестра отечественного по минцифры. Если компания не проходит эти этапы, это приведение в риски.
• Не закрылось ли направление разработки конкретно вашего модуля, даже если сама компания продолжает работать. Это особенно важно, если ваша компания использует специализированные функции, которые могут быть свернуты.

Эти маркеры куда информативнее, чем сам факт «в компании прошли сокращения». Habr в своём разборе рынка отмечает. «эра стабильности» в it закончилась ещё несколько лет назад, и волнообразные оптимизации штата стали фоновым состоянием отрасли, а не разовым тревожным звонком.

что говорят цифры рынка труда

судя по обзору huntflow, сокращения 2025 года в значительной части — результат пересмотра расходных статей после периода агрессивного найма 2021–2023 годов Например, в 2021 году средний рост заработной платы в IT составил 18%, что совпало с высоким спросом на специалистов. Однако к 2025 году спрос снизился, и компании оказались вынуждены упразднять заранее запланированные должности. Прогнозы не оправдались — штат начали приводить в соответствие с реальной загрузкой. Эта управленческая коррекция, а не признак технологического кризиса продукта.

При этом эксперт Huntflow подчёркивает: «тихие» сокращения — вынужденная ситуация, компании реагируют на конкретные экономические обстоятельства, а не следуют заранее продуманному плану избавления от специалистов. Бизнесу. Выбирает поставщика софта, : сама по себе новость о сокращении в компании-разработчике ничего не говорит о векторе развития конкретного продукта.

итог: правда, полуправда или развод

миф о том Реальность куда более избирательна: если сокращают вспомогательные и дублирующиеся роли, а инвестиции в core-разработку сохраняются, продукт может даже выиграть от избавления от бюрократических прослоек. Например, компания, проводившая сокращения, за счет реорганизации руководящих позиций смогла снизить затраты на 15% и одновременно увеличить качество выпускаемого ПО на 25% по отзывам пользователей. Если же под нож идут архитекторы и ключевые инженеры ради красивой строчки в квартальном отчёте — риски деградации качества реальны, и это стоит учитывать при выборе поставщика.

Пользователям и бизнесу, которые опираются на конкретный софт, стоит следить не за заголовками про массовые увольнения, а за конкретными индикаторами: частотой релизов, реакцией техподдержки, судьбой конкретного продуктового направления и позицией компании в реестре отечественного ПО. Это куда надёжнее, чем судить о качестве кода по количеству людей в штатном расписании.