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

Зачем бизнесу техническое задание на разработку

Типичная история из ташкентской практики: владелец магазина просит «бота, чтобы клиенты заказывали и платили». Разработчик понимает это как каталог и кнопку оплаты через Click. Владелец имел в виду ещё и остатки со склада, уведомления менеджеру в рабочую группу и промокоды. На приёмке выясняется, что у каждого своя версия «готового» продукта, и начинается спор о том, кто что обещал.

ТЗ убирает этот спор заранее. Это не формальность для тендера, а рабочий инструмент: по нему разработчик оценивает объём, вы сравниваете предложения разных студий на одной базе, а при приёмке обе стороны смотрят в один документ. Чем точнее ТЗ, тем меньше правок «по ходу» и тем честнее оценка стоимости и сроков.

Из чего состоит хорошее ТЗ

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

• Цель: какую проблему решаем и как поймём, что она решена (например, меньше ручной переписки с заявками в Instagram Direct).
• Пользователи и роли: клиент, менеджер, администратор, курьер — и что каждый видит и может делать.
• Сценарии: пошаговое поведение пользователя и системы.
• Функции с приоритетами: обязательно, желательно, на потом.
• Интеграции: Click, Payme, CRM, Google Sheets, учётная система, SMS-провайдер.
• Данные и ограничения: что хранится и кому доступно, языки интерфейса (русский и узбекский), нагрузка в пик акций, безопасность.
• Критерии приёмки: проверяемые условия готовности.

Как написать ТЗ: пошаговая инструкция

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

• Опишите текущий процесс как есть: откуда приходит клиент, кто отвечает, где теряются заявки. Достаточно схемы на листе или в заметках.
• Сформулируйте цель одним-двумя предложениями и выберите один-два измеримых признака успеха.
• Перечислите роли и составьте для каждой список действий.
• Распишите основные сценарии по шагам: кто делает, что видит, что происходит дальше. Отдельно — нестандартные случаи: товара нет, оплата не прошла, клиент передумал.
• Расставьте приоритеты. Первая версия должна решать главную задачу, остальное уходит в следующий этап.
• Укажите внешние системы, какие данные между ними передаются, и добавьте критерии приёмки к каждой крупной функции.
• Отдайте ТЗ разработчику на вопросы и вместе уточните спорные места до начала работы.

Пример: фрагмент ТЗ для Telegram-бота

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

«Клиент выбирает букет в каталоге и нажимает «Заказать». Бот просит выбрать дату и время доставки, затем отправить геолокацию или написать адрес. Бот показывает итоговую сумму и предлагает оплату через Payme или Click либо наличными курьеру. После успешной оплаты заказ получает статус «Оплачен», клиент видит сообщение с номером заказа, а менеджер получает уведомление в рабочую группу. Если оплата не прошла, бот сообщает об этом и предлагает повторить или выбрать наличные; заказ при этом остаётся в статусе «Ожидает оплаты». Если выбранного букета нет в наличии, бот предлагает похожие позиции и не создаёт заказ».

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

Критерии приёмки: как не спорить о вкусах

Критерий приёмки — это условие, при выполнении которого функция считается готовой. Хороший критерий отвечает на вопрос «что я сделаю и что должен увидеть».

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

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

Типичные ошибки при составлении ТЗ

Часть ошибок повторяется почти в каждом проекте.

• Описаны экраны и кнопки, но не процессы: непонятно, что происходит после нажатия.
• Размытые формулировки: «современный дизайн», «интуитивный интерфейс», «быстрая работа».
• Все функции равнозначны, нет разделения на обязательные и желательные, поэтому бюджет уходит на второстепенное.
• Забыты интеграции: оплата, CRM, учёт остатков, выгрузка отчётов.
• Не описаны исключения: нет товара, дубль заказа, пользователь заблокировал бота.
• Не названо, кто принимает работу и кто со стороны заказчика отвечает на вопросы.
• ТЗ на десятки страниц, которое никто не перечитывает и которое устаревает после первого изменения.

Кто пишет ТЗ и что делать, если опыта нет

Варианты отличаются затратами времени и качеством результата.

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

Заказчик и аналитик исполнителя пишут вместе. Обычно самый рабочий вариант: вы приносите знание процессов и клиентов, аналитик переводит это в требования и задаёт неудобные вопросы. От вас требуется время на интервью и быстрые ответы.

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

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

Чек-лист перед передачей ТЗ разработчику

Пройдитесь по списку и честно ответьте «да» на каждый пункт.

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

Изменения требований и следующий шаг

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

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