Тендер на IT-разработку длился четыре месяца. Комиссия отсмотрела 14 предложений, собрала три раунда презентаций, заполнила оценочные таблицы на 200 строк. Победил подрядчик с самой низкой ценой. Через полгода проект пришлось остановить: код не прошёл аудит безопасности, архитектура не масштабировалась, а документации не было вовсе. Пересборка обошлась в два раза дороже первоначального контракта.
Знакомый сценарий? К сожалению, он типичен. Проблема не в тендерах как инструменте, а в том, как их проводят. IT-разработка — не закупка канцтоваров. Критерий «минимальная цена» здесь не работает, потому что стоимость владения продуктом в 3-5 раз превышает стоимость разработки.
В этом гайде — пошаговый чек-лист для отдела закупок: как провести тендер на разработку ПО, который приведёт к рабочему продукту, а не к повторному тендеру через год. Шесть этапов, оценочная карта и красные флаги, которые сэкономят месяцы и миллионы.
Почему тендеры на IT-разработку — не обычные закупки
Отдел закупок привык работать по 44-ФЗ или внутренним регламентам, где ключевые параметры — цена, срок поставки, соответствие спецификации. С IT-разработкой эта логика ломается по трём причинам.
Во-первых, продукт ещё не существует. Вы покупаете не товар со склада, а процесс создания. Поэтому оценивать нужно не столько итоговую цену, сколько способность подрядчика этот продукт создать. Подробнее о формировании требований — в нашем гайде по составлению ТЗ.
Во-вторых, дешёвое решение часто обходится дороже. Подрядчик, который занизил цену на 30%, компенсирует это экономией на архитектуре, тестировании и документации. Через год вы получите технический долг, который стоит больше, чем разница между дешёвым и качественным предложением.
В-третьих, IT-проект требует совместной работы. В отличие от поставки оборудования, здесь заказчик и подрядчик работают вместе 2-6 месяцев. Совместимость команд, процесс коммуникации, культура разработки — всё это влияет на результат не меньше, чем технические компетенции.
Именно поэтому стандартные закупочные процедуры нуждаются в адаптации. Давайте разберём, как провести тендер на IT-разработку правильно — этап за этапом.
Чек-лист: 6 этапов тендера на IT-разработку
Каждый этап — конкретные действия и критерии перехода к следующему. Пропуск любого из них повышает риск провала.
Этап 1. Подготовка технического задания
Тендер без чёткого ТЗ — лотерея. Подрядчики будут оценивать разные вещи, и сравнить их предложения окажется невозможно. Однако ТЗ для тендера — не 200-страничный документ с детализацией до кнопки.
Что должно быть в тендерном ТЗ:
- Бизнес-цель проекта — что именно должно измениться после запуска (метрики, KPI)
- Функциональные требования — основные сценарии использования (user stories)
- Нефункциональные требования — нагрузка, безопасность, интеграции, compliance (ФЗ-152)
- Ограничения — бюджетный коридор, сроки, технологический стек, корпоративные стандарты
- Критерии приёмки — как вы определите, что проект выполнен
Важный нюанс: оставьте подрядчику пространство для предложений по архитектуре и технологиям. Лучшие подрядчики не просто выполняют ТЗ — они его улучшают.
Этап 2. Формирование шорт-листа (5-7 компаний)
Рассылать тендерную документацию 30 компаниям — путь к хаосу. Оптимальный шорт-лист: 5-7 подрядчиков, отобранных по базовым критериям:
- Опыт в вашей отрасли (enterprise, не стартапы)
- Релевантный технологический стек
- Наличие compliance-процессов (ФЗ-152, ISO 27001 или аналоги)
- Готовность к NDA до начала обсуждения деталей
- Reference check — контакты 2-3 enterprise-клиентов
Где искать: рейтинги Clutch и GoodFirms, рекомендации коллег из индустрии, резиденты технопарков (Сколково, Иннополис). Подробнее о критериях — в нашем гайде по выбору IT-подрядчика.
Этап 3. Запрос предложений (RFP)
Отправьте шорт-листу структурированный RFP, который включает:
- Техническое задание (этап 1)
- Формат ответа — что именно вы хотите увидеть в предложении
- Сроки подачи (2-3 недели — достаточно для качественного ответа)
- Критерии оценки с весами (прозрачность повышает качество предложений)
- Процедура вопросов — единый канал, ответы видны всем участникам
Формат ответа должен быть стандартизирован. Иначе вы будете сравнивать PDF на 50 страниц с письмом на полстраницы — и то, и другое бесполезно.
Этап 4. Техническая оценка предложений
Это ключевой этап, где чаще всего допускают ошибки. Оценку должны проводить не только закупщики, но и технические специалисты — CTO, архитектор или внешний технический консультант.
На что смотреть:
- Понимание задачи — подрядчик переформулировал ваши требования или скопировал ТЗ?
- Предложенная архитектура — есть ли техническое видение, или только «мы всё сделаем»?
- Состав команды — кто именно будет работать (имена, роли, опыт)
- Управление рисками — что будет, если сроки сдвинутся или требования изменятся
- Прозрачность ценообразования — разбивка по этапам, а не одна итоговая цифра
Этап 5. Демо и пилотная задача
Финалистов (2-3 компании) пригласите на живую демонстрацию. Попросите показать аналогичные проекты, провести мини-воркшоп по вашей задаче или выполнить небольшую пилотную задачу. Это стоит 1-2 недели, но экономит месяцы потенциальных проблем.
Что оценивать на демо:
- Качество коммуникации — понимают ли вас с полуслова
- Проактивность — предлагают ли улучшения или только кивают
- Культурная совместимость — комфортно ли работать с этими людьми
Этап 6. Контрактование и старт
Выбрали победителя — фиксируйте всё в договоре:
- Фиксированная цена или чёткая формула time&material с верхним лимитом
- Этапы с промежуточными демо и приёмками (не «всё через 6 месяцев»)
- Права на код и документацию — передача на каждом этапе
- SLA на поддержку после запуска
- Процедура изменения требований (change request)
- Штрафные санкции за срыв сроков (и бонусы за досрочную сдачу)
Итого: от подготовки ТЗ до подписания договора — 6-8 недель при грамотной организации. Не 4 месяца, как в истории из начала статьи.
Оценочная карта подрядчика: 8 критериев с весами
Субъективные оценки «нравится / не нравится» — путь к конфликтам в комиссии. Используйте формализованную оценочную карту, где каждый критерий имеет вес и шкалу.
КритерийВесЧто оценивать
Техническая экспертиза20%Стек, архитектура, портфолио аналогичных проектов Понимание задачи15%Качество переформулирования ТЗ, встречные вопросы Состав команды15%Уровень специалистов, стабильность, доступность Цена15%Общая стоимость, прозрачность разбивки Сроки10%Реалистичность, наличие буферов, этапность Безопасность и compliance10%ФЗ-152, NDA, аудит, корпоративные стандарты Управление проектом10%Методология, отчётность, управление рисками Reference check5%Отзывы enterprise-клиентов, повторные контракты
Обратите внимание: цена занимает только 15% — не 50% и не 70%, как в классических закупках. Это принципиальная позиция. Экономия 200 000 рублей на тендере, которая приводит к перерасходу в 2 000 000 рублей на переделку, — не экономия. Подробнее о структуре затрат — в статье о стоимости корпоративного IT-проекта.
Правило: если разница в цене между финалистами менее 20%, выбирайте по техническим критериям и качеству коммуникации. Эти 20% окупятся отсутствием проблем на проекте.
Красные флаги: когда подрядчика стоит исключить из тендера
Некоторые сигналы видны ещё на этапе рассмотрения предложений. Вот семь красных флагов, каждый из которых — повод для исключения:
- Цена значительно ниже рынка (на 40%+ дешевле среднего). Подрядчик либо не понял задачу, либо планирует компенсировать change request-ами.
- Нет конкретных имён в команде. «Мы подберём специалистов после подписания договора» = нет свободных людей сейчас.
- Отсутствие встречных вопросов по ТЗ. Хороший подрядчик всегда задаёт уточняющие вопросы. Молчание означает либо непонимание, либо «подпишем — разберёмся».
- Compliance «за доплату». Если соответствие ФЗ-152 не входит в стандартный пакет, подрядчик не работает с enterprise-клиентами регулярно.
- Отказ от пилотной задачи или демо. Нечего показать = нет релевантного опыта.
- Нет чётких этапов и промежуточных результатов. «Всё будет готово через 4 месяца» — так не работает. Нужны двухнедельные спринты с демо.
- Нежелание предоставить reference check. Довольные клиенты — лучшая рекомендация. Если их нет — задумайтесь.
Даже один из этих флагов — повод перенести подрядчика в конец списка. Два и более — основание для исключения.
Нюансы для корпоративных тендеров
Если ваша компания работает по внутренним регламентам закупок, учтите несколько особенностей:
Согласование с IT-департаментом. Тендер на разработку ПО — не чисто закупочная процедура. Привлеките CTO или технического директора к формированию критериев и оценке предложений. Без технической экспертизы в комиссии решение будет приниматься по единственному понятному параметру — цене.
Бюджетный коридор вместо потолка. Указывайте диапазон бюджета, а не верхний предел. Это позволяет подрядчикам предложить оптимальное решение, а не урезанное до минимума. К примеру, корпоративный MVP за фиксированную цену до 900 000 рублей — предсказуемая цифра для бюджетного комитета.
Сроки тендера. Затянутый тендер — враг инноваций. Каждый месяц задержки со стартом разработки — это месяц преимущества у конкурентов. Оптимум: 6-8 недель от публикации RFP до подписания договора.
FAQ о тендере на IT-разработку
Сколько подрядчиков включать в шорт-лист тендера?
Оптимально 5-7 компаний. Меньше — недостаточно конкуренции и выбора. Больше — комиссия потратит непропорционально много времени на оценку предложений, а качество анализа снизится. На финальный этап (демо, пилотная задача) выходят 2-3 компании.
Должна ли цена быть главным критерием выбора?
Нет. В нашей оценочной карте цена занимает 15% — наравне с пониманием задачи и составом команды. Для IT-разработки стоимость владения продуктом (поддержка, масштабирование, доработки) в 3-5 раз превышает стоимость первоначальной разработки. Экономия на тендере часто оборачивается кратным перерасходом через 6-12 месяцев.
Как оценить подрядчика, если у нас нет технической экспертизы?
Привлеките внешнего технического консультанта на этап оценки предложений. Это стоит 50 000 - 150 000 рублей, но сэкономит миллионы при неправильном выборе. Альтернатива — попросить подрядчиков провести демо-воркшоп, где они покажут подход к вашей задаче. Качество коммуникации и проактивность видны без технического бэкграунда.
Можно ли провести тендер на IT-разработку за 2-3 недели?
Полноценный тендер с оценочной картой — нет, минимум 6-8 недель. Однако если задача типовая (например, MVP), можно использовать упрощённую процедуру: шорт-лист из 3 подрядчиков, оценка за 2 недели, пилотная задача за 1 неделю. Итого 3-4 недели. Главное — не жертвовать качеством оценки ради скорости.
Что делать, если тендер уже прошёл, но подрядчик не справляется?
Зафиксировать проблему документально (несоответствие этапных результатов ТЗ), активировать процедуру change request или досрочного расторжения из договора. Если в договоре нет этих пунктов — это сигнал на будущее: закладывайте exit-стратегию в контракт до подписания. Для следующего проекта рассмотрите подрядчиков с фиксированной ценой и поэтапной приёмкой.
Итог: тендер — это инвестиция в результат
Грамотный тендер на разработку ПО — это не бюрократическая формальность, а инструмент управления рисками. Шесть этапов, оценочная карта с весами, красные флаги при отборе — всё это сокращает вероятность провала проекта в разы. Главное правило: оценивайте не только цену, но и способность подрядчика создать работающий продукт.
Если вы готовите тендер прямо сейчас и хотите включить команду с фиксированными сроками и бюджетом в шорт-лист — запишитесь на бесплатный Zoom-звонок с ITESCO. Разберём вашу задачу, подготовим техническое предложение в формате, удобном для тендерной комиссии. Корпоративный MVP за 22 рабочих дня, до 900 000 рублей, соответствие ФЗ-152 включено.