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

Итак, начнем.

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

• необходимо сподвигнуть клиента на добавление продукта в корзину;

• уменьшить время принятия решения по добавлению продукта в корзину.

Для удовлетворения этих требований маркетингом было предложено следующее решение:

• около корзины покупателя на сайте отображать рекомендуемый данному конкретному клиенту продукт для быстрого добавления в корзину (в один клик);

• рекомендуемый клиенту продукт выбирается на основе анализа его предыдущей активности;

• при этом при переходе в различные разделы сайта должен рекомендоваться тот продукт, который предлагается в этом разделе;

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

Собственно говоря, на основе этих пунктов любой начинающий аналитик без труда напишет юзер-стори. А вот дальше начинается самое интересное. Системному аналитику нужно понять, как эта юзер-стори ляжет на архитектуру существующего эксплуатируемого решения (в нашем случае — интернет-магазина), и предложить вариант реализации.

Текущая архитектура нашего интернет-магазина достаточно стандартна и является микросервисной. Используемый архитектурный подход — RESTful. На сайте крутятся скрипты vue.js, а различные сервисы на сервере реализуют логику, обрабатывают запросы от клиентов (тех самых скриптов).

Опираясь на текущее решение нашего интернет-магазина, было предложено следующее решение.

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

Скрипт vue.js на клиенте методом GET, передавая токен пользователя, запрашивает пул рекомендованных продуктов у данного сервиса.

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

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

Поскольку получать очередной продукт из пула рекомендованных продуктов нужно либо по желанию пользователя (нажатие кнопки «Обновить»), либо при переходе в очередной раздел сайта, либо по истечении срока жизни пула, который составляет от 5 минут до 24 часов в зависимости от категории продуктов, то запросы на получение пула с сервера могут существенно увеличить нагрузку на сервер. Поэтому было предложено (что вполне очевидно в данной ситуации) использовать кэширование на клиенте, что позволит не дергать сервер каждый раз для выбора следующего из пула продукта. Возможность использования кэширования — один из принципов применяемого нами архитектурного подхода RESTful (довольно-таки подробно и понятно про кэширование в REST написано тут).

Итак, общая архитектура решения стала прорисовываться. Осталось определить конечные точки нашего сервиса, передаваемые и получаемые параметры (в идеале – с их типами) и методы, которые скрипт будет использовать при обращении к ним.

Пулы рекомендованных продуктов, которые мы запрашиваем у сервера, а потом кэшируем на клиенте, зависят от раздела сайта, на котором находится покупатель. У нас 3 раздела. Соответственно, будет 3 конечных точки, которые мы назовем в соответствии с названиями разделов. Обращаться мы к ним будем, само собой разумеется, методом GET:

Получение пула рекомендованных продуктов для раздела сайта 1:

GET /RecommendedProductsService/WebsiteSection1/

Получение пула рекомендованных продуктов для раздела сайта 2:

GET /RecommendedProductsService/WebsiteSection2/

Получение пула рекомендованных продуктов для раздела сайта 3:

GET /RecommendedProductsService/WebsiteSection3/

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

{"WebsiteSection1Products":
 [
   {
     "color",
     "price",
     "size"
   }
 ]
}

Вот собственно и все. Теперь осталось все это грамотно изложить в конфлюенсе и можно отдавать в разработку.

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