Готовое техническое задание не обязательно. На первом разговоре полезнее не документ на десятки страниц, а ясный контекст: для кого создаётся сайт, какое решение должен принять посетитель и что бизнес сделает после его обращения. Ниже — набор вводных, которого достаточно, чтобы перейти от идеи к осмысленной оценке.
Главный принцип: описывайте не желаемые блоки страницы, а ситуацию пользователя и результат, который должен получить бизнес.
Начните с бизнес-задачи
Формулировка «нужен современный сайт» ничего не говорит о его назначении. Один сайт должен собирать квалифицированные заявки, другой — объяснять сложную услугу, третий — разгружать менеджеров, четвёртый — получать органический трафик из поиска.
Ответьте письменно на четыре вопроса:
- Что сейчас происходит без нового сайта?
- Где именно теряются время, заявки или доверие?
- Какое действие посетителя будет считаться успехом?
- По какому показателю через два–три месяца станет понятно, что решение работает?
Хорошая формулировка выглядит так: «Посетитель из поиска должен понять различия между четырьмя услугами, выбрать подходящую и отправить заявку с описанием задачи». Такая цель уже подсказывает структуру, контент и аналитику.
Опишите аудиторию и её контекст
Персонаж вроде «мужчина 25–45 лет» почти бесполезен. Для интерфейса важнее ситуация, в которой человек открывает страницу.
- Что он уже знает о компании и услуге?
- Сравнивает ли несколько исполнителей или впервые изучает тему?
- Какой риск его останавливает: цена, сроки, непонятный процесс, безопасность?
- Кто принимает решение и кто будет пользоваться результатом?
- С какого устройства и источника он, скорее всего, придёт?
Если аудиторий несколько, не пытайтесь одинаково подробно обслужить каждую на главной. Выберите приоритетную, а для остальных предусмотрите отдельные страницы или понятные маршруты.
Нарисуйте путь до и после заявки
Сайт не заканчивается кнопкой «Отправить». Опишите весь маршрут простыми шагами:
- Человек видит объявление, рекомендацию или результат поиска.
- Попадает на конкретную страницу.
- Изучает доказательства, условия и процесс.
- Оставляет заявку или переходит в мессенджер.
- Менеджер получает данные и уточняет задачу.
- Заявка фиксируется в таблице, CRM или другой системе.
Так становятся заметны необходимые интеграции и поля формы. Например, если менеджеру для первого ответа всегда нужен адрес существующего сайта, это поле лучше запросить сразу. Если лиды теряются между почтой и таблицей, одной красивой формой проблема не решается.
Соберите материалы и источники доверия
До оценки полезно составить перечень того, что уже есть. Не обязательно приводить всё в идеальный вид — достаточно дать доступ или указать ответственного.
- логотип, фирменные цвета и шрифты;
- описания услуг и ответы на частые вопросы;
- реальные кейсы, цифры и отзывы, которые разрешено публиковать;
- фотографии команды, продукта или процесса;
- юридическая информация и политика обработки данных;
- действующий домен, аналитика и доступы к сервисам;
- примеры сайтов, которые нравятся, с пояснением почему.
Последний пункт особенно важен. Фраза «нравится минимализм» допускает десятки трактовок, а комментарий «здесь удобно сравнить четыре направления и сразу виден следующий шаг» объясняет полезное решение.
Определите границы первой версии
Первая версия должна решать одну законченную задачу, а не содержать все идеи на несколько лет. Разделите требования на три группы:
- обязательно к запуску — без этого основной сценарий не работает;
- желательно — повышает удобство, но может появиться после проверки основы;
- позже — гипотеза, для которой пока нет данных или контента.
Для сайта услуг обязательными обычно становятся посадочные страницы, форма, адаптивность, базовое SEO, аналитика и юридические страницы. Личный кабинет, калькулятор, мультиязычность и сложные анимации стоит включать только при понятной пользе.
Зафиксируйте реальные ограничения
Ограничение — не помеха проекту, а важная часть решения. Заранее укажите:
- дату, связанную с запуском рекламы, мероприятием или сезоном;
- ориентир бюджета или допустимый диапазон;
- системы, которые нельзя заменить;
- требования к размещению данных и доступам;
- людей, которые согласуют содержание и дизайн;
- кто будет обновлять сайт после запуска.
Если дата жёсткая, меняется не только график, но и состав первой версии. Честное сокращение объёма безопаснее обещания реализовать всё к сроку без резерва.
Не принимайте технические решения заранее
Не требуется самостоятельно выбирать фреймворк, CMS, базу данных или хостинг. Эти решения зависят от частоты обновлений, интеграций, требований к скорости и модели поддержки.
Также не нужно рисовать каждый экран до обсуждения структуры. Прототип полезен после того, как понятны пользовательский маршрут и приоритеты. Иначе он закрепляет случайные решения и делает изменения психологически дороже.
Проверьте результат первого разговора
После разбора задачи у вас должны остаться не только впечатления, но и конкретные артефакты:
- цель и приоритетная аудитория;
- карта основных страниц или экранов;
- границы первой версии;
- перечень материалов и интеграций;
- список открытых вопросов и рисков;
- этапы работы и способ приёмки;
- диапазон оценки с указанными допущениями.
Если разработчик называет точную цену до этих уточнений, выясните, что именно входит в предложение. Одинаковое название «сайт компании» может скрывать совершенно разный объём контента, аналитики, интеграций и дальнейшей поддержки.
Чек-лист перед обращением
Для первого сообщения достаточно подготовить короткий ответ по шаблону:
- Чем занимается бизнес и кому помогает.
- Какая проблема должна исчезнуть после запуска.
- Какое действие должен совершить посетитель.
- Какие страницы или функции точно нужны.
- Какие материалы и системы уже существуют.
- Есть ли обязательная дата и диапазон бюджета.
Этих вводных достаточно, чтобы начать предметный разговор. Полное ТЗ формируется уже в процессе анализа, когда решения можно связать с задачей, а не с предположениями.