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