Как составить техническое задание на разработку

Хорошее техническое задание экономит не страницы, а деньги: по нему подрядчик называет цену, которая не «уплывёт» через месяц, а вы принимаете работу по понятным критериям. Плохое ТЗ — это либо три строчки «нужен сайт как у конкурентов», либо 80 страниц требований, которые никто не дочитал до конца.

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

Зачем нужно ТЗ и чем оно отличается от брифа

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

У техзадания три практические функции:

• Оценка. Без перечня ролей, сценариев и интеграций любая цена — это гадание. Разброс оценок одного и того же «сайта» у разных подрядчиков в 3–5 раз обычно объясняется тем, что каждый представил себе свой сайт.
• Договорённость. ТЗ фиксирует объём работ. Всё, что в него не вошло, — изменение объёма, которое обсуждается отдельно, а не «ну это же очевидно».
• Приёмка. Каждое требование должно проверяться: «форма заявки отправляет данные в CRM за 5 секунд» проверить можно, «удобная форма» — нельзя.

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

Шаблон ТЗ на разработку: 9 обязательных разделов

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

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

Как написать ТЗ на разработку: сценарии вместо списка функций

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

Формула пользовательской истории

Используйте простой шаблон: «Как [роль], я хочу [действие], чтобы [результат]». Например: «Как менеджер, я хочу получать уведомление в Telegram о новой заявке, чтобы связаться с клиентом в течение 15 минут».

Критерии приёмки к каждой истории

К каждой истории добавьте 2–5 проверяемых условий. Для примера выше:

• уведомление приходит не позднее 10 секунд после отправки формы;
• в уведомлении есть имя, телефон, выбранная услуга и источник заявки (UTM-метка);
• кнопка «Взять в работу» меняет статус заявки и скрывает её у других менеджеров;
• если менеджер не ответил за 15 минут, уведомление получает руководитель.

Так пишутся требования, по которым можно и оценить работу, и принять её. Для ботов и Mini App это особенно важно: логика там живёт в диалоге, и без сценариев подрядчик вынужден додумывать. Подробнее о том, как мы проектируем карты состояний, — на странице разработки Telegram-ботов.

Приоритеты: MoSCoW

Разметьте каждую функцию: Must (без неё продукт не запускается), Should (нужна, но можно через месяц), Could (приятно иметь), Won't (точно не в этой версии). Эта разметка — основа первой версии продукта; как отобрать функции для запуска, мы подробно разбирали в статье о разработке MVP.

Нефункциональные требования, о которых забывают

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

• Нагрузка: сколько пользователей ожидается в первый месяц и через год, есть ли пики (распродажи, рассылки).
• Скорость: целевое время загрузки страниц и ответа бота; для сайтов — ориентир по Core Web Vitals.
• Доступность: допустимое время простоя, нужен ли мониторинг и дежурство.
• Безопасность: какие данные храним, кто к ним имеет доступ, нужна ли двухфакторная авторизация, журнал действий.
• Персональные данные: обработка по 152-ФЗ, локализация хранения в РФ, согласия и политика конфиденциальности.
• Размещение: ваше облако, собственные серверы или закрытый контур без доступа в интернет.
• Поддержка: браузеры, версии iOS и Android, языки интерфейса, доступность для людей с нарушениями зрения.
• Передача: документация, доступы, репозиторий на вашем аккаунте, инструкция по развёртыванию.

Пример технического задания на сайт

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

1. Цель: получать заявки на расчёт оборудования от B2B-клиентов; ориентир — 40 квалифицированных заявок в месяц через 3 месяца после запуска.
2. Аудитория: инженеры и снабженцы предприятий, 70% заходят с десктопа.
3. Роли: посетитель; контент-менеджер (правит каталог и новости); администратор (доступы, настройки).
4. Структура: главная, каталог из 6 категорий и ~120 позиций, карточка товара с PDF-спецификацией, кейсы, о компании, контакты, блог.
5. Ключевой сценарий: посетитель находит позицию через фильтр → открывает карточку → нажимает «Запросить КП» → заполняет форму из 4 полей → заявка уходит в Bitrix24 и в Telegram отдела продаж.
6. Интеграции: Bitrix24 (создание лида), Яндекс Метрика с целями, выгрузка каталога из 1С раз в сутки.
7. Дизайн: брендбук есть, нужен UX-прототип и адаптив для мобильных.
8. Нефункциональные требования: загрузка страницы до 2 секунд на 4G, техническое SEO и микроразметка, хостинг в РФ.
9. Приёмка: все сценарии из п. 5 проходят на тестовом стенде, формы доходят в CRM, Lighthouse Performance — от 90.

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

Частые ошибки в ТЗ и как их избежать

Ещё одна ловушка — пытаться описать всё до последней кнопки ещё до прототипа. Детали интерфейса быстрее и дешевле решаются на кликабельном прототипе: вы видите экраны, нажимаете, меняете. ТЗ задаёт рамку, прототип её наполняет.

Онлайн-опросник: ТЗ без чистого листа

Самое сложное — начать. Поэтому на сайте есть онлайн-опросник для составления ТЗ: он превращает структуру выше в последовательность вопросов с подсказками и вариантами ответов. Писать с нуля не нужно — большинство пунктов выбираются кнопками. Опросник состоит из 7 разделов:

1. О вас — контакты, компания, ваша роль в проекте.
2. О продукте — тип продукта, цель, стадия, текущий стек, референсы и ссылки на документы.
3. Пользователи и роли — аудитория, роли, масштаб, география, проблема пользователя.
4. Функциональность — функции, обязательный минимум, оплаты, интеграции.
5. Платформы и дизайн — где работает продукт, дизайн, брендинг, контент.
6. Данные, AI и безопасность — нужен ли AI, миграция данных, требования к безопасности и размещению.
7. Бюджет, сроки и процесс — бюджет, дедлайн и его причина, поддержка, ваше участие.

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