Как оформить функциональные и бизнес-требования к сайту электронной коммерции?
Чтобы составить Техническое Задание на разработку ПО, вам необходимо определить, какие задачи стоят перед вашим интернет-магазином или маркетплейсом, и каким образом будет организовано взаимодействие с посетителями. Чтобы получить такое понимание, нужно учесть интересы целевой аудитории и тех, кто будет работать с сайтом внутри компании. Другими словами, потребуется оформить требования.
Функциональные и бизнес-требования, закрепленные в документе, помогают лучше оценить сроки выполнения работ и бюджет, а также избежать необходимости исправлять ошибки в случае недопонимания между заказчиком работ и разработчиком. Давайте рассмотрим, что представляют собой функциональные и бизнес-требования, как правильно их оформлять, и как передавать исполнителю работ.
Что такое бизнес-требования
Бизнес-требования представляют собой обобщенные задачи ко всему проекту. Их нужно писать понятно для руководителей и других заинтересованных лиц компании, которые не знают всей специфики веб-разработки.
Что входит в бизнес-требования
- Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
- Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
- Анализ конкурентов
- Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
- Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах) . Ускорить обработку заказов через автоматизацию работы менеджеров.
- Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 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 тысяч посетителей в день.
Рекомендации заказчику, пишущему требования
Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:
- Просмотр истории визитов;
- Добавление еще одного визита;
- Выбор посещения зубного кабинета;
- Просмотр деталей визита (число, время, кабинет, лечащий врач) ;
- Редактирование информации о визите;
- Удаление визита.
Заказчик, выполняющий функции бизнес-аналитика внутри компании, может использовать следующие виды сбора требований:
- Анкетирование. Сюда можно отнести “Бриф на разработку сайта”. Это анкета со списком основных требований к сайту.
- Интервью. Такой способ используется в основном для получения уточнений по конкретному вопросу или требованию.
- Мозговой штурм. Участники генерируют множество идей и вариантов решений, развивая.
- Запустить голосование
- Привлечь эксперта
Выводы
- Завершите сбор требований до формирования спецификации на разработку магазина. Так вы вложите меньше усилий и средств и уменьшите время создания разработки.
- Ставьте задачи конкретно. Так вероятность создания магазина, выполняющего все возложенные на него задачи, выше. Всегда дополняйте конкретные функциональные обобщенными бизнес-требованиями. Так, совместно с разработчиком, вы сможете выработать оптимальный путь решения задачи
- Участвуйте в сборе требований. Только заказчик имеет глубокое представление о специфике своего бизнеса. В случае с некрупной организацией, имеет смысл нанять сторонних специалистов или обратиться к команде разработчика. Какой бы путь ни был выбран, принимайте активное и непосредственное участие на всех этапах. Так вы гарантируете, что все особенности бизнеса будут учтены.