Вновь приглашаем на открытый курс «Основы екома»!

🗓️ 16 и 17 мая с 15:00 до 19:30

За 2 дня расскажем, как устроена современная электронная коммерция. Поговорим об основных понятиях, трафике, витрине, операциях и ИТ-решениях.

💵Участие бесплатное
🧑🏻‍🏫 Любой уровень подготовки
👥 Формат на выбор: онлайн и оффлайн

Онлайн
Курс пройдёт в формате прямой трансляции на Youtube, ссылку отправим за день.

Офлайн
Лично встретимся в нашем лектории по адресу г. Зеленоград, корпус 322а, 2-й этаж.
Приходите к 14:45, чтобы не опоздать к началу.

👉 Записаться

До встречи 👋

Наконец-то электронные чаевые добрались до заправок. Можно больше не покупать сникерсы ребятам, которые в -30 заправляют машины.

Cash on delivery (COD) больше не проблема

До недавнего времени считалось, что Россия (как и вся Восточная Европа) — регион, где люди предпочитают постоплату. McKinsey связывает это с тем, что покупатели боятся мошенничества с картой или товарами.

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

Но больше нельзя считать, что приверженность клиентов COD тормозит развитие екома в России.

Просто потому, что они уже не привержены. Хотя опрос Яндекса и показыает, что пользователи любят оплату картой при получении, компании больше не расценивают этот способ как обязательный, а форсят предоплату. То есть то, что было Must have, стало Would be nice.

P.S. Интересно, что функции обычно мигрируют в обратную сторону из Killer feature в Would be nice, а затем в Must have.

P.P.S Скрины из исследования Яндекса

Headless

#кусочекзнаний #определения

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

Обычно говорят про headless CMS (система управления контентом сайта), но, вообще говоря, любое бизнес-приложение может поддерживать headless-подход. Например, все сервисы платфомы Ensi — безголовые (именно так русифицируют термин).

Обновляем «Кусочки екома»🤩

Кстати, мы тут начали делать облачные сервисы. Приглашаем потестировать облачный товарный поиск для екома 👇

Мы стартовали открытое бета-тестирование Ensi Cloud Search!

Как принять участие:
- Оставьте заявку на странице: https://ensi.cloud/search
- Вам придет письмо с инструкцией
- Пришлите нам необходимые данные

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

Калининградская версия сложной рекламной конструкции

Ensi на Ecom Expo 👋

Друзья, завтра и послезавтра ждем вас на нашем стенде H6.4 в Экспоцентре, где можно обсудить автоматизацию екома и нашу платформу

Еком — это потребительская область, поэтому требования к IT-системам электронной коммерции могут формулироваться на разном уровне: начиная от описания вида «добавьте в первый экран все важные кнопки», до sequence-диаграмм запросов и модели данных сервисов.

Разберем основные типы требований:

👇 👇 👇

— Бизнес-требования и бизнес-правила.
— Пользовательские требования.
— Функциональные требования.
— Нефункциональные требования.

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

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

— Мы должны научиться эффективно обрабатывать онлайн-заказы и возвраты наших покупателей.

Для описания БТ используют разные форматы: от формализованного подхода под названием BRD (Business Requirements Document), до интуитивно понятных эпиков и фичей. Больше примеров

Бизнес-правила

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

Примеры: Требования по соблюдению закона 152-ФЗ «О персональных данных», Требования к фискализации, Требования к маркировке

Пользовательские требования

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

— Как администратор системы я хочу просматривать детальную страницу заказа, чтобы ознакомиться с составом заказа

1. Пользователь — это не только конечный покупатель, но и, например, менеджер по обработке заказов.

2. В отличие от бизнес-требований пользовательские описывают не просто какие-то абстрактные «хотелки», а конкретные «хотелки» в конкретной системе.

3. Так как это описание функций через интерфейс, для формулирования ПТ используются популярные форматы User story, Use case и Customer journey map.

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

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

1. Администратор в подразделе «Скидки», раздела «Маркетинг» переходит к созданию скидки.
2. Администратор заполняет данные в форме создания скидки. При некорректном заполнении полей, отображаются ошибки валидации.
3. Администратор просматривает список привязанных товаров.

Пример ФТ 👆 для функционального блока «Скидки» в Ensi.

1. Для описания ФТ проще всего использовать конструкцию:
«Субъект + Действие + Объект + Условие».

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

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

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

Например: требования к производительности, к надежности, к масштабируемости, к безопасности.

1. К НФТ часто относятся недостаточно внимательно или вообще забывают про них.

2. Созданная без учета НФТ система может работать слишком медленно или быть недостаточно безопасной.

Черные методы продвижения на WB