Техзадание на сайт, которое помещается на одну страницу

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

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

Почему одной страницы достаточно

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

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

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

Что должно быть на этой странице

Вот что стоит написать. На каждый пункт — несколько предложений, не больше.

О компании и продукте. Чем занимаетесь, что продаёте, чем отличаетесь. Для застройщика — какой проект, класс жилья, сколько очередей, на каком этапе продажи.

Кто покупатели. Не «все, кому нужна квартира», а конкретнее: семьи, которые переезжают из съёмного жилья, покупатели для сдачи в аренду, люди из других городов. Откуда они приходят и что для них важно при выборе.

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

Что есть сейчас. Текущий сайт, если он есть, и что в нём не устраивает. Какие материалы готовы: логотип, фирменный стиль, тексты, фотографии, визуализации, планировки.

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

Конкуренты. Два-три проекта, с которыми вас сравнивают покупатели, и чем вы от них отличаетесь — или хотели бы отличаться.

Ограничения. Срок, к которому нужен запуск, и почему именно он. Ориентир по бюджету. Кто со стороны компании принимает решения и согласует работу.

Чего писать не нужно

Некоторые вещи в первом документе скорее мешают:

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

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

Примеры помогают больше описаний

Два-три сайта, которые нравятся, и один-два, которые не нравятся, с короткими пояснениями часто дают подрядчику больше, чем страница рассуждений о стиле. Они не обязательно должны быть из вашей отрасли. Важно объяснить, что именно цепляет: как устроен подбор, как подана информация, какое ощущение оставляет сайт. Если есть материалы, которые покупатели уже видели, — буклет, презентация проекта, рекламные макеты, — их тоже стоит приложить.

Что происходит дальше

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

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

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

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