Чек-лист для тех, кто хочет заходить в тендеры системно, а не на удачу

По данным CNews за январь—август 2025 года объем ИТ-закупок ПО и оборудования по 44-ФЗ достиг 269,1 млрд рублей, что на 29,7% выше аналогичного периода 2024 года. Для многих ИТ-компаний государство сегодня остается одним из крупнейших и наиболее стабильных заказчиков.

Десять лет назад я был уверен, что выиграть тендер несложно: собрать документы, немного снизить цену и ждать победы. Тогда я работал в телеком-компании, и мы участвовали в закупке на услуги мобильной связи. Контракт был крупный, и мы подошли к нему, как нам казалось, идеально: менеджеры собрали сильное предложение, юристы вычитали договор, маржу мы снизили почти до минимума. В победе не сомневались.

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

Через две недели мне позвонили с электронной площадки:

— У вас несколько дней на обеспечение и подписание контракта. Вы в курсе, что победили?

Оказалось, что участник, занявший первое место, просто не вышел на подписание. Контракт предложили нам как второму участнику. И в этот момент стало по-настоящему тревожно: если бы мы пропустили срок, нас могли признать уклонившимися и включить в реестр недобросовестных поставщиков. Для компании, которая работает с государственными заказчиками, это фактически бан на участие в закупках на два года.

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

С тех пор прошло десять лет. За это время я прошел через сотни закупок по 44-ФЗ и 223-ФЗ, видел, как крупные компании теряли контракты из-за формальной ошибки в заявке, а небольшие команды забирали миллионные ИТ-проекты, потому что лучше готовились. За эти годы я собрал рабочую систему подготовки к ИТ-госзакупкам. В статье собрал то, что действительно помогает снизить риск ошибок и повысить шансы на победу.

Почему ИТ-госзакупки — это отдельная реальность

Госзакупки в ИТ сильно отличаются от обычных коммерческих тендеров. В B2B-проектах заказчик обычно хочет получить результат и готов обсуждать компромиссы по пути. В госконтракте, особенно по 44-ФЗ, контракт — это почти закон: сроки, объем работ, порядок приемки и штрафы зафиксированы заранее, а менять условия по ходу проекта сложно.

Для бизнеса это означает простую вещь: выиграть тендер — не самая сложная часть. Сложнее потом исполнить контракт так, чтобы проект приняли и оплатили.

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

Какие ИТ-закупки бывают

Если сильно упростить, в госсекторе есть три основных типа ИТ-тендеров.

Поставка коробочного ПО

Заказчик покупает готовые лицензии: антивирусы, офисные пакеты, системы защиты, базовые платформы. Здесь риски ниже: главное — подтвердить право поставки, соответствие требованиям и наличие ПО в нужных реестрах.

Внедрение, настройка и сопровождение, техническая поддержка

У заказчика уже есть система, а подрядчику нужно адаптировать ее под процессы: настроить роли, интеграции, миграцию данных, доработать отдельные модули, работать по строгому SLA, оказывая услуги L1–L3 технической поддержки. Риски выше, потому что в таких контрактах часто размыта граница между настройкой, сопровождением и разработкой. В итоге заказчик может ожидать больше, чем заложено в бюджет.

Разработка под заказ

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

Почему самый трудоемкий этап — не подача заявки, а анализ ТЗ

Многие до сих пор думают, что участие в тендере — это заполнить форму на площадке и прикрепить документы. На практике в ИТ-госзакупках до 80% времени уходит на анализ технического задания, проекта контракта и связанных документов.

Именно на этом этапе становится понятно, стоит ли вообще заходить в закупку.

Проблема в том, что ТЗ часто пишут не технари. В документации можно встретить формулировки вроде «приложение должно работать быстро», «интерфейс должен быть интуитивно понятным» или «система должна поддерживать все актуальные версии устройств». Для разработчика это не требования, а источник будущих споров.

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

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

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

Где в документации прячутся самые опасные «мины»

В ИТ-закупках критичные требования редко лежат на поверхности. Они прячутся в сносках, приложениях, формах актов, проекте контракта и инструкциях по оформлению заявки.

Лицензии и требования по ИБ

Если проект связан с персональными данными, защищенными контурами, криптографией или интеграцией с государственными системами, могут внезапно всплыть требования к лицензиям ФСТЭК или ФСБ. В основном описании закупки про это иногда не сказано ни слова, зато в одном из приложений такое требование уже есть.

Если этот момент пропустить, можно потратить время на подготовку сильной заявки и вылететь по формальному критерию.

Права на исходный код

В проекте контракта нередко встречаются формулировки вроде «передать все исключительные права в полном объеме». На практике это может означать не только передачу результата проекта, но и ожидание, что подрядчик отдаст весь код, документацию и материалы так, чтобы третья сторона могла продолжить разработку без его участия.

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

Требования к среде и совместимости

Заказчик может указать, что решение должно работать в определенной инфраструктуре, например на Astra Linux, с конкретной СУБД или в действующей информационной системе. Но не всегда указывает версию, ограничения или то, что среда еще даже не развернута.

Для подрядчика это прямой риск: вы оцениваете обычную интеграцию, а потом неделями адаптируете систему под нестандартный контур.

Скрытые критерии приемки

Это один из самых опасных моментов. В ТЗ может быть написано «приложение должно пройти функциональное тестирование», а в приложении к контракту окажется методика испытаний на 200 тест-кейсов с конкретными требованиями к поведению интерфейса и времени отклика.

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

Формальные требования к заявке

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

Поэтому в хорошей тендерной функции всегда есть отдельный финальный чек-лист по оформлению, а не только по сути.

Что особенно важно в закупках на разработку ПО и мобильных приложений

У разработки в госзакупках есть три слабых места.

1. ТЗ часто не покрывает реальную сложность проекта

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

2. Мобильное приложение — это не только код

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

Если это заранее не зафиксировано, подрядчик может попасть в ситуацию, когда технически продукт готов, но юридически этап не сдан.

3. Самый опасный этап — приемка

В госконтракте приемка — это не формальность. Любой баг, даже косметический, может стать поводом не подписывать акт. А просрочка сдачи автоматически превращается в пени и штрафы.

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

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

Как заказчики выбирают победителей

Многие ИТ-компании до сих пор мыслят слишком линейно: кто дал меньшую цену, тот и победил. Это верно не всегда.

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

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

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

Какие тренды будут влиять на ИТ-госзакупки в ближайшие годы

Первый большой тренд — углубление импортозамещения. Если раньше это часто звучало как декларация, то теперь это рабочая механика отбора. Для разработчиков и интеграторов наличие продукта в реестре отечественного ПО становится не преимуществом «на будущее», а вполне прикладным фактором допуска и конкурентоспособности.

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

Третий тренд — постепенный переход от разовой поставки к сервисной модели. Государственный заказчик медленно, но все же движется к закупкам сервисов, подписки, сопровождения и SLA. Для бизнеса это означает: одной разработкой уже не обойтись, нужно уметь доказывать надежность эксплуатации.

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

Что реально помогает выигрывать чаще

За годы работы я пришел к нескольким практическим выводам.

Во-первых, не стоит готовить каждую заявку с нуля. У компании должна быть библиотека типовых блоков: описание методологии, меры по ИБ, шаблоны резюме, типовые архитектурные схемы, сведения об опыте, комплект учредительных документов. Это экономит время и снижает вероятность формальных ошибок.

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

В-третьих, необходимо использовать право на запрос разъяснений. Не угадывать, что имел в виду заказчик, а задавать вопросы через площадку. Ответы становятся частью документации и потом защищают вас на приемке.

В-четвертых, важно готовиться к приемке уже на стадии заявки. Не только думать, как выиграть, но и понимать, как будете сдавать работу, какие документы нужны, где может возникнуть спор, какие условия нужно зафиксировать заранее.

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

Финальный чек-лист перед участием в ИТ-тендере

Вот короткая версия чек-листа, который я бы рекомендовал пройти перед каждой закупкой.

Перед решением об участии

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

При анализе документации

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

При подготовке технической части

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

При расчете цены

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

Перед подачей

Проверить форматы файлов, подписи, полномочия подписанта, структуру и нумерацию документов, опись, дедлайны, работоспособность электронной подписи и настройки уведомлений.

После подачи

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

В тендерах действительно можно выигрывать системно. Но для этого нужно перестать относиться к ним как к «бумажной формальности» и начать воспринимать как отдельную управленческую дисциплину.

Мой главный урок из той истории десятилетней давности простой: в тендерах побеждает не самый умный и не самый смелый. Побеждает самый подготовленный.