Vlas Zubenko
АвторVlas ZubenkoВеб-разработчик, руковожу командой · 9+ лет · 260+ проектов
Подробнее об авторе

Зачем вообще писать ТЗ

Не ради формальности и не ради юридической защиты. Ради того, чтобы смета была цифрой, а не вилкой. Разработчик, который не понимает объём, закладывает риск — и вы платите за его неуверенность. При этом ТЗ на сорок страниц вам не нужно. Больше того, длинное ТЗ, написанное не специалистом, чаще мешает: оно фиксирует решения, которые стоило бы обсудить, и пропускает то, что реально определяет цену.

Восемь пунктов, которых достаточно

  • Зачем сайт. Одно предложение: заявки, продажи, доверие, найм. От ответа зависит вся структура
  • Кто ваш клиент и как он ищет. «Владельцы кафе, гуглят с телефона» — этого достаточно, чтобы поменять половину решений
  • Типы страниц, а не страницы. Главная, услуга, кейс, статья, контакты — это пять шаблонов. Сорок страниц на шести шаблонах дешевле девяти на девяти
  • Есть ли дизайн. Готовый файл Figma убирает целый этап и 25–40% стоимости
  • Есть ли контент. Тексты, фото, данные товаров. Это причина номер один, по которой проекты опаздывают
  • Все интеграции списком: оплата, CRM, бронирование, аналитика, рассылка, службы доставки
  • Языки. Второй язык — не перевод, а продублированная структура и проверка каждого шаблона
  • Дедлайн и чем он вызван. Запуск, сезон, выставка — план выстроят вокруг даты, если знать её заранее
Разработчику нужно знать не как должен выглядеть сайт, а что он должен делать и для кого. Первое — его работа, второе — ваша.

Что писать не нужно

  • Конкретные технологии, если у вас нет причины их требовать. «Сделайте на React» без причины сужает выбор и иногда удорожает вдвое
  • Цвета и шрифты в ТЗ. Это результат дизайна, а не вводные к нему
  • Пожелания вроде «современно», «дорого», «как у Apple». Замените одной ссылкой на сайт, который вам нравится, и одним предложением почему
  • Список из сорока функций «на будущее». Всё, что не нужно на запуске, удорожает и откладывает запуск
  • Описание того, как реализовать. Скажите, что должно получиться, — как, посчитает исполнитель

Три вопроса, которые экономят больше всего

Задайте их себе до того, как отправите бриф. Каждый из них меняет смету сильнее, чем любой пункт про дизайн. Кто будет менять тексты на сайте после запуска — вы или разработчик? Будут ли пользователи, которые входят в личный кабинет и что-то там делают? И сколько у вас реально уникальных типов страниц, если считать честно?

Что попросить в ответ

  • Смету по этапам, а не одну сумму
  • График с зависимостями: «дизайн к 14-му при условии, что тексты придут к 7-му»
  • Список того, что не входит. Смету определяют исключения не меньше, чем итог
  • Кому принадлежат домен, хостинг и код после сдачи
  • Что происходит с правками после запуска и сколько они стоят

Вывод

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

Vlas Zubenko
АвторVlas ZubenkoВеб-разработчик, руковожу командой · 9+ лет · 260+ проектов
Подробнее об авторе

Частые вопросы

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

Нет. Длинное ТЗ от неспециалиста чаще мешает: фиксирует решения, которые стоило обсудить, и пропускает то, что определяет цену.

Конкретные технологии без причины, цвета и шрифты, слова «современно» и «как у Apple», список функций «на будущее» и указания, как реализовать.

Потому что не видит объёма и закладывает риск. Восемь пунктов брифа обычно превращают вилку в цифру.

Смету по этапам, график с зависимостями, список исключений, ответ про владение доменом и кодом и стоимость правок после запуска.

Есть похожая задача?

Расскажите, что должен делать сайт, — честный диапазон получите в тот же день.

Обсудить проект