Кратко
- Техническое задание (ТЗ) — документ, который описывает, что нужно сделать: цель, требования к результату, сроки и критерии приёмки.
- Расшифровка «ТЗ» — «техническое задание», термин один и тот же в любой отрасли, меняется только содержание документа.
- Структура опирается на ГОСТ 34.602 и ГОСТ 19, но жёсткого стандарта для бизнес-проектов нет: состав разделов подстраивают под задачу.
- Чаще всего ТЗ пишут для разработки сайта, приложения или дизайн-проекта — самого частого практического случая.
Техническое задание, или ТЗ, — это документ, в котором заказчик описывает, что именно должен сделать исполнитель: какая цель у проекта, какие требования к результату, в какие сроки и по каким критериям работу примут. Без ТЗ стороны обычно по-разному понимают одну и ту же задачу. Часто это выясняется уже после того, как деньги потрачены, а срок подходит к концу.
Расшифровка: что означает аббревиатура ТЗ
«ТЗ» расшифровывается как «техническое задание», независимо от отрасли: в разработке сайтов, дизайне, строительстве, промышленности термин один и тот же, меняется только содержание документа. Рядом иногда встречаются «технические условия» и «спецификация» — это отдельные документы с более узким назначением, а не синонимы ТЗ.
Зачем нужно техническое задание
Без ТЗ проект держится на устных договорённостях и переписке в мессенджере, и это работает, пока обе стороны помнят одно и то же. На практике память подводит, а формулировки вроде «сделайте удобный сайт» каждый понимает по-своему.
Типичные последствия такого подхода знакомы почти всем, кто заказывал разработку хотя бы раз. Сайт сдают без нужной формы обратной связи, потому что о ней говорили на словах, а в переписке не зафиксировали. Всё, что не прописано явно, исполнитель может посчитать «дополнительной работой», а не частью изначальной задачи, и попросить за неё доплату. Без чёткого списка требований проект дорабатывают по кругу: то, что уже сделано, переделывают под новые пожелания. А если критерии приёмки не описаны заранее, спор о готовности работы превращается в вопрос мнения, а не фактов.
ТЗ снимает эту проблему тем, что фиксирует ожидания на бумаге до начала работы. Обе стороны соглашаются с одним и тем же текстом, а не с разными версиями в голове.
Структура технического задания: из чего оно состоит
Единого обязательного бланка для бизнес-проектов нет. Но у структуры, близкой к ГОСТ 34.602 (для автоматизированных систем) и ГОСТ 19 (для программной документации), есть логика, которая работает почти в любом проекте: от сайта до дизайн-макета.
- Общие сведения. Название проекта, кто заказчик и кто исполнитель, сроки начала и окончания работ.
- Цель и назначение. Зачем нужен проект и какую задачу он должен решить — не «сделать сайт», а «увеличить число заявок с сайта».
- Требования к результату. Функциональные требования — что система должна уметь делать; технические — на чём и как это должно работать.
- Состав и содержание работ. Что входит в задачу, а что явно не входит: этот пункт снимает большинство споров позже.
- Сроки. Общий срок, а для крупных проектов — сроки по этапам.
- Критерии приёмки. По каким признакам заказчик поймёт, что работа сделана и соответствует ТЗ.
- Бюджет. Если он часть документа, а не отдельного коммерческого предложения.
Для небольшого проекта — например, лендинга или логотипа — часть пунктов можно объединить в один-два абзаца. Для крупного каждый раздел стоит расписать подробно, вплоть до отдельных подпунктов по каждому экрану или странице.
Как составить техническое задание: пошагово
- Сформулируйте цель. Не функцию, а результат: не «нужна форма заявки», а «клиенты должны иметь возможность оставить заявку за 30 секунд».
- Опишите результат конкретно. Сайт из скольки страниц, приложение с какими экранами, документ какого объёма должен получиться на выходе.
- Разделите требования на функциональные и технические. Функциональные — что система делает («пользователь может отфильтровать каталог по цене»). Технические — на чём и как это работает («сайт на CMS Х, адаптивная вёрстка, время загрузки не более 3 секунд»).
- Зафиксируйте, что не входит в задачу. Это важно так же, как описать, что входит: снимает споры о «дополнительной работе» позже.
- Пропишите сроки и этапы. Если проект большой, разбейте на этапы с промежуточной сдачей: так проще контролировать процесс.
- Опишите критерии приёмки. Чек-лист, тестовый сценарий или соответствие макету — способ должен быть понятен обеим сторонам заранее.
- Согласуйте документ с исполнителем до старта. Если формулировка вызывает у него вопросы на этапе согласования, лучше уточнить её сейчас, а не после сдачи работы.
Пример: плохая формулировка и хорошая
Разница между расплывчатым и рабочим ТЗ обычно в конкретике, а не в объёме текста.
Плохо: «Нужен удобный личный кабинет для пользователей».
Хорошо: «Личный кабинет со следующими разделами: профиль (имя, email, телефон), история заказов за последние 12 месяцев с фильтром по статусу, кнопка повторного заказа. Доступ — после регистрации по email. Адаптивная вёрстка для экранов от 360 px».
Первая формулировка допускает десятки трактовок. Вторая оставляет мало пространства для разночтений именно потому, что называет конкретные разделы, действия и ограничения, а не общее пожелание.
ТЗ на разработку сайта или приложения — самый частый случай
Чаще всего техническое задание нужно на конкретный digital-проект: сайт, мобильное или веб-приложение. У структуры из раздела выше здесь появляется практическая специфика.
Сайт. В ТЗ обычно расписывают структуру страниц (карту сайта), функциональные блоки — каталог, форму обратной связи, личный кабинет, поиск, технические требования — на какой CMS или технологии делать сайт, где он будет размещаться, какие сторонние сервисы нужно подключить (аналитика, платёжные системы, CRM), требования к адаптивности под мобильные устройства.
Приложение. Здесь добавляются список экранов и пользовательских сценариев (что пользователь делает на каждом экране), API и интеграции со сторонними сервисами, требования к производительности — сколько времени грузится экран, сколько пользователей приложение выдерживает одновременно, и требования к безопасности — как хранятся и передаются данные.
Дизайн-проект. Логика немного другая: количество экранов или макетов, стиль и референсы, формат передачи файлов исполнителю, требования к брендбуку, если он есть.
Общее правило для всех трёх случаев одно: чем конкретнее описаны требования на старте, тем меньше вероятность, что готовый результат не совпадёт с тем, что было в голове у заказчика.
Как быстрее собрать ТЗ, если писать с нуля сложно
Собрать структуру ТЗ с нуля не так уж сложно. Сложнее вспомнить все детали, которые важны именно для вашего проекта, и не забыть указать то, что кажется «само собой разумеющимся», но для исполнителя таким не является.
Здесь может пригодиться ассистент для составления ТЗ, который собирает документ диалогом. Вы описываете задачу своими словами: какой нужен сайт, приложение или дизайн, а ассистент задаёт уточняющие вопросы по каждому разделу структуры — какие функции обязательны, какие сроки, как вы поймёте, что работа принята. Вместо пустого шаблона, который придётся заполнять самостоятельно, получается документ, собранный под вашу конкретную задачу, с разделами, которые легко упустить, если пишете ТЗ впервые.
Это особенно удобно, когда нужно быстро подготовить черновик перед встречей с исполнителем или разместить задачу на бирже фриланса: вместо чистого листа сразу получаете структуру, которую останется только уточнить и согласовать.
Частые сценарии: кто и когда пишет ТЗ
При найме фрилансера ТЗ фактически заменяет менеджера проекта, который в штате обычно переспрашивает детали: чёткий документ можно приложить к заказу на бирже, отправить исполнителю напрямую или зафиксировать как приложение к договору с исполнителем. Для дизайнера в ТЗ важнее не техническая часть, а стиль, референсы и количество итераций правок — это стоит прописать отдельно, чтобы не спорить потом о вкусе. Для разработчика, наоборот, в приоритете логика работы, технические ограничения и список интеграций: без них он будет додумывать архитектуру сам. А если вы сами исполнитель и ищете заказчика, разговор о задаче обычно начинается раньше — с коммерческого предложения.
Вопросы про техническое задание
Кто должен писать ТЗ — заказчик или исполнитель? Чаще всего черновик готовит заказчик: он лучше понимает бизнес-задачу. Исполнитель дорабатывает документ с точки зрения технической реализации — уточняет формулировки, добавляет ограничения, которые заказчик мог не учесть. Итоговую версию обычно согласовывают обе стороны перед стартом работ.
Сколько времени занимает составление технического задания? Зависит от масштаба проекта. Для небольшого лендинга — от пары часов до одного дня, для сайта среднего размера или приложения — от нескольких дней до пары недель, особенно если требования нужно собрать с нескольких заинтересованных сторон внутри компании.
Что делать, если ТЗ уже есть, но проект пошёл не по плану? Сначала сверить фактический результат с документом построчно: часто выясняется, что часть требований была прописана нечётко и допускала разные трактовки. Дальше зафиксировать расхождения письменно и обсудить их с исполнителем со ссылкой на конкретный пункт ТЗ, а не на общее впечатление «что-то не так».
Нужно ли отдельно согласовывать изменения в ТЗ, если требования поменялись в процессе работы? Да, лучше фиксировать изменения отдельным документом или дополнением к исходному ТЗ, а не только в переписке. Заказчик видит, что и когда поменялось, исполнитель видит, что новые требования согласованы, а не додуманы постфактум — это защищает обе стороны.