«Сделайте сайт, как у конкурента, только лучше» — самая дорогая формулировка в веб-разработке. Не потому что она наглая, а потому что её невозможно исполнить предсказуемо: у каждого участника в голове окажется свой «лучше». Техническое задание существует ровно для того, чтобы у всех была одна картинка объёма, сроков и критериев готовности. Расскажем, что происходит без ТЗ, что в нём должно быть и почему это самый выгодный этап проекта.
Что происходит без ТЗ
- Каждая правка — торг. Объём нигде не зафиксирован, поэтому любое «а можно ещё…» — это переговоры о доплате, даже если по сути это была ошибка исполнителя
- Сроки плывут. «Примерно через месяц» без зафиксированного списка работ превращается в «ещё две недели» — без последствий для кого-либо
- Приёмка превращается в спор. Без критериев готовности спор идёт по ощущениям, а ощущения у сторон всегда разные
- Цена растёт у всех на виду. Смета, посчитанная по трём вводным, обновляется на каждом этапе — не от жадности, а от незнания реального объёма
Парадокс в том, что заказчики, экономящие на ТЗ, почти всегда переплачивают на правках — просто эту переплату сложнее увидеть, потому что она размазана по этапам и не выглядит одной строкой в смете.
Что должно быть в хорошем ТЗ
Хороший документ не длинный, а полный. Пять обязательных частей:
- Цели и критерии успеха. Зачем проект: заявки, продажи, узнаваемость. Без целей невозможно решить, чем пожертвовать, когда объём не влезает в бюджет
- Структура. Карта страниц и экранов: что есть, что на что ссылается, что происходит на мобильных
- Функциональность. По каждой странице — что должно работать: формы, каталог, интеграции, авторизация. С описанием поведения, а не общими словами «удобно и современно»
- Границы объёма. Что НЕ входит в работу. Эта секция важнее списка «что входит» — именно в ней живут будущие споры
- Критерии приёмки. Как проверяется готовность: список проверяемых пунктов, а не «нам всё нравится»
К этому — сроки этапов, порядок оплаты и список материалов с каждой стороны. Всё остальное — приятные дополнения, а не замена этих пяти частей.
Как мы пишем дизайн-брифы: пример из практики
Мы в PROWEB пишем ТЗ и брифы сами: заказчик формулирует задачи, мы фиксируем объём. Свежий пример — дизайн-бриф на редизайн корпоративного сайта. Что в нём:
- Принципы вместо абстракций. В начале документа — визуальные принципы в духе «меньше, но лучше» (Дитер Рамс): контент в фокусе, интерфейс — «невидимый проводник», один акцентный цвет занимает не более десятой части площади
- Дизайн-токены. Цвета, типографика, отступы, радиусы и анимации описаны как именованные переменные; компоненты ссылаются только на токены, поэтому тёмная тема и правки палитры не переделывают весь макет
- Покомпонентная библиотека. Кнопки, формы, карточки, аккордеоны — каждый компонент с вариантами: светлая и тёмная темы, размеры, состояния hover/focus/error. Страницы собираются из готовых компонентов, а не рисуются с нуля
- Постраничные спецификации. Для каждой страницы — десктопный и мобильный макет, состояния интерактивных элементов и аннотации по поведению и анимациям
- Приёмочные критерии и процесс. Отдельные секции: доступность (контраст текста, навигация с клавиатуры), ограничение итераций правок на страницу и порядок демо после каждого этапа
Такой документ — не бюрократия ради бюрократии: по нему же принимается работа. Дизайнер знает, что рисовать, разработчик — что верстать, заказчик — что проверять.
Кому поручить писать ТЗ
Типичная ошибка — ждать, что заказчик напишет ТЗ сам, или наоборот, что подрядчик «сам всё поймёт». Работает разделение:
- Заказчик формулирует бизнес-часть: цели, аудитория, что сайт должен уметь, какие материалы есть, какие ограничения — сроки, бюджет, юридические требования
- Подрядчик переводит это в объём: структура, функциональность, технологии, критерии приёмки, смета
- Финальная редакция — совместная: документ фиксируется, когда обе стороны понимают его одинаково
Если подрядчик против ТЗ «потому что и так ясно» — это не про документ. Это про то, как пойдёт весь проект.
Что ТЗ экономит
- Правки «мы не так поняли» — крупнейшую статью перерасхода в веб-проектах; фиксация объёма убирает её почти целиком
- Споры при приёмке — критерии готовности написаны до старта, когда стороны ещё друг другу доверяют
- Переделки — изменение на этапе ТЗ стоит часы, то же изменение после запуска — дни
- Время всех участников — вопросы «а как это должно работать?» получают ответы из документа, а не из чата
Работа над ТЗ занимает дни. Переделки без ТЗ — недели. Считайте сами, что дешевле.
Коротко
ТЗ — не формальность, а фиксация объёма: цели, структура, функциональность, границы («что НЕ входит») и критерии приёмки. Без него каждая правка — торг, сроки плывут, а приёмка превращается в спор по ощущениям. Заказчик формулирует задачи, подрядчик — объём; финальную редакцию фиксируют обе стороны. Хорошее ТЗ — с принципами, дизайн-токенами, покомпонентной библиотекой и постраничными спецификациями — экономит не только дизайн и разработку, но и нервы: документ, по которому работают, — это же документ, по которому принимают результат.