Техническое задание на сайт: восемь пунктов вместо сорока страниц

Зачем ТЗ, если подрядчик и так всё понял

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

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

Хорошее ТЗ короче, чем принято думать. Оно занимает несколько страниц, а не сорок, и почти целиком состоит из решений, а не описаний.

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

Чего в техническом задании быть не должно

Начнём с того, что обычно занимает половину объёма и не приносит пользы.

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

Описание дизайна словами. «Современно, стильно, чтобы цепляло» невозможно ни выполнить, ни проверить. Вместо этого — три-четыре ссылки на сайты, которые нравятся, и одна строка о том, что именно в них нравится.

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

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

С чего начинается: задача, а не список страниц

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

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

Дальше — кто эти люди. Один-два типа посетителей, и по каждому: с каким вопросом приходит, что должен сделать, что мешает ему сделать это сегодня.

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

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

Список страниц и как понять, что он полный

Теперь структура. Перечислите страницы списком, по одной строке на каждую, и рядом — зачем она.

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

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

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

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

Данные: самый пропускаемый раздел

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

Всё, что на сайте существует во множественном числе, живёт в таблице: товары, услуги, объекты, специалисты, статьи. Для каждого такого набора нужны три вещи.

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

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

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

Интеграции: перечислить поимённо

Список внешних систем, с которыми сайт должен разговаривать. Не «интеграция с CRM», а название CRM.

По каждой — что именно должно происходить и в какую сторону. Заявка уходит в CRM. Остатки приходят из учётной системы раз в час. Оплата проходит через конкретный банк. Уведомление приходит в мессенджер.

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

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

Что происходит со старым сайтом

Раздел нужен всем, у кого сайт уже есть, и его пропускают почти все.

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

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

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

Стоит это несколько дней работы и экономит месяцы восстановления позиций.

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

Короткая таблица, которая предотвращает больше споров, чем весь остальной документ.

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

Фотографии: есть свои, нужна съёмка или берутся из стоков. У каждого варианта своя цена и свой срок.

Доступы: домен, хостинг, почта, аналитика, учётная система. Соберите их заранее и проверьте, что они рабочие: пароль от домена, зарегистрированного семь лет назад на бывшего сотрудника, находится долго.

Наполнение после запуска: кто заводит товары и пишет новости. Сайт, который некому наполнять, устаревает за квартал независимо от того, как он сделан.

Как принимать работу: Первая страница — задача бизнеса, а не структура сайта.

Раздел, который пишут реже всего, а он определяет, чем закончится проект.

Критерии приёмки должны быть проверяемыми в присутствии обеих сторон. «Сайт работает корректно» — не критерий. «Заявка с формы приходит на указанную почту и в CRM в течение минуты» — критерий.

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

Отдельно — что считается ошибкой, а что доработкой. Ошибка исправляется в рамках работ, доработка оценивается отдельно. Без этой границы любой спор превращается в переговоры о деньгах.

И назовите срок, в течение которого исправляются ошибки после запуска. Месяц — разумно; пожизненная поддержка бесплатно не бывает и закладывается в цену.

Три места, из-за которых срываются сроки

По опыту почти все задержки происходят не там, где их ждут.

Тексты. Их пишут в последнюю очередь, и они держат всё. Решение — писать параллельно с разработкой и отдавать страницами, а не целиком.

Доступы. Заводятся дольше, чем кажется, особенно к банковским и учётным системам. Начинать их собирать надо в день подписания.

Согласование внутри заказчика. Если решение принимают трое, а собираются они раз в две недели, каждая правка стоит две недели. Назовите одного человека, чьё слово окончательное, — это самая дешёвая ускоряющая мера из всех.

Шаблон на одну страницу

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

Задача бизнеса и один-два типа посетителей. Список страниц с назначением каждой. Наборы данных с полями и объёмом. Внешние системы поимённо с направлением обмена. Судьба старых адресов. Кто что предоставляет и к какому сроку. Критерии приёмки. Граница между ошибкой и доработкой.

Восемь пунктов, три-четыре страницы. Этого достаточно, чтобы получить сопоставимые предложения от разных подрядчиков и чтобы через три месяца разговор шёл о работе, а не о том, кто что имел в виду.

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