Процесс

Техническое задание: как описать задачу, чтобы её поняли

ТЗ — не список страниц и не пожелание «сделайте красиво». Разбираем, что в нём должно быть, чтобы подрядчик и заказчик понимали объём работ одинаково.

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

Что такое ТЗ и чем оно не является

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

Чем ТЗ не является:

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

Формулировка «сделайте красиво» не работает по простой причине: красота — не свойство результата, а мнение конкретного человека в конкретный день. Если критерий приёмки — чьё-то мнение, приёмка превращается в переговоры без конца. Заменой служит другое: описанная задача, описанная аудитория и референсы с объяснением, что именно в них нравится — структура, плотность, типографика, характер иллюстраций.

Обязательные разделы

Задача бизнеса

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

Полезно сформулировать и отрицание — чего сайт делать не должен. Это ограничение экономит больше денег, чем любой список функций.

Сценарии пользователей

Самая полезная часть ТЗ. Сценарий — это короткое описание пути: кто пришёл, откуда, что хочет сделать, какими шагами это делает, чем заканчивается.

Например: «Клиент пришёл из поиска по названию услуги. Читает описание, смотрит состав и порядок работы, оставляет заявку с телефоном и удобным временем звонка. Заявка приходит на почту отдела и в CRM». В таком виде сразу видно, какие страницы нужны, какие поля в форме и куда идут данные.

Сценариев обычно немного — три-пять основных и несколько побочных. Если сценарий не удаётся описать, значит, задача ещё не продумана, и разработка её не прояснит.

Объём

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

Отдельно стоит оговорить адаптивность: какие устройства поддерживаются, есть ли отдельное поведение для мобильной версии, какие браузеры считаются целевыми.

Интеграции

Каждая внешняя система — отдельный риск, и о ней нужно писать конкретно: что за система, в какую сторону идут данные, есть ли у неё документированный интерфейс, кто предоставляет доступы и тестовую среду. Оплата, CRM, складской учёт, службы доставки, мессенджеры, системы аналитики — всё это часто оказывается сложнее самого сайта.

Если интеграция обязательна для запуска, это надо написать прямо. Иначе есть шанс получить готовый сайт, который нельзя включить.

Кто что предоставляет

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

Проект не останавливается из-за сложной функции. Он останавливается из-за того, что три недели некому написать описание двенадцати услуг.

Как фиксировать границы работ

Граница — это то место, где заканчивается ответственность подрядчика. Её описывают не общими словами, а списком того, что в работу не входит: наполнение контентом сверх оговорённого объёма, доработка после запуска, разработка фирменного стиля, съёмка, ведение рекламы, написание текстов.

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

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

Про уровень детализации

Излишне подробное ТЗ вредит не меньше, чем поверхностное. Если в документе описан цвет каждой кнопки, работа превращается в перерисовку документа, а не в решение задачи. Разумная граница проходит так: заказчик описывает что и зачем, подрядчик отвечает за как.

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

Если задача крупная и непонятная целиком, честнее разбить её: сначала описать и сделать ядро, а остальное уточнять по ходу. Для сложных систем это часто единственный рабочий путь — мы обсуждаем это в разделе про веб-приложения.

Чеклист: проверьте своё ТЗ

Пройдите по пунктам, прежде чем отправлять документ подрядчику.

  1. Сформулирована задача бизнеса, а не список хотелок.
  2. Описаны основные сценарии пользователей — путь целиком, от входа до результата.
  3. Посчитаны типы страниц, роли, языковые версии.
  4. Перечислены все внешние системы и указано, кто даёт к ним доступ.
  5. У каждого материала — текстов, фото, документов — есть ответственный и срок.
  6. Написано, что в работу не входит.
  7. Описан порядок внесения изменений и порядок сбора замечаний.
  8. По каждому пункту можно ответить «сделано» или «не сделано» без спора о вкусах.

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