Как мы дважды получили ноль в IT‑тендерах

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

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

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

27 контрактов на 168 млн рублей: почему мы считали этот опыт подходящим

В первом конкурсе цена имела вес 30%, а квалификация участника — 70%. Поэтому опыт здесь был не дополнительным преимуществом, а одной из ключевых частей заявки.

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

Под этот критерий мы представили 27 исполненных контрактов общей стоимостью около 168 млн рублей. Среди них были сопровождение Портала административной реформы Минэкономразвития, развитие официального сайта Ростуризма и разработка Единой автоматизированной информационной системы Уполномоченного при Президенте РФ по правам ребенка.

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

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

Комиссия посмотрела на это иначе.

Почему все 27 контрактов получили ноль

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

У нас были функции, из которых это следовало. Но самой нужной формулировки в документах не оказалось.

В результате комиссия не засчитала ни один из 27 контрактов. Более низкая цена уже не могла компенсировать разницу: у нас получилось около 30 итоговых баллов, у конкурента — примерно 88.

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

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

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

В тендере вопрос «делали ли мы такое?» оказался только первым. Второй и не менее важный вопрос: «сможем ли мы доказать это именно тем способом, который предусмотрел заказчик?»

Во втором конкурсе мы сделали работающий интерфейс вместо отдельного макета

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

По другой характеристике требовалось подготовить материалы для раздела «Мегаполисы мира». В документации отдельно были перечислены три результата: макет интерфейса, HTML‑верстка и Frontend‑приложение с интерактивными 3D‑элементами на WebGL.

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

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

Для конкурсной комиссии это были разные вещи.

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

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

Мы смотрели прежде всего на содержание результата. Комиссия — еще и на комплектность заявки.

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

Два совершенно разных конкурса, но одна ошибка

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

Но в обоих случаях мы сделали одну и ту же вещь: сами интерпретировали, что можно считать достаточным подтверждением требования.

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

Для внутренней логики проекта это могло быть вполне разумно. Для конкурсной заявки — нет.

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

Поэтому со временем у нас появился довольно простой тест. Если во время проверки заявки кто‑то говорит: «Ну здесь же и так понятно, что…», — этот пункт нужно проверить еще раз.

Как мы теперь готовим такие заявки

Если написано «макет», мы прикладываем макет. Если отдельно требуется приложение — приложение. Если нужен определенный вид опыта, ищем его прямое подтверждение в документах.

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

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

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

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

С опытом все сложнее, чем с макетом

Историю с WebGL решить довольно просто: увидел требование — подготовил отдельный файл.

С подтверждением опыта такой подход работает не всегда.

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

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

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

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

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

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

Что я вынес из этих двух проигрышей

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

Теперь рядом с этим всегда стоит еще один вопрос: сможет ли комиссия подтвердить наше соответствие требованиям только по тем материалам, которые находятся перед ней?

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

27 контрактов не стали менее реальными из‑за того, что их не засчитали. Работающее WebGL‑приложение тоже не перестало работать из‑за отсутствия отдельного макета. Но конкурс оценивает не компанию целиком и не реальное качество всех ее проектов. Он оценивает конкретную заявку по заранее заданным правилам.

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

Сильная заявка — та, где комиссии не нужно ничего додумывать за участника.