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

Зачем ТЗ заказчику?

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

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

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

Объём документа — две-три страницы. Документ длиннее для небольшого проекта никто не читает целиком, включая автора.

Что обязательно описать в ТЗ?

Цель, аудиторию, структуру, целевое действие и критерий готовности. Ни один из этих пяти блоков не требует технических знаний.

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

Аудитория. Кто приходит, откуда и с каким вопросом. Люди из поиска и по рекомендации ведут себя по-разному, турист с телефона и закупщик с рабочего ноутбука тем более. Хватит двух абзацев, но конкретных: возраст, язык, устройство, что человек уже знает о вас, когда открыл сайт.

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

Целевое действие. Что человек должен сделать: отправить форму, написать в WhatsApp, позвонить, оставить телефон, оформить заказ. Одно основное действие на страницу. Здесь же запишите, куда приходят заявки: почта, Telegram, CRM.

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

Дополнительно перечислите, чего в проекте нет: наполнение каталога, написание текстов, продвижение после запуска, версия на другом языке. Раздел «не входит» предотвращает больше конфликтов, чем все остальные вместе.

Чего в ТЗ быть не должно?

Дизайна, описанного словами, технических решений без причины, «сделайте красиво» и списков «на будущее».

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

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

«Сделайте красиво» и «как у конкурентов, только лучше». При приёмке ни то ни другое не проверить, поэтому спор гарантирован.

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

Как собрать структуру сайта?

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

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

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

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

Если клиентов и переписки ещё нет, потратьте десять минут на поиск: посмотрите, что спрашивают в тематических чатах и на форумах по вашей теме.

Формулировки, которые снимают споры

Спор снимают формулировки, которые можно проверить в день сдачи:

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

Что делать, если писать ТЗ некогда?

Сделать минимальную версию на одну страницу или заменить документ разговором либо прототипом. Начинать вообще без письменной фиксации не стоит.

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

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

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

Без письменной фиксации через три недели обе стороны будут искренне помнить разное, даже если никто никого не обманывает. ТЗ — содержательная часть договора, и часто их удобно держать одним документом; что ещё должно быть в договоре, я описал в статье о договоре на разработку сайта. Как готовность материалов влияет на срок, есть в статье «Сколько делается сайт».