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

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

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

Человек-оркестр

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

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

Аналитик как переводчик

Аналитики, если их правильно привлекать к разработке ИТ‑продуктов, являются незаменимыми и ценными звеньями одной цепи. Представьте себе эту цепочку в виде четырех взаимосвязанных колец:

БИЗНЕС — БИЗНЕС‑АНАЛИТИК — СИСТЕМНЫЙ АНАЛИТИК — ТЕХНИЧЕСКОЕ РЕШЕНИЕ.

Хотя в разработке участвуют и другие специалисты, эта связь между заказчиком и решением очень важна. Аналитики — это как профессиональные «переводчики», устраняющие коммуникационные разрывы. Заказчик говорит на языке бизнеса, а «технари» общаются в коде. Аналитики, свободно владеющие обоими языками, должны досконально понимать и другие диалекты.

Компетенции бизнес-аналитика

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

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

Основные навыки бизнес‑аналитика:

• Глубокое изучение проекта, выяснение первоначальных представлений заказчика

• Определение проблем бизнеса, потенциальных решений и возможностей роста

• Эффективные навыки ведения переговоров и сильная эмпатия

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

• Понимание цикла разработки программного обеспечения и согласование желаний с осуществимостью

Для того, чтобы лучше понять обязанности бизнес‑аналитика, рассмотрим пример. Допустим, у нас имеется SaaS‑продукт, в котором клиенты охотно принимают пробный период, что приводит к расширению базы пользователей. Однако коэффициент конверсии в платящих клиентов остается удручающе низким. По окончании пробного периода пользователи неоднократно создают новые бесплатные учетные записи (правда знакомо), что закрепляет цикл неоплаты. Какие действия может предпринять бизнес‑аналитик в данном случае?

Во‑первых, он может провести анализ рынка, чтобы определить оптимальную цену на продукт. Хотя достижение показателей ежедневных активных пользователей (DAU), еженедельных активных пользователей (WAU) и ежемесячных активных пользователей (MAU), превышающих 50%, заслуживает похвалы, лишь часть пользователей конвертируется из‑за высокой стоимости продукта. Гипотеза: повышение потенциала дохода, основанного на объеме, за счет снижения цены может оказаться полезным. Изучение возможности введения более доступных уровней подписки может стимулировать клиентов к переходу с базовых тарифных планов, подобно использованию тактики «кнута и пряника».

Во‑вторых, предложите маркетинговые стратегии, включающие персонализированный опыт, ретаргетинг и рассылку сообщений в приложении. Это все были «пряники».

В‑третьих, предложите внедрить «кнут» — технические средства защиты для ограничения повторных бесплатных регистраций. Специфика реализации таких гарантий будет определена системным аналитиком, с которым мы сотрудничаем.

Компетенции системного аналитика

Роль системного аналитика плавно переходит от роли бизнес‑аналитика. Его основная задача заключается в обеспечении связи между потребностями бизнеса и техническими решениями. По сути, это перевод понятий из области коэффициентов конверсии, пожизненной ценности (LTV) и коэффициентов кликов (CTR) в область обеспечения качества (QA), пользовательского опыта (UX) и разработки кода. Как и в любом другом переводе, сохранение основной сути имеет первостепенное значение.

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

Рабочий процесс системного аналитика включает в себя следующие этапы:

• Анализ бизнес‑целей, сформулированных бизнес‑аналитиком

• Разбивка требований бизнес‑аналитика на функциональные и нефункциональные компоненты

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

• Определение задач разработки и оценка соответствия решения спецификациям проекта

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

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

Предположим, выбранные решения связаны с маркетинговой персонализацией и техническими ограничениями на регистрацию. Системный аналитик доработает их, уточнив процедуры CRM, улучшив веб‑аналитику, внедрив SMS‑подтверждения и IP‑ограничения. Эти требования затем излагаются в четком и последовательном документе о технических задачах (ТЗ) для руководителя проекта и команды разработчиков.

Таким образом, для системного аналитика необходимыми являются следующие навыки:

• Знание различных подходов к разработке программного обеспечения и архитектурных паттернов

• Способность эффективно переводить бизнес‑концепции в технические термины

• Опыт создания комплексных технических спецификаций для разработки и модернизации технических решений

• Уверенное владение методами системного анализа и практикой обеспечения безопасности программного обеспечения

• Знакомство с SQL и его практическое применение в средах баз данных и СУБД

• Знание различных стилей интеграции приложений, включая принципы работы брокеров сообщений, API и шин

• Владение навыками использования CASE‑средств, таких как UML и BPMN

Ключевые различия между этими должностями

Теперь поговорим о том, чем же принципиально отличаются друг от друга данные специалисты. Бизнес‑аналитик (BA) выявляет и определяет требования заинтересованных сторон, вникает в бизнес‑процессы клиентов и совместно формулирует задачи. Они анализируют и доводят эти задачи до сведения всех заинтересованных сторон.

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

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

Подход, основанный на Т‑образных навыках, может еще больше усугубить неоднозначность ролей, поскольку он предполагает подготовку разносторонних специалистов, обладающих знаниями из смежных областей. Более того, другие ИТ‑роли, например, связанные с бизнес‑процессами, данными, UX, безопасностью, финансами и вебом, также включают в себя должность «аналитика». Иногда менеджера по продукту могут даже называть аналитиком продукта. Тем не менее, эти роли остаются разными.

Заключение

В заключении хотелось бы предостеречь от совмещения ролей. Хотя на первых порах многопрофильный аналитик может быть очень эффективным, за этим часто следуют выгорание и текучесть кадров. Это служит предостережением как для соискателей, так и для работодателей: универсальные специалисты встречаются редко. Точно так же, как не стоит искать в одном человеке Ruby‑разработчика и UI/UX‑дизайнера, так и здесь.

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

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

Чтобы не оставаться в догадках и научиться четко разделять роли, управлять рисками и видеть проект системно — загляните на эти открытые уроки:

• 7 августа в 20:00 — Как бизнес-аналитик управляет рисками при разработке IT-продукта

• 25 августа в 20:00 — Бизнес-аналитик и Системный аналитик: зачем нужны 2 роли

Комплексное погружение в бизнес-анализ и системный анализ для работы на IT-проектах вас ждет на специализации OTUS.