Пишите ТЗ на сайт так, будто завтра приёмка

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

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

Что должно быть в ТЗ на сайт, кроме списка страниц

Типичное ТЗ — список. Главная, услуги, о компании, контакты. Каталог с фильтром, форма заявки, личный кабинет. Адаптивная вёрстка, SEO-оптимизация, современный и удобный дизайн. По такому списку подрядчик назовёт цену, и к первому чтению документ готов.

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

Проблема старая. В 1995 году Standish Group опросила 365 руководителей ИТ-отделов про 8 380 проектов. В срок, в бюджет и со всеми обещанными функциями закончились 16,2%. Среди причин, по которым проекты бросали, первыми назвали неполные требования, вторыми — то, что будущих пользователей не привлекли к работе. Сайты тогда почти никто не заказывал, а список причин с тех пор звучит знакомо.

Я бы проверял ТЗ одним вопросом к каждой строке: что вы будете делать с ней в день приёмки? И писал бы его с конца, от последнего дня проекта к первому. Так и пойдём.

Критерии приёмки сайта: примеры строк ТЗ

Критерий приёмки — то, что можно проверить за минуту без спора о вкусе. Почти любую расплывчатую строку можно переписать в такую:

• Вместо «современного дизайна»: макеты главной и одной внутренней страницы согласуем до вёрстки, на макеты два круга правок. Дальше вёрстка совпадает с макетом.
• Вместо «адаптивной вёрстки»: все страницы открываются на телефоне шириной 390 пикселей и на компьютере шириной 1440, без горизонтальной прокрутки и наезжающих блоков.
• Вместо «быстро загружается»: на телефоне главная по PageSpeed Insights показывает крупнейший элемент первого экрана (LCP) не позже чем через 2,5 секунды. Этот порог Google считает хорошим.
• Вместо «удобной формы заявки»: заявка попадает в CRM и копией на почту, «Спасибо» посетитель видит только после записи. Проверяем пробной заявкой.
• Вместо «SEO-оптимизации»: у каждой страницы отдельный заголовок и описание для поиска, есть карта сайта, старые адреса перенаправлены на новые.

Цифры можно взять другие. Важна форма: по каждой строке понятно, кто проверяет и чем.

У приёмки есть и юридическая сторона. Если сайт делают по договору подряда, по ст. 720 ГК заказчик обязан осмотреть и принять работу. Принял без проверки — по общему правилу теряет право ссылаться на недостатки, которые можно было заметить при обычной приёмке. Критерии приёмки защищают прежде всего заказчика: без них непонятно, с чем сверять, и акт подписывают на глаз.

Домен, хостинг и права на сайт: на кого их оформить

Следующий шаг назад — запуск. В шаблонах ТЗ из поисковой выдачи такого раздела обычно нет, а вопросы из него всплывают позже всех, иногда через год, когда подрядчик пропал.

Домен оформляют на компанию заказчика. Администратор домена — тот, на кого он зарегистрирован: он платит за продление, управляет настройками DNS и может передавать полномочия другим. Если домен записан на разработчика, адресом вашего сайта распоряжается он.

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

С кодом и дизайном закон на стороне заказчика, но с оговоркой. По ст. 1296 ГК исключительное право на программу, созданную по заказу, принадлежит заказчику, если договор не говорит иное. Эту строчку «если не говорит иное» и стоит поискать в договоре. Если сайт собран на платной системе управления или чужом шаблоне, на них у вас будет лицензия, а не права. Это нормально, но знать об этом надо до подписания.

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

Кто пишет тексты для сайта

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

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

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

Что сайт делает после кнопки и что не входит в работу

Функции в ТЗ обычно перечислены. Хуже с тем, что происходит после действия посетителя. «Форма заявки» — это кнопка. А дальше? Заявка приходит на почту, в Telegram, в CRM? Кто её видит первым? Что увидит посетитель, если CRM не ответила? Как это проверить, разобрано в справочнике про заявки с сайта в CRM. В ТЗ достаточно записать, куда заявка должна попасть и как вы это проверите.

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

А потом список, который почти никто не пишет: что не входит в работу. Например:

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

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

Как составить техническое задание на сайт: шаги

1. Опишите посетителя и одно действие. Кто приходит на сайт и что он должен на нём сделать: оставить заявку, записаться, купить, позвонить. Один абзац. Если действий пять, договоритесь, какое главное. А если пока не уверены, что этот сайт кому-то нужен, сначала стоит проверить саму идею.
2. Запишите критерии приёмки. Для каждого важного требования — как его проверят в последний день.
3. Решите про домен, хостинг и права. На кого оформлено, у кого доступы, что написано в договоре о правах на код и дизайн.
4. Распределите наполнение. Кто пишет тексты и готовит фото, к какой дате, что будет, если не успели.
5. Перечислите страницы и функции. Для каждой функции — что происходит после неё и куда уходят данные.
6. Напишите, что не входит в работу. Всё, о чём стороны могут подумать по-разному.
7. Отдайте ТЗ подрядчику на вопросы. И только после ответов просите смету.

Длина здесь ничего не решает. ГОСТ 34.602-2020, который с 2022 года заменил версию 1989 года, написан для автоматизированных систем. Для сайта небольшой компании раздел вроде «подготовки объекта автоматизации к вводу системы в действие» — лишний вес. Генераторы ТЗ на нейросетях обещают черновик за 20–40 минут и все нужные разделы. Разделы, скорее всего, будут. Ответа на вопрос, кто пишет тексты, не будет: его знаете только вы. Про цену длинных документов, которые дёшево написать и дорого читать, есть отдельное эссе.

Что попросить у подрядчика в ответ на ТЗ

Не только смету. Попросите вернуть ТЗ со списком вопросов.

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

Если вопросов нет совсем, я бы задал их сам: «Как вы будете сдавать работу? Что мне нужно проверить перед подписанием акта?» Если в ответ звучит «да всё будет нормально», критерии приёмки придётся писать вам. После приёмки пригодится и чек-лист UX-аудита: по нему можно пройти по готовому сайту глазами посетителя.