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

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

А теперь к хорошим новостям: вам не нужно быть разработчиком, чтобы составить рабочее ТЗ. Нужно просто понимать как составить техническое задание, из чего оно состоит и зачем каждая часть нужна. Разбираем по порядку.

Зачем вообще нужно ТЗ, если вы не разработчик

Техническое задание - это не для галочки и не чей-то прикол. Это единственный документ, который защищает обе стороны:

• Вас - от ситуации «я имел в виду совсем не это», когда готовый сайт не соответствует ожиданиям.

• Исполнителя - от бесконечных «а можно ещё вот тут поправить», которые не были оговорены изначально и съедают время сверх сметы.

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

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

Тут часто путают два документа:

• Бриф - короткая анкета в начале: кто вы, чем занимаетесь, какая цель, есть ли референсы, какой бюджет. Обычно 10-15 вопросов, занимает 15-20 минут.

• Техническое задание - куда более подробный документ, который появляется уже после брифа и обсуждений. В нём фиксируется конкретная структура сайта (Либо же вариации структуры), функционал каждой страницы, интеграции, требования к дизайну и критерии, по которым вы будете принимать готовую работу.

Бриф - это отправная точка, можно сказать, что знакомство с Вами. ТЗ - это контракт по сути, даже если оно не оформлено юридически.

Из чего состоит рабочее техническое задание

Вот минимальный набор блоков, без которых ТЗ превращается в филькину грамоту.

1. Цель проекта и задачи бизнеса

Не «нужен сайт», а «нужен сайт, который приносит заявки на монтаж окон» или «нужна витрина, которая повышает доверие перед встречей с инвесторами». Цель определяет вообще всё остальное - от структуры до тона текстов.

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

Кто эти люди, что они ищут, с какого устройства заходят чаще (мобильный трафик сейчас часто больше половины). Это влияет на приоритеты в дизайне и на то, что показывать в первую очередь.

3. Структура сайта (карта разделов)

Список всех страниц: главная, каталог, карточка товара, о нас, контакты и так далее. Для каждой - короткое описание, что на ней должно быть.

4. Функционал

Что сайт должен уметь, а не просто показывать:

• форма заявки - куда уходят данные, нужна ли CRM (Это может быть Битрикс, ZohoCRM и так далее);

• каталог - есть ли фильтры, сортировка, поиск;

• личный кабинет - регистрация, авторизация, что видит пользователь;

• интеграции - платёжные системы, службы доставки, аналитика.

5. Референсы, но с оговоркой

Скидывать 10 разных сайтов, каждый из которых нравится по своей причине, - плохая практика. Лучше: 2-3 сайта и конкретно, что именно в каждом нравится («вот этот способ показа товара», «вот такая структура меню»). Это экономит часы обсуждений.

6. Контент

Кто пишет тексты и делает фото/видео - вы или исполнитель? Это критично: без готового контента дизайн часто верстают «на сухую», а потом всё съезжает при замене на реальные тексты.

7. Бюджет и сроки

Без вилки бюджета исполнитель либо предложит вариант не по карману, либо, наоборот, занизит объём работ, чтобы уложиться в непонятную цифру. Честная вилка - это не слабость переговорной позиции, а способ получить релевантное предложение.

8. Критерии приёмки

Как вы поймёте, что работа сделана и её можно принимать? Пропишите конкретно: «все страницы из раздела 3 реализованы», «форма отправляет заявку на email и в CRM», «сайт открывается на мобильном без горизонтальной прокрутки». Расплывчатые критерии - главный источник споров на финише проекта.

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

• «Сделайте как у массажного салона напротив пивнухи, но лучше» - конкретики это не задание, а пожелание. У кого «лучше», по каким параметрам?

• Смешивание этапов - попытка утвердить сразу и дизайн, и код, и контент в одном документе на старте, когда ещё ничего не согласовано даже на уровне структуры.

• Отсутствие критериев приёмки - самая частая причина конфликтов «мы же не это обсуждали» уже после сдачи проекта.

• ТЗ на 2 строки в мессенджере - «нужен лендинг, бюджет 500 USD, срок неделя» - это не ТЗ, это заявка на недопонимание.

Чек-лист: что должно быть в ТЗ перед стартом работы

• Цель проекта и ключевая задача бизнеса

• Портрет целевой аудитории (Как правило это влияет на цвета, иллюстрации, UX)

• Полная структура сайта (карта разделов)

• Описание функционала для каждого раздела

• 2-3 референса с пояснением, что именно нравится

• Кто готовит контент - вы или исполнитель

• Вилка бюджета

• Сроки с ключевыми точками (не только финальный дедлайн)

• Критерии приёмки готовой работы

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

Как хорошее ТЗ экономит бюджет

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

Если не хочется составлять ТЗ вручную - в vyxro.dev мы как раз для этого держим интерактивный бриф: отвечаете голосом или текстом в удобном темпе, а дальше уже мы превращаем это в структурированное техническое задание вместе с вами.