Бывает, что проект только стартовал и задачи системного и бизнес-аналитика выполняет один человек. Но если в команде работают оба специалиста, задачи у них разные. Разберём, чем они отличаются.
Бизнес-аналитик отвечает за процессы, которые связаны с использованием продукта. Например, разбирается, как повысить количество заказов или снизить количество пользователей, которые удаляют приложение. Его задача — исследовать проблему или запрос клиента, определить потребности бизнеса и предложить заказчику эффективное решение, которое принесёт прибыль.
Системный аналитик отвечает за проектирование решения, которое устранит проблему или поможет решить запрос клиента. Он знает, как работает или может работать продукт, что нужно сделать, чтобы новая функциональность появилась, а всё остальное в продукте не сломалось. Чтобы всё в итоге работало, как было задумано, пишет спецификацию требований, создаёт задачи для команды разработки. Помогает определить, какие задачи нужно сделать первыми.
Допустим, нужно сделать новую функцию — уведомление о заказе, которое будет приходить на почту. Бизнес-аналитик так сформулирует задачу: «Настроить отправку писем с информацией о статусе заказа на почту клиента». Сюда же он может добавить, как часто должны приходить эти письма.
Системный аналитик определит, какие письма, когда и кому нужно отправлять, какую систему рассылки стоит использовать. Составит шаблоны писем, определит, какие данные туда нужно подставлять. И перейдёт к техническим деталям: какую нагрузку должен выдерживать почтовый сервер и как должны быть распределены режимы отправки писем в зависимости от часового пояса. Эта информация поможет разработчику, когда он приступит к своим задачам.
Бизнес-аналитик участвует во всех этапах разработки продукта — от идеи до развития продукта. На основе требований от заказчика и пользователей готовит документ бизнес-требований. Он описывает, как должен работать продукт с точки зрения бизнеса. Общается с системным аналитиком и технической командой, чтобы уточнить требования.
Когда продукт разработан и протестирован, бизнес-аналитик проверяет, соответствует ли результат бизнес-требованиям, и презентует результат заказчикам. На этапе развития общается с пользователями и составляет список доработок. Начинается новый цикл разработки — уже по новым требованиям.
Системный аналитик присоединяется к проекту на более поздних этапах, когда уже сформулированы бизнес-требования. Он переводит эти требования с языка бизнеса на язык разработки, продумывает, как их реализовать. Так получается ещё до начала разработки понять приблизительный объём работ и возможные сложности. При необходимости — изменить требования. На этапе разработки и тестирования системный аналитик следит, чтобы продукт в итоге работал так, как было задумано.
Обычно системный аналитик подключается к проекту, когда бизнес-требования уже готовы и пора делать документацию для технической команды
Софтскилы бизнес-аналитика и системного аналитика мало отличаются
Работа системного аналитика подойдёт тем, кто готов поломать голову над сложными задачами и работать с разными уровнями абстракции. В одном и том же проекте часто приходится погружаться в незначительные проблемы конкретного пользователя и одновременно понимать глобальную идею бизнеса.
Бизнес-анализ — для тех, кто готов работать с большими объёмами информации. Бизнес и пользователи не приходят с готовыми требованиями, а чаще делятся идеями, ожиданиями или ощущениями. Аналитику предстоит разобрать этот клубок информации. Систематизировать, найти утверждения, которые противоречат друг другу, и выяснить, как всё работает в реальности.
По жёстким навыкам аналитики тоже пересекаются. Чем больше опыта — тем больше общего. Опытный бизнес-аналитик больше погружён в технические особенности. И наоборот — зрелый системный аналитик глубже джуна разбирается в бизнесовой части проекта. Есть и специфические знания — актуальные либо для системного, либо для бизнес-аналитика.
В зависимости от команды и проекта требования к хардскилам могут меняться. Вот основные.
Разберём, как действуют аналитики, на примере приложения по доставке готовых наборов питания на неделю. Пользователи могут заказать их на сайте или в приложении. Особенность наборов — одинаковый состав. Даже если покупатель заказывает больший объём, по составу он будет такой же, как стандартный.
Приходит к бизнес-аналитику владелец продукта и говорит: «У нас упала конверсия и средний чек. Что можем с этим сделать?» Вот как поступит бизнес-аналитик:
● Выяснит, как формируется конверсия и средний чек. Для этого он почитает документацию и уточнит информацию у эксперта от бизнеса. Дальше — разберётся, как покупатели заказывают наборы питания, и опишет этот процесс с помощью блок-схемы.
Так выглядит описание процесса заказа от бизнес-аналитика
● Разберётся, в чём проблема. Бизнес-аналитик попросит аналитика данных выгрузить статистику переходов в другой сервис. Проанализирует сервисы конкурентов, к которым уходят пользователи. Ещё раз пообщается с пользователями, построит диаграмму и увидит, что большинство уходит, потому что состав набора нельзя менять.
● Найдёт решение. Бизнес-аналитик смотрит, как решают проблему конкуренты или похожие сервисы. После — проведёт мозговой штурм в команде, соберёт несколько вариантов решения и выберет подходящее. Например, разработать конструктор наборов питания.
● Адаптирует идею. Пользователи уходят на этапе выбора набора. Гипотеза бизнес-аналитика: если предложить пользователю элемент управления ингредиентами в карточке товара, то он чаще будет завершать покупку. Как именно будет выглядеть конструктор, можно проработать потом. На этом этапе важно зафиксировать, что опция настройки будет. Когда покупатель ей воспользуется, система отреагирует и пересчитает стоимость заказа. Дальше пользователь вернётся на страницу оформления заказа.
● Составит бизнес-требования. Документально зафиксирует задачу — нужно разработать конструктор. Опишет функции, которые будут доступны пользователям в этом конструкторе, добавит ограничения. Когда документ будет готов — передаст бизнес-требования команде системного анализа и обсудит их с системным аналитиком.
Так выглядит новая схема заказа, которую бизнес-аналитик включит в требования
В первую очередь нужно решить, как лучше менять состав набора: убирать продукты, менять на другие или добавлять новые. Допустим, системный и бизнес-аналитики решили, что лучше убирать продукты, которые не нравятся. Дальше действует системный аналитик:
● Задаёт дополнительные вопросы бизнес-аналитику.
● Общается с пользователями.
● Смотрит выгрузку с данными.
● Обсуждает задачу с разработчиками.
Предположим, что системный аналитик выяснил, что пользователи не любят орехи. Теперь он должен понять, как информация о том, что покупатель убирает из заказа орехи, попадёт к поварам, упаковщикам и менеджерам по закупкам. Второй момент — что добавить в интерфейс, чтобы пользователь мог убрать ингредиент. Для этого системный аналитик готовит wireframe — упрощенный прототип интерфейса.
Wireframe поможет дизайнеру понять, что нужно реализовать в интерфейсе. В этом случае — дать пользователю возможность в один клик убрать лишний ингредиент. На основе прототипа он отрисует полноценный макет (на скриншоте — справа)
Он погружается в техническую часть продукта и готовит всё, что поможет команде разработки внести изменения:
● Выясняет, как базы данных, CRM, интерфейс приложения и другие системы в продукте обмениваются информацией.
● Определяет, что нужно доработать, чтобы данные о пожеланиях пользователей попадали в систему.
● Создаёт диаграмму, которая отображает последовательность операций в системе. Так разработчики поймут, что изменить в интерфейсе и на сервере.
● Ставит задачи (тикеты) разработчикам в специальной системе — например, JIRA. Каждый тикет — это инструкция, где подробно описаны изменения и пользовательский путь. Так получится следить за процессом разработки и видеть, что уже сделано, а что — в процессе.
● Когда всё будет готово, вместе с тестировщиками проверяет, что новая функция в продукте работает.
● Готовит инструкции для техподдержки — чтобы они были в курсе новой функции и могли проконсультировать пользователей, если возникнут проблемы.
Сколько будет тикетов для команды разработки — зависит от сложности проекта. Добавление новой функции — большая задача, которую можно разбить на десятки или даже сотни тикетов для разработчиков, дизайнеров и тестировщиков
Когда продукт готов к запуску, бизнес-аналитик презентует его заказчику.
Советы экспертов
Читать также: