В задачи бизнес-аналитика входит:

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

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

Таким образом, бизнес-аналитик объясняет ИТ-инженерам на понятном им языке, что необходимо сделать для решения задачи бизнес-заказчика.

Подробнее о задачах бизнес-аналитика и способах их решения мы поговорим в главе 2.

Если бизнес-аналитик отвечает на вопрос «что нужно сделать?», то системный аналитик определяет, «как сделать то, что нужно заказчику, используя информационную систему». Задача системного аналитика – предложить варианты реализации требований, полученных от бизнес-аналитика, с использованием той или иной информационной системы.

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

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

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

Как следует из названия, продуктовая аналитика посвящена разработке и развитию какого-либо продукта. Продукт – понятие многогранное. Например, в банковской сфере это может быть кредит или пластиковая карта с кешбэком. В промышленности продуктом будет автомобиль, станок или слиток металла.

Говоря о продуктовой аналитике, мы будем рассматривать термин «продукт» с точки зрения ИТ. Иными словами, продукт для нас – это мобильное приложение, информационная система или онлайн-сервис. Например, продуктовый аналитик может заниматься созданием и развитием интернет-магазина.

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

При работе с цифровыми продуктами главным инструментом продуктового аналитика становится A/B-тестирование. Чтобы лучше понять его суть, рассмотрим упрощенный жизненный цикл нового продукта или сервиса.

Стадия 1. «А может, не надо?»

Задумав новый сервис, «который перевернет мир», важно спросить себя: действительно ли существует необходимость в подобном сервисе? Аналитик отвечает на десятки вопросов типа:

 Каковы перспективы сервиса с учетом тенденций развития отрасли?

 Почему мы считаем, что сервис понравится потребителям?

 Нет ли похожих сервисов у конкурентов? Если есть, то каковы их успехи? Если сервис «не взлетел», то по какой причине?

Если ответы на эти вопросы даны и энтузиазм не испарился, можно переходить к этапу 2.

Стадия 2. Пилотный проект

На втором этапе аналитик должен определиться: как дешево проверить, что от внедрения нового сервиса или продукта будет польза? На этом этапе проектируются и запускаются примитивные прототипы – простые приложения, сайты и т. п.

Стадия 3. А/В-тестирование и вилка решений

Суть А/B-тестирования лучше пояснить на примере.

Допустим, у вас есть интернет-магазин. Вы хотите добавить ему пару новых функций – например, красивую кнопку оформления заказа и 3D-обзор товара. Для удобства назовем их «Функция 1» и «Функция 2» соответственно. Текущее состояние магазина без новых функций будет служить контрольным показателем. Итак, вы создаете несколько версий магазина: только с «Функцией 1», только с «Функцией 2» и с обеими «Функциями» сразу, а потом демонстрируете новые версии сайта фокус-группам пользователей.

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

На данном этапе возникает так называемая вилка решений. Перед началом работ вы должны однозначно определиться с критериями принятия решения. Иными словами, организаторы тестирования «на берегу» договариваются: если новая функция приведет к увеличению интересующего показателя на X % – значит, работы по внедрению продолжаются. А если функция понизит интересующую метрику на Y% – значит, от функции отказываемся и придумываем что-то еще.