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

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

Проекты редко ломаются в коде. Они ломаются в словах. Заказчик говорит «фильтры» и имеет в виду пять параметров с подсчётом товаров, разработчик делает два выпадающих списка. Оба честно выполнили договорённость, оба недовольны, а сроки уже сорваны.

Хорошее ТЗ нужно, чтобы картинка в голове у вас и у подрядчика совпала до начала работ, а не после. Ниже структура документа, которая реально нужна сайту для бизнеса, примеры формулировок «плохо и хорошо», фрагмент реального ТЗ и то, как документ помогает на приёмке, когда спорить уже поздно.

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

Вторая: зафиксировать, как будет проверяться результат. Когда в документе написано, как должна работать форма, проверить её можно за минуту. Когда написано «удобная форма», спор о том, удобная ли она, может тянуться неделями.

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

Для лендинга под одну услугу или сайта-визитки на пять страниц документ на тридцать листов избыточен. Хватит хорошего брифа, прототипа и короткого списка требований к формам и аналитике. Подробное ТЗ окупается там, где есть логика: каталог с фильтрами, личный кабинет, интеграции, несколько ролей в админке, переезд старого сайта с сохранением позиций в поиске.

Эти документы часто путают или пытаются заменить один другим. Но они отвечают на разные вопросы и появляются в разное время.

Удобнее всего, когда ТЗ ссылается на прототип, а не пересказывает его. Описывать текстом, что «справа от заголовка расположена синяя кнопка», бессмысленно: картинка скажет точнее. Задача ТЗ описать то, чего на картинке не видно. Что происходит после нажатия на кнопку, куда уходят данные, кто и где может это поменять.

Для автоматизированных систем есть ГОСТ 34.602-2020, который с 2022 года заменил стандарт 1989 года. Его требуют госзаказчики и крупные компании для сложных внутренних систем. Для сайта малого или среднего бизнеса полное следование ГОСТу обычно избыточно: документ получается толстым, а читать его некому. Логику разделов из стандарта взять полезно, бюрократию можно оставить.

Ниже структура, с которой удобно начинать. Это не догма. Для маленького сайта часть разделов займёт по два предложения, для сложного проекта какие-то разделы разрастутся в отдельные документы. Но пропускать раздел целиком не стоит, даже если в нём написано «не требуется». Это тоже договорённость, и её лучше зафиксировать.

Чаще всего проваливаются три раздела: админка, контент и приёмка. Про админку забывают, потому что на старте кажется, что «там всё стандартно». Про контент забывают, потому что каждая сторона уверена, что тексты пишет другая. Про приёмку вспоминают в день сдачи, когда договариваться уже неудобно.

Главное правило одно: требование должно быть проверяемым. Если по формулировке нельзя однозначно сказать «сделано» или «не сделано», это пожелание, а не требование. Проверить себя просто. Представьте, что принимаете работу у человека, которого видите впервые. Сможете ли вы доказать ему, что что-то не так, опираясь только на текст документа?

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

Толстое ТЗ не значит хорошее. Есть вещи, которые раздувают документ и ничего не дают ни вам, ни подрядчику.

• История компании и миссия. Подрядчику нужен контекст, но он помещается в бриф на полстраницы.
• Технические решения без причины. Строка «сайт должен быть на React» имеет смысл, если за ней стоит требование: например, ваши программисты будут поддерживать сайт сами и знают эту технологию. Иначе вы ограничиваете подрядчика, ничего не получив взамен.
• Функции «на будущее». Форум, мобильное приложение, три языка, которые «может, понадобятся». Каждая такая строка увеличивает оценку. Лучше вынести их в список будущих задач и вернуться к нему после запуска.
• Пересказ макетов словами. Расположение элементов показывает прототип. ТЗ описывает поведение.
• Оценочные слова. «Удобный», «стильный», «интуитивно понятный», «как у Apple». Их невозможно проверить, а значит, и принять.

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

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

4.3. Шаблон «Страница услуги». Назначение: посетитель понимает, что входит в услугу, видит примеры работ и оставляет заявку. Количество страниц по шаблону не ограничено, они создаются из админки.

• 4.3.1. Первый экран. Заголовок H1 до 70 символов, подзаголовок до 200 символов, фоновое фото или видео, кнопка «Рассчитать стоимость», открывающая форму из раздела 5.1.
• 4.3.2. Состав работ. Список этапов от 3 до 10 пунктов, у каждого название и описание до 300 символов. Порядок меняется перетаскиванием в админке.
• 4.3.3. Примеры работ. Карточки проектов из раздела «Портфолио», выбранные вручную для каждой услуги, от 3 до 9 штук. Если проекты не выбраны, блок не выводится.
• 4.3.4. Сроки и от чего зависит стоимость. Текстовый блок с форматированием: списки, жирный шрифт, ссылки. Цены на сайте не публикуются.
• 4.3.5. Вопросы и ответы. От 3 до 8 пар «вопрос и ответ», ответы раскрываются по клику.
• 4.3.6. Форма заявки. Форма из раздела 5.1, название услуги подставляется в скрытое поле автоматически, чтобы менеджер видел, откуда пришла заявка.
• 4.3.7. SEO. Поля title, description, H1 и адрес страницы редактируются вручную. Если title не заполнен, он собирается по шаблону «Название услуги в Москве | Название компании».

Обратите внимание на мелочи. Указано, что будет, если проекты не выбраны. Указаны ограничения длины, чтобы дизайнер знал, на какой объём текста рассчитывать вёрстку, а копирайтер не написал заголовок на три строки. Указана связь с другими разделами (форма 5.1), чтобы одну и ту же форму не описывать трижды и не получить три разные. Из таких мелочей и складывается документ, по которому можно работать.

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

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

Есть три варианта, и у каждого своя цена ошибки.

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

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

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

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

Даже если ТЗ пишет подрядчик, последнее слово за вами. Прочитайте документ целиком, а не по диагонали. Каждый непонятный абзац даёт повод задать вопрос до подписания, а не после.

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

Чтобы приёмка прошла спокойно, заранее договоритесь о трёх вещах:

• кто со стороны компании принимает работу и имеет право сказать «принято»: один человек, а не комиссия из пяти, где у каждого своё мнение;
• сколько дней отводится на проверку и что происходит, если замечаний в срок нет;
• что считается дефектом (работает не так, как написано в ТЗ), а что новым пожеланием (работает как написано, но захотелось иначе).

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

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

1. Какое действие посетителя для вас главное: звонок, заявка, покупка, запись?
2. Как вы через полгода поймёте, что сайт работает? Какая цифра должна измениться?
3. Кто ваши посетители и с каких устройств они чаще заходят?
4. Какие три вопроса клиенты задают менеджерам чаще всего? Ответы на них должны быть на сайте.
5. Какие разделы нужны на старте, а что можно добавить потом?
6. Кто будет обновлять сайт после запуска и что именно ему придётся менять?
7. Куда должны попадать заявки и кто их обрабатывает?
8. С какими системами сайт обменивается данными: CRM, 1С, телефония, оплата?
9. Есть ли старый сайт с поисковым трафиком, который нельзя потерять при переезде?
10. Есть ли жёсткая дата запуска и с чем она связана: выставка, сезон, рекламная кампания?

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

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