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