Я уже рассказывал здесь, как мы объединяли 14 сайтов в один, связывали Flask и Bitrix в одну систему, защищали контур рассылки и как после 5 лет работы попрощались с большим проектом. Все эти истории были о том, что происходило после того, как проект уже оказался у нас.

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

Мы это проходили на собственных конкурсах. В одном показали frontend-приложение на WebGL, которое можно было запустить и проверить. В другом подтвердили квалификацию 27 исполненными контрактами примерно на 168 млн рублей. Казалось бы, обе части заявки должны были играть в нашу пользу. Вместо этого в обоих случаях получили 0 баллов именно там, где рассчитывали на сильную позицию.

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

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

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

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

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

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

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

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

Когда работающий WebGL-интерфейс не заменил отдельный макет

Во втором конкурсе цена имела вес 60%, качественные характеристики предложения — 30%, квалификация — 10%. В качественной части конкурса оценивались две отдельные характеристики.

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

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

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

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

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

Что объединяет две наши ошибки

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

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

Обратная сторона формального подхода

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

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

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

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

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

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

А пока мы исходим из тех правил, которые есть.

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