Техническое задание для разработки: сценарии, приемка и права

Критерии выбора и требования к документу

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

Что изменилось в индустрии и что проверять сейчас

Требования к процессу разработки постоянно ужесточаются. При составлении ТЗ сегодня необходимо учитывать несколько важных факторов:

* Использование AI-инструментов: многие команды разработчиков применяют нейросети (например, GitHub Copilot) для написания кода, генерации тестов и документации. В ТЗ и договоре стоит прямо указать, допустимо ли это в вашем проекте, и кто несет ответственность за безопасность, отсутствие уязвимостей и чистоту лицензий сгенерированного кода.

* Рост доли интеграций: современные продукты редко работают изолированно. Платежи, push-уведомления, картографические сервисы, ERP, BI-системы и маркетинговые платформы требуют детального описания API-взаимодействий.

* Требования к инфраструктуре: заказчики все чаще (и справедливо) требуют передачу не только готового билда, но и настроек CI/CD, репозитория, API-документации (Swagger/OpenAPI) и инструкций для DevOps-инженеров.

* Формат сдачи работ: стало юридически и технически опасно принимать работу исключительно «по демонстрации экрана в Zoom». Необходима строгая проверка по заранее описанным тест-кейсам на независимом тестовом стенде.

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

Обязательные блоки в структуре ТЗ

В грамотном техническом задании должны быть зафиксированы не только функции системы, но и условия, при которых каждая функция считается успешно реализованной.

1. Цель и бизнес-логика продукта

Четкое позиционирование. Например: «мобильное приложение для онлайн-записи клиентов на медицинские услуги с интеграцией внутренней МИС», «B2B-портал для оптовых закупок с динамическим ценообразованием».

2. Ролевая модель пользователей

Исчерпывающий список: неавторизованный гость, клиент, администратор, контент-менеджер, модератор, курьер, партнер, бухгалтер, специалист технической поддержки. Для каждой роли прописываются уровни доступа (RBAC).

3. Пользовательские сценарии (Use Cases)

Описание пути пользователя. Не просто «модуль авторизации», а пошаговый алгоритм: пользователь вводит номер телефона -> получает SMS с OTP-кодом -> вводит код -> система проверяет совпадение -> при успехе открывается главный экран личного кабинета -> при ошибке выводится предупреждение.

4. Функциональные требования

Конкретные действия, которые выполняет система: создание заявок, автоматическая отправка email/push-уведомлений, формирование отчетов в формате PDF/XLSX, проведение транзакций, выгрузка логов.

5. Нефункциональные требования (NFR)

Технические ограничения: скорость ответа сервера (например, не более 300 мс), требования к безопасности (шифрование AES-256), частота резервного копирования, поддерживаемые устройства, браузеры (Chrome 100+, Safari 15+), минимальные версии ОС (iOS 15+, Android 10+), отказоустойчивость (SLA 99.9%).

6. Интеграции со сторонними сервисами

Протоколы взаимодействия (REST, GraphQL, SOAP), платежные провайдеры, CRM-системы, складские программы (1С, МойСклад), облачная телефония, картографические API.

7. Критерии приемки (Acceptance Criteria)

Метрики проверки каждой функции: какие тестовые данные используются, какой результат ожидается, как система должна реагировать на некорректный ввод.

8. Права и передаваемые материалы

Кому принадлежат исходный код, дизайн-макеты, структура базы данных, документация, доменное имя, аккаунты в сторах (App Store, Google Play), лицензии и ключи API.

9. Порядок внесения правок

Сколько итераций правок включено в базовую стоимость, четкое разграничение понятий «ошибка (баг)» и «новая задача (фича)».

10. Поддержка после запуска

Длительность гарантийного срока, SLA на исправление критических уязвимостей, стоимость нормо-часа для будущих доработок.

Сравнение вариантов

Перед заказом разработки цифрового продукта компании обычно выбирают один из нескольких подходов к постановке задачи: от короткого брифа до глубокого аналитического этапа. Начинать разработку коммерческого продукта исключительно по устному описанию или переписке в мессенджере — критическая ошибка, ведущая к потере бюджета.

Для коммерческого проекта с внешним подрядчиком наиболее безопасным выбором является связка «ТЗ + смета + критерии приемки». Если продукт сложный, настоятельно рекомендуется начать с отдельного аналитического этапа: составить карту ролей, Customer Journey Map (CJM), кликабельный прототип, архитектурную схему и реестр рисков.

Пример плохого и хорошего требования в ТЗ

Плохо (оставляет пространство для фантазий):

> *«Сделать удобный личный кабинет с оплатой и уведомлениями».*

Хорошо (можно оценить, разработать и протестировать):

> *«Пользователь с ролью "Клиент" может войти в систему по email и одноразовому коду. На главном экране он видит список активных заказов с пагинацией (по 10 на страницу). Клиент может открыть карточку заказа и оплатить счет банковской картой через подключенный виджет платежного сервиса (например, ЮKassa). После успешной транзакции клиент получает email-уведомление с электронным чеком. Функция считается принятой, если: оплата успешно проходит в тестовом контуре, статус заказа в БД меняется на "Оплачен", уведомление доставляется в течение 2 минут, а при имитации ошибки банка пользователю выводится сообщение "Оплата отклонена" без потери содержимого корзины».*

Критерии проверки подрядчика и документации

Перед подписанием договора необходимо проверить не только итоговую цену, но и полноту будущей передачи результата. Типовая ошибка бизнеса — оплатить миллионы рублей за разработку, но по итогу не получить исходники, административные доступы, документацию или исключительные права на дизайн.

Таблица проверки условий сотрудничества

Как правильно описывать пользовательские сценарии

Сценарии (Use Cases) — это фундамент любого ТЗ. Они описывают не статичный список экранов, а динамичный путь пользователя к достижению конкретной цели.

Удобная и понятная структура описания сценария включает:

* Роль пользователя (кто выполняет действие).

* Цель (какой бизнес-результат должен быть достигнут).

* Стартовое условие (что должно произойти до начала сценария).

* Шаги (последовательность действий).

* Альтернативные варианты (что если пользователь пойдет другим путем).

* Ошибки и исключения (как система реагирует на сбои).

* Результат (изменения в системе).

* Критерий приемки (как тестировщик проверит этот сценарий).

Пример сценария для мобильного приложения

Роль: Авторизованный клиент.

Цель: Записаться на услугу в автосервис.

Стартовое условие: Пользователь установил приложение, прошел авторизацию и находится на главном экране.

Шаги:

1. Пользователь открывает раздел «Услуги».

2. Выбирает нужную категорию и конкретную услугу.

3. Открывается календарь: пользователь выбирает доступную дату и слот времени.

4. Система рассчитывает и показывает итоговую стоимость.

5. Пользователь нажимает кнопку «Подтвердить запись».

6. Система отправляет push-уведомление на устройство и дублирует информацию на email.

Ошибки и исключения:

* Выбранное время уже занято другим клиентом (конкурентный запрос) -> система предлагает ближайшие свободные слоты.

* Нет доступа к интернету -> выводится системный алерт «Проверьте подключение к сети».

* Сервис внутренней CRM недоступен -> выводится сообщение «Сервис временно недоступен, попробуйте через 5 минут».

Критерий приемки: Запись успешно создается в базе данных, отображается в разделе «Мои записи» в приложении клиента, администратор автосервиса видит новую заявку в веб-панели, push-уведомление доставляется на тестовое устройство не позднее чем через 2 минуты после подтверждения.

Приемка: как понять, что разработка действительно завершена

Процесс приемки должен быть детально описан до старта работ. В противном случае подрядчик будет считать задачу выполненной сразу после локальной демонстрации, а заказчик — только после успешного запуска на реальных пользователях и получения первой прибыли.

Что включить в критерии приемки

Для каждого крупного модуля или функции укажите:

* тестовые данные (какие логины, пароли, номера карт использовать);

* ожидаемый результат (изменение статусов, появление записей);

* допустимое время реакции интерфейса;

* поведение системы при имитации ошибок (например, отказ платежного шлюза);

* устройства, разрешения экранов и браузеры, на которых проводится проверка;

* срок, выделенный заказчику на проверку (например, 5 рабочих дней).

Пример юридической формулировки для договора:

> *«Заказчик обязуется провести проверку выполненного этапа работ в течение 5 (пяти) рабочих дней с момента предоставления Исполнителем доступа к тестовому стенду и передачи акта. Если мотивированные замечания не направлены Заказчиком в указанный срок, этап считается принятым в полном объеме, за исключением скрытых дефектов, подпадающих под условия гарантийного обслуживания».*

Крайне важно разделять три понятия:

* Баг (ошибка) — функция работает не так, как описано в утвержденном ТЗ. Исправляется бесплатно.

* Правка — незначительное изменение внутри согласованной логики (подвинуть кнопку, изменить цвет, переписать текст уведомления). Обычно лимитируется по количеству.

* Новая задача (Change Request) — требование, которого изначально не было в ТЗ. Оценивается и оплачивается отдельно.

Например: если кнопка «Оплатить» выдает ошибку 500 — это баг. Если нужно изменить текст на кнопке с «Оплатить» на «Перейти к оплате» — это правка. Если после запуска вы решили добавить оплату криптовалютой или систему реферальных промокодов — это новая задача.

Права на код, дизайн и данные

Раздел интеллектуальных прав — один из самых рискованных в IT-разработке. Сам факт оплаты услуг разработчика далеко не всегда означает, что заказчик автоматически получил все исключительные права и исходники. В разных юрисдикциях правила трактуются по-разному, поэтому для крупных проектов формулировки должен проверять профильный IT-юрист.

Что обязательно нужно закрепить в договоре:

* Передаются ли исключительные права в полном объеме или предоставляется только неисключительная лицензия на использование.

* Момент перехода прав: после оплаты конкретного этапа, после 100% оплаты всего договора или в момент подписания акта приема-передачи.

* Объем передаваемого: входят ли в передачу исходный код (комментированный), дизайн-макеты, техническая документация, автотесты, схемы архитектуры БД.

* Использование Open-Source: имеет ли право подрядчик использовать открытые библиотеки (и с какими лицензиями — MIT, Apache разрешены, а вот GPL может потребовать открытия всего вашего кода).

* Портфолио: имеет ли право подрядчик публиковать кейс о вашем проекте, использовать логотип и раскрывать метрики.

* Инфраструктура: на кого регистрируются домены, облачные серверы, аккаунты разработчика (Apple/Google) и сервисы аналитики (строго на заказчика).

Для проектов, ориентированных на международный рынок (особенно с юрисдикцией США), полезно учитывать подход U.S. Copyright Office и положения 17 U.S.C. § 201. В модели *work made for hire* (работа, выполненная по найму) заказчик может считаться первоначальным владельцем прав только при строгом соблюдении установленных условий и наличии прямого письменного соглашения. Безопаснее не полагаться на общую фразу «работа оплачена», а детально прописывать отчуждение прав.

Что запросить при финальной передаче проекта

Минимальный список артефактов для безопасного завершения проекта:

* Полный доступ к репозиторию (GitLab, GitHub, Bitbucket) с историей коммитов.

* Исходный код всех частей: backend, frontend, мобильные приложения.

* Дизайн-исходники в Figma (с передачей прав владельца файла).

* Документация по развертыванию (README, инструкции по запуску).

* Файлы конфигурации и переменные окружения (без раскрытия production-секретов в открытом виде).

* Полный реестр используемых внешних сервисов и API.

* Схема базы данных (ER-диаграмма) и скрипты миграций.

* Инструкции по деплою (CI/CD пайплайны).

* Тестовые аккаунты с разными ролями.

* API-документация (OpenAPI/Swagger).

* Подписанные акты выполненных работ и акты передачи исключительных прав.

Если подрядчик передает вам только скомпилированное приложение (билд) или архив с кодом без инструкций, дальнейшая поддержка продукта станет критически дорогой, а вы окажетесь в заложниках у первоначальной команды (vendor lock-in).

Бюджет и сроки: риски и скрытая стоимость

Для масштабного цифрового проекта всегда запрашивайте 3 варианта сметы: базовую (минимальный жизнеспособный продукт), оптимальную (рекомендуемую подрядчиком) и срочную (с коэффициентом за овертаймы).

Что должно быть прозрачно оценено в смете:

* Аналитика и проектирование архитектуры;

* UX/UI-дизайн и создание дизайн-системы;

* Backend-разработка (серверная часть и БД);

* Frontend-разработка (веб-интерфейс);

* Мобильная разработка (iOS/Android);

* Интеграции со сторонними сервисами;

* QA (ручное и автоматизированное тестирование);

* Публикация в App Store / Google Play / RuStore (включая прохождение модерации);

* Настройка серверов (DevOps);

* Написание технической документации;

* Гарантийная поддержка.

Ориентиры для грамотного планирования:

* Резерв бюджета на непредвиденные изменения: 10–20% от общей суммы.

* Срок проверки каждого этапа заказчиком: 3–5 рабочих дней.

* Гарантия на исправление дефектов: стандартно 30–90 дней после релиза.

* Длительность спринта при итерационной разработке: 1–2 недели.

* Безопасная платежная схема: например, 30% аванс, 40% после сдачи основного функционала на тестовом стенде, 30% после финальной приемки и передачи прав.

Не выбирайте подрядчика исключительно по минимальной цене. Аномально низкая смета почти всегда означает, что в нее не включены аналитика, тестирование, помощь с публикацией, написание документации или передача исключительных прав.

Когда ТЗ не подходит и что может пойти не так

Глубоко проработанное ТЗ нужно не всегда. Оно будет избыточным, если вы проверяете продуктовую гипотезу за пару дней (No-Code решения), собираете внутренний прототип «на коленке» или заказываете микро-правку в уже работающем продукте. В таких случаях достаточно User Story, макета и критерия приемки.

Но для полноценного коммерческого сервиса отсутствие ТЗ генерирует фатальные риски:

* Разрыв ожиданий: подрядчик и заказчик совершенно по-разному видят финальный результат.

* Срыв сроков: проект растягивается на месяцы без понятной зоны ответственности.

* Устные договоренности: невозможно доказать, что конкретная функция обсуждалась на созвоне.

* Скрытые расходы: внезапно выясняется, что нужны платные серверы, дорогие лицензии на шрифты или платные API.

* Неподходящий стек: код написан на устаревшем или экзотическом фреймворке, который никто на рынке не хочет поддерживать.

Особенно опасно начинать разработку мобильного приложения без фиксации требований к версиям ОС, логике работы push-уведомлений, правилам обработки потери сети и политике хранения персональных данных (ФЗ-152, GDPR).

Документы и формальности

• [ ] Составлено детальное ТЗ или аналитическое описание архитектуры проекта.

• [ ] Получена прозрачная смета с разбивкой стоимости по каждому этапу.

• [ ] Согласован календарный план-график с контрольными точками.

• [ ] Подготовлен договор и все необходимые приложения к нему.

• [ ] Четко прописан порядок сдачи и приемки работ.

• [ ] Зафиксированы условия и сроки гарантийного обслуживания.

• [ ] Согласованы условия отчуждения интеллектуальных прав.

• [ ] Подписано NDA (соглашение о неразглашении), если передаются коммерческие тайны или базы данных.

Сценарии и функциональность

• [ ] Описаны все роли пользователей и их права доступа.

• [ ] Для каждой ключевой функции прописан пошаговый пользовательский сценарий.

• [ ] Указаны алгоритмы поведения системы при ошибках и сбоях.

• [ ] Зафиксированы нефункциональные требования (устройства, браузеры, нагрузки).

• [ ] Детально описаны все внешние интеграции.

• [ ] Определены тестовые данные для проверки.

• [ ] Сформулированы измеримые критерии готовности (Definition of Done) для каждого этапа.

Бюджет и сроки

• [ ] Запрошены и проанализированы 3 варианта сметы (базовая, оптимальная, срочная).

• [ ] Зафиксированы сроки подготовки оценок на будущие доработки (обычно 3–7 дней).

• [ ] Понятна стоимость внесения правок сверх лимита.

• [ ] Согласована стоимость часа работы специалистов (Rate) для техподдержки.

• [ ] Заложен финансовый резерв 10–20% на непредвиденные изменения.

• [ ] Утвержден безопасный график платежей (привязанный к результатам, а не к календарю).

• [ ] Четко определено, что считается багом, а что — новой платной задачей.

Права и передача результата

• [ ] Однозначно указано, что исключительные права на код и дизайн переходят к заказчику.

• [ ] В список передаваемых артефактов включены исходники дизайна (Figma).

• [ ] В список включена техническая документация и инструкции.

• [ ] Гарантируется передача прав администратора на репозиторий и серверы.

• [ ] Проверены лицензии сторонних компонентов (отсутствие токсичного Open-Source).

• [ ] Согласованы рамки использования проекта в публичном портфолио разработчика.

• [ ] Подготовлен шаблон акта приема-передачи исключительных прав.

Чем ТЗ отличается от брифа?

Бриф — это документ верхнего уровня. Он описывает бизнес-задачу: что нужно сделать, для какой целевой аудитории и зачем это бизнесу. ТЗ — это инженерный документ. Оно фиксирует технические детали: конкретные сценарии, архитектуру БД, методы API, ограничения, критерии приемки и порядок передачи прав. Для лендинга хватит брифа, для SaaS-продукта обязательно нужно ТЗ.

Можно ли начать разработку вообще без ТЗ?

Технически можно, но для бизнеса это огромный риск. Без ТЗ вы не сможете юридически доказать, что система должна была работать иначе. Для стартапов и MVP допустим гибкий формат (Agile): формируется общий Backlog, рисуется кликабельный прототип, а детальные сценарии и критерии приемки прописываются только на ближайший спринт (1-2 недели).

Кто должен писать ТЗ — заказчик или разработчик?

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

Что важнее в случае спора: ТЗ или договор?

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

Как понять, что критерии приемки написаны нормально?

Хороший критерий не допускает двойных толкований и легко проверяется тестировщиком. Пример хорошего: «Отчет выгружается в формате XLSX за период до 1 года, время формирования не превышает 5 секунд». Пример плохого: «Интерфейс должен быть удобным, красивым, современным и работать быстро». Субъективные оценки невозможно измерить.

Что делать, если в процессе разработки появились новые крутые идеи?

Любые новые идеи нужно фиксировать через процедуру Change Request (запрос на изменение). Подрядчик описывает идею, оценивает ее в часах, показывает влияние на общие сроки и бюджет. После этого заказчик принимает решение: делать сейчас, отложить в бэклог до версии 2.0 или отказаться. Новые идеи не должны «бесплатно» впихиваться в текущую смету, иначе проект никогда не дойдет до релиза.

Нужно ли прописывать в ТЗ права на open-source библиотеки?

Да, это критически важно. В ТЗ или договоре необходимо указать, какие типы лицензий допустимы (например, MIT, Apache 2.0, BSD), кто проверяет их чистоту и можно ли использовать компоненты с копилефт-лицензиями (например, GPL), которые могут обязать вас открыть исходный код всего вашего коммерческого продукта.

Какие документы нужно подписать в самом конце проекта?

Для безопасного завершения сотрудничества подпишите: финальный акт сдачи-приемки выполненных работ, отдельный акт приема-передачи исключительных прав на объекты интеллектуальной собственности. Убедитесь, что вы получили физический доступ к репозиторию, исходному коду, макетам, документации и всем административным панелям до проведения финального платежа.