Что такое техническое задание — и как сделать идеальное

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

Почему техническое задание — это не роскошь, а необходимость

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

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

Без ТЗ возникает так называемый «эффект телепатии»: заказчик думает, что исполнитель знает его мысли, а тот — что «тут всё понятно». На практике это приводит к бесконечным правкам, перепискам в мессенджерах и усталости команды. Согласно исследованиям PMI (Project Management Institute), до 30% всех проектов терпят неудачу из-за плохой документации требований. Даже если вы не работаете с гигантскими корпорациями, а ведёте небольшой бизнес — ТЗ становится вашей страховкой от финансовых и репутационных потерь.

Когда можно обойтись без технического задания

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

1. Задача очень простая. Если вы просите сотрудника «поставить кофе на стол» или «отправить отчёт по форме №3», то подробное ТЗ — перебор. Достаточно одного предложения.
2. Исполнитель — опытный специалист. Если человек уже выполнял эту задачу десятки раз, знает все нюансы, понимает tone of voice и стандарты компании — дополнительная инструкция не добавит ценности. Его компетентность и внутренний регламент работают как живое ТЗ.
3. Процесс регулярный и стандартизированный. Здесь вместо ТЗ работает регламент. Это документ, описывающий повторяющиеся действия: как оформлять отчёты, как проводить аудит, как собирать метрики. Регламент — это ТЗ, застывшее во времени и применяемое системно.

В этих случаях ТЗ не просто не нужно — оно может быть излишним бременем. Но если вы чувствуете, что «что-то не так» — скорее всего, именно отсутствие ТЗ создаёт эту неопределённость. Помните: если вы задаёте вопрос «А что ты под этим понимаешь?» — у вас уже есть проблема, которую ТЗ может решить.

Когда без технического задания не обойтись: три критических случая

Техническое задание — это не про «хорошо бы». Это про необходимость. Вот три сценария, где его отсутствие обрекает проект на провал:

1. Исполнитель впервые берётся за задачу

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

2. Задача делегируется

Менеджер поручает задачу подчинённому. Понятно, что он уже делал это сам — и знает, как должно быть. Но для исполнителя всё ново. Без ТЗ он будет задавать одни и те же вопросы: «А это делать через Excel или Google Sheets?», «Нужно ли включать комментарии?», «Куда отправлять результат?». Это отнимает время у обоих. Хорошее ТЗ превращает делегирование в автоматизированный процесс. Новый сотрудник получает инструкцию, а менеджер — освобождается от постоянных уточнений.

3. Работа с аутсорсом или фрилансерами

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

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

Как составить техническое задание: универсальный шаблон для ежедневных задач

Не все ТЗ требуют 30-страничных отчётов. Для повседневных задач — написания постов, подготовки макетов, сценариев для видео — достаточно лаконичного, но ёмкого документа. Вот минимальный шаблон, который покрывает 95% случаев:

1. Подробное описание результата

Что именно нужно получить? Не «сделать пост», а «пост в Instagram с текстом до 120 знаков, с эмодзи, подзаголовком и хештегами #бренд#продукт». Не «дизайн», а «макет главной страницы сайта в Figma, размер 1920x1080px, с блоками: хедер, герой, преимущества, CTA». Чем конкретнее — тем меньше вопросов.

2. Характеристика результата

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

• Тон речи (tone of voice): формальный, дружелюбный, саркастичный?
• Объём: сколько слов, страниц, секунд видео?
• Форматы: PDF, JPG, MP4, DOCX?
• Цветовая палитра: указать HEX-коды или ссылку на брендбук
• Шрифты: какие использовать? Можно ли заменить?
• Иллюстрации: нужны ли? Где брать? Можно использовать стоки?
• Ссылки: куда ведут кнопки? Какие страницы должны быть связаны?

Этот раздел — ваша «инструкция по вкусу». Он устраняет субъективность. Вместо «сделай красиво» вы говорите: «Использовать цвета #1E3A8A и #F59E0B, шрифт Inter, иконки из библиотеки Figma Community».

3. Ресурсы для выполнения задачи

Что у исполнителя есть, чтобы выполнить задачу? Недостаточно сказать «сделай пост». Нужно дать доступ:

• Ссылка на брендбук
• Доступ к Google Docs с тоном речи
• Логины в соцсетях или CMS
• Примеры успешных постов прошлых кампаний
• Контакты ответственных за фото/видео/юридические проверки

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

4. Срок выполнения

Когда нужно сдать результат? Не «как можно скорее», а «до 15 апреля, 17:00 МСК». Указывайте часовой пояс. Если срок жёсткий — укажите, что это финальный дедлайн. Если возможны корректировки — укажите, когда будут итерации. Чёткие сроки снижают стресс и повышают ответственность.

Этот шаблон можно оформить в одном сообщении в Telegram, в описании задачи в Notion или Trello. Главное — чтобы всё было в одном месте, и исполнитель не должен был переключаться между чатами, документами и письмами.

Пример: ТЗ для поста в Instagram

Результат: Пост в Instagram (вертикальный формат, 1080x1350px) с текстом и изображением.

Характеристики:

• Тон: дружелюбный, с юмором
• Объём: текст — до 120 знаков, хештеги — не более 5
• Цвета: #1E3A8A (синий), #F59E0B (оранжевый)
• Шрифт: Inter, размер 32pt для заголовка
• Изображение: фото продукта на фоне кухни, естественное освещение
• Ссылки: ведут на главную страницу сайта (ссылка в био)

Ресурсы:

• Брендбук: link
• Примеры постов: link
• Фото продукта: в папке Google Drive → Product Photos

Срок: до 10 апреля, 18:00 по МСК

Такое ТЗ займёт 3 минуты, но сэкономит часы на переписке.

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

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

Основные разделы проектного ТЗ

Вот структура, которая работает в 9 из 10 случаев:

1. Введение

Краткое резюме: зачем это делается? Кто заказчик? Какие цели? Укажите дату составления, версию документа, список авторов. Это нужно для исторической отслеживаемости.

2. Назначение продукта

Какую проблему решает проект? Не «сделать сайт», а «снизить количество звонков в службу поддержки на 40% за счёт автоматизации ответов на частые вопросы». Чёткая формулировка цели — основа всего дальнейшего.

3. Целевая аудитория

Кто будет использовать продукт? Возраст, пол, интересы, поведение, боли. Например: «Мужчины 28–45 лет, владеющие недвижимостью в Москве, сталкиваются с трудностями при оформлении ипотеки из-за сложных формальностей».

4. Требования к функционалу

Что должен уметь продукт? Здесь — список функций. Не «сайт с формой», а:

• Форма заявки — 3 поля: имя, телефон, email
• Проверка валидности телефона по маске +8 (___) ___-__-__
• Автоматическая отправка письма подтверждения на email
• Интеграция с CRM (1С, Bitrix)

Чем конкретнее — тем меньше ошибок.

5. Требования к дизайну и интерфейсу

Как продукт должен выглядеть? Укажите:

• Цветовая палитра (с HEX)
• Шрифты и их размеры
• Типографику (отступы, интервалы)
• Примеры экранов (скины или ссылки на макеты)
• Адаптивность: мобильная версия? Планшет?

6. Технические характеристики

Как будет работать?

• Язык программирования: PHP, Python
• Фреймворк: Laravel, Django
• Хостинг: AWS или российский провайдер?
• База данных: PostgreSQL
• Требования к безопасности: HTTPS, двухфакторная аутентификация

7. Интеграции и внешние зависимости

Что должно работать вместе?

• Интеграция с платёжной системой (ЮKassa, Сбербанк)
• Подключение к Google Analytics
• API внешнего сервиса для доставки (CDEK)

8. Что не входит в проект?

Это критически важно. Многие конфликты возникают из-за неявных ожиданий. Пропишите явно:

• Контент-наполнение сайта — не входит
• SEO-оптимизация — не входит (если это отдельный проект)
• Рекламные кампании — не входят
• Пост-запускная поддержка — только 14 дней

Этот раздел защищает вас от «а я думал, это тоже включено!».

9. Порядок контроля и приёмки

Как будет проверяться результат?

• Этапы тестирования: модульное, интеграционное, юзабилити
• Кто участвует в приёмке: заказчик, QA-инженер, маркетолог
• Критерии приёмки: «все функции работают без ошибок», «сайт загружается за 2 секунды»
• Процедура передачи: файлы, доступы, инструкции

10. Документация

Что должно быть сдано вместе с продуктом?

• Руководство пользователя
• Инструкция по настройке сервера
• Список аккаунтов и паролей (в зашифрованном виде)
• План технической поддержки

11. Источники и приложения

Ссылки на исследования, брендбуки, примеры конкурентов. Это укрепляет доверие и показывает, что ТЗ основано на реальных данных, а не на домыслах.

Стандарт ГОСТ 34.602-89: когда нужен «железный» подход

Если вы работаете с государственными заказами, IT-проектами или сложной автоматизированной системой — вам нужен стандарт ГОСТ 34.602-89. Он устанавливает обязательную структуру технического задания на создание автоматизированных систем.

Вот его основные разделы:

ГОСТ требует полной прозрачности. Каждый пункт должен быть измеримым, проверяемым и однозначно трактуемым. Это не просто документ — это правовой акт. Его нарушение может повлечь юридические последствия.

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

Это частый вопрос. Бриф — это начало диалога. ТЗ — это его результат.

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

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

Если бриф — это «мне нужен сайт, чтобы привлекать клиентов», то ТЗ — это «сайт должен иметь 5 страниц, форму обратной связи с CAPTCHA, интеграцию с CRM, скорость загрузки менее 2 секунд и соответствовать стандартам WCAG 2.1».

Как избежать типичных ошибок при составлении ТЗ

Многие ТЗ выглядят «официально», но на деле — бесполезны. Вот пять самых частых ошибок:

1. Слишком расплывчатые формулировки

«Сделать красиво», «чтобы было понятно», «быстро» — эти слова не имеют смысла. Что значит «красиво»? Кто определяет «понятно»? Когда «быстро»?

Решение: Заменяйте субъективные слова на измеримые. Вместо «красиво» — «цветовая схема: #1E3A8A, #F59E0B, белый фон». Вместо «быстро» — «время загрузки страницы ≤ 1,8 секунды при скорости интернета 5 Мбит/с».

2. Отсутствие критериев приёмки

Если не указано, как будет проверяться результат — вы получите «почти правильный» вариант. А потом удивитесь: «Но ведь я просил другое!»

Решение: Пропишите: «Проект считается принятым, если выполнены все 12 пунктов из списка проверки (см. Приложение А)».

3. Нет пункта «Что не входит»

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

Решение: Создайте раздел «Исключения». Даже если кажется, что это очевидно — пишите.

4. Нет ответственных

«Кто сделает?» — часто остаётся без ответа. В итоге никто не берёт на себя ответственность. Позже выясняется: «А это ведь не мой раздел».

Решение: Каждому требованию — ответственный. «Ответственный за дизайн: Иван Петров», «Ответственный за тестирование: Алексей Сидоров».

5. ТЗ — живой документ? Или «на бумаге»?

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

Решение: Ведите версионность. «v1.0 — 5 апреля», «v1.1 — 8 апреля (добавлено требование к мобиле)». Все изменения — с подписями. Используйте Google Docs или Notion с историей изменений.

Практические советы: как сделать ТЗ, которое будут читать и использовать

Хороший ТЗ — это не документ, который «сдали», а инструмент, которым пользуются. Вот как его сделать живым:

• Пишите простыми словами. Не «интеграция с внешними API» — а «связать сайт с платёжной системой». Даже если ТЗ читает технический специалист — ясность важнее терминов.
• Используйте визуализацию. Скриншоты, схемы, эскизы — лучше 10 страниц текста. Добавляйте ссылки на макеты, Figma-проекты.
• Проверяйте на понимание. Спросите исполнителя: «Как ты понял задачу?». Его ответ покажет, насколько ТЗ было ясным.
• Создавайте шаблоны. Если вы часто делаете сайты — сделайте универсальный шаблон ТЗ. Заполняйте поля, а не пишите с нуля.
• Храните в одном месте. Не разбрасывайте ТЗ по папкам, чатам и почте. Используйте базу знаний (Notion, Confluence, WEEEK База знаний).
• Проводите ревью. Перед утверждением — дайте ТЗ прочитать двум-трём людям. Часто они находят противоречия, которых вы не заметили.

Заключение: Техническое задание — это инвестиция в ясность

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

Когда вы пишете ТЗ, вы не просто описываете задачу. Вы создаёте общее понимание. Вы говорите: «Я знаю, что ты можешь сделать. И я хочу, чтобы мы вместе это сделали правильно».

Используйте шаблоны. Не бойтесь деталей. Пишите чётко. Уточняйте. Документируйте.

Потому что лучший способ избежать ошибок — не ждать их, а предотвратить. А техническое задание — ваш первый и самый мощный инструмент для этого.