Тендер требует 100 человек в штате. Почему это реальная проблема для заказчика.

Открываешь тендерную документацию на разработку информационной системы — и попадаешь в 2015 год. Требование: не менее 100 специалистов в штате. Заказчик оценивает не результат, а количество голов. При этом четыре человека с выстроенным ИИ-стеком закрывают тот же объём задач — но формально не проходят квалификационный отбор. Это не жалоба. Это диагноз системе, которая защищает неэффективность и наказывает за технологическую зрелость.

Февраль 2026 года. Крупный государственный заказчик размещает конкурс на разработку платформы с элементами машинного обучения. Бюджет — десятки миллионов рублей. Задача технически понятная: классификация документов, NLP-пайплайн, интеграция с внутренними системами. Четыре инженера с правильным стеком и опытом в RAG-архитектурах закроют это за 4–5 месяцев.

Но в квалификационных требованиях — «не менее 100 штатных специалистов». Отдельно прописаны роли: системный архитектор, бизнес-аналитик, тестировщик, DevOps-инженер, специалист по информационной безопасности, технический писатель — и так далее, 10–15 позиций с требованием подтверждения дипломами и трудовыми книжками.

И это не уникальный случай. Мы мониторим тендерные площадки — и коммерческие, и государственные. Хорошие, интересные проекты с адекватными техническими задачами регулярно обвешаны требованиями, которые не имеют отношения к результату. Либо документацию пишут под конкретного подрядчика, либо заказчик искренне верит, что 100 человек в 2026 году — это гарантия качества.

Ни то, ни другое не работает в пользу заказчика.

Давайте посмотрим на ситуацию глазами бизнеса, а не бюрократии.

Допустим, вы CTO или продакт, и вам нужна платформа классификации документов с NLP. Вы идёте на рынок и видите два предложения:

Любой вменяемый предприниматель задаст один вопрос: «Какой результат я получу и за какие деньги?» Не «сколько у вас людей в штатном расписании».

Но многие закупки устроены иначе. Здесь выбирают не результат, а соответствие формальным критериям. И критерий «100 человек в штате» автоматически отсеивает вариант Б — даже если он объективно лучше по всем метрикам: срок, стоимость, качество, скорость адаптации.

Это не теоретическая проблема. Это реальные деньги — в том числе бюджетные деньги.

У привязки к штатной численности есть причины, и они не сводятся к глупости закупщиков. Это системная логика, которая самовоспроизводится.

Квалификационные требования в российских тендерах — это юридические документы. Их составляют юристы и закупщики, а не технические специалисты. Шаблон, написанный в 2018 году, кочует из конкурса в конкурс с минимальными правками. Требование «N специалистов в штате» — стандартный блок, который никто не ставит под сомнение, потому что «так всегда делали».

Это классическая институциональная инерция. Каждый конкретный закупщик действует рационально: зачем менять шаблон, если с ним уже прошли десятки закупок без жалоб? Риск изменения выше, чем риск стагнации. В масштабе системы это означает, что критерии оценки подрядчиков отстают от реальности на 5–8 лет.

Если подрядчик с 200 людьми провалит проект — виноват подрядчик. Если закупщик выберет команду из 5 человек и проект провалится — «почему выбрали маленькую компанию?». Обратного вопроса — «почему выбрали раздутую команду, которая не справилась?» — никто не задаёт.

Эта асимметрия ответственности порождает асимметрию критериев. Закупщик оптимизирует не качество результата, а собственную безопасность. И с его позиции это абсолютно рациональное поведение.

Человек в штате — это трудовой договор, должностная инструкция, KPI, понятная отчётность. ИИ-инструмент — это лицензия, API, модель, которую нельзя вызвать на совещание и спросить «когда будет готово?». Для управленца, выросшего в парадигме «больше людей — больше контроля», переход к оценке по результату требует перестройки мышления. Это болезненно, и большинство предпочитает не начинать.

Когда у вас 100 человек на проекте, у вас есть иллюзия управляемости. Можно поставить менеджера над менеджером, нарисовать диаграмму Ганта, проводить ежедневные стендапы. Когда у вас четыре человека с ИИ-стеком — вам нужно уметь оценивать результат. А это принципиально другой навык.

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

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

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

Если закупщик выберет подрядчика с 200 людьми и проект провалится — это «не повезло с подрядчиком». Рутинная неудача. Никто не будет задавать вопросов.

Если выберет команду из 4 человек с ИИ-стеком и проект провалится — это «безответственное решение». Карьерный риск. Разбор полётов. «Кто это согласовал?»

Результат одинаковый — провальный проект. Последствия для принимающего решение — диаметрально разные.

Этот принцип работает не только в госзакупках. Он пронизывает весь корпоративный мир. Но в государственном секторе он особенно разрушителен, потому что здесь нет рыночной обратной связи. Частная компания, которая систематически переплачивает за раздутые команды, теряет конкурентоспособность и в итоге уходит с рынка. Государственный заказчик — нет.

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

Давайте переведём проблему в цифры, понятные любому предпринимателю.

Стоимость содержания. Средняя зарплата разработчика в Москве — от 250 тыс. рублей. С налогами, офисом, оборудованием и накладными расходами — около 400–500 тыс. рублей в месяц на человека. Команда из 100 человек обходится в 40–50 млн рублей в месяц только на содержание. За год проекта — 500–600 млн рублей.

Команда из четырёх человек с ИИ-стеком — 2–3 млн рублей в месяц, включая подписки на модели и инфраструктуру.

Коммуникационные потери. Закон Брукса не отменён: добавление людей на поздних стадиях проекта замедляет его. Но есть менее известный эффект: количество коммуникационных связей растёт как n(n-1)/2. В команде из 4 человек — 6 связей. В команде из 25 (типичная проектная группа из штата в 100 человек) — 300 связей. Каждая связь — это потенциальное недопонимание, согласование, встреча.

На практике это означает, что значительная часть рабочего времени большой команды уходит не на разработку, а на координацию. По разным оценкам — от 30% до 60%. Четыре человека, сидящие в одном чате, тратят на координацию около 5% времени.

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

Скорость адаптации. Если в процессе проекта меняются требования (а они меняются всегда), маленькая команда перестраивается за дни. Большая — за месяцы, потому что нужно переписать ТЗ, пересогласовать с пятью отделами, перераспределить задачи между тремя подкомандами.

Итого: заказчик платит в 5–10 раз больше, получает результат в 2–3 раза позже и получает систему, которая хуже адаптирована к реальным потребностям. Но формально — всё корректно. 100 человек в штате были.

Можно было бы сказать: «Так было всегда, крупные подрядчики всегда выигрывали тендеры». Отчасти верно. Но за последние три года произошёл качественный сдвиг, который делает разрыв между формальными требованиями и реальностью критическим.

ИИ-инструменты вышли на уровень production-ready. Если в 2022 году GPT-3 был экспериментом, то в 2025–2026 году ИИ-агенты — это рабочий инструмент. Мы используем их для генерации кода, тестирования, документации, анализа требований, прототипирования интерфейсов. Один инженер с правильно настроенным ИИ-стеком выполняет объём работы, который три года назад требовал 5–7 человек.

Это не маркетинг. Это наш реальный опыт из более чем 20 проектов. Задача, которая раньше занимала у разработчика две недели, сейчас решается за два-три дня — при том же или более высоком качестве.

Инфраструктура стала доступнее. CI/CD, облачные платформы, managed-сервисы — всё это позволяет маленькой команде управлять инфраструктурой, которая раньше требовала отдельного DevOps-отдела. Kubernetes, Terraform, GitHub Actions — один инженер закрывает то, что раньше делали пятеро.

Качество инструментов разработки выросло кратно. Современные IDE с ИИ-ассистентами, автоматизированное тестирование, code review с помощью LLM, автоматическая генерация документации — каждый из этих инструментов сокращает трудозатраты на 20–40% по отдельным операциям. В совокупности — мультипликативный эффект.

Кадровый рынок изменился. Нанять 100 квалифицированных специалистов в 2026 году — сама по себе нетривиальная задача. Дефицит IT-кадров в России оценивается в 500–700 тысяч человек. Компании, которые действительно держат 100 человек в штате, далеко не всегда могут гарантировать, что все они — специалисты нужного уровня. Часть — джуны для массовки, часть — на скамейке между проектами, часть — в процессе онбординга.

То есть само требование «100 человек в штате» уже не гарантирует то, ради чего оно задумывалось: наличие достаточного количества квалифицированных ресурсов для выполнения проекта.

Любая устойчивая неэффективность существует потому, что кто-то от неё выигрывает. Давайте честно разберём бенефициаров.

Крупные интеграторы и аутсорсеры. Для них FTE-требования — это барьер входа, который защищает от конкуренции со стороны более эффективных команд. Зачем оптимизировать процессы и внедрять ИИ, если можно просто выставить 100 человек и выиграть по формальным критериям? Это рациональная стратегия в рамках существующих правил, но она тормозит развитие всей отрасли.

Закупщики и чиновники. Как мы уже разобрали — для них FTE-требования это страховка. Личная безопасность важнее эффективности закупки.

Кому вредит?

Заказчику. Он получает более дорогой, более медленный и часто менее качественный продукт. Бюджетные деньги расходуются неэффективно.

Малым технологическим командам. Они не могут участвовать в крупных проектах, даже если объективно способны их выполнить лучше. Это сужает рынок и снижает конкуренцию.

Инновационной экосистеме в целом. Когда система закупок не признаёт технологическую эффективность, у компаний нет стимула инвестировать в ИИ-инструменты и оптимизацию процессов. Зачем, если рынок вознаграждает за размер штата, а не за качество работы?

Конечным пользователям. Государственные информационные системы, разработанные раздутыми командами по устаревшим методологиям, часто работают плохо. Мы все сталкиваемся с неудобными госпорталами и падающими сервисами — и отчасти причина именно в том, как выбираются подрядчики.

Мы не питаем иллюзий, что система изменится за один день. Но есть конкретные шаги, которые могли бы сдвинуть ситуацию.

Вместо «не менее 100 человек в штате» — «продемонстрировать способность выполнить задачу сопоставимого масштаба». Портфолио, работающие прототипы, референсы заказчиков. Конкретный результат вместо абстрактного количества.

Да, это сложнее оценивать. Да, это требует технической экспертизы на стороне заказчика. Но это единственный способ получить лучший результат за те же деньги.

Допустить к тендеру всех, кто прошёл минимальный порог. Дать 2–4 недели и ограниченный бюджет на создание прототипа. Оценить результат — не презентацию, а работающий код. Выбрать подрядчика на основе реального результата.

Этот подход уже работает в коммерческом секторе. Крупные компании проводят технические конкурсы, хакатоны, пилоты — и выбирают по качеству, а не по размеру.

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

Микросервисная архитектура в закупках, если хотите.

Ввести в критерии оценки коэффициент технологической зрелости: какие инструменты использует команда, какова производительность на человека, какова автоматизация процессов. Команда из 4 человек, которая закрывает объём работы 20 человек, должна получать преимущество, а не дисквалификацию.

Привлекать независимых технических экспертов к оценке заявок. Не юристов, которые проверяют наличие печатей, а инженеров, которые могут оценить реалистичность технического предложения. Это стандартная практика в грантовых конкурсах и научных проектах — пора применить её к IT-закупкам.

Справедливый вопрос. Давайте разберём риски честно.

Автобусный фактор. Если в команде из 4 человек один выходит из строя — это потеря 25% мощности. В команде из 100 — это 1%. Это реальный риск, и его нужно митигировать: документация, bus factor planning, контрактные обязательства по замене.

Но давайте посмотрим на обратную сторону. В команде из 100 человек текучесть кадров — 15–20% в год. Это значит, что за год проекта 15–20 человек уйдут и будут заменены новыми, которым нужен онбординг. Реальная потеря производительности от текучки в большой команде часто выше, чем риск потери одного человека в маленькой.

Масштабирование. Некоторые проекты действительно требуют масштаба: миграция данных из 50 источников, интеграция с 30 системами, поддержка 10 часовых поясов. Четыре человека физически не смогут быть везде одновременно.

Но ключевое слово — «некоторые». Большинство проектов, которые мы видим в тендерах, не требуют 100 человек. Они требуют 100 человек только потому, что так написано в шаблоне.

Ответственность и гарантии. Маленькая компания не может предложить такие же финансовые гарантии, как крупный интегратор. Это факт. Но можно решить через страхование профессиональной ответственности, эскроу-счета, поэтапную оплату по результатам. Механизмы существуют — их просто не используют.

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

Большинство крупных IT-компаний работают по модели «скамейка» (bench). В любой момент времени значительная часть сотрудников находится между проектами. Когда выигрывается новый тендер, команда собирается из тех, кто свободен, — не обязательно из лучших специалистов для конкретной задачи.

Часто крупный подрядчик, выигравший тендер с требованием «100 человек в штате», фактически ставит на проект 15–20 человек, а остальные 80 числятся для формального соответствия. Заказчик платит за 100, а работают 20. И эти 20 не всегда лучше, чем 4 человека, которые специализируются именно на этой технологии.

Ещё более распространённый сценарий: крупный подрядчик выигрывает тендер и передаёт часть работы на субподряд — тем самым маленьким командам, которые не прошли квалификационный отбор. Только теперь с наценкой 30–50% и потерей прямой коммуникации с заказчиком.

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

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

Но параллельно мы считаем важным говорить об этой проблеме открыто. Потому что она касается не только нас.

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

Всё это — не злой умысел. Это следствие системы, которая оптимизирована под процедурную корректность, а не под результат. Система работает ровно так, как спроектирована.

Но она спроектирована для другой эпохи. Эпохи, когда количество людей действительно коррелировало с количеством работы. В 2026 году эта корреляция разрушена. Четыре человека с ИИ-стеком — это не четыре человека. Это четыре человека плюс инструменты, которые мультиплицируют их возможности в разы.

Пока система закупок не признает эту реальность, мы будем продолжать жить в мире, где лучший подрядчик не может даже подать заявку.

Если вы заказчик, формирующий тендерную документацию, — задайте себе один вопрос: «Требование N человек в штате помогает мне получить лучший результат или помогает мне чувствовать себя в безопасности?»

Если второе — возможно, есть более эффективные способы управления рисками. Пилотные проекты, поэтапная приёмка, независимая экспертиза — всё это снижает риск без ограничения конкуренции.

А если вы предприниматель, CTO или продакт, который сталкивается с похожими барьерами, — давайте обсудим. Не для того чтобы жаловаться, а чтобы выработать подходы, которые работают в текущих реалиях. Система меняется медленно. Но рынок меняется быстро. И те, кто адаптируется первыми, получают преимущество.

https://vibelab.ru

Подписывайся на Телеграм Вайблаб, чтобы наблюдать за тем, как мы строим AI-first компанию.

Напишите нам напрямую