Бизнес-аналитик и Менеджер проекта, Системный аналитик ,Product Manager, Business Analyst - профессия, преимущества и недостатки, зарплаты

Привет, Вы узнаете о том , что такое бизнес-аналитик, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое бизнес-аналитик, менеджер проекта, системный аналитик, product manager, business analyst , настоятельно рекомендую прочитать все из категории Профессии и специальности.

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

Международный Институт Бизнес-Анализа (IIBA, International Institute of Business Analysis) определяет бизнес-аналитика «как посредника между заинтересованными лицами для сбора, анализа, коммуницирования и проверки требований по изменению бизнес-процессов, регламентов и информационных систем. Бизнес-аналитик понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие организации достичь своих целей».

В консалтинговом бизнесе бизнес-аналитиком называется высшая позиция для консультанта.

День бизнес-аналитика отмечается 24 июня.

IIBA отмечает всемирный день бизнес-анализа 1-го ноября

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

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

Product Management и Business Analyst достаточно родственные профессии. Управление продуктом определенно включает в себя создание требований для продукта (функциональных и нефункциональных), что является прямой обязанностью бизнес-аналитика.

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

На что тратит время бизнес аналитик?

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

Примерное распределение работы можно описать так:

• Встречи — 20%
• Документация — 30%
• Работа с командой — 25%
• Тестирование — 5%
• Командировки — 5%
• Саморазвитие — 15%

А вот точное количество часов за последние 3 месяца:



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

Теперь давайте рассмотрим каждый пункт подробнее.

Virus neutralizer

Game: Perform tasks and rest cool.1 people play!

Play game

Встречи

Начнем с самого главного — с того, чего, собственно, и начинается бизнес-анализ — с деловых встреч, куда отнесем и встречи с клиентами, и внутренние собрания с командой.

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

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

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

Работа с документацией

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

Вот всего лишь несколько примеров того, с чем приходится регулярно сталкиваться:

• Спецификация требований — превращение вольного полета мысли клиента в структурированный документ, четко описывающий, что необходимо сделать команде. Позже именно этот документ утверждается с клиентом и ложится в основу выполняемого проекта.
• Изменения требований (Change Request) — процесс, инициируемый клиентом в том случае, когда требуются изменения в продукте уже после начала разработки или даже после ее окончания. Документ описывает, какая часть системы и как должна быть модифицирована, содержит оценку выполнения работы по времени и стоимости.
• Инструкция пользователя и другие обучающие материалы — очевидно, что после окончания проекта, необходимо написать документацию для клиента, в которой будет описано, как пользоваться системой, даны советы и ответы на частые вопросы.

Для работы с документацией у каждого аналитика есть свой любимый инструментарий — кто-то любит рисовать диаграммы, а кто-то пишет полотно текста в Word. В любом случае я бы советовал вам ознакомиться с основами UML, BPMN, понятиями User Stories и Acceptance Criteria. Они наверняка повстречаются у каждого работодателя.

Работа с командой

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

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

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

Тестирование

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

От бизнес-аналитика ожидается выполнение так называемых User Acceptance Tests — тестов принятия пользователем. Никто не требует писать автоматизированные скрипты или проверять размеры и цвета кнопочек на сайте. Все, что требуется — представить себя пользователем и воспользоваться готовым продуктом. Проверить, не возникает ли каких-либо неудобств при его использовании, работает ли в общем система так, как хотел пользователь, нету ли явных ошибок или несоответствий требованиям.

Важный момент! Нужно помнить, что аналитики проводият все время с командой, участвуют в обсуждениях, знают о разных «хаках» и узких местах программы. В то же время, выполняя тесты, мы должны понимать, что клиент не обладает этими знаниями, он не знает, куда нужно нажимать, а куда — нет. Об этом говорит сайт https://intellect.icu . Необходимо абсолютно непредвзято оценить систему и указать на все ошибки разработчикам — чем раньше удастся их выявить, тем проще будет исправить.

Саморазвитие

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

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

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

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

• Быть хорошим переговорщиком (коммуникатором). Он должен уметь понять собеседника, объяснить ему сложные вещи из мира IT, убедить и переубедить клиента в эффективности разного рода решений, при необходимости — сгладить конфликтные ситуации;
• Разбираться в технической стороне разработки ПО;
• Обладать хотя бы базовой, но основательной экспертизой в юзабилити и проектировании интерфейсов;
• Понимать принципы движения денежного потока и работы с финансами — чтобы иметь возможность до конца точно соблюсти интересы клиента относительно продукта, если разрабатывается коммерческое ПО;
• Иметь прикладные навыки из области системного анализа: составление технической документации, специфических диаграмм и схем.

Какие бывают аналитики?

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

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

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

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

Бизнес-аналитик выясняет потребности клиента и обосновывает необходимости реализации проекта. После этого на основании выявленных бизнес-требований и пользовательских требований клиента аналитик определяет границы проекта.

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

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

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

Заказать консультацию по бизнес-анализу для вашего программного продукта можно здесь.

От своих специалистов мы ожидаем следующих знаний и компетенций:

Вследствие разделения зон ответственности, системные и бизнес-аналитики оформляют различные наборы документов. В результате работы бизнес-аналитика будет создан Vision and Scope document, обозначающий границы проекта, будут задокументированы бизнес-требования (BRD) и составлены спецификации требований (SRC).

Системный аналитик представит концепцию IT-решения (Software Design Document) с указанием платформы реализации проекта, технологии, в том числе языков программирования, интерфейсов взаимодействия.

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

Чем отличаются бизнес аналитик от системного аналитика?

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

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

Чем отличаются бизнес аналитик от проект менеджера?

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

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

некторые сичтают что

• если я иду на собеседование то «на ПМ или БА мне все равно я все умею».
• или я управленец затыкающими горящие проектные позиции «универсальными PM-BA».

Давате рассмотрим и сравним их зоны отвественности и профессиональные требования

Зоны ответственностей Бизнес-аналитика:

• Business Analysis Planning and Monitoring (запланировать свою будущую работу в рамках проекта и постоянно следить за тем, что она делается эффективно).
• Enterprise Analysis (изучить вас, понять ваши проблемы и их потенциальные решения).
• Requirements Elicitation (понять в деталях, что вы хотели бы получить в рамках выбранного решения)
• Requirements Analysis (осмыслить на досуге полученную от вас информацию).
• Requirements Management and Communication (записать четко сформулированную суть решения, донести до вас и исполнителей и не дать вам впихнуть в оговоренные деньги / сроки «еще одну мелочь»).
• Solution Assessment and Validation (выбрать наилучшее решение на этапе их сравнения, прикинуть, подойдет ли оно в вашей ситуации, и впоследствии изучить и оценить, насколько оно вам помогает).

Планирование продукта. Роадмаппинг (roadmapping)

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

Типичный роадмап — это набор фичей, наложенных на временную ось. Обязательно указаны зависимости между фичами, дана их оценка по какому-то из методов (ценность, условная стоимость реализации, или характеристика модели Кано). Хорошо бы атрибутировать фичу по функциональному и структурному компоненту.

Зоны ответственностей Менеджера проекта:

• Project Integration Management (общее планирование и управление ходом проекта)
• Project Scope Management (следить за тем, что по вашему решению ведутся верные и только нужные работы).
• Project Time Management (следить за тем, чтобы все укладывалось в срок).
• Project Cost Management (следить за рамками выделенного бюджета).
• Project Quality Management (следить за качеством работ и обеспечивать надлежащий уровень качества решения).
• Project Human Resource Management (набрать народ в команду, обучить, внимательно следить за каждым в отдельности – в общем, все, что связано с ключевым проектным ресурсом – людьми).
• Project Communications Management (определить, кто и с кем общается на проекте, правильно ли общаются, нужная ли информация и своевременно ли распространяется – все, что связано с обменом проектной информацией).
• Project Risk Management (усердно думать о том, что может «внезапно» пойти не так, и как с этим бороться).
• Project Procurement Management (обеспечение команды всем необходимым извне – столы, стулья, печеньки, компьютеры и т.п.).
• Project Stakeholders Management (понять, кто вообще имеет отношение к проекту с какой-бы то ни было стороны, как они могут «нагадить» (а на самом деле, любое влияние их и на них) и тщательно ими управлять, чтобы проект шел, как задумывалось).

Разработка продукта. Управление командой разработчиков

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

У продакт-менеджера не так. Продакты принимают детальное участие в разработке:

• постоянно разъясняют и уточняют требования;
• участвуют в разработке и утверждении тест-кейсов;
• занимаются триажем багов;
• работают со стейкхолдерами команды разработки.

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

Запуск продукта

Когда продукт создан, его необходимо правильно запустить в “эксплуатацию”. Это go-to-market plan, различная документация, миграция пользователей, онбординг существующих пользователей, развертывание и т.п. Здесь много технической работы, но много и организационной, и многие вопросы решает продакт-менеджер.

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

Сюда же можно отнести и вывод продукта или его частей с рынка (end-of-life). Для все еще популярных продуктов эта процедура может растянуться на многие месяцы.

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

Virus neutralizer

Game: Perform tasks and rest cool.1 people play!

Play game

Отслеживание показателей качества продукта

Продукт мало поставить — нужно поддерживать его в “живом состоянии”, а это:

• отсутствие багов;
• довольные пользователи;
• стабильная или возрастающая прибыль от продукта;
• отслеживание новых технологий и новых конкурентов.

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

Работа с короткими итерациями и MVP

Продакт-менеджер сильно ориентирован на то, чтобы получить максимум результата с наименьшими затратами. Назовем это MVP. В этом есть большое количество плюсов:

• возможность изменить требования для дальнейшей разработки;
• заявить себя на рынке раньше конкурентов;
• доказать жизнеспособность продукта и получить финансирование от бизнес-ангелов;
• остановить разработку продукта и заняться чем-то другим.

Обычно, сложно спрогнозировать успех продукта и “попадание в требования”. Надежный индустриальный подход — расширять продукт небольшими итерациями с анализом успеха каждой такой итерации.

Требования к Бизнес-аналитику и Менеджеру проекта

Рассмотрим ключевые soft skills, необходимые этим ролям. Я специально не фокусируюсь на профессиональных знаниях и навыках (например, для БА это могут быть тех-писательство, визуальное моделирование, прототипирование пользовательских интерфейсов, знание техник и процессов работы с требованиями и т.п.), т.к. они, как следует из областей знаний выше – кардинально разные.

Общие требования:

• Коммуникативность.
• Обучаемость, способность эффективно управлять своим временем / рабочим окружением, стрессоустойчивость и прочие вещи, одинаково важные для всех проектных ролей.

Специфические требования (несомненно, все, что ниже, желательно иметь обеим ролям, но с таким же успехом их желательно иметь и разработчикам, тестировщикам и всем иным участникам проекта):

Требования к Бизнес-аналитику:

• Аналитическое мышление
• Системное мышление, включая умения как вдаваться в детали, так и абстрагироваться на более высокие уровни.
• Техническая грамотность, достаточная для постановки задачи и уразумения «а что же мы вообще тут делаем».
• В некоторых случаях – доменная экспертиза.

Требования к Менеджеру проекта:

• Навыки решения проблем.
• Навыки управления людьми, организаторские способности, лидерство, влияние
• Широкий кругозор по отношению к разработке ПО и базовые знания сути работ каждой отдельно взятой роли.

Заключение

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

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

Исследование, описанное в статье про бизнес-аналитик, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое бизнес-аналитик, менеджер проекта, системный аналитик, product manager, business analyst и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Профессии и специальности

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.