Как подготовить техническое задание на разработку, чтобы получить точную оценку сроков и бюджета

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

Плохое ТЗ почти всегда приводит к широкой вилке. Если заказчик пишет "нужен сайт как у конкурента", "хотим личный кабинет", "сделайте платформу", "нужен Telegram Mini App", "нужно подключить CRM" или "сделайте красиво и удобно", разработчик не может честно оценить проект. Под такими фразами может скрываться лендинг на одну страницу, сложный веб-сервис с ролями и платежами, каталог, интеграция с 1С, партнерская программа, админка, API, аналитика и месяцы работы.

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

Зачем вообще нужно ТЗ

ТЗ помогает убрать догадки. Бизнес видит свою задачу через результат: нужны заявки, продажи, автоматизация, запуск MVP, личный кабинет, Telegram-продукт, интеграция с CRM. Разработчик видит задачу через объем работ: интерфейс, backend, база данных, роли, формы, платежи, API, админка, тестирование, деплой и поддержка. ТЗ соединяет эти два взгляда.

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

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

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

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

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

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

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

Для простого лендинга брифа и короткого функционального описания может хватить. Для веб-сервиса, личного кабинета, CRM-интеграции, системы билетов, Telegram Mini App или MVP лучше готовить полноценное ТЗ или хотя бы расширенный документ с ключевыми сценариями.

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

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

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

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

Первое - цель проекта. Не "сделать сайт", а "получать заявки на разработку", "продавать билеты онлайн", "запустить MVP сервиса", "автоматизировать партнерские заявки", "дать клиентам личный кабинет", "перенести ручной процесс из таблиц в систему".

Второе - аудитория. Кто будет пользоваться продуктом: клиенты, партнеры, менеджеры, администраторы, ученики, преподаватели, организаторы, поставщики, операторы, сотрудники? У каждой группы разные задачи и права.

Третье - текущий процесс. Как задача решается сейчас? Через таблицы, мессенджеры, email, CRM, WordPress, Tilda, Excel, ручную обработку? Где возникают ошибки, задержки и потери?

Четвертое - желаемый результат. Что должно измениться после запуска? Меньше ручной работы, больше заявок, быстрее обработка, понятные статусы, онлайн-оплата, контроль входа, партнерский учет, автоматическая передача в CRM.

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

Даже этот базовый набор уже делает оценку точнее.

Начните с цели, а не со списка функций

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

Цель отвечает на вопрос, зачем создается проект. Например:

проверить спрос на новый сервис;

получать заявки из рекламы;

продавать билеты на мероприятия;

дать клиентам доступ к документам и платежам;

автоматизировать работу партнеров;

заменить ручную обработку заявок;

связать сайт с CRM;

запустить каталог внутри Telegram;

перенести старый проект на поддерживаемую архитектуру.

Цель помогает выбирать функции. Если задача - проверить спрос на MVP, не нужно начинать с многоуровневой партнерской программы и сложного личного кабинета. Если задача - продавать билеты, нельзя забыть оплату, QR-билеты и контроль входа. Если задача - не терять заявки, важнее формы, CRM, UTM и уведомления, чем декоративные анимации.

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

Опишите пользователей и роли

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

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

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

Нужно описывать роли не общими словами, а через права:

клиент видит только свои заявки и документы;

партнер видит свои лиды, статусы и комиссии;

менеджер видит заявки своего направления;

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

оператор входа может сканировать QR-билеты, но не меняет цены;

бухгалтер видит платежи и документы, но не редактирует контент.

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

Опишите пользовательские сценарии

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

Пример сценария для заявки:

Пользователь открывает страницу услуги.

Нажимает кнопку "Обсудить проект".

Заполняет имя, телефон, email, тип задачи и комментарий.

Отправляет форму.

Видит подтверждение.

Заявка сохраняется на сайте.

Данные передаются в CRM.

Менеджер получает уведомление.

Пример сценария для системы билетов:

Участник выбирает категорию билета.

Заполняет данные.

Переходит к оплате.

Платеж подтверждается провайдером.

Система создает QR-билет.

Участник получает письмо.

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

Система фиксирует проход.

Пример сценария для Telegram Mini App:

Пользователь открывает бота.

Нажимает кнопку запуска Mini App.

Выбирает категорию в каталоге.

Открывает карточку.

Указывает параметры.

Отправляет заявку.

Получает уведомление в Telegram.

Менеджер видит заявку в CRM или админке.

Такие сценарии дают разработчику гораздо больше информации, чем абстрактное "нужен каталог и заявка".

Разделите первый релиз и будущие идеи

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

Лучше разделить функции на три группы:

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

важно после запуска;

можно рассмотреть позже.

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

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

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

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

Опишите страницы и экраны

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

По каждой странице или экрану полезно указать:

цель страницы;

кто ее видит;

какие блоки нужны;

какие действия доступны;

какие данные отображаются;

откуда данные берутся;

какие формы есть;

куда ведут кнопки;

какие состояния бывают.

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

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

Опишите функции через действия

Функции лучше описывать не как названия модулей, а как действия пользователя или системы. Не "нужна админка", а "администратор может создавать, редактировать и скрывать категории, смотреть заявки, менять статус и выгружать список". Не "нужна CRM", а "после отправки формы создается лид в CRM с полями имя, телефон, email, услуга, комментарий, UTM и страница заявки".

Примеры хорошего описания:

пользователь может зарегистрироваться по email и паролю;

пользователь может восстановить пароль через email;

клиент видит список своих заявок;

менеджер может изменить статус заявки;

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

администратор может повторно отправить билет;

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

система проверяет дубль по телефону и email;

платежный статус обновляется по webhook от провайдера;

UTM-метки сохраняются и передаются в CRM.

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

Опишите данные

Данные - основа веб-сервиса. Если не описать, какие сущности существуют и какие поля у них есть, оценка будет неточной.

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

Не нужно сразу рисовать сложную базу данных, но нужно перечислить, с какими объектами работает система:

пользователи;

роли;

заявки;

заказы;

платежи;

документы;

товары или услуги;

категории;

статусы;

партнеры;

уведомления;

отчеты;

файлы.

Важно указать, какие данные обязательны, какие редактируемые, какие видит пользователь, какие видит менеджер, какие передаются во внешние системы.

Если проект связан с персональными данными, нужно не собирать лишнее. Чем больше данных, тем выше ответственность за хранение и безопасность.

Опишите статусы и правила переходов

Статусы кажутся мелочью, но они сильно влияют на разработку. Заявка, заказ, платеж, билет, документ, обращение в поддержку, партнерская сделка - все это может иметь жизненный цикл.

Пример статусов заявки:

новая;

в работе;

требуется уточнение;

предложение отправлено;

счет выставлен;

оплачено;

закрыто успешно;

отказ;

дубль;

спам.

Пример статусов билета:

создан;

ожидает оплаты;

оплачен;

отправлен;

использован;

отменен;

возвращен;

заблокирован.

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

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

Опишите интеграции

Интеграции часто являются самой неопределенной частью оценки. Фраза "подключить CRM" может означать одну форму с отправкой имени и телефона, а может - сложную двустороннюю синхронизацию лидов, сделок, статусов, задач, ответственных, источников и платежей.

По каждой интеграции нужно указать:

с какой системой интегрируемся;

какие данные передаем;

какие данные получаем;

когда происходит обмен;

как обрабатываются ошибки;

нужны ли повторные попытки;

кто отвечает за доступы;

есть ли документация API;

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

как проверять результат.

Типовые интеграции:

CRM: лиды, сделки, контакты, задачи, UTM, статусы;

платежный провайдер: счет, оплата, webhook, возврат;

email-сервис: письма, шаблоны, статусы отправки;

Telegram: бот, Mini App, уведомления, заявки;

1С или учетная система: товары, счета, документы, статусы;

аналитика: события, цели, источники;

внешние API: каталоги, проверки, данные партнеров.

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

Опишите CRM и обработку заявок

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

Минимально стоит указать:

список форм;

поля каждой формы;

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

направление услуги;

страницу заявки;

UTM-метки;

создание контакта, лида или сделки;

воронку и статус;

ответственного;

уведомления;

правила дублей;

резервное сохранение заявки.

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

Для точной оценки важно понимать CRM заранее: Битрикс24, amoCRM, HubSpot, самописная система, таблица, email или админка. У каждой системы свои API, ограничения и логика.

Опишите платежи

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

Вопросы для ТЗ:

продается товар, услуга, билет, подписка или доступ;

оплата разовая или регулярная;

нужны ли промокоды;

нужна ли оплата от юридических лиц;

нужен ли счет;

нужны ли возвраты;

что происходит после успешной оплаты;

что происходит при ошибке;

где пользователь видит статус;

куда передаются данные о платеже;

нужны ли уведомления.

Нельзя описывать платеж как "подключить оплату". Для разработки важно, что происходит до, во время и после платежа. Например, система продажи билетов после оплаты должна создать QR-билет и отправить письмо. Личный кабинет после оплаты должен открыть доступ или отметить счет оплаченным. Партнерская система может начислить комиссию.

Если платежи оставить на конец обсуждения, оценка почти наверняка изменится.

Опишите админку

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

В ТЗ нужно описать, что администратор или менеджер может делать:

смотреть заявки;

менять статусы;

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

управлять категориями;

добавлять товары или услуги;

смотреть платежи;

загружать документы;

отправлять уведомления;

выгружать отчеты;

управлять промокодами;

повторно отправлять билеты;

блокировать пользователя;

смотреть логи.

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

Админка может быть простой в первом релизе, но она должна закрывать ежедневные операции. Иначе после запуска бизнес будет зависеть от разработчика даже в мелочах.

Опишите дизайн и референсы

Дизайн влияет на сроки, но его часто описывают слишком расплывчато: "современно", "дорого", "минималистично", "как у Apple", "чтобы было красиво". Такие слова не дают точной оценки.

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

Нужно указать, есть ли брендбук, логотип, цвета, шрифты, изображения, готовые тексты, UI-kit, дизайн в Figma. Если дизайна нет, разработка включает этап проектирования интерфейса и визуальной концепции. Если дизайн есть, нужно понять его готовность: только главная страница или все состояния?

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

Если в ТЗ нет требований к дизайну и состояниям, оценка будет приблизительной.

Опишите контент

Контент часто задерживает запуск сильнее, чем код. Тексты, изображения, карточки, категории, документы, тарифы, юридические страницы, письма, уведомления, данные для каталога - все это нужно подготовить.

В ТЗ стоит указать:

кто пишет тексты;

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

есть ли готовые изображения;

кто готовит карточки товаров;

сколько позиций в каталоге;

нужны ли статьи;

нужны ли кейсы;

есть ли юридические документы;

кто готовит email-шаблоны;

нужны ли переводы;

кто загружает первичные данные.

Если контент готовит заказчик, это влияет на сроки. Если контент готовит команда разработки или редактор, это влияет на бюджет.

Для каталога особенно важно количество позиций и структура данных. "Нужен каталог" может означать 20 карточек, а может - 10 000 товаров с импортом, фильтрами, характеристиками, ценами и изображениями.

Контент - часть проекта, а не что-то второстепенное.

Опишите SEO и аналитику

Если сайт должен получать поисковый трафик, SEO-требования нужно учитывать до разработки. Нужно описать структуру URL, title, description, H1, sitemap, robots.txt, canonical, редиректы, скорость, микроразметку при необходимости, страницы услуг, статьи, кейсы и внутреннюю перелинковку.

Если проект переносится со старого сайта, важно сохранить SEO: список старых URL, карта редиректов, мета-данные, контент, sitemap, индексируемые страницы. Без этого редизайн может привести к потере трафика.

Аналитика тоже должна быть в ТЗ. Нужно указать, какие события отслеживать:

отправка формы;

клик по телефону;

переход в мессенджер;

открытие модального окна;

начало заполнения формы;

успешная оплата;

регистрация;

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

скачивание документа;

запуск Telegram Mini App.

Если есть реклама, нужно сохранять UTM-метки и передавать их в CRM. Если есть SEO-статьи, нужно видеть, какие материалы приводят заявки. Если есть MVP, нужно отслеживать ключевые действия, чтобы понимать, что развивать.

Аналитика должна быть не "поставить счетчик", а система событий, связанных с бизнес-целью.

Опишите безопасность и персональные данные

Если проект собирает персональные данные, работает с платежами, кабинетами, документами или CRM, безопасность нужно описывать в ТЗ.

Базовые вопросы:

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

где они хранятся;

кто имеет доступ;

есть ли политика обработки персональных данных;

нужно ли согласие в формах;

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

нужна ли двухфакторная авторизация;

какие роли есть в админке;

как защищены файлы;

нужны ли логи действий;

как делаются резервные копии.

Для российского бизнеса важно учитывать 152-ФЗ "О персональных данных". Юридические тексты должен готовить юрист или ответственный специалист, но разработка должна поддерживать технические механизмы: чекбоксы согласия, фиксация факта отправки, ограничение доступа, хранение и удаление по процессу.

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

Опишите технические ограничения

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

Нужно указать:

текущий сайт и доступы;

CMS или платформа;

хостинг или сервер;

домен;

CRM;

платежный провайдер;

email-сервис;

аналитика;

Telegram-бот;

API внешних систем;

ограничения по технологиям;

требования к размещению данных;

требования к браузерам и устройствам.

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

Честное описание ограничений помогает избежать сюрпризов.

Опишите критерии приемки

Критерии приемки отвечают на вопрос: как понять, что работа выполнена. Без них в конце проекта начинаются споры: разработчик считает задачу закрытой, заказчик чувствует, что "что-то не так".

Примеры критериев:

форма отправляет заявку и показывает подтверждение;

заявка сохраняется в админке;

заявка создается в CRM с нужными полями;

UTM-метки передаются корректно;

пользователь может зарегистрироваться и войти;

клиент видит только свои документы;

платежный статус обновляется по webhook;

QR-билет нельзя использовать повторно;

администратор может менять статус заявки;

страницы корректно отображаются на мобильных устройствах;

ключевые события фиксируются в аналитике.

Критерии должны быть проверяемыми. Фраза "сайт должен быть удобным" важна, но ее сложно принять. Лучше описать конкретные действия, которые пользователь и администратор могут выполнить.

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

Укажите сроки и бюджетный ориентир

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

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

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

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

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

Что можно не описывать заранее

Не нужно пытаться самостоятельно решить все технические вопросы. Заказчик не обязан знать, какую базу данных выбрать, как спроектировать API, какие очереди использовать, как хранить сессии, как настроить сервер, если это не является внутренним требованием.

Не обязательно заранее рисовать все экраны. Можно описать сценарии и роли, а интерфейс спроектировать на этапе аналитики и прототипирования.

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

Не нужно заранее описывать редкие исключения на годы вперед. Достаточно выделить критичные сценарии первого релиза и известные ограничения.

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

Частые ошибки в ТЗ

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

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

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

Четвертая ошибка - не описывать интеграции. "Подключить CRM" или "подключить оплату" без полей, статусов и ошибок не дает точной оценки.

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

Шестая ошибка - не описывать состояния ошибок. Реальный продукт должен работать не только при идеальном сценарии.

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

Пример структуры ТЗ

Ниже пример структуры, которую можно использовать как основу:

Краткое описание проекта.

Цель и бизнес-задача.

Аудитория и роли пользователей.

Текущий процесс и проблемы.

Состав первого релиза.

Функции, которые можно отложить.

Пользовательские сценарии.

Страницы и экраны.

Данные и сущности.

Статусы и правила переходов.

Формы и заявки.

CRM и интеграции.

Платежи.

Админка.

Уведомления.

Дизайн и референсы.

Контент.

SEO и аналитика.

Безопасность и персональные данные.

Технические ограничения.

Критерии приемки.

Сроки и бюджетный ориентир.

Открытые вопросы.

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

Пример короткого ТЗ для MVP

Проект: MVP веб-сервиса для приема заявок на подбор оборудования.

Цель: проверить спрос и получать структурированные B2B-заявки вместо переписок в мессенджерах.

Пользователи: посетитель, менеджер, администратор.

Первый релиз: страница проекта, каталог направлений, карточки категорий, форма заявки, админка заявок, CRM-интеграция, UTM-метки, email-уведомление, базовая аналитика.

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

Отложить: личный кабинет клиента, сложные фильтры, онлайн-оплата, партнерская программа, автоматический расчет стоимости.

Критерии приемки: форма работает на мобильных и desktop, заявка сохраняется, CRM получает все поля, UTM передаются, администратор видит статус, пользователь получает подтверждение.

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

Как Wcoders может подойти к подготовке ТЗ

Для Wcoders тема ТЗ связана со всеми ключевыми направлениями сайта: цифровые платформы, MVP, Telegram Mini Apps, интеграции, личные кабинеты, системы продаж, CRM и инженерная разработка. Команда может не просто попросить готовое ТЗ, а помочь собрать его на этапе предпроектной аналитики.

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

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

В портфолио Wcoders можно связать тему ТЗ с реальными типами проектов: Telegram Mini App для China Bridge, система продажи билетов и партнерских продаж, финансовый web-сервис с личным кабинетом, проекты с API и интеграциями. Каждый такой проект требует не только дизайна, но и описания сценариев, данных, ролей и правил.

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

FAQ

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

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

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

Лучший вариант - совместная работа. Заказчик описывает бизнес-задачу, процессы, ограничения и цели. Разработчик помогает перевести это в сценарии, функции, данные, интеграции и технические требования.

Нужно ли в ТЗ указывать бюджет?

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

Что делать, если я не знаю всех функций заранее?

Нужно описать цель, пользователей и главный сценарий. Остальное можно уточнить на этапе аналитики. Неизвестные вопросы лучше честно вынести в раздел "открытые вопросы", а не прятать.

Чем ТЗ для сайта отличается от ТЗ для веб-сервиса?

ТЗ для сайта чаще описывает страницы, контент, формы, SEO и дизайн. ТЗ для веб-сервиса дополнительно описывает роли, данные, статусы, backend-логику, интеграции, админку, безопасность, платежи и пользовательские сценарии.

Можно ли использовать примеры конкурентов?

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

Что важнее для оценки: дизайн или функции?

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

Итог

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

Хорошее ТЗ не обязано быть огромным. Оно должно быть ясным. Для лендинга достаточно компактного описания, для MVP и веб-сервиса нужен более подробный документ, для сложной платформы стоит начинать с предпроектной аналитики.

Главное - отделить первый релиз от будущих идей и описывать функции через действия. Тогда разработчик сможет оценить не абстрактное "сделать платформу", а конкретный продукт: кто им пользуется, что делает, какие данные проходят через систему и как бизнес поймет, что результат готов.