Как составить ТЗ на разработку

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

Кстати, в AmSales мы делаем интеграцию с 1С и внедрение и настройку Битрикс24 под ключ. Если нужна помощь - напишите нам.

Ключевые этапы составления технического задания

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

Первый этап - это сбор и декомпозиция бизнес-процессов. Прежде чем описывать кнопки, нужно отрисовать путь пользователя (User Flow) и логику движения данных. Например, если это CRM, важно понимать, в какой момент лид переходит в статус "сделка" и какие поля при этом становятся обязательными. На этом этапе формируется верхнеуровневый функциональный состав системы. Без четкого понимания того, какие роли будут в системе (администратор, менеджер, клиент), дальнейшая работа превратится в бесконечные правки.

Второй этап - описание функциональных и нефункциональных требований. Функциональные требования - это то, что система делает (например, "система должна отправлять уведомление в Telegram при поступлении оплаты"). Нефункциональные требования - это то, как она это делает (скорость отклика, нагрузка, масштабируемость). Часто про нагрузку забывают, а потом выясняется, что при 100 одновременных пользователях база данных "ложится". Это критично для любого масштабируемого продукта.

Третий этап - проектирование архитектуры и интеграций. Здесь вы определяете, с какими внешними сервисами будет обмениваться ПО. Это может быть интеграция с банками, государственными сервисами (например, через "Госуслуги" для получения налоговых уведомлений) или складскими программами типа 1С. Важно зафиксировать протоколы обмена данными (REST API, SOAP) и формат передаваемых данных. Если вы не пропишете интеграции сразу, стоимость их добавления "по ходу дела" может составить до 40% от первоначального бюджета.

Структура идеального документа

Хороший пример ТЗ на разработку программного продукта включает в себя следующие блоки:

• Общие сведения и цели проекта.
• Термины и определения (чтобы разработчик и заказчик понимали "пользователя" одинаково).
• Описание предметной области и бизнес-процессов.
• Требования к функциональности (разбитые по модулям).
• Требования к интерфейсу (UI/UX).
• Требования к информационной безопасности и хранению данных.
• Порядок приемки и критерии тестирования.

Требования к ИИ и хранению данных

С 1 сентября 2026 года правила игры в сфере интеллектуальных систем радикально изменились. С вступлением в силу Федерального закона от 26.07.2026 № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации», требования к ТЗ стали гораздо жестче. Теперь, если ваш продукт использует функции ИИ, вы обязаны закладывать в ТЗ механизмы маркировки контента, созданного с помощью нейросетей. Это не просто формальность, а юридическое требование для прозрачности взаимодействия с пользователем.

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

Еще один критический момент - локализация. В 2026 году подтверждено: разработчиками национальных и суверенных моделей ИИ могут быть только российские юридические лица. Если вы планируете использовать ИИ-модули в продукте, в ТЗ необходимо прописать требование об использовании исключительно российских моделей или моделей, развернутых на отечественной инфраструктуре. Использование зарубежных облачных API для обработки данных пользователей теперь несет не только технические, но и серьезные комплаенс-риски.

Что касается хранения данных, то здесь действует правило "территориального суверенитета". Все данные, на которых обучаются модели, а также данные пользователей, обрабатываемые ИИ, должны храниться исключительно на территории России. В ТЗ это должно быть отражено не просто фразой "хранить в РФ", а конкретными требованиями к облачному провайдеру, его локации и методам шифрования при передаче данных. Игнорирование этого требования делает продукт нелегальным с точкими зрения актуального законодательства.

Нюансы импортозамещения и реестра ПО

Сегодня разработка ПО под реестр отечественного софта - это не просто маркетинговый ход, а вопрос выживания на рынке госзаказов и крупных корпораций. Если ваша цель - попасть в реестр, ТЗ должно писаться с учетом требований Постановления Правительства РФ от 28.11.2025 № 1937. Важно понимать, что критерии включения в реестр зависят от категории вашего продукта. Например, для офисного ПО действуют одни правила, а для средств разработки - другие. С 01.01.2027 правила для средств разработки стали еще более детализированными.

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

Для особо значимых проектов, реализуемых в рамках импортозамещения, существует отдельный механизм. Согласно Постановлению Правительства РФ от 19.06.2026 № 760, компании могут модернизировать или разрабатывать ПО за счет собственных средств, чтобы закрыть дыры в технологическом стеке. В этом случае ТЗ должно быть максимально подробным в части "перехода" со старого решения на новое. Нужно описать не только новый функционал, но и способы миграции данных из ушедших зарубежных систем без потери целостности.

Не забудьте про сроки. Поскольку правила формирования реестра менялись (последние крупные изменения вступили в силу в сентябре 2026 года для офисного ПО), при составлении ТЗ нужно опираться на актуальную редакцию критериев Минцифры. Использование устаревших требований из 2024 или начала 2025 года приведет к тому, что вы потратите бюджет на разработку функций, которые не помогут вам получить статус отечественного ПО.

Особенности для платформенной экономики

С 1 октября 2026 года в России вступил в силу закон о платформенной экономике, который перевернул рынок маркетплейсов, сервисов доставки и фриланс-бирж. Теперь, если вы разрабатываете платформенное решение, ваше ТЗ должно содержать модули автоматизированной проверки. Например, система должна автоматически проверять карточки товаров на соответствие обязательным требованиям и блокировать публикацию, если отсутствуют необходимые сведения. Это не просто "фича", а требование закона, нарушение которого ведет к штрафам для самой платформы.

Другой важный аспект - управление занятостью. Если ваша платформа работает с самозанятыми, в бизнес-логику системы необходимо внедрить жесткие лимиты. Согласно новым правилам, один самозанятый может работать через одну платформу не более 60 часов в месяц у одного заказчика в течение 6 месяцев подряд. Если ваша система позволяет обойти этот лимит, вы подставляете и себя, и своих заказчиков под юридические риски. В ТЗ должен быть прописан механизм мониторинга этих часов и автоматическая блокировка возможности выполнения заказов при достижении порога.

Интеграция с государственными сервисами также стала обязательным элементом. Например, учитывая, что с августа 2026 года налоговые уведомления приходят физлицам на "Госуслуги", любая платформа, имеющая личный кабинет пользователя, должна предусматривать возможность интеграции с государственными API для синхронизации статусов и уведомлений. Это повышает доверие пользователей и снижает нагрузку на вашу службу поддержки.

Безопасность и защита данных по ФСТЭК

Безопасность в 2026 году - это не "антивирус и сложный пароль". ФСТЭК России обновила правила поиска уязвимостей и скрытых возможностей в ПО. Если вы разрабатываете систему для крупного бизнеса, финтеха или госсектора, в ТЗ обязательно должен быть раздел о безопасной разработке (Secure SDLC). Это подразумевает не только проверку кода на наличие дыр, но и проектирование системы так, чтобы она была устойчива к современным методам атак.

В ТЗ нужно четко определить уровень защищенности, который требуется от продукта. Если система предполагает работу с персональными данными или государственными информационными системами, требования будут включать в себя использование сертифицированных средств защиты информации, разграничение прав доступа на уровне ядра и ведение детальных логов всех действий привилегированных пользователей. Помните, что требования ФСТЭК к тестированию безопасности могут потребовать выделения отдельного этапа в проекте, на который уйдет от 15% до 25% времени разработки.

Важным нюансом является защита от утечек данных через API. В эпоху микросервисной архитектуры большинство взломов происходит не через интерфейс, а через некорректно настроенные эндпоинты. В ТЗ следует прописать требования к аутентификации и авторизации каждого запроса, а также к ограничению частоты запросов (rate limiting), чтобы предотвратить попытки массового сбора данных (scraping) или brute-force атак.

Также не стоит забывать о требованиях к хранению логов. В случае инцидента безопасности вам нужно будет доказать, что именно произошло, кто имел доступ к данным и в какой момент была обнаружена проблема. Логи не должны быть просто "текстовыми файлами на сервере"; они должны быть защищены от модификации самим разработчиком или администратором системы, что часто требует использования специализированных WORM-хранилищ (Write Once, Read Many).

Как избежать переквалификации отношений

Это "минное поле" для всех, кто разрабатывает платформенные сервисы или системы управления персоналом. Постановление Правительства РФ от 19.06.2026 № 760 четко указывает: если вы создаете инструмент, который позволяет заказчику использовать труд самозанятого более 60 часов в месяц в течение полугода, налоговая может признать такие отношения трудовыми. Это влечет за собой доначисление налогов, взносов и огромные штрафы.

Чтобы защитить бизнес, в ТЗ на разработку HR-модулей или платформ занятости нужно закладывать механизмы "предохранителей". Например, система должна не просто считать часы, а иметь функционал уведомления обеих сторон о приближении к критическому порогу. Более того, логика системы не должна напоминать трудовой распорядок: в ТЗ не должно быть требований по контролю времени "с 9 до 18", контроля рабочего места или жесткого графика дежурств. Платформа должна обеспечивать взаимодействие, а не управление процессом труда.

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

Для минимизации рисков рекомендуем при проектировании логики оплаты использовать модели, которые не привязаны к фиксированному окладу. Оплата за конкретный результат (milestone), за закрытую задачу или за объем выполненных работ - это стандарт для гражданско-правовых отношений. В ТЗ это должно быть отражено в архитектуре платежного модуля: транзакции должны быть привязаны к актам выполненных работ или закрытым тикетам в системе.

Типичные ошибки при описании логики

Самая частая ошибка - использование размытых формулировок. Фразы типа "система должна работать быстро", "интерфейс должен быть удобным" или "высокая степень надежности" - это мусор. Разработчик поймет "быстро" как "отклик в 2 секунды", а заказчик - как "мгновенно". В ТЗ всегда должны быть численные показатели: "время отклика API не более 200 мс при нагрузке 500 RPS", "доступность сервиса (uptime) не менее 99.9%".

Вторая ошибка - отсутствие описания негативных сценариев. Большинство людей пишут ТЗ для "идеального пути" (Happy Path), когда пользователь нажимает правильные кнопки и вводит корректные данные. Но система живет в мире ошибок. Что произойдет, если во время оплаты пропадет интернет? Что будет, если пользователь введет отрицательную сумму заказа? Что, если API государственного сервиса вернет ошибку 500? Если эти сценарии не описаны, разработчик реализует их "на свое усмотрение", и результат вас разочарует.

Третья ошибка - нарушение целостности данных при интеграциях. Часто в ТЗ пишут: "данные из CRM должны передаваться в 1С". Но не пишут, что делать, если в CRM у товара есть поле "Цвет", а в 1С его нет. Или если артикулы в системах не совпадают. В итоге данные либо теряются, либо "мусорят" в базе. Всегда прописывайте правила маппинга (сопоставления) полей и логику обработки конфликтов данных.

Четвертая ошибка - игнорирование ролевой модели. Часто разработчики создают систему, где права доступа размыты. В итоге менеджер по продажам может случайно удалить базу клиентов или увидеть зарплаты руководителей. В ТЗ должна быть детальная матрица доступа: какая роль к какому объекту (сущности) имеет доступ (чтение, запись, удаление, редактирование) и при каких условиях.

Что запомнить

• Всегда проверяйте актуальность требований к ИИ и хранению данных согласно ФЗ № 243-ФЗ.
• Включайте в ТЗ механизмы контроля лимитов для самозанятых, чтобы избежать переквалификации отношений.
• Прописывайте требования к импортозамещению и реестру ПО на этапе проектирования архитектуры, а не после запуска.
• Заменяйте качественные прилагательные ("быстрый", "надежный") на количественные метрики.
• Описывайте не только идеальный путь пользователя, но и все возможные ошибки системы.