Что такое ТЗ: техническое задание - документ, в котором заказчик и исполнитель фиксируют, что именно нужно сделать, для кого, с какими функциями и по каким признакам работу примут. Для сайта, мобильного приложения или внутренней системы ТЗ становится общей точкой отсчета. По нему команда оценивает сроки и бюджет, пишет код и в итоге сдает результат.
Без ТЗ проект держится на памяти и переписке. Через два месяца никто не помнит, договаривались ли о личном кабинете и входила ли в цену интеграция с CRM. Ниже разбираем, из чего состоит документ, как его правильно составить и как выглядят примеры для сайта, приложения и информационной системы.
Что такое техническое задание?
Если объяснять простыми словами, ТЗ - это инструкция к будущему продукту, написанная до того, как продукт появился. Документ отвечает на вопросы: зачем нужен проект, кто им будет пользоваться, что пользователь сможет сделать, на чем все будет работать и как проверить, что задача решена.
Формально ТЗ - приложение к договору. Если оно подписано обеими сторонами, спор о том, входила ли функция в работу, решается открытием документа, а не воспоминаниями. Для государственных и крупных корпоративных систем есть стандарт: ГОСТ 34.602-2020 описывает техническое задание на создание автоматизированной системы. Коммерческим сайтам и приложениям ГОСТ не обязателен, но его структуру часто берут за основу.
Что такое ТЗ заказчика?
ТЗ заказчика - документ, который готовит сам заказчик или его менеджер проекта до выбора исполнителя. Обычно это описание бизнес-задачи, пожелания к функциям и примеры, которые нравятся. Такой текст полезен для первой оценки, но редко годится для разработки как есть: в нем нет технических требований, описания ролей и ограничений. Поэтому исполнитель проводит аналитику и превращает ТЗ заказчика в полноценное техническое задание, которое обе стороны подписывают заново.
Что такое ТЗ в дизайне?
В дизайне ТЗ (его часто называют брифом) описывает задачу для дизайнера: что нужно нарисовать, для какой целевой аудитории, в каком стиле и в каких форматах сдать. Для интерфейса приложения туда входят список экранов, ограничения платформы, фирменные шрифты и цветовая гамма, примеры интерфейсов, которые нравятся и не нравятся. Чем точнее описаны пожелания, тем меньше кругов правок.
Что такое ТЗ в работе?
В работе ТЗ выполняет три функции. Первая - договоренность между заказчиком и исполнителем: что входит в работу, а что нет. Вторая - постановка задачи для команды: аналитик, дизайнер, разработчики и тестировщики читают один документ и не пересказывают друг другу задачу своими словами. Третья - основа для приемки: готовый продукт сравнивают с ТЗ пункт за пунктом.
Когда речь идет о небольшой доработке, ТЗ может занимать полстраницы. Для нового приложения документ растягивается на десятки страниц с описанием каждого экрана и каждой интеграции. Объем зависит от сложности, а не от желания выглядеть солидно.
Из чего состоит техническое задание
Единого шаблона технического задания нет, но у хорошего документа почти всегда есть одни и те же разделы.
- Цели проекта. Какую бизнес-задачу решает продукт и как понять, что он ее решил.
- Целевая аудитория и роли. Кто пользуется продуктом: покупатель, курьер, администратор. У каждой роли свои права.
- Функциональные требования. Что система делает: регистрация, каталог, корзина, оплата, уведомления. Каждое требование описывают как действие пользователя и ответ системы.
- Нефункциональные требования. Скорость загрузки, нагрузка, безопасность, поддерживаемые версии iOS и Android, браузеры.
- Технические требования. Язык и фреймворк, если они важны заказчику, хостинг, интеграции с 1С, CRM, платежными сервисами.
- Структура и прототипы. Список страниц или экранов, схемы переходов, ссылки на прототип.
- Требования к дизайну. Фирменный стиль, шрифты, цвета, референсы.
- Критерии приемки. По каким признакам работу считают сделанной.
- Этапы и порядок сдачи. Что сдают на каждом этапе и какие документы подписывают.
Этапы разработки сайта: техническое задание
ТЗ пишут после предпроектного исследования и до дизайна. Порядок работ при создании сайта обычно такой:
- Бриф: заказчик отвечает на вопросы о целях, аудитории, конкурентах и бюджете.
- Аналитика: интервью с заказчиком и будущими пользователями, разбор процессов и конкурентов.
- Прототип: схема страниц и сценариев, на которой проверяют логику.
- Техническое задание: описание функций, требований и критериев приемки на основе прототипа.
- Оценка: исполнитель считает сроки и стоимость по ТЗ.
- Дизайн, разработка, тестирование, запуск.
Прототип и ТЗ часто делают параллельно: на прототипе видно, чего не хватает в тексте, а текст объясняет то, что на картинке не показать.
Зачем тратить время на ТЗ
Главный аргумент против ТЗ - время. Кажется, что его лучше потратить на код. На практике экономия оборачивается переделками: функцию, которую поняли по-разному, приходится переписывать, а спор о том, входила ли она в цену, портит отношения. В среднем по рынку аналитика и ТЗ занимают 10-15 процентов бюджета мобильного приложения, а разработка - 50-60 процентов. Ошибку дешевле поймать в первой части, чем во второй.
ТЗ пригодится и после запуска. Новый разработчик читает его вместо того, чтобы расспрашивать всех подряд, а при смене подрядчика документ сокращает время на погружение.
Пример ТЗ
Ниже сокращенные примеры разделов. В реальном документе каждый пункт раскрывают подробнее, но логика та же: одно требование - одна проверяемая фраза.
ТЗ на разработку сайта: пример
Проект: сайт службы доставки цветов.
- Цель: принимать заказы онлайн и сократить число звонков операторам.
- Аудитория: частные покупатели и корпоративные клиенты, большинство заходит с телефона.
- Роли: гость, покупатель, менеджер, администратор.
- Функции: каталог с фильтрами по цене и поводу, карточка букета, корзина, оформление заказа с выбором даты и интервала доставки, оплата картой и через СБП, личный кабинет с историей заказов.
- Админка: управление каталогом, статусами заказов, промокодами.
- Интеграции: платежный сервис, служба SMS-уведомлений, выгрузка заказов в CRM.
- Приемка: покупатель проходит путь от главной до оплаты на iPhone и Android-смартфоне без ошибок.
ТЗ на разработку сайта: примеры формулировок
Большинство споров на приемке вырастает из размытых фраз. Описывайте требования так, чтобы их мог проверить тестировщик. Сравните:
| Плохо | Хорошо |
|---|---|
| Сайт должен быть удобным | Заказ оформляется не больше чем за 3 шага от корзины |
| Быстрая загрузка | Главная страница загружается на мобильном интернете за 3 секунды или быстрее |
| Современный дизайн | Дизайн по утвержденному макету в Figma, шрифты и цвета из брендбука |
| Интеграция с CRM | Новый заказ создает сделку в CRM с полями: имя, телефон, состав, сумма, дата доставки |
| Удобная админка | Менеджер меняет статус заказа в один клик, покупатель получает SMS о смене статуса |
Правило простое: если требование нельзя проверить, его нельзя и принять. Конкретные требования экономят деньги обеим сторонам.
Техническое задание на разработку мобильного приложения: пример
ТЗ на приложение отличается от ТЗ на сайт несколькими разделами: платформы, работа без интернета, push-уведомления, публикация в сторах. Сокращенный пример для приложения записи в фитнес-клуб:
- Платформы: iOS и Android, одна кодовая база на Flutter.
- Роли: клиент, тренер, администратор клуба.
- Функции клиента: вход по номеру телефона с кодом из SMS, расписание занятий, запись и отмена, покупка абонемента, push-напоминание за 2 часа до тренировки.
- Функции тренера: список записанных, отметка посещения.
- Офлайн: расписание и купленные абонементы доступны без интернета, запись требует сети.
- Интеграции: учетная система клуба, платежный сервис, сервисы push-уведомлений Firebase Cloud Messaging и Apple Push Notification service.
- Публикация: приложение проходит проверку App Store и Google Play, исполнитель готовит скриншоты и описание.
- Приемка: сценарии записи, отмены и оплаты проходят на тестовых устройствах из согласованного списка.
Пример технического задания на разработку информационной системы
Для внутренних систем (складской учет, документооборот, личный кабинет дилеров) заказчики чаще просят оформить ТЗ по ГОСТ 34.602-2020. Стандарт задает разделы, среди них общие сведения, цели и назначение системы, характеристика объекта автоматизации, требования к системе, состав и содержание работ, порядок контроля и приемки, требования к документированию.
Сокращенный пример для системы учета заявок сервисной компании:
- Назначение: учет заявок от клиентов, распределение по инженерам, контроль сроков.
- Объект автоматизации: диспетчерская служба и выездные инженеры.
- Пользователи: диспетчер, инженер, руководитель, клиент в личном кабинете.
- Требования к функциям: создание заявки из письма и звонка, автоматическое назначение по району, статусы, фотоотчет инженера из мобильного приложения, отчеты по срокам.
- Требования к надежности и безопасности: разграничение прав, журнал действий, резервное копирование раз в сутки.
- Порядок приемки: предварительные испытания, опытная эксплуатация, приемочные испытания.
Частые ошибки в ТЗ
- Описание решения вместо задачи. Заказчик просит сделать как у конкурента и не объясняет, какую проблему это решает.
- Нет ролей. Непонятно, кто что видит и что может менять.
- Размытые формулировки без критериев проверки.
- Забытые сценарии ошибок: что видит пользователь, если оплата не прошла или пропал интернет.
- Нет админки. Сайт описан подробно, а как менеджер будет им управлять, не сказано.
- ТЗ пишут один раз и не обновляют. Изменения согласуют в чате, а документ устаревает к середине проекта.
Как проверить готовое ТЗ
Перед подписанием прочитайте документ глазами трех людей. Пользователь: смогу ли я по описанию пройти главный сценарий от начала до конца? Бухгалтер: понятно ли, что входит в цену, а что оплачивается отдельно? Тестировщик: можно ли каждое требование проверить и ответить да или нет? Отдельно сверьте требования проекта с бюджетом и сроками. Если на какой-то вопрос ответ отрицательный, документ лучше доработать сейчас, пока правка текста дешевле переделки кода.
Кто составляет техническое задание
Составлять техническое задание может сам заказчик, если у него есть опыт и время. Чаще его пишет исполнитель: бизнес-аналитик вместе с менеджером проекта и техническим лидом. Заказчик дает вводные, отвечает на вопросы, участвует в интервью и согласует документ. Главное, что нужно от него: четко сформулировать, какую задачу бизнеса решает продукт. Так требования заказчика переводятся на язык, понятный разработчикам, а исполнитель сразу видит, где в задаче риски.
В Кодовой студии ТЗ входит в этап аналитики перед разработкой приложения или веб-системы. Можно заказать и отдельное составление технического задания, чтобы потом сравнить предложения нескольких исполнителей по одному документу. Ориентир по бюджету всего проекта дает калькулятор, стоимость ТЗ называем после брифа.
Услуга студии
Разработка технического задания
Составление технического задания на сайт, приложение или систему: интервью, сценарии, прототип и требования, по которым считается бюджет.
