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