Почти каждый второй тендер на IT-разработку по 44-ФЗ либо срывается, либо заканчивается претензиями заказчика. Причина почти всегда одна — техническое задание, которое невозможно исполнить так, чтобы результат устроил обе стороны. Я работаю с госзакупками программ для ЭВМ больше семи лет и вижу одну и ту же картину: поставщики либо пишут ТЗ «на отвали», либо копируют шаблоны из интернета, которые не работают в реальных торгах. В этой статье разберу, как составить техническое задание на IT-разработку по 44-ФЗ, чтобы не потерять деньги, время и репутацию.
Почему ТЗ на IT-разработку — это не просто формальность
В 44-ФЗ техническое задание — это не приложение к контракту, а его основа. Если в ТЗ допущена ошибка, заказчик может отказаться принимать работу, а вы останетесь без оплаты. По статистике ФАС, около 30% жалоб на IT-закупки связаны именно с некорректным описанием объекта закупки. При этом суды часто встают на сторону заказчика, если ТЗ составлено с нарушением требований закона.
Программа для ЭВМ — это не «коробка» с фиксированными функциями. Это живой продукт, который должен решать конкретные задачи. Поэтому в ТЗ нужно прописать не просто «что сделать», а «как проверить, что сделано правильно».
Структура технического задания на IT-разработку по 44-ФЗ
В законе нет жёсткой формы ТЗ, но есть требования к описанию объекта закупки (ст. 33 44-ФЗ). На практике я рекомендую использовать проверенную структуру, которая закрывает все риски:
- Наименование и цель работы — кратко, но без обобщений. Не «Разработка ПО», а «Разработка программы для ЭВМ «Система учёта заявок» для нужд отдела ИТ».
- Функциональные требования — что именно должна делать программа. Без технического жаргона, но с конкретикой.
- Требования к архитектуре и совместимости — на каких ОС, СУБД и оборудовании будет работать продукт.
- Требования к документации — какие инструкции, руководства и исходники вы передаёте.
- Порядок приёмки и критерии оценки — как заказчик поймёт, что работа выполнена.
- Сроки и этапы — разбивка на этапы с чёткими дедлайнами.
- Требования к гарантии и сопровождению — сколько и как вы будете исправлять ошибки после сдачи.
Главные ошибки поставщиков при составлении ТЗ
Ошибка №1 — копирование шаблонов. Я видел ТЗ, где в требованиях к программе для ЭВМ было написано «должна быть удобной». Это не критерий, это пустой звук. Заказчик скажет, что ему неудобно, и вы будете переделывать бесплатно.
Ошибка №2 — избыточная детализация. Если вы пропишете каждую кнопку и каждый запрос к БД, вы загоните себя в угол. Любое отклонение от ТЗ — повод для штрафа. Оставляйте пространство для манёвра, но в разумных пределах.
Ошибка №3 — игнорирование совместимости. Часто заказчик не знает, какое у него оборудование. Пропишите в ТЗ, что вы предоставляете программу для ЭВМ, которая работает на Windows Server 2019 и PostgreSQL 14. Если у заказчика другое — это его проблема, но лучше проверить до подписания контракта.
Как прописать функциональные требования без риска
Функциональные требования — самая спорная часть ТЗ. Я рекомендую использовать метод «пользовательских историй» (user stories). Вместо «система должна отправлять уведомления» пишите: «Пользователь с ролью «Администратор» может настроить автоматическую отправку уведомлений на email при наступлении события X». Это снимает двусмысленность.
Пример из практики: один поставщик написал в ТЗ «программа должна формировать отчёты». Заказчик потребовал 50 видов отчётов, хотя в спецификации было 10. Суд встал на сторону заказчика, потому что «формировать отчёты» — это неограниченное требование. Прописывайте точное количество и формат.
Таблица сравнения: что писать и что не писать в ТЗ
| Что писать | Чего избегать |
|---|---|
| «Программа должна поддерживать импорт данных из Excel в формате .xlsx» | «Программа должна быть совместима с популярными форматами» |
| «Время отклика интерфейса не более 2 секунд при 100 одновременных пользователях» | «Система должна работать быстро» |
| «Исходный код передаётся на языке Python 3.10 с комментариями на русском» | «Исходный код передаётся в понятном виде» |
| «Гарантийное обслуживание 12 месяцев с исправлением ошибок за 5 рабочих дней» | «Гарантия на продукт» |
Требования к документации и исходникам
Многие поставщики забывают, что по 44-ФЗ заказчик имеет право требовать не только работающую программу, но и документацию. В ТЗ обязательно пропишите:
- Руководство пользователя (в формате PDF или DOCX).
- Руководство администратора (описание развёртывания и настройки).
- Исходный код на носителе или в репозитории (GitLab, GitHub).
- Инструкцию по установке и обновлению.
Без этого приёмка может затянуться на месяцы. Я знаю случай, когда заказчик не принимал программу, потому что в документации была опечатка в IP-адресе сервера. Формально — нарушение, по факту — потеря времени.
Порядок приёмки: как защитить себя
Приёмка — это этап, на котором чаще всего возникают споры. В ТЗ нужно чётко прописать:
- Кто и как тестирует программу (заказчик, независимый эксперт, вы).
- Какие критерии считаются критическими ошибками (например, потеря данных или неработоспособность ключевого модуля).
- Сколько времени даётся на исправление замечаний.
- Что считается успешной приёмкой (подписание акта или протокол тестирования).
Лайфхак: пропишите в ТЗ, что приёмка осуществляется по заранее согласованному сценарию тестирования. Это исключит субъективные претензии вроде «мне не нравится цвет кнопки».
Сроки и этапы: как не попасть на неустойку
По 44-ФЗ за каждый день просрочки начисляется пеня — 1/300 ключевой ставки ЦБ от цены контракта. Если контракт на 5 млн рублей, просрочка на месяц может стоить 50-70 тысяч. Чтобы этого избежать, разбивайте работу на этапы с чёткими дедлайнами и оплатой после каждого этапа.
Пример этапов для разработки программы для ЭВМ:
- Этап 1: Разработка технического проекта и прототипа (30% стоимости).
- Этап 2: Разработка MVP и тестирование (40% стоимости).
- Этап 3: Внедрение, документация и финальная приёмка (30% стоимости).
Такая разбивка снижает риски: если заказчик затягивает согласование на первом этапе, вы не работаете в минус.
Как избежать типовых споров с заказчиком
Спор №1: «Программа работает, но не так, как мы хотели». Решение — в ТЗ должно быть описание функционала через сценарии использования, а не через общие фразы.
Спор №2: «Исходный код не соответствует стандартам». Решение — пропишите в ТЗ требования к стилю кода (PEP 8 для Python, PSR для PHP) и наличие комментариев.
Спор №3: «Программа не совместима с нашим оборудованием». Решение — проведите аудит до подписания контракта и пропишите точные характеристики.
FAQ: частые вопросы по ТЗ на IT-разработку по 44-ФЗ
1. Можно ли изменить ТЗ после подписания контракта?
По 44-ФЗ изменение существенных условий контракта запрещено, но есть исключения. Если изменения не меняют объект закупки и не увеличивают цену более чем на 10%, можно оформить дополнительное соглашение. На практике лучше сразу прописывать в ТЗ возможность корректировки в пределах разумного.
2. Что делать, если заказчик требует функционал, не указанный в ТЗ?
Отказывайтесь и ссылайтесь на ТЗ. Если заказчик настаивает, оформляйте дополнительное соглашение на новые работы. Бесплатные доработки — путь к убыткам.
3. Как проверить, что ТЗ составлено корректно?
Проверьте, чтобы каждый пункт ТЗ был измеримым. Если можно задать вопрос «а как это проверить?» и получить однозначный ответ — всё в порядке. Если нет — переписывайте.
4. Нужно ли прикладывать к ТЗ сценарии тестирования?
Желательно. Это снимает споры на этапе приёмки. Достаточно 5-10 ключевых сценариев, которые покрывают основной функционал.
5. Какие санкции за несоответствие ТЗ?
Штрафы по 44-ФЗ: за неисполнение обязательств — до 10% от цены контракта, за просрочку — пеня. В худшем случае — расторжение контракта и включение в реестр недобросовестных поставщиков (РНП).
6. Можно ли использовать открытое ПО в разработке по 44-ФЗ?
Да, если это не нарушает лицензионных соглашений и не противоречит требованиям заказчика. Пропишите в ТЗ, что используется открытое ПО с указанием лицензий.
7. Как защитить свои исходники при передаче заказчику?
По 44-ФЗ исключительные права на программу переходят к заказчику, если это указано в контракте. Если вы хотите оставить права на переиспользование кода, прописывайте это в ТЗ и контракте отдельно.
Вывод: как не потерять деньги на ТЗ
Техническое задание на IT-разработку по 44-ФЗ — это ваш главный инструмент защиты. Не экономьте время на его составлении. Пропишите функционал через сценарии, чётко укажите критерии приёмки и разбейте работу на этапы. Если сомневаетесь в формулировках — лучше проконсультируйтесь с экспертом.
В учебном центре «Дипломикс» мы помогаем поставщикам составлять ТЗ, которые проходят проверку ФАС и не вызывают споров на приёмке. Если хотите избежать типовых ошибок и сдать работу без штрафов — оставьте заявку на консультацию. Разберём ваш контракт, подскажем, как усилить позиции, и поможем подготовить документы, которые защитят ваш бизнес.
