Среди ИТ-тендеров сформировалось несколько системных проблем: плохие техзадания, перекос в сторону крупных интеграторов, очередь работ по крупным заказам, а малые и средние команды практически простаивают. Что самое интересное — проблемы вытекают одна из другой.
Эксперт: Тимур Алимханов, сооснователь веб-интегратора StepUp, опыт работы с государством — 14 лет.
В этой статье хочу затронуть проблемы, которые наблюдаю среди ИТ заказов в госзакупках. О них не пишут в деловых изданиях, но моя команда встречается с ними постоянно.
Дисклеймер
Материал отражает мой опыт в сфере ИТ-закупок, а конкретно в разработке сайтов и порталов. Ваш опыт и мнение может отличаться — это нормально. Об этом всегда можно написать в комментариях.
База по закупкам (если в курсе, смело листайте дальше)
Не перестаю повторять, что государство одновременно сочетает в себе черты худшего и лучшего ИТ-заказчика. Заказов много, бюджеты большие, регулирующие законы сложные, но изученные вдоль и поперек. Однако есть нюансы и с ними надо разобраться.
На всякий случай проясню базовые вещи. Госзакупки — это система, где государственные компании ищут поставщиков товаров, работ и услуг. Заказчик публикует техзадание, стоимость и прочие документы, а участники подают заявки. В итоге заказчик выбирает лучшее предложение. Понятное дело, есть куча нюансов, но сейчас ими грузиться не стоит.
Чтобы не путаться разделим госзакупки по 44-ФЗ и 223-ФЗ.
Госзакупки по 44-ФЗ. Проводят все государственные и муниципальные организации, которые живут за счет бюджета. Жестко регулируется. Забавный факт: документ в 10 раз толще 223-ФЗ.
Госзакупки по 223-ФЗ. Нужны для компаний с долей государственного от 50% и их «дочек», естественных монополий, регулируемых видов деятельности и бюджетных учреждений, которые планируют потратить грант, средства субподряда или собственные деньги.
Есть еще коммерческие закупки. Там можно творить что угодно в рамках Гражданского кодекса. Однако сегодня говорим не про них.
Закупки — это трудно и не для всех. Однако если вы здесь освоитесь, то получите обширный пул заказчиков. Правда, здесь есть нюансы. О них — далее.
Дисбаланс заказов: они либо мелкие, либо дорогие и сулящие седые волосы
Формально в ИТ-секторе госзакупок созданы все условия, чтобы среда была максимально конкурентной. Подвох кроется в деталях, и сейчас в предложениях сложился дисбаланс. Грубо говоря, есть два вида заказов: маленькие с сомнительной выгодой и крупные с проблемным ТЗ.
Поясню по каждому пункту.
Маленькие с сомнительной выгодой. Здесь можно возразить, мол, это для вас такие заказы неинтересны, а новичкам в самый раз. Окей, давайте посчитаем.
Есть заказ на разработку сайта с бюджетом 300 000 рублей. К стандартным расходам добавьте зарплату специалиста по госзакупкам, юриста с соответствующим опытом и других сотрудников, нужных для сопровождения проекта. Если все пройдет как по маслу и проект уложится в 10 итераций, можно открывать шампанское. Только недорогое, ведь маржа составит 20 000 рублей. Если проект забуксует, прибыли не будет вообще.
Крупные с проблемным ТЗ. На торговых площадках встречаются закупки-долгожители. Чаще это заказы с ценником в 200-300 млн рублей и известным именем заказчика. Однако поставщики соответствующего опыта обходят заявку стороной. Причина — проблемное ТЗ, а это не просто «красный флажок», а Красная площадь на 1 мая.
Впрочем, тут лучше всего пояснить на примере.
Есть такая штука — закрытые закупки. Это когда заказчик приглашает к участию ограниченный круг поставщиков, а они уже конкурируют за проект. В этом году меня пригласили на такой закрытый тендер по 223-ФЗ. Заказчик — крупнейший государственный застройщик, которому нужно внедрить два корпоративных портала.
Техническое задание написано жирными мазками, а некоторые аспекты совсем расплывчато. Блоку безопасности в ТЗ уделили много внимания, однако устно проговорили, что его реализация обсуждаема т.к. блок не приоритетный.
Закон позволяет пообщаться с функциональным заказчиком — людьми, которые будут принимать проект. Я воспользовался этой возможностью в моем случае это были ИТ-департамент и безопасники.
Начинаю общаться и тут выясняется, что блок безопасности стоит в приоритете. Корпоративный портал с усредненными характеристиками и портал, построенный вокруг безопасности — две огромные разницы. Первоначально ТЗ оценивалось в 15 млн рублей за два портала. После общения с функциональными заказчиками и перерасчетом стоимость выросла до 40 млн рублей. В общем, из проекта я выбыл.
Дисбаланс взялся не с пустого места. Часто заказчик пытается сэкономить, описывая фронт работ обтекаемо и отсюда следует другая проблема.
Техзадания будто специально пишут плохо
Компании, которые обожглись об обтекаемое ТЗ, отбирают проекты очень осторожно. Получается парадоксальная ситуация: есть опытные и крутые исполнители, но из-за рисков они не берутся за заказы.
Раскрою внутреннюю кухню. Когда берусь за тендер, то закладываю прибыль исходя из позитивного не негативного сценария. Если сработал хорошо, то прибыль доходит до 30%. Если дал маху и по разным причинам потратил больше ресурсов, то 15%. Если совсем плохо, то прибыли нет или ухожу в минус. Плохие сценарии — супер редкие. Все-таки 14 лет опыта научили видеть узкие места заранее.
Но!
Когда читаю некоторые ТЗ, понимаю, что никакого опыта не хватит, чтобы довести проект до финала. Просто ТЗ написано так, чтобы создавать задачи, которые никогда не закончатся. Для таких заказов бессмертная фраза «Денег нет, но вы держитесь» — не мем, а девиз по жизни.
Основная проблема неточных ТЗ — они открывают потенциал для бесконечного цикла разработки. Каждый элемент проекта можно сделать стандартно, а можно заморочиться и сделать лучшую реализацию на рынке. Все зависит от воли заказчика. И да — бюджет увеличивать никто не будет.
Вот еще пример. Идет разработка портала, бюджет зафиксирован на отметке 20 млн рублей. Выясняется, что поддержка портала должна быть 24/7, 180 часов в месяц, на линии работает оператор уровня миддл и ситуативные специалисты рангом выше. Иными словами, поддержка съедает половину бюджета.
Я пошел навстречу заказчику и предложил подробнейшее ТЗ, где расписал как перераспределить ресурсы. Ответ был примерно такой: «Поддержку срезать не будем, все остается как было, постарайтесь уложиться в деньги».
Я убежден, что плохие ТЗ — не коллективный злой умысел. Это следствие низкой квалификации или внутреннего разлада коллектива заказчика. И это следующая проблема.
Часто ТЗ писать просто некому
В идеальном мире заказчик пишет ТЗ, а поставщик работает по нему и все счастливы. Да, какие-то детали уточняются, но в целом логика проекта не ломается. В реальности ТЗ скорее обрисовывает контур того, что нужно. Исполнитель подписывается под бюджет, а потом составляет частное техническое задание, оно же ЧТЗ. Вот там и закрепляется полный план работ.
Вспомню неудавшийся опыт с корпоративным порталом для федерального застройщика. Первые 20 рабочих дней ушли бы на формирование ЧТЗ с учетом модели угроз. По-хорошему только на модель угроз надо потратить 40 дней минимум.
Получается, я как исполнитель делаю работу заказчика, формируя ЧТЗ, да еще и должен уложиться в сжатые сроки. Это относится не к конкретному тендеру, а к сектору закупок в целом.
Написать ТЗ и протащить его до публикации на портале закупок — разные навыки. Пока документ пройдет через все инстанции, он может измениться до неузнаваемости. Даже автор с трудом узнает свою работу.
Часто заказчики удивляются срокам разработки ЧТЗ. Допустим, я планирую сдать документ за 20 дней, а заказчик говорит, что можно управиться за 10 дней. Спору нет — они то хорошо знают свою инфраструктуру, а мне надо вникнуть.
Почему почти никто не пишет ЧТЗ? Взгляд со стороны подсказывает, что нет желания и компетенций писать четко и понятно.
Вторая причина — разлад внутри коллектива заказчика. Причины разлада могут быть разные. Возможно, департаменты тянут одеяло на себя, может, торопятся или наоборот — проект навязали со стороны и никто не хочет брать ответственность.
Формат ТЗ в закупках устанавливает закон, но в законе нет строчки «сделать так, чтобы исполнитель поседел». Здесь теряюсь в догадках.
Крупные команды завалены работой на годы вперед
Был тендер, где я оказался единственным участником. Никакой монополии, просто больше никто не заявился. Начал проект, на стадии ЧТЗ предложил реализовать портал на Битриксе, но это решение принципиально не приняли. Что мешало прописать в ТЗ рекомендуемые платформы? Загадка.
С заказчиком разошлись по соглашению сторон. На момент написания статьи тендер был актуален, а исполнители не спешили высылать заявки. На другие тендеры заказчика тоже мало откликов.
Возвращаемся к первому пункту — заказы приходят убыточные, либо большие, но без прибыли за счет слабых ТЗ. Среднего варианта нет. Я бы с удовольствием брал «середняки» с четким ТЗ, но их попросту нет.
Давайте пофантазируем, что есть ЧТЗ на 200 млн рублей. Просто заявиться не получится, ведь есть требования закона. Контракт может взять только та компания, которая выполнила подобные работы на сумму не менее 20% от текущего. Получается, должен быть подобный контракт на 40 млн рублей. Обычно люди перестраховываются и вписывают четко по требованию перечень работ.
Вот в чем фокус. Есть много хороших команд, которые зашли на рынок госзакупок и выполнили контракты на 5-7 млн рублей. Они крупный тендер не возьмут даже если захотят. Сначала надо дорасти. Однако исполнители соответствующих масштабов загружены на несколько лет вперед. Вот попадает заказ к крупному интегратору, которому 200 млн не то, чтобы большие деньги. Он ищет субподрядчика и нехотя реализовывает.
Предприниматели, которые хотят расти, попадают в просак. У них есть крутые специалисты, есть ресурсы, чтобы выполнить проект и расти дальше. Однако они упираются в «стеклянный потолок».
А что делать?
Суммируем проблемы.
Дисбаланс заказов на площадках госзакупок → либо мелкие, либо крупные. Оба с сомнительной экономической выгодой.
Низкая квалификация составителей ТЗ → объем работ сложно оценить, ТЗ прописывается после принятия проекта, цены не соответствуют объему работ.
Потенциально интересные заказы простаивают → желания не соответствуют бюджету, а ТЗ составлено так плохо, что отпугивает исполнителей.
Большинство из перечисленных болячек можно решить советом «заказчикам нужно усилить менеджмент и грамотно писать ТЗ». Давайте просто признаем, что это совет из серии «Делайте зарядку и спите 8 часов».
На мой взгляд проблемы будут актуальны пока ИТ-заказы не выделят в отдельную категорию. В России уже действуют отрасли, стоящие в тендерах особняком, например, гособоронзаказ. А теперь представим, что ИТ-заказы размещаются на своих площадках по специальным требованиям.
Фреймворк в этом отношении максимально полезен. Допустим, публикуя закупку, заказчик обязан указывать раздел: веб-разработка, инфобезопасность или что-то еще. Выбранный раздел задает нужные поля для заполнения. Не заполнишь — закупку не пропустят.
В сфере закупок еще много над чем работать. Отделение ИТ-сферы в отдельный кластер кажется логичным шагом, чтобы дать начало позитивным изменениям. Сейчас есть разнообразие площадок, но нет культуры формирования четких ТЗ и требований. Нужен фреймоворк, который сработает как первая линия защиты от человеческого фактора.
Каким может быть отдельная экосистема для ИТ-закупок — вопрос обширный. Думаю, что напишу по нему отдельный материал.
