Чему госзаказам стоит поучиться у Авито

Несложные изменения, которые сделают ИТ-сектор госзакупок намного дружелюбнее (сейчас все совсем не радужно).

Частное наблюдение — статьи про госзаказы делятся на два типа:

— Разбор законодательных новшеств с аккуратными рассуждениями к чему все это может привести;

— Крик души, где автор сетует на несправедливость системы, усложненные правила, нелогичное поведение заказчика и многое другое. 

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

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

Формально, государство должно быть самым интересным заказчиком. В Российской Федерации выстроена и отлажена система, где государство заказывает товары и услуги у бизнеса. Суммы оборотов постоянно растут. В январе 2022 года в открытом доступе были закупки на 459,1 млрд. рублей, а в январе 2023 года уже 600,1 млрд. рублей. Сумма значительная даже с учетом колебаний рубля.

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

Как исполнители и заказчики находят друг друга. Чтобы госзаказчик и исполнитель нашли друг друга в России работает единая информационная система закупок (ЕИС). Это портал, где публикуют тендеры по 44 и 223-ФЗ. Информация автоматически переносится на 8 федеральных электронных торговых площадок (ЭТП).

Для исполнителей работает аналогичный принцип. Организации и ИП, зарегистрированные в ЕИС, автоматически регистрируются на всех ЭТП. Всего их 8: Сбербанк-АСТ, РТС-тендер, Российский аукционный дом (lot-online), Национальная электронная площадка (НЭП), Агентство по государственному заказу Республики Татарстан (Zakazrf), Единая электронная торговая площадка (ЕЭТП), Газпромбанк (ЭТП ГПБ) и ТЭК-Торг. 

Внешне все прекрасно. Регистрируешься и пользуешься ЭТП, какая больше по вкусу, берешь заказы и горя не знаешь.

Система выстроена грамотно — тут споров нет. Однако ряд практик сформировали в ИТ-секторе госзакупок клубок проблем. Они достаточно значительные, чтобы отбить желание развиваться в работе с государством.

Почему находить заказы сложнее, чем должно быть. Госзакупки делят типы работ по Общероссийскому классификатору продукции. Интересный мне сегмент обозначается как ОКПД 2: 62.01.11.000 «Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения».

Теперь зайдем на ЕИС «Закупки» и отсортируем закупки по нужному ОКПД и бюджетам. Получим такую картину. Посмотрите внимательно и попробуйте понять, где скрыт подвох.

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

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

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

Плохие ТЗ и почему они не наказываются

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

Никому не надо объяснять почему плохо написанное ТЗ — зло. В госзакупках ситуация осложняется тем, что расплывчатое техзадание становится источником бесконечных задач. Источником работы становится заказчик, и ему выгодно заставить исполнителя сделать побольше. А куда он денется? Если начнешь скандалить, то попадешь в Реестр недобросовестных поставщиков, а это очень плохой сценарий.

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

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

Давайте зайдем к проблеме издалека — с точки зрения правовых норм. Если кратко, плохое ТЗ ничего не нарушает. Ужасное тоже. Это как с дипломом, написанным за ночь до сдачи. Вроде технически это можно принять и поставить «тройку», чтобы не мучить студента, однако все понимают ценность такой работы. Вот и с ТЗ похожая история.

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

Государство обязывает прописать четыре характеристики объекта закупки:

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

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

3. Функциональные. Отражают способность объекта выполнять свою функцию. Как правило, здесь прописываются потребительские свойства. Для еды — энергетическая ценность, для цветов — запах, для краски — цвет.

4. Эксплуатационные. Долговечность, гарантия, оригинальность товара — все прописывается в этом пункте.

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

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

Пару слов о ГОСТах и как они не помогают

ГОСТы — штука интересная. Если увидишь в ТЗ ссылку на один ГОСТ, то он обязательно потянет другой, а тот следующий. И так у задачи появится четкое обрамление.

А какие ГОСТы есть в ИТ? Глобально их два. Первый — требования доступности для инвалидов по зрению, ГОСТ Р 52872-2012. Важный и понятный документ. Напрямую разработку не регулирует. Второй — ГОСТы серии 19, буквально настольная книга создателей программных продуктов. Еще есть приказ Минэка об утверждении требований к технологическим, программным и лингвистическим средствам официальных сайтов. Действие этого документа касается узкой прослойки порталов.

Чтобы превратить программный код в продукт, нужно снабдить его всей необходимой документацией.

Продукт = программный код + документация

Вот здесь и помогают ГОСТы. Например, ГОСТ 19 устанавливает взаимосвязанные правила разработки, оформления и обращения программ и программной документации. Как стандарт он устанавливает требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ.

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

В ЭТП могут соседствовать два тендера. ТЗ в обоих выполнено строго по ГОСТам, но одно написано из рук вон плохо, а другое — отлично. Вот и получается, что решающим фактором остается виденье заказчиком конечного продукта и навык этот продукт грамотно описать.

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

ГОСТы важны и спорить с этим глупо. Однако они отвечают на вопрос «Как правильно оформить?», но не «Что оформить?». Если заказчик не знает чего он в действительности хочет, то ГОСТы бессильны.ГОСТы важны и спорить с этим глупо. Однако они отвечают на вопрос «Как правильно оформить?», но не «Что оформить?». Если заказчик не знает чего он в действительности хочет, то ГОСТы бессильны.

Чем госзаказам полезен опыт сайтов объявлений

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

Благо в России есть классифайды которые все продумали за пользователя.

Боишься, что опубликуешь не там → классификатор подскажет, где лучше разместить объявление;

Не знаешь, какую информацию указывать → интерфейс проведет тебя по всем нужным пунктам;

Сомневаешься, что написал правильно → можешь сравнить с другими публикациями в своей нише.

Все максимально дружелюбно и унифицировано. А теперь представим, что нечто подобное будет работать с ИТ 

Здесь можно возразить — площадок много и за всеми не уследишь. Не совсем. 

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

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

А если бы подобные заказы работали по системе досок объявлений? Логика такая: определенный раздел открывает связанные опции. Если на условном Авито продавать автомобиль, то форма анкеты будет отличаться от, скажем, пылесоса. Здесь аналогичная логика. Заказчик выбрал «портал», потом подраздел «корпоративный», далее приоритетные блоки. Даже с плохим ТЗ уже многое прояснится.

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

План по спасению ИТ-сектора госзаказов

Мне представляется два выхода из сложившейся ситуации:

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

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

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

   Если у вас есть соображения, как обустроить ИТ-сектор госзаказов, пишите в комментариях.