Кто такой бизнес-аналитик в it, как стать бизнес-аналитиком?

Кто такой бизнес-аналитик? Что делает бизнес-аналитик?

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

Почему важно понимать, кто такой ба?

Существует много мнений насчет того, кто это такой - бизнес-аналитик в айти (кто такой БА). Для тех, кто думает, как стать бизнес-аналитиком (войти в ит через бизнес-анализ или перейти в БА из другой ИТ профессии), в этой статье я расскажу, какие обязанности БА, чтобы вы имели представление, что изучать.

Профессия бизнес-аналитик сейчас достаточно востребована в ИТ.

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

Без понимания основных задач бизнес-аналитика, очень сложно определиться с учебным планом. Давайте разберемся, кто же это, бизнес-аналитик :)

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

Бизнес-аналитик - это

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

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

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

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

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

Профессия бизнес-аналитик в айти - достаточно прибыльная.

Зарплата бизнес-аналитика в Украине, согласно зарплатным опросам https://dou.ua/:

Сколько платят бизнес-аналитикам, согласно рассылке https://djinni.co/ :

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

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

Для тех, кто хочет получить профессию бизнес-аналитика в it, перейти в БА из QA, для junior бизнес-аналитиков, которые быстро хотят стать мидлами, или кому интересен бизнес-анализ я и веду этот блог - подписывайтесь :)

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

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

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

Митинги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Как правильно писать требования. Эта большая тема включает в себя правильное формулирование, знание видов документов, умение выбрать степень детализации, и выбрать вид атрефакта, который нужен в конкретной ситуации. Например, в начале проекта - писать большую подробную спецификацию, или достаточно видения проекта. Или, когда проект уже в работе, писать юз кейсы (use case), или использовать юзер стори (user story). Как показывает практика - чаще всего будет хватать юзер стори (это наиболее часто используемый тип требований, который используют в современных проектах), так что обязательно научитесь их писать, независимо от того, начинающий ли вы специалист или БА (или менеджер) с большим опытом написания сложных спецификаций. Иногда из-за неумения их писать вас могут не взять на проект.

• Как проводить митинги - тоже отдельная тема, митинги бывают разные, для начала хватит понимания, что такое груминг и как его вести, а также, как проводить клиентские митинги - интервью, регулярные статус-звонки, и демонстрацию функциональности. Если очень кратко - у митинга должна быть агенда, на митинг нужно звать только тех, кому нужно присутствовать и прикладывать агенду к приглашению. На самом митинге будьте открыты к новой информации, но пытайтесь модерировать митинг так, чтобы он не превратился в балаган или ушел не в то русло (хотя, если это митинг по выяснению требований, иногда полезно уйти не в то русло, чтобы узнать о настоящей проблеме клиента/пользователя). После митинга, желательно выслать решения, принятые на митинге и экшен айтемы, которые договорились сделать. Иначе, потом будет сложно найти истоки решений или кто-то из отвественных за экшен айтем может сказать "а мы не договаривались, что за это отвечаю именно я".

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

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

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

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

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

• управление временем - еще один важный навык. Бизнес-аналитик очень часто параллельно решает несколько задач, работая в несколько потоков. Обрабатывает новые запросы, анализирует задачи - готовит их к новому спринту, готовит задачи для эстимации, отвечает на вопросы, проясняет технические ограничения с командой, проверяет гипотезы с пользователями. Поэтому важно уметь все грамотно спланировать и распределить, чтобы не "утонуть" в обилии задач, и распределить свое время так, чтобы сделать задачи своевременно.

Более подробно описала необходимый набор умений, и как их развивать здесь.

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

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

Но есть 2 самых органичных пути -

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

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

• пытаться брать на себя обязанности бизнес-аналитика, если вы уже в ит и есть возможность (обычно она есть, не обязательно ее "просить" официально, просто подключайтесь, и вас, возможно, заметят. А не заметят - будет опыт, который можно показать на собеседовании в другую компанию)
• и тем, кто в ит, и кто нет - читать книги про бизнес-анализ в айти, собрала топ 5 книг здесь - https://www.thebagirl.com/knighi-dlia-biznies-analitikov/
• более детально разобраться в обязанностях бизнес-аналитика и научиться их выполнять (желательно на курсе, или с ментором, чтобы была обратная связь о том, насколько все правильно - и в выполнении задач, и в построенном пути развития) - это подойдет и тем, кто в ит, и кто еще нет
• после обучения (курсы/книги), мониторить вакансии на популярных сайта с вакансиями, правильно обновив свой профиль в LinkedIn
• иногда крупные компании запускают бесплатные образовательные программы - можно попробовать податься, и после курсов лучших студентов берут на работу (в любом случае, это будет еще один шаг в обучении - бесплатный, но к нему уже нужно быть готовыми, то есть иметь знания, т.к. на такие курсы большой конкурс)
• если есть возможность - попытаться поучаствовать в чьем-то проекте - это может быть проект в какой-то группе по интересам, реальным проектом в компании, где работают ваши знакомые, стартапом, которому нужна помощь - обычно, это не оплачивается, но бывает всякое)
• штурмовать компании - ходить на интервью, собирать обратную связь и "подтягивать" слабые места, пока не получите приглашение на работу
• последнее, но не менее важное - если найдете ментора - он/она может вас направлять/давать дз/давать обратную связь/советовать что-то из своего опыта (опытные бизнес-аналитики иногда подрабатывают менторством).

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

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