Госзакупки IT-решений — это не про «напишите нам программу». Это про формальное соответствие. И главный документ, который либо приведет вас к победе, либо к отклонению заявки — техническое задание (ТЗ).
Парадокс в том, что заказчики по 44-ФЗ часто пишут ТЗ так, что исполнить его невозможно без нарушения законодательства. А поставщики, видя нестыковки, либо молчат (и потом срывают контракт), либо пытаются оспорить — и проигрывают время.
В этой статье я разберу, как составить техническое задание на IT-разработку (программа для ЭВМ, мобильное приложение, веб-сервис) так, чтобы оно было законным, исполнимым и не отсекало добросовестных участников. А если вы поставщик — покажу, на что смотреть в чужом ТЗ, чтобы не попасть в ловушку.
Почему ТЗ на IT-разработку — это зона риска
В отличие от закупки «коробочного» ПО, разработка — это процесс. Вы не можете просто прийти и сказать «у меня есть программа». Заказчик описывает результат, которого хочет достичь, но часто путает требования к функционалу с требованиями к технологии реализации.
Основные проблемы, которые я вижу в ТЗ на IT-разработку по 44-ФЗ:
- Избыточные требования к языкам программирования и СУБД. Заказчик требует строго «Java, PostgreSQL, Linux» — и это ограничивает конкуренцию. Если такие требования не обоснованы архитектурой, их можно оспорить.
- Отсутствие четких критериев приемки. «Интерфейс должен быть удобным» — это не критерий. А «время отклика при 1000 одновременных пользователей не более 2 секунд» — уже да.
- Смешение этапов. ТЗ на разработку часто включает требования к хостингу, техподдержке и обучению — хотя это разные услуги, и их нужно описывать отдельно.
- Копирование готового решения. Заказчик берет ТЗ от своей текущей системы, меняет логотип и выставляет на торги. В итоге разработчик должен сделать точную копию — но это нарушает авторские права и часто невозможно технически.
Если вы заказчик — помните: плохое ТЗ = срыв сроков, суды и жалобы в ФАС. Если вы поставщик — плохое ТЗ = убытки или отклонение заявки.
Как должно выглядеть грамотное ТЗ на разработку ПО по 44-ФЗ
Техническое задание — это приложение к контракту. Оно должно быть частью документации о закупке. Если заказчик выкладывает только «Описание объекта закупки» без детального ТЗ — это повод насторожиться.
Я рекомендую придерживаться следующей структуры (она не обязательна по закону, но проверена практикой):
1. Общие сведения
Здесь указывается наименование системы, основание для разработки, сроки, источник финансирования. Без лишних деталей — только факты.
2. Назначение и цели создания
Зачем нужна эта программа? Какие бизнес-процессы она автоматизирует? Например: «Автоматизация учета заявок граждан в администрации города». Цели должны быть измеримыми: «Сокращение времени обработки заявки с 3 дней до 24 часов».
3. Требования к функциональным характеристикам
Самый объемный раздел. Здесь описываются модули, роли пользователей, сценарии работы. Важно: не перечислять каждую кнопку, а описать, что система должна делать.
Пример плохого описания: «В форме должна быть кнопка «Сохранить» и поле «Имя»».
Пример хорошего описания: «Пользователь с ролью «Оператор» может создать заявку, заполнив обязательные поля: ФИО, контактный телефон, текст обращения. После сохранения заявка получает статус «Новая» и становится доступна для просмотра руководителю».
4. Требования к надежности и производительности
Конкретные цифры: время непрерывной работы, количество одновременных пользователей, объем базы данных, время восстановления после сбоя. Если заказчик пишет «система должна работать стабильно» — это не требование, а пожелание.
5. Требования к составу и содержанию работ
Этапы: проектирование, разработка, тестирование, опытная эксплуатация, ввод в промышленную эксплуатацию. По каждому этапу — сроки и результат (документ, код, отчет).
6. Порядок приемки
Как заказчик будет проверять, что программа работает? Нужны тестовые сценарии, критерии успешного прохождения, сроки на проверку. Если этого нет — приемка превращается в бесконечные «а давайте еще вот это поправим».
7. Требования к документации
Какие документы разработчик передает заказчику: руководство пользователя, руководство администратора, описание API, исходный код (если требуется).
Ошибки поставщиков при анализе ТЗ на IT-разработку
Я много раз видел, как участники закупок хватались за голову уже после подписания контракта. Вот типовые ловушки:
- Нечитаемые требования. В ТЗ 100 страниц, из которых 80 — копипаст из ГОСТов. Вы не обязаны исполнять то, что невозможно понять. Если требование сформулировано неоднозначно — запрашивайте разъяснение.
- Требования к совместимости. «Программа должна работать с СУБД Oracle 12c и PostgreSQL 14». Это разные СУБД. Если заказчик требует поддержки обеих — это либо ошибка, либо попытка затащить конкретного вендора.
- Сроки, нереальные для разработки. «Разработать CRM-систему за 30 дней». Если это не доработка готового решения — такое ТЗ невыполнимо. Участие в такой закупке — гарантированный срыв.
- Отсутствие требований к интеграции. Система должна обмениваться данными с внешними сервисами, но в ТЗ нет ни слова про API, форматы данных или протоколы. После подписания контракта заказчик говорит: «А, ну да, надо еще с 1С интегрировать».
Лайфхак: перед подачей заявки сделайте таблицу соответствия. В одной колонке — требование ТЗ, в другой — как вы его выполняете. Если хотя бы одно требование вызывает вопрос — запрашивайте разъяснение. Это ваше право по 44-ФЗ.
Таблица сравнения: ТЗ на «коробку» vs ТЗ на разработку
| Критерий | Закупка готового ПО | Закупка разработки ПО |
|---|---|---|
| Объект закупки | Программа с известными характеристиками | Результат работ (программа, документация) |
| Требования к функционалу | Конкретный перечень функций (как в описании товара) | Описание сценариев и бизнес-процессов |
| Сроки | Поставка в течение нескольких дней | От 2 месяцев до года |
| Приемка | Проверка наличия функций и лицензии | Тестирование, опытная эксплуатация, подписание актов |
| Риск для заказчика | Несовместимость с инфраструктурой | Недоделанный функционал, срыв сроков |
| Риск для поставщика | Отклонение заявки из-за несоответствия характеристик | Необоснованный отказ в приемке, штрафы |
Эта таблица наглядно показывает: подход к ТЗ на разработку принципиально другой. Нельзя просто скопировать требования из каталога товаров.
Что делать, если вы нашли ошибки в ТЗ заказчика
Ситуация: вы участвуете в закупке на разработку, но видите, что ТЗ составлено с нарушениями. Например, требования ограничивают конкуренцию (указан конкретный язык программирования без обоснования) или содержат взаимоисключающие пункты.
Ваши действия:
- Запросить разъяснение. По 44-ФЗ у вас есть право направить запрос заказчику. Если он не ответит или ответит уклончиво — это повод для жалобы.
- Подать жалобу в ФАС. Если нарушения очевидны (например, в ТЗ указан товарный знак без слов «или эквивалент»), жалоба может приостановить закупку.
- Не участвовать. Иногда самый выгодный вариант — пропустить сомнительный лот. Штрафы за срыв контракта могут быть больше, чем потенциальная прибыль.
Но есть нюанс: если вы уже подписали контракт, а потом обнаружили, что ТЗ невыполнимо — это не освобождает вас от ответственности. Суды часто встают на сторону заказчика, если поставщик не запрашивал разъяснения на этапе закупки.
FAQ: Частые вопросы по ТЗ на IT-разработку
1. Можно ли в ТЗ указать конкретную СУБД или язык программирования?
Можно, если это обосновано. Например, если система должна интегрироваться с существующей инфраструктурой заказчика, где уже используется PostgreSQL. Но если обоснования нет — это ограничение конкуренции, и ФАС может признать закупку незаконной.
2. Что делать, если в ТЗ есть требования к «удобному интерфейсу»?
Требовать конкретики. «Удобный» — субъективная оценка. Запросите разъяснение: какие именно критерии удобства? Время выполнения типовой операции? Количество кликов для достижения цели? Если заказчик не может ответить — это риск для обеих сторон.
3. Обязательно ли прикладывать к ТЗ макеты интерфейсов?
Не обязательно, но желательно. Макеты (wireframes) снимают множество споров на этапе приемки. Если заказчик не готов делать макеты — можно включить в ТЗ требование разработать прототип на этапе проектирования и согласовать его.
4. Как описать в ТЗ требования к безопасности?
Ссылайтесь на нормативные документы: 152-ФЗ (персональные данные), приказы ФСТЭК, ГОСТы по защите информации. Не пишите «система должна быть защищена» — укажите класс защищенности, требования к разграничению доступа, шифрованию.
5. Можно ли изменить ТЗ после заключения контракта?
По 44-ФЗ — да, но с ограничениями. Изменения не должны менять суть контракта (объект закупки). Если вы понимаете, что ТЗ требует корректировки — оформляйте дополнительное соглашение. Но лучше все предусмотреть на этапе подготовки.
6. Что важнее: ТЗ или контракт?
Оба документа равнозначны. Но если в контракте сказано одно, а в ТЗ — другое, приоритет имеет контракт. Поэтому проверяйте, чтобы условия не противоречили друг другу.
7. Как поставщику проверить ТЗ на реалистичность?
Сделайте декомпозицию работ: разбейте разработку на этапы, оцените трудозатраты по каждому этапу. Если суммарное время превышает срок контракта — либо вы ошиблись в оценке, либо ТЗ невыполнимо. Второй вариант встречается чаще.
Вывод: как не потерять деньги на ТЗ
Техническое задание на IT-разработку по 44-ФЗ — это не формальность, а основа вашего контракта. Ошибки в нем стоят дорого: от штрафов до судебных исков.
Если вы заказчик — не экономьте время на подготовку ТЗ. Привлекайте экспертов, которые понимают разницу между «хочу как в Яндексе» и «требования к производительности». Если вы поставщик — не бойтесь задавать вопросы и запрашивать разъяснения. Лучше потерять заявку сейчас, чем получить убытки через полгода.
В учебном центре «Дипломикс» мы помогаем и заказчикам, и поставщикам разбираться в тонкостях 44-ФЗ. Если вам нужно составить или проверить ТЗ на IT-разработку — записывайтесь на консультацию. Разберем ваш случай, найдем риски и подготовим документы, которые пройдут любую проверку.
Не хотите рисковать контрактом? Свяжитесь с нами — поможем составить ТЗ, которое защитит ваши интересы.
