Техническое задание считают то бюрократией, то панацеей. Истина посередине: ТЗ — это инструмент синхронизации ожиданий, и его ценность зависит от того, что и как в нём написано. Разберём, когда ТЗ действительно нужно, что в нём должно быть и почему писать его лучше вместе со студией, а не вместо неё.
Бриф и ТЗ — разные документы
Бриф — это рассказ о задаче на языке бизнеса: кто вы, кто ваши клиенты, что должен делать сайт, что нравится и не нравится в примерах. Его пишет заказчик, и для старта переговоров его достаточно. ТЗ — это описание решения: структура, функциональность, сценарии, требования к интеграциям. Оно появляется после аналитики, когда решение спроектировано.
Требовать от заказчика готовое ТЗ до начала работы — значит перекладывать на него проектирование. Составление ТЗ — работа студии, выполняемая на основе брифа и совместных обсуждений.
Зачем ТЗ заказчику
ТЗ фиксирует договорённости: что входит в проект, а что нет. Без него граница объёма существует только в памяти участников, и каждая сторона помнит своё. С ТЗ спор «это входило в стоимость или нет» решается ссылкой на документ, а не выяснением, кто что имел в виду.
Второй эффект — качество мышления. Когда решение приходится описывать словами, противоречия и дыры видны до того, как на них потрачены дизайн и код.
Что должно быть в хорошем ТЗ
Хорошее ТЗ описывает цели и контекст, структуру сайта, состав и логику каждого типа страниц, сценарии пользователей, требования к панели управления, интеграции с внешними системами, требования к адаптивности, скорости и SEO, а также границы проекта — что осознанно не делается. Отдельный блок — критерии приёмки: как обе стороны поймут, что работа выполнена.
Каким ТЗ быть не должно
Плохое ТЗ бывает двух видов. Первый — размытое: «современный удобный сайт с продающим дизайном» не проверяемо и не защищает никого. Второй — избыточно жёсткое, где расписан каждый пиксель: оно запрещает улучшать решения по ходу проекта и устаревает к середине работы. Рабочее ТЗ фиксирует существенное — состав, логику, границы — и оставляет пространство для проектных решений.
ТЗ в небольших проектах
Для лендинга или небольшого сайта многостраничное ТЗ избыточно — его роль выполняют бриф, прототип и короткое описание состава работ в договоре. Важен принцип, а не формат: до начала дизайна и разработки обе стороны одинаково понимают, что будет сделано. Форма документа вторична.
Коротко
Мы начинаем проекты с брифа и аналитики, а состав и логику решения фиксируем письменно — в форме, соразмерной масштабу задачи. Если проект только формируется, начните с брифа: у нас есть материал о том, как его подготовить.