{"id":13583,"url":"\/distributions\/13583\/click?bit=1&hash=e33bc0d3a37a74826169363c867d3f9f74deaa73040cb6145c82841335993467","title":"\u041d\u0435\u0439\u0440\u043e\u0441\u0435\u0442\u044c \u042f\u043d\u0434\u0435\u043a\u0441\u0430 \u043f\u0435\u0440\u0435\u0432\u043e\u0434\u0438\u0442 \u0432\u0438\u0434\u0435\u043e \u0432 \u043f\u0440\u044f\u043c\u043e\u043c \u044d\u0444\u0438\u0440\u0435","buttonText":"\u041a\u0430\u043a?","imageUuid":"135b72ce-4b43-5240-a9ca-242ab0616d40","isPaidAndBannersEnabled":false}
Simtech Development

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

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

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

Что такое бизнес-требования

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

Что входит в бизнес-требования

  • Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
  • Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
  • Анализ конкурентов
  • Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
  • Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах) . Ускорить обработку заказов через автоматизацию работы менеджеров.
  • Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 0,8% до 1,1%. Втрое увеличить количество вендоров. Поднять прямые онлайн-продажи без похода в магазин на 30% за полгода.
  • Пользовательские требования, то есть какую задачу должен решить пользователь на сайте. Купить шампунь, если речь идет о покупателе на сайте. Организовать доставку в другую страну, если пользователь — другая компания. Увеличить заработок для вендора. Иметь доступ только к заказам для менеджера по продажам и так далее.

Как бизнес-требования влияют на итоговый продукт?

Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

  • Требование А. Чтобы привлечь вендоров, владелец маркетплейса может предложить продавцам продолжать работать в собственных системах, интегрировав эти системы в маркетплейс. Вендорам не придется изучать интерфейс новой для себя системы, а владелец будет иметь все необходимые данные на своей платформе. Таким образом, способом реализации продукта станет интеграция с сервисами вендора по API.
  • Требование Б. По условию франшизы за определённой территорией может быть закреплен только один продавец / территориальный представитель, который будет работать с заказами покупателей из данного региона. Продажа товаров на данной территории другими представителями бренда запрещена по условиям договора. Способ реализации: определение геолокации покупателя, сортировка товаров и отображение актуальных остатков для конкретной локации, привязка покупателя к продавцу для дальнейших заказов.
  • Требование В. Владелец сайта-каталога (где можно просматривать товары, но нельзя покупать их) хочет создать интернет-магазин без перехода на новую платформу. В связи с этим, требуется внедрить функционал оформления заказа из платформы CS-Cart таким образом, чтобы для покупателя это выглядело «бесшовно», как будто он и не покидал существующий сайт. Способ реализации: интеграция технологии единого входа — SSO — при которой пользователь переходит из одной системы в другую без повторной аутентификации.

Почему нужно конкретно и четко оформить бизнес-требования?

Четкое формулирование бизнес-требований:

  • Позволяет управлять ожиданиями. Исполнитель узнает об ожиданиях клиента и может предложить лучшее решение
  • Помогает точнее выполнить оценку объема работ
  • Экономит время исполнителя и заказчика на процесс сбора требований

Вы можете использовать следующие уточняющие вопросы, помогающие и заказчику, и исполнителю структурировать информацию.

  • Опишите ваш продукт / услугу. Что будет являться товаром? Какие его характеристики? Как будет считаться его стоимость?
  • Роли пользователей (администратор, продавец покупатель) и какие действия может выполнять каждый из них? Есть ли какие-либо зависимости / ограничения?
  • CJM (путь покупателя по сайту) : какими будут действия покупателя по приобретению вашего продукта? Какие соответствующие действия должен будет выполнять продавец / администратор?
  • Регистрация пользователей: какие данные должны предоставить пользователи для регистрации?
  • Как будет выглядеть личный кабинет (профиль) покупателя для пользования услугой? Какие действия он сможет выполнять?
  • Понадобится ли интеграция со сторонними системами? Какими?

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

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

Примеры функциональных требований:

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

Нефункциональные требования. Важные особенности

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

Нефункциональных требований очень много. Вот некоторые из них.

  • Дизайн, UX/UI. Добавить дополнительную кнопку на чекауте. При переходе на страницу продукта пользователь видит все вариации продукта.
  • Требования к коду: cделать модификацию на JS, работа в репозитории клиента, использовать указанные заказчиком библиотеки при реализации модификации.
  • Настройка процессов непрерывной доставки и улучшения кода. CI и CD процессы призваны автоматизировать проверку и доставку разработанного ПО заинтересованным лицам.
  • Адаптация готовых решений. Вы можете выбрать готовые модули на маркетплейсе и с его помощью быстро закрыть какое-то функциональное требование, например, с помощью модуля Google Analytics Enhanced Ecommerce следить за событиями покупки на сайте прямо в админке платформы. Но бывают случаи, когда модули приходится дорабатывать под нужды конкретного проекта.
  • Контент. На продуктовые страницы добавить ссылки на юридические документы. Такое требование часто озвучивают владельцы немецких маркетплейсов.
  • Производительность сайта. Магазин должен выдерживать нагрузку в 1000 посетителей онлайн одновременно.

Кто собирает требования?

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

✔ Стороннее агентство, нанятое заказчиком

✔ Штатный аналитик заказчика

✔ Наша команда в рамках услуги “Проектирование”

Как происходит сбор требований?

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

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

Кто участвует в сборе требований?

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

  • Вендоры и отдел привлечения вендоров (для маркетплейсов)
  • Бухгалтерия (чтобы понимать, какие отчеты нужны, как проводить платежи)
  • Юридический отдел (если есть юридические ограничения, которые нужно учесть при создании интернет-магазина) .
  • Маркетинг (для реализации механики промо акций)
  • IT-отдел (при наличии, поскольку ему придется поддерживать готовую систему после сдачи работ)
  • Специалисты по безопасности
  • Сторонние эксперты

Вспомогательные материалы, предоставляемые заказчиком

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

  • Примеры конкурентов и реализации желаемого функционала
  • Блок-схема с описанием бизнес-процессов, функциональности
  • CJM-карта
  • Архитектурная диаграмма
  • Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя)
  • Дизайн-макеты
  • План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т. п.
  • Список ролей участников проекта и схема принятия решения
  • User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя) .

Какие ошибки допускают заказчики в ходе сбора информации?

  • Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
  • Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor) , но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart) . До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
  • Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который плохо выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.

Насколько детализированными должны быть требования?

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

  • Пример 1. Форма для регистрации интуитивно понятна.

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

  • Пример 2. Магазин не должен тормозить.

Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.

Рекомендации заказчику, пишущему требования

Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:

  • Просмотр истории визитов;
  • Добавление еще одного визита;
  • Выбор посещения зубного кабинета;
  • Просмотр деталей визита (число, время, кабинет, лечащий врач) ;
  • Редактирование информации о визите;
  • Удаление визита.

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

  • Анкетирование. Сюда можно отнести “Бриф на разработку сайта”. Это анкета со списком основных требований к сайту.
  • Интервью. Такой способ используется в основном для получения уточнений по конкретному вопросу или требованию.
  • Мозговой штурм. Участники генерируют множество идей и вариантов решений, развивая.
  • Запустить голосование
  • Привлечь эксперта

Выводы

  • Завершите сбор требований до формирования спецификации на разработку магазина. Так вы вложите меньше усилий и средств и уменьшите время создания разработки.
  • Ставьте задачи конкретно. Так вероятность создания магазина, выполняющего все возложенные на него задачи, выше. Всегда дополняйте конкретные функциональные обобщенными бизнес-требованиями. Так, совместно с разработчиком, вы сможете выработать оптимальный путь решения задачи
  • Участвуйте в сборе требований. Только заказчик имеет глубокое представление о специфике своего бизнеса. В случае с некрупной организацией, имеет смысл нанять сторонних специалистов или обратиться к команде разработчика. Какой бы путь ни был выбран, принимайте активное и непосредственное участие на всех этапах. Так вы гарантируете, что все особенности бизнеса будут учтены.
0
Комментарии
Читать все 0 комментариев
null