Профессия "бизнес-аналитик". Кто такие бизнес-аналитики и как стать БА?

Профессия "бизнес-аналитик". Кто такие бизнес-аналитики и как стать БА?

Бзнес-аналитик: кто это такой, и что делает?

Речь пойдет о бизнес-аналитиках в IT.

Существует много мнений насчет того, кто это такой - бизнес-аналитик. Не во всех IT компаниях есть бизнес-аналитики. Некоторые компании берут в аналитики кого-то из старых сотрудников, например, QA, и не всегда понимают, чего ожидать - и что это за профессия бизнес-аналитик, как измерить эффективность работы такого человека (имеют только отдаленное представление, иногда путают с системным аналитиком). Также, на разных проектах, бизнес-аналитики могут заниматься различными активностями. Ещё, активности могут зависеть от взрослости команды и профессиональности менеджера.

Давайте разберемся, кто же это, бизнес-аналитик :)

Официальное определение из BABOK 3.0:

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

Звучит достаточно сухо - задач бизнес-анализа достаточно много. Ниже я распишу те задачи, с которыми бизнес-аналитик сталкиваются достаточно часто.

Обязанности бизнес-аналитика:

  • выявление и анализ бизнес-потребностей заказчика;
  • анализ и документирование бизнес-процессов;
  • предложения решений проблем/способов удовлетворить потребности бизнеса и коммуникация по утверждению лучшего;
  • анализ, написание и управление требованиями;
  • общение со стейкхолдерами (заинтересованными лицами);
  • взаимодейтвие с командой разработки и UI/UX дизайнерами.

Сколько зарабатывают бизнес-аналитики?

Профессия бизнес-аналитик в ИТ - достаточно прибыльная. Зарплаты аналитиков в Украине, согласно зарплатным опросам https://dou.ua/:

Согласно рассылке https://djinni.co/ :

Для подписчиков внизу статьи добавлю разбивку предложений зп для БА за последние полгода, зависящую от опыта и уровня английского. Так что подписывайтесь (или логиньтесь, если уже подписаны :) ).

Как мы видим, уровень зп неплохой. Зависит он чаще от опыта, знаний, самостоятельности, эффективности работы. Опытный - не равно тот, кто любую абстрактную задачу возьмет и доведет до девелопмента. Для этого нужны и опыт, и знания, которые можно почерпнуть и из этого блога - подписывайтесь :)

Из чего состоит рабочий день бизнес-аналитика?

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

Что делает бизнес-аналитик? Не все активности повторяются изо дня в день, поэтому, для примера, возьмем неделю, а не день.

Photo by Jazmin Quaynor on Unsplash

Митинги

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

Photo by Chris Montgomery on Unsplash

Митинги с командой:

  • ежедневный стендап-митинг (stand up meeting, он же daily scrum) - это статус-митинг с командой разработки;
  • груминг (grooming/backlog refinement - презентация/обсуждение требований с командой, разбор бэклога продукта (требований));
  • короткие прояснения требований по запросу (для этого не обязательно "собирать митинг" - можно просто обсудить в чате);
  • выяснение деталей у команды разработки - можем ли мы реализовать требование, какое из решений лучше с архитектурной точки зрения, и т.п. (тоже не обязательно митинг - если вопросы мелкие или их мало - можно и в режиме чата);
  • брейншторминги (brainstorm sessions);
  • обсуждение дизайнов.

Митинги с заказчиками:

  • митинги для прояснения требований, обсуждения решений, дизайнов;
  • статус-митинги - это, можно сказать, stand up meeting, только для клиента - без команды и не обязательно каждый день. На нем происходит обсуждение прогресса, сложностей;
  • стратегические синки (от слова sync - синхронизация) для понимания/обсуждения стратегии/видения продукта - важные митинги, чтобы бизнес-аналитик видел big picture - понимал видение продукта и планы по его развитию, а не просто занимался юзер стори на следующий спринт;
  • демонстрация готовой функциональности.

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

Митинги с пользователями:

  • тестирование дизайнов/прототипов;
  • встречи с фокус-группами;
  • интервью;
  • приемочное тестирование (UAT - user acceptance testing).

Анализ и документирование требований

Это постоянные, ongoing, активности - всегда нужно анализировать фичи, готовить задачи разной детализации в бэклог. И, в зависимости от размера/стадии фичи, эти активности сильно отличаются.

  • иногда вам придется записывать высокоуровневые запросы "на потом" - например, нужно подумать над экспортом данных в эксель, фича приоритизирована на следующий квартал - поэтому в джиру/асану/трелло/что-то еще, бизнес-аналитик заводит требования с парой строк описания и ссылками на то, что может пригодиться. В качестве ссылок могут быть - письма, ссылки на документы, схемы бизнес-процессов. В качестве описание - от кого требование, какая его важность, и пара мыслей о фиче - например, можно дать возможность выбора пользователю включить в репорт данные Х (чтобы потом, когда бизнес-аналитик откроет задачу через месяц, можно было вспомнить контекст и знать, за что раскручивать клубок);
  • иногда, глубоко анализировать небольшую фичу, чтобы в скором времени отдать ее в разработку: на этом этапе, бизнес-аналитик использует техники анализа, которые считает подходящими для каждого конкретного случая. Он изучает документы, интерфейсы, рисует диаграммы, проводит интервью для уточнения деталей, определяет зависимости, проводит мозговые штурмы, оформляет требования в системе управления требованиям, (например, Confluence), и обязательно проверяет свои требования, используя характеристики качества. Чаще всего в результате этой деятельностиполучается юзер стори с приемочными критериями в Jira. На этом этапе часто уже известны мотивы для создания фичи, и фича - это уже результат анализа бизнес-процессов, собственно, какого-то бизнес-анализа, поэтому задачи данного этапа - иногда больше похожи на задачи системного аналитика, нежели бизнес-аналитика;  
  • иногда, работать над эпиком (грубо говоря, epic - это большая фича) -  прорабатывать его общую концепцию, вникать в его смысл - какое его предназначение (это нужно в любой задаче, но тут прям сильно нужно :)), делать описание/анализ бизнес-процессов, изучать конкурентов - есть ли у них такая же или подобная функциональность, валидировать гипотезы с пользователями - вдруг это нужно только заказчику, а пользователям не нужно (или нужно, но в другом виде), прототипировать. На этом этапе тоже используются техники анализа, и даже больше, чем на предыдущем, из-за неизвестности и большого количества вариантов выбора. Обычно, начинающие бизнес-аналитики таким не занимаются, или занимаются под "присмотром" более опытного коллеги.
Photo by Campaign Creators on Unsplash

Управление требованиями

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

Какие активности включает в себя это управление? Перечислю основные из них:

  • заносить в специальную таблицу/дополнительный инструмент/бэклог, где фичу потом приоритизируют, или рассматривают в контексте изменений части продукта (модуля). Например: к вам приходят запросы средней приоритетности, и до них пока не дошли руки. Но вот в один прекрасный день вы получаете запрос на изменение целого модуля системы. И тогда все запросы, которые к нему относились и копились, помогут вам сделать этот модуль лучше, или подскажут, с каким пользователем необходимо пообщаться, чтобы узнать о его опыте использования данного модуля (раз он просил изменения, то явно пользуется же :) );
  • оценивать влияние изменения (даже мелкая правка может запустить цепную реакцию и переделок может оказаться больше, чем казалось бы. Например, изменение бизнес-процессов одного отдела, влияет на изменение бизнес-процессов другого, или, добавление определенного поля на регистрации влечет за собой изменение профиля пользователя;
Photo by Bradyn Trollip on Unsplash
  • работать с командой, чтобы оценить трудозатраты и правильно приоритизировать запросы, понимать, насколько "дорогим" будет данное изменение.

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

Примерный календарь БА (при работе на 1 проекте)

Что должен знать бизнес-аналитик?

Требования могут отличаться в зависимости от уровня специалиста, могут зависеть от специфики проекта и компании.

Основываясь на личном опыте, который я получила работая на различных проектах последние 3 года (когда были более-менее "устаканившиеся" процессы), хочу выделить следующее:

  • Как правильно писать требования. Эта большая тема включает в себя правильное формулирование, знание видов документов, умение выбрать степень детализации, и выбрать вид атрефакта, который нужен в конкретной ситуации. Например, писать большую подробную спецификацию, или достаточно видения проекта. Или, писать юз кейсы (use case), или использовать юзер стори (user story). Как показывает практика - чаще всего будет хватать юзер стори (это наиболее часто используемый тип требований, который используют в современных проектах), так что обязательно научитесь их писать, независимо от того, начинающий ли вы специалист или БА (или менеджер) с большим опытом написания сложных спецификаций. Иногда из-за неумения их писать вас могут не взять на проект/в компанию.
  • Как проводить митинги - тоже отдельная тема, митинги бывают разные, для начала хватит понимания, что такое груминг и как его вести, а также, как проводить клиентские митинги - интервью, регулярные статус-звонки, и демонстрацию функциональности.
Photo by Leon on Unsplash
  • БА важно понимать, как происходит разработка - цикл разработки проекта, знать основные технические термины и понятия, понимать методологии разработки, фреймворки, например, скрам (scrum).
  • Как выявлять требования - какие существуют техники выяления требований, как их эффективно применять. Для начала изучить самые популярные - интервью, ревью документов, анализ интерфейсов.
  • Техники анализа - серьезные помощники при выполнении обязанностей бизнес-аналитика в ИТ. Включают в себя: анализ стейкхолдеров, диаграммы (моделирование бизнес-процессов, диаграммы потока данных, диаграмма сущность-связь (ERD), диаграмма способов применения (Use Case Diagram) и т.д.), прототипирование, составление словарей данных, SWAT и т.д. Применяются они не одновременно все, а в зависимости от анализируемой задачи и ее сложности. Иногда говорят, что UML диаграммы - это больше прерогатива системного аналитика, нежели бизнес-аналитика - но нет, любой аналитик может столкнуться с необходимостью "переварить" фичу, используя разные нотации. Также диаграммы помогают презентовать решения клиентам или помогают команде разобраться с задачей. Лично я очень люблю диаграммы за то, что они дают быстрое понимание процесса. Презентовать диаграмму гораздо эффективнее, быстрее и проще, нежели текст - в диаграмме сразу видны логические ошибки, например.
  • Правила и способы управления бэклогом.
  • Последний, но не по важности, пункт - английский. Даже если ваши клиенты говорят с вами на родном языке, много литературы и статей, которые помогут вам развиться как специалист, публикуются на английском языке. Иногда их переводят, но зачастую далеко не все, и позже, чем они появляются. Также, уровень зарплат и возможность попасть в международную компанию, напрямую зависят от знания языка. Как и возможность продвигаться по карьерное лестнице - в международных компаниях существуют определенные ограничения - нельзя занимать определенные должности со слабым английским. А в мелких часто просто нет вакансий для бизнес-аналитика, где язык не нужен. Почитать, как быстрей выучить язык, можно здесь.

Что должен уметь бизнес-аналитик?

Уметь применять знания, описанные выше :)

Далее - навыки/характеристики/качества, необходимые для того, чтобы удержаться, закрепиться и быстро развиваться:

  • умение общаться - для бизнес-аналитика софт-скилы - это хард-скилы, то есть, то, что вот прям должно присутствовать. Нужно уметь общаться с клиентами (как устно, так и письменно), проводить переговоры, уметь правильно аргументировать, убеждать клиента, доносить свои мысли до него и команды. Уметь объяснять команде, какие проблемы решает продукт/фича, и из споров о решении проблемы уметь выделить классное решение. Иметь хороший уровень эмпатии, чтобы чувствовать собеседника - это полезно не только в обычных разговорах, но и при интервьюировании - чувствовать, что именно является проблемой, как копнуть поглубже, чтобы дойти до сути.
  • аналитическое мышление - для того, чтобы не принимать на веру все, что говорят, определять настоящие проблемы и предлагать решения, анализировать сложные системы и процессы. Иногда клиент просит не то, что ему нужно - просит определенное решение проблемы, но саму проблему не называет. Тут-то бизнес-аналитик и включает "подозреваку" и начинаем узнавать, а в чем, собственно, боль - и думать, вдруг есть решения удобнее/дешевле/быстрее. В этом и заключается задача бизнес-анализа - в умении мыслить критически, искать еорень проблемы и помогать бизнесу. Или, например, когда бизнес-аналитик (или системный аналитик) презентует фичу команде или определенному разработчику, иногда слышен ответ "это сделать нельзя". Тут тоже помогает критическое мышление. Нельзя такой ответ брать на веру, нужно узнать, в чем причина "отказа", что именно нельзя, и почему. Иногда в самом диалоге находится решение, а иногда оказывается, что нельзя сделать какую-то ненужную мелочь из решения, и от нее можно безболезненно отказаться. Иногда оказывается, что разработчик не знает, как это сделать, а другой разработчик знает. Иногда (тоже бывает, все мы люди) - разработчик просто не хочет реализовывать сложную задачу, и уходит в отрицание (иногда это даже неосознанно).
  • умение учиться - бизнес-аналитик учится постоянно. Помимо изучения новых инструментов и подходов, аналитик вникает в разные бизнесы, бизнес-процессы, домены. Проекты отличаются друг от друга, и иногда от бизнес-аналитика ждут, что он будет экспертом в доменной области. Например, без понимания банковской сферы, сложно попасть в банковский проект. Поэтому, меняя проекты вместе с доменами, нужно уметь быстро погрузиться в новый. Попав в любой в проект, нужно понять, какие бизнес-проблемы он решает, чего хотят пользователи, что нужно рынку.
  • лидерство - как ни крути, бизнес-аналитик - это лидерская должность. Даже если есть продакт-менеджер и проджект-менеджер, и лиды различных направлений. Бизнес-аналитику нужно уметь мотивировать людей для того, чтобы они хотели создавать, а не просто выполняли задачи. Команды намного счастливее, когда считают, что делают что-то полезное, зная, что их ожидает впереди. Рассказать, в чем ценность продукта, делиться стратегией - это и будет вашей задачей.
Photo by KOBU Agency on Unsplash
  • управление временем - еще один важный навык. Бизнес-аналитик очень часто параллельно решает несколько задач, работая в несколько потоков. Обрабатывает новые запросы, анализирует задачи - готовит их к новому спринту, готовит задачи для эстимации, отвечает на вопросы, проясняет технические ограничения с командой, проверяет гипотезы с пользователями. Поэтому важно уметь все грамотно спланировать и распределить, чтобы не "утонуть" в обилии задач.
Photo by Glenn Carstens-Peters on Unsplash

Как стать бизнес-аналитиком в ИТ?

Есть несколько путей.

Самые органичные -

  • человек из IT свитчится в аналитики - это может быть QA, разработчик, менеджер, системный аналитик, саппорт специалист. В этом случае, у этого человека уже есть какой-то опыт и понимание разработки, жизненного цикла, основных терминов, процессов и т.д. В этом случае иногда можно стать сразу мидл (middle) специалистом (или мидл-) -  он на каком-то уровне уже выполнял задачи из бизнес-анализа, понимает процессы и технические моменты.
  • человек с опытом в определенной сфере (например, инвестиции, банкинг, телекоммуникации) становится джуниор бизнес-аналитиком в ИТ. (обычно джуниор, т.к. нужно еще познать процессы, понять, как разрабатываются продукты, как взаимодействовать в командой разработки и клиентами, технические ньюансы и техники анализа). Обычно такой свитчер - кладезь полезной информации о домене, бизнес-процессах в определенной сфере, и "валидатор" идей и решений внутри команды. Очень полезно обладать такой информацией, и не всякий бизнес-аналитик с опытом в ИТ может осилить задачи, которые осилит доменный эксперт.

Вообще, БА могут стать целеустремленные люди из любых отраслей (и любого возраста, опыт тут даже плюсом будет :) )

В следующих статьях я буду раскрывать каждый из пунктов этой статьи более детально, так что подписывайтесь на обновления и ... становитесь Бизнес-Аналитиками!

А вот и обещанная разбивка статистики по зарплатам (только для подписчиков)