Сравнения и выбор

ТЗ на разработку цифрового сервиса: спецификация, прототип или user stories — что выбрать перед договором

Автор и проверка: Алексей Воронов, редакционный координатор miniwebsansar.com · Факты, документы, риски и применимость · Обновлено: 30 сентября 2025 г.

Перед договором не всегда нужно классическое ТЗ на 80–120 страниц: для понятного сервиса часто хватает спецификации, для продукта с важным интерфейсом нужен прототип, а для поэтапной разработки — user stories с

Критерии выбора

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

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

1. Насколько понятна бизнес-логика

Если сервис простой и уже понятно, как он должен работать, обычно достаточно спецификации. Например, сервис записи на консультации, личный кабинет клиента, каталог с заявками, простая CRM для внутренних задач или мобильное приложение с 5–10 основными экранами можно описать через функции, роли, статусы и интеграции.

В спецификации нужно указать:

• кто пользуется сервисом: клиент, менеджер, администратор, партнер;

• какие действия выполняет каждая роль;

• какие статусы есть у заявки, заказа, оплаты или обращения;

• какие уведомления отправляются;

• какие данные хранятся;

• какие внешние сервисы подключаются;

• что входит в первую версию, а что остается на следующий этап.

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

2. Сколько экранов и пользовательских сценариев

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

Прототип особенно нужен, если в сервисе есть:

• регистрация и восстановление доступа;

• личный кабинет;

• оплата, подписка, возврат или промокоды;

• длинные формы;

• фильтры, поиск, сортировка;

• мобильная и веб-версия;

• роли с разными правами;

• пуш-уведомления, email, SMS;

• сценарии ошибок: не прошел платеж, нет интернета, пустой результат поиска, заявка отменена;

• админ-панель с управлением пользователями, заказами, тарифами или контентом.

Например, фраза «пользователь оформляет заказ» может означать 3 экрана или 12 экранов. В первом варианте человек выбирает услугу, подтверждает данные и оплачивает. Во втором — выбирает адрес, время, тариф, исполнителя, вводит промокод, подтверждает телефон, выбирает карту, получает чек, отслеживает статус и пишет в поддержку. Без прототипа эти различия легко не заметить до начала разработки.

3. Нужна ли гибкая разработка

User stories подходят, когда продукт развивается итерациями: сначала MVP, затем аналитика, личный кабинет, интеграции, рекомендации, расширенная админ-панель. Это удобно для Scrum, Kanban и других форматов, где работа идет спринтами по 1–2 недели.

Хорошая user story описывает не просто функцию, а пользу для конкретной роли:

> Как клиент, я хочу восстановить доступ по email, чтобы войти в аккаунт без обращения в поддержку.

Но сама история недостаточна. К ней нужны критерии приемки:

• пользователь вводит email;

• система отправляет одноразовую ссылку;

• ссылка действует 30 минут;

• после смены пароля старые сессии сбрасываются;

• сообщение об ошибке не раскрывает, зарегистрирован ли email;

• событие фиксируется в журнале безопасности.

Без критериев приемки user stories превращаются в список пожеланий. Формулировка «как пользователь, я хочу удобный личный кабинет» не защищает ни заказчика, ни подрядчика. Ее нужно разбить на проверяемые части: профиль, документы, история оплат, уведомления, настройки безопасности, удаление аккаунта.

4. Какой уровень юридической защиты нужен

Если проект небольшой, а цена ошибки невысока, можно обойтись компактным набором документов. Если сервис обрабатывает платежи, персональные данные, медицинскую, финансовую или корпоративную информацию, нужен более строгий комплект.

Перед договором стоит подготовить или запросить:

• техническое задание, спецификацию или backlog user stories;

• смету с этапами и стоимостью;

• календарный план;

• порядок приемки;

• правила внесения правок;

• условия гарантии;

• условия поддержки после запуска;

• акт выполненных работ;

• порядок передачи исключительных прав или лицензии;

• перечень сторонних сервисов, библиотек, шаблонов, API и платных лицензий;

• требования к передаче исходного кода, макетов, документации и доступов.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов, отсутствие поддержки, неясные права на код и дизайн. Эти вопросы нужно закрывать до предоплаты, а не после первого конфликта.

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

| Формат перед договором | Когда выбирать | Что фиксирует | Сильные стороны | Основные риски |

|---|---|---|---|---|

| Спецификация | Логика понятна, нужен быстрый старт | функции, роли, статусы, интеграции, приемку | быстрее и дешевле полного ТЗ | может не показать проблемы интерфейса |

| Прототип | Много экранов и сценариев | структуру экранов, переходы, состояния, формы | снижает риск UX-переделок | без текстовых требований не описывает всю логику |

| User stories | Нужна поэтапная разработка MVP | ценность, сценарии, критерии приемки | удобно для спринтов и приоритизации | без границ backlog растет бесконечно |

| Полное ТЗ | Сложный проект, тендер, фиксированная цена | полный объем работ, архитектуру, требования, приемку | лучше защищает стороны в договоре | дольше и дороже готовить |

Вариант 1. Спецификация

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

Для сервиса онлайн-записи спецификация может включать:

• регистрацию по телефону и email;

• каталог услуг;

• выбор специалиста и времени;

• SMS, email или push-уведомления;

• онлайн-оплату;

• личный кабинет клиента;

• админ-панель для расписания;

• интеграцию с CRM;

• отчет по заявкам;

• роли администратора и оператора.

Для небольшого сервиса такую спецификацию часто реально подготовить за 3–7 рабочих дней. Стоимость предпроектного описания у подрядчиков различается: для малого продукта это может быть 30 000–150 000 ₽, для сервиса с интеграциями, личным кабинетом и несколькими ролями — 150 000–400 000 ₽ и выше. Иногда аналитика включается в первый этап разработки, но лучше видеть ее стоимость отдельно.

Спецификация подходит, если:

• продукт типовой;

• основная логика уже понятна;

• нет сложных исключений;

• подрядчик делал похожие решения;

• стоимость разработки фиксируется по этапам;

• нужно сравнить 2–3 предложения от разных исполнителей.

Спецификация не подходит как единственный документ, если:

• важна конверсия интерфейса;

• в сервисе много шагов и состояний;

• есть платежи, подписки, возвраты;

• разные подразделения по-разному понимают продукт;

• есть риск, что заказчик и подрядчик представляют разные экраны под одной и той же функцией.

Вариант 2. Прототип

Прототип показывает, как пользователь движется по сервису. Это не финальный дизайн и не готовое приложение, а схема экранов, переходов и состояний.

Для мобильного приложения прототип особенно полезен, потому что нужно заранее увидеть:

• первый вход;

• разрешения на уведомления и геолокацию;

• регистрацию;

• восстановление доступа;

• пустые состояния;

• ошибки сети;

• оплату;

• историю действий;

• поддержку;

• повторную авторизацию.

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

Прототип снижает стоимость ошибок. Исправить схему экрана на этапе прототипа обычно дешевле, чем менять уже сверстанный интерфейс, подключенный к backend. Если разработка одного сложного экрана стоит условно 20 000–80 000 ₽, ошибка в логике на 10–15 экранах может превратиться в отдельную доработку на сотни тысяч рублей.

Но прототип не заменяет спецификацию. На схематичном экране не всегда видно:

• какие поля обязательны;

• какие форматы данных допустимы;

• какие проверки выполняются;

• какие уведомления отправляются;

• какие интеграции нужны;

• что считается ошибкой;

• как тестировать результат;

• что входит в гарантию.

Лучший вариант для интерфейсного продукта — прототип плюс короткая текстовая спецификация. Прототип отвечает на вопрос «как пользователь это проходит», а спецификация — «что система должна делать и как это принять».

Вариант 3. User stories

User stories удобны, когда проект нельзя полностью зафиксировать заранее или команда сознательно идет к продукту через MVP. Такой подход подходит для стартапов, SaaS, внутренних автоматизаций, маркетплейсов, сервисов подписки и продуктов, где после первых пользователей требования будут уточняться.

Пример user stories для B2B-сервиса заявок:

• как менеджер, я хочу видеть список новых заявок, чтобы быстро распределять их между исполнителями;

• как исполнитель, я хочу получать уведомление о назначенной задаче, чтобы не пропустить срок;

• как администратор, я хочу менять роли пользователей, чтобы управлять доступом без разработчика;

• как руководитель, я хочу видеть отчет по просроченным задачам, чтобы контролировать качество работы команды.

Для договора важно указать, какие истории входят в первую поставку. Например:

• релиз 1: регистрация, роли, создание заявки, список заявок, назначение исполнителя, уведомления;

• релиз 2: отчеты, фильтры, экспорт, комментарии;

• релиз 3: интеграция с CRM, расширенная аналитика, API.

User stories подходят, если:

• разработка идет спринтами;

• есть product owner или ответственный со стороны заказчика;

• MVP важнее полного релиза;

• часть требований будет уточняться после тестирования;

• бюджет выделяется по этапам;

• команда готова регулярно проводить демонстрации и приемку.

User stories не подходят как единственная основа договора, если:

• цена строго фиксирована;

• объем работ нельзя менять;

• заказчик не готов участвовать в спринтах;

• нет приоритизации backlog;

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

Вариант 4. Полное ТЗ

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

В полном ТЗ обычно фиксируют:

• цель продукта;

• границы проекта;

• роли пользователей;

• функциональные требования;

• нефункциональные требования;

• требования к производительности;

• требования к безопасности;

• требования к доступности;

• структуру данных;

• API;

• интеграции;

• события и уведомления;

• админ-панель;

• журналирование действий;

• резервное копирование;

• порядок тестирования;

• критерии приемки;

• состав передаваемых материалов.

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

Полное ТЗ готовится дольше. Для среднего цифрового сервиса аналитика может занять 2–4 недели, для сложной корпоративной системы — 1–2 месяца. Но если общий бюджет проекта составляет несколько миллионов рублей, экономия на предпроектной проработке часто приводит к более дорогим спорам, задержкам и переделкам.

Критерии проверки

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

Таблица проверки перед договором

| Что проверить | Как проверить | Что должно насторожить |

|---|---|---|

| Портфолио | Попросить 3–5 похожих проектов и уточнить роль подрядчика | показывают только красивые экраны без объяснения задач |

| Смету | Запросить базовую, оптимальную и срочную версии | одна общая сумма без этапов и состава работ |

| Сроки | Попросить календарный план по неделям | обещание «сделаем быстро» без дат |

| ТЗ или спецификацию | Проверить функции, роли, интеграции, приемку | много общих слов и нет измеримых критериев |

| Прототип | Посмотреть ключевые сценарии, ошибки и состояния | есть только главные экраны без переходов |

| User stories | Проверить критерии приемки и приоритеты | backlog есть, но непонятно, что входит в первую версию |

| Правки | Уточнить количество включенных итераций | правки только «по договоренности» |

| Гарантию | Зафиксировать срок исправления ошибок | гарантия не указана или заканчивается сразу после акта |

| Поддержку | Уточнить SLA, каналы связи, стоимость часа | после запуска поддержки нет |

| Права | Проверить передачу кода, макетов, документации | подрядчик оставляет критичные материалы у себя |

| Сторонние сервисы | Узнать стоимость лицензий, API, хостинга, SMS | ежемесячные платежи выясняются после запуска |

| Форматы файлов | Указать репозиторий, исходники, макеты, документацию | передают только сборку или картинки без исходников |

Измеримые критерии приемки

В договоре и приложениях лучше избегать оценочных слов. Вместо «быстро загружается» — «основные страницы открываются до 2 секунд при тестовой нагрузке». Вместо «удобная форма» — «форма содержит 6 обязательных полей, проверку email, маску телефона и сообщение об ошибке».

Что стоит измерять и фиксировать:

• список экранов и состояний;

• список ролей и прав доступа;

• поддерживаемые платформы: web, iOS, Android;

• поддерживаемые браузеры и версии ОС;

• количество интеграций;

• требования к API;

• сценарии тестирования;

• время реакции поддержки;

• гарантийный срок: например 30, 60 или 90 дней;

• стоимость часа доработок после приемки;

• количество раундов правок;

• состав передаваемых материалов.

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

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

Если выбрать только спецификацию

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

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

Если выбрать только прототип

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

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

Если выбрать только user stories

Backlog может бесконечно расти. Заказчик считает, что «личный кабинет» включает документы, подписки, историю платежей, уведомления и поддержку, а подрядчик заложил только профиль и смену пароля.

Что сделать: разбить крупные истории на мелкие, назначить приоритеты, указать релиз 1, релиз 2 и релиз 3. В договоре отдельно отметить, какие истории входят в оплаченный этап.

Если сразу писать полное ТЗ

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

Что сделать: сначала провести короткий discovery, собрать прототип MVP, оценить 2–3 варианта реализации, затем фиксировать подробное ТЗ.

Как выбрать формат под конкретный сценарий

Интернет-сервис с простой заявкой

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

Оптимальный комплект:

• спецификация на 10–25 страниц;

• схема пользовательского пути;

• смета по этапам;

• календарный план;

• критерии приемки;

• условия поддержки.

Мобильное приложение

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

Оптимальный комплект:

• прототип основных экранов;

• спецификация логики;

• перечень платформ: iOS, Android или обе;

• список поддерживаемых версий ОС;

• требования к push, аналитике, авторизации;

• критерии публикации и передачи исходников.

SaaS для бизнеса

Для SaaS-продукта лучше сочетать user stories, спецификацию и прототип ключевых экранов. Обычно здесь есть роли, тарифы, ограничения, права доступа, отчеты, уведомления, импорт и экспорт данных. Если это не зафиксировать, после запуска начнутся споры о том, что входило в первую версию.

Оптимальный комплект:

• backlog user stories;

• приоритеты для MVP;

• прототип личного кабинета и админ-панели;

• спецификация тарифов, ролей и ограничений;

• требования к API и интеграциям;

• порядок поддержки и развития.

Корпоративная система

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

Оптимальный комплект:

• полное ТЗ;

• архитектурная схема;

• описание интеграций;

• требования к безопасности;

• регламент тестирования;

• план миграции данных;

• порядок приемки по этапам;

• гарантия и SLA поддержки.

Что проверять в 2026 году перед подписанием договора

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

Проверьте заранее:

• кто оплачивает хостинг, домен, облачное хранилище, SMS, email-рассылки, push-сервисы;

• есть ли платные API и лимиты запросов;

• сколько стоит поддержка после релиза;

• какая стоимость часа доработок;

• передается ли исходный код;

• где будет храниться репозиторий;

• кто владеет дизайном, макетами и документацией;

• какие данные собираются и как удаляются;

• кто отвечает за обновления библиотек и безопасность.

Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную. В базовой версии должны быть только обязательные функции MVP. В оптимальной — важные улучшения, которые реально повышают пользу продукта. В срочной — доплата за ускорение, параллельную работу команды или сокращение сроков. Если подрядчик дает только одну сумму без состава работ, сравнить предложения будет сложно.

Можно ли подписывать договор без ТЗ?

Можно, но рискованно. Если нет ТЗ, спецификации, прототипа или backlog с критериями приемки, стороны по-разному понимают объем работ. Минимум перед договором нужен список функций, ролей, интеграций, сроков, этапов, стоимости, правок, гарантии и приемки.

Что лучше для небольшого цифрового сервиса: ТЗ или спецификация?

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

Прототип может заменить ТЗ?

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

Когда нужны user stories?

User stories нужны, когда продукт создается поэтапно и требования будут уточняться после первых релизов. Они хорошо подходят для MVP, SaaS, внутренних систем и сервисов, которые развиваются спринтами. Главное — добавлять критерии приемки и фиксировать, какие истории входят в оплаченный этап.

Сколько времени закладывать на подготовку ТЗ?

Для компактной спецификации можно ориентироваться на 3–7 рабочих дней. Для среднего сервиса аналитика и ТЗ часто занимают 2–4 недели. Для сложной корпоративной системы с интеграциями, безопасностью и несколькими ролями подготовка может занять 1–2 месяца.

Что обязательно должно быть в смете?

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

Какие формулировки в договоре опасны?

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

Что проверить у подрядчика перед предоплатой?

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

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

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

Как понять, что ТЗ достаточно подробное?

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