10
лет в электронной коммерции
8 800 3020 886
ГлавнаяБлогЗачем составлять требования к сайту перед разработкой технического задания

Зачем составлять требования к сайту перед разработкой технического задания

В разработке и реализации сайта электронной коммерции участвуют пожелания клиента и техническая реализация проекта. В идеале желания должны совпасть с технической реализацией, чтобы клиент получил то, что в итоге хотел. Для этого нужно выяснить все пожелания, собрать все требования с клиента и описать их в техническое задание (ТЗ) для разработчиков. А для того, чтобы создать ТЗ существуют такие вещи, как: бриф, описание бизнес требований, функциональных требований.

В интернете вы можете найти много статей с примерами различных требований. В разных компаниях эти документы могут называться по-разному. Их содержание и порядок создания также могут отличаться, так как каждая компания описывает свой опыт взаимодействия с клиентами.
Разберемся, что есть что? Как клиенту объяснять, что нужно сделать? Какие требования собрать перед встречей с разработчиками и быстрее начать разработку сайта электронной коммерции.

Что такое бизнес требования? Пример

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

Они включают в себя:

  • Информацию и данные о компании. Сфера деятельности бизнеса, основные конкуренты, клиенты, основные преимущества, бизнес документы, регулирующие деятельность отрасли.
  • Информация о целевой аудитории. Необходимо четко представлять, кто будет посетителями сайта. Сегментируйте аудиторию на группы, используя данные о поле, возрасте, регионах проживания, привычках и увлечениях. Это позволит понять вам, с какой целью посетители будут заходить на сайт.
  • Информация о конкурентах. Какой функционал предлагает сайт конкурентов, какие у них преимущества, какое ценообразование и ассортимент.
  • Уточнить цель создания сайта. Это может быть расширение географии продаж, увеличение охвата клиентов и, как следствие, увеличение конверсии и прибыли.
  • Определить метрики эффективности сайта. По каким показателям вы поймете, что сайт помогает добиться вашей бизнес цели. Это могут быть: ROI, коэффициент конверсии, количество лидов и т.д.

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

Бизнес требования важно выяснить в самом начале жизненного цикла проекта, чтобы команда бизнеса и команда разработчиков находились на одной волне. Они служат основой для определения подходящей платформы, объема задач и разработки плана проекта.

Без четкого понимания бизнес требований бюджет проекта может выйти из-под контроля или привести к неправильным результатам.

Какие задачи помогают решить описанные бизнес требования

Четко сформулированные бизнес требования решают следующие задачи:

  1. Помогают команде бизнеса и разработчикам четко понять, что должно получится на выходе, какая основная цель сайта.
  2. Помогают определиться в дальнейшем с killer features, без которых цель сайта будет недостижима.
  3. Помогают приоритизировать последующие требования, чтобы грамотно расходовать бюджет.
  4. Помогают экономить время и бюджет на разработку, чтобы предупредить большое количество доработок.
сбор требований

Что такое функциональные требования? Пример

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

Важные разделы сайта, для которых необходимо описать функциональность

Разберем кратко разделы на примере сайта по бронированию путешествий и отдыха:

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

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

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

4. Каталог услуг: он предполагает разные разделы сайта, по которым пользователь будет перемещаться в зависимости от цели визита. Его ширина и глубина ограничивается вашими бизнес целями и требованиями.

5. Карточка товара/услуги: предполагает описание услуги с фотографиями, отзывы, доступные даты, стоимость, возможность связаться, оставить заявку, приобрести/забронировать услугу.

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

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

8. Страница оплаты: после того как пользователи выбрали услугу, они должны быть перенаправлены на безопасную страницу оплаты, где они могут ввести свои платежные данные для завершения процесса бронирования.

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

10. Личный кабинет пользователя: в нем пользователь может указывать персональную информацию, выбирать удобные способы оплаты, привязывать карту, просматривать историю покупок/бронирований.

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

Как составить функциональные требования?

Один из подходов составления функциональных требований состоит в том, что вы описываете поведение пользователей в зависимости от его роли на сайте. Это так называемые пользовательские истории, или user story.

User story отвечают на три вопроса:

  1. Кто пользователь?
  2. Какое действие он хочет выполнить?
  3. Для чего это ему?

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

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

Что такое техническое задание?

Техническое задание (ТЗ) –- это документ, в котором описываются все требования и характеристики для создания сайта. Этот документ составляют разработчики на основании тех требований, которые собраны с заказчика. В нем описывается технический функционал для бэкэнда, фронтэнда, все интеграции, требования к системе и инфраструктуре, а также подходы к тестированию продукта.

В нашей практике встречается два варианта развития событий:

  1. У клиента есть бизнес и функциональные требования. Тогда эти требования компания-разработчик уточняет и трансформирует в ТЗ.
  2. У клиента нет сформированных требований. Тогда проводится бриф, описываются бизнес задачи, функциональные требования и составляется ТЗ.

Составленное ТЗ согласовывается с клиентом и является неотъемлемой частью договора.

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

Почему описывать требования нужно?

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

Основные ошибки при составлении требований к проекту

1.Расплывчатое или чрезмерно подробное описание требований. Формулировки должны быть понятны и обозначать одно и тоже для всех участников, а результат можно оценить или измерить.

Например:

  • “Понятный чекаут для покупателя” — расплывчато, а оценка может быть только субъективной.
  • “Чекаут для покупателя должен содержать шкалу прогресса” — в этом случае ясно, что необходимо сделать разработчикам.

2. В требованиях не закладываются автоматизации и возможности для масштабирования. Часто это происходит по причине экономии средств, но по итогу могут привести к неверно выбранному решению.

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

3. Чрезмерное погружение в описания и многочисленные правки. Это не значит, что правок не должно быть совсем. Но доводя до идеала описание требований, вы должны помнить о цели. А конечная цель — запустить проект. Четкие бизнес требования помогут не отклонится от курса.

4. Выбор не подходящего технического решения. Выбор и внедрение любых сервисов и интеграций должно быть обоснованным решением, а не пожеланием заказчика. Главная задача сервисов — соответствие всем требованиям заказчика и техническая совместимость с платформой, на которой создается сайт.

Выводы

1. Для того чтобы подготовиться к встрече с разработчиками, следует заранее продумать и составить бизнес требования к проекту. Сформулированные бизнес требования помогут определиться с основным функционалом для запуска сайта, бюджетом и сроками разработки.

2. Описывая функционал сайта по разделам, воспользуйтесь методом User Story. Он подразумевает описание поведения пользователя, в зависимости от его роли на сайте. Помните о том, каких целей должны достичь пользователи сайта.

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

4. В составлении функциональных и бизнес требований может помочь аналитик. Он сделает единое видение и понимание работы сайта для заказчика и разработчиков.

Получите консультацию специалиста по вашему проекту

  • Содержание
Команда Cart-Power
Все статьи автора
Чек-лист будет отправлен на указанный Вами e-mail
Пожалуйста, заполните форму