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

Оказывается Яндекс продает мебель из своих ПВЗ на Я.Маркете. Можно использовать в эклектичных интерьерах, например, в каком-нибудь баре 😎

Сравнение данных по екому от Data Insight и Flocktory

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

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

Данные Flocktory vs. Data Insight за 2022 год

Выручка -35% +38%
Количество заказов -48% +64%
Средний чек +25% -16%

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

Данные Flocktory
Данные Data Insight

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

И не казалось, что тут что-то про сердечные ритмы и здоровье.

User Story

Это формат записи пользовательских требований вида:

Как [персонаж] я хочу [действие], чтобы [ценность для персонажа]

Оcновные особенности формата

1. Формат понятен человеку с любым уровнем подготовки;

2. В качестве актора может быть указана роль (клиент, менеджер, администратор) или подробно описанный пользователь (Иван, 32 года, офисный работник, женат, есть ребенок, собака и машина).

3. US описывает потребности клиента, что особенно актуально в екоме;

4. Несмотря на простоту, формат часто используют слишком буквально и получают однообразный список требований вида «я как пользователь хочу …»;

5. В последний блок вместо ценности для пользователя нередко записывают дополнительные требования из-за чего их легко потерять или реализовать неверно: Как администратор системы я хочу просматривать детальную страницу заказа, чтобы отменить или повторить его»;

6. Нередко забывают, что US — это формат именно пользовательских требований, на формулировании которых аналитическая работа не заканчивается.

К вопросу о нейминге