Менеджер проекта vs бизнес-аналитик: в чём разница между ролями

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

Менеджер проекта vs бизнес-аналитик: в чём разница между ролями

Руководитель отдела бизнес-аналитики Настя Романцова и руководитель отдела управления проектами Серёжа Шмаков рассказывают, как мы в red_mad_robot нашли свой путь, с какими проблемами столкнулись и что сделали, чтобы их решить.

Зоны ответственности бизнес-аналитика

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

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

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

  1. Проведение вторичных исследований рынка.
  2. Анализ потребностей целевой аудитории.
  3. Интервьюирование бизнеса для понимания целей и задач.
  4. Проработка верхнеуровневой архитектуры продукта.
  5. Проектирование бизнес-процесса разрабатываемой функциональности.
  6. Проработка функциональных и нефункциональных требований к системе.
  7. Подготовка необходимых диаграмм для команды разработки.
  8. Передача материалов командам дизайна и разработки.
  9. Проектирование спецификаций API.

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

Настя Попова, бизнес-аналитик red_mad_robot

Зоны ответственности проектного менеджера

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

Обязанности менеджера:

  1. Выбор подходящего фреймворка и адаптация производственного процесса под проект или команду.
  2. Выявление основных метрик проекта и управление ими.
  3. Повышение эффективности обмена информацией между участниками проекта, контроль за её систематизацией и тщательным сохранением.
  4. Формулировка цели вместе с командой и бизнесом, фокусировка команды на целях.
  5. Управление ожиданиями.
  6. Управление проектными рисками.
  7. Доведение всех задач проекта до результата.
  8. Критический взгляд на всё и регулярная рефлексия.

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

Алёна Аверина, младший менеджер проектов red_mad_robot

Как обязанности BA и PM распределены на рынке

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

  • отрасль и масштаб разрабатываемого продукта,
  • тип разработки (аутсорс или внутренняя разработка)
  • бюджет проекта.

Рассмотрим самые популярные существующие варианты.

Менеджер продукта

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

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

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

Проектный менеджер + системный аналитик + владелец продукта

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

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

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

Внешняя разработка

На аутсорсе есть различные варианты состава команд:

  1. Роли проектного менеджера и бизнес-аналитика объединяются для сокращения точек коммуникации и принятия решений. Впрочем, это больше свойственно небольшим аутсорс-продакшенам. Как только студия и количество проектов начинают расти, стартует поиск бизнес-аналитика или технического писателя, который готов и способен описывать требования.
  2. Обязанности распределяются на две роли для сохранения точечной экспертизы и качества работы.
  3. Присутствует только проектный менеджер. В таком случае обязанности по проектированию системы берёт на себя команда разработки или клиент.
  4. Присутствует только бизнес-аналитик. В таком случае в команде выделяется кто-то вроде скрам-мастера, а роль управленца берёт на себя владелец продукта или кто-то из бизнеса.

Какой вариант выбрали мы

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

Какие плюсы мы видим у такого подхода:

  1. Уделяем много внимания обучению и развитию цифровой зрелости команды на стороне клиента, умело управляем ожиданиями и результатом. Хватает времени и на команду.
  2. Можем быстро и эффективно решать сложные кейсы проектирования благодаря разделению ролей и фокусированию.
  3. Быстро нарабатываем экспертизу в новых типах продуктов, так как у аналитика есть возможность погрузиться в новую сферу.
  4. Есть возможность развивать глубокую экспертизу в подходах и инструментах — как проектного менеджмента, так и аналитики. В этом помогают отдельные скиллсеты для каждой роли и обучающие мероприятия в практиках менеджмента и аналитики.
  5. Все разработанные нами фичи тщательно описаны и задокументированы, а это повышает качество, сокращает косты на развитие и поддержку и упрощает передачу проекта в инхаус-команду клиента.
  6. Точнее и быстрее нанимаем сотрудников с подходящим скиллсетом и опытом.
  7. При необходимости легко масштабируем команду — менеджеры умеют это делать и могут выделить время на такие задачи.

С какими сложностями при этом столкнулись и как их решили

Пересечение зон ответственности

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

  1. Общая ответственность за функциональный состав продукта. Менеджер отвечает за сроки, очерёдность и общее качество выпускаемой функциональности продукта. А аналитик — за состав функций и связи между ними. На фоне этого возникают конфликты при поиске баланса между «сложно и круто» и «быстро и эффективно».
  2. Размытая ответственность за управление бэклогом продукта. Часто ответственность за бэклог оставалась размытой, либо мы со временем переставали придерживаться изначальных договорённостей. В итоге бэклог теряет актуальность, становится неудобным и непонятным для бизнеса. Как следствие, бэклог проекта мог потерять свою функцию управления траекторией достижения бизнес-целей.
  3. Похожие траектории развития — часто и PM, и BA растут в Product Owner. Аналитик и менеджер зачастую выбирают следующим шагом в развитии роль владельца продукта. Поэтому на проекте оба хотят прокачать похожие навыки — и тут возникают пересечения обязанностей и интересов. Это влияет на итоговое качество работы, ведь если за один и тот же процесс отвечают несколько людей, то в итоге за него не отвечает никто.

Как решили

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

Проблемы коммуникации с клиентом

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

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

Как решили

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

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

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

Ира Макарова, ex-руководитель отдела управления проектами red_mad_robot

Бонус: как понять, что мне ближе — BA или PM

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

Ты будущий проектный менеджер, если ты:

  1. Базово любишь людей, готов уделять время общению и решению конфликтов (куда без них). Стоит помнить, что 80% работы менеджера проектов — это коммуникация.
  2. Любишь организовывать людей на пути к чему-то светлому и доброму и доводить их до конечной цели. Да и вообще, ставишь цели и достигаешь их.
  3. Умеешь и любишь доводить дела до конца, а не только их начинать, загоревшись идеей.
  4. Требователен к себе и другим, не боишься быть плохим в чьих-то глазах, если нужно сделать непопулярную, но полезную для всех штуку.
  5. Обладаешь системным мышлением, чёткостью и обязательностью (сказал — ну что уж тут, сделал).
  6. Умеешь оставаться эффективным в условиях неопределённости, планировать, но при этом перестраивать план, когда это нужно. И сохраняешь при этом спокойствие.
  7. Берёшь на себя ответственность за успехи и неудачи, умеешь анализировать причины провалов или успешных начинаний и применять их в своём развитии.

Ты будущий бизнес-аналитик, если ты:

  1. Умеешь мыслить системно, находить неочевидные взаимосвязи и строить логические цепочки — большую часть времени аналитик проектирует работу продукта.
  2. Умеешь и любишь общаться, можешь найти подход к разным людям — аналитик часто проводит время в коммуникации с командой, клиентом и пользователями продукта.
  3. Умеешь искать и находить нестандартные и элегантные решения задач в жёстких рамках и ограничениях.
  4. Готов погружаться и изучать технические особенности разработки цифровых продуктов.
  5. Умеешь работать в неопределённости и понижать её уровень.
  6. Не боишься задавать глупые вопросы, если это поможет докопаться до истины. Аналитикам часто приходится задавать вопросы, которые кажутся совсем простыми и очевидными.

Итог

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

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

А если быть честным, то мы считаем, что аутсорс-разработка будет лучшим вариантом для быстрого роста, так как это возможность за 1–2 года поучаствовать в нескольких проектах с разными командами и клиентами, научиться у каждого уникальным навыкам.

Кстати, у нас открыты вакансии Senior Business Analyst и Project manager.

Над материалом работали:

  • текст — Настя Романцова, Серёжа Шмаков,
  • редактура — Виталик Балашов,
  • иллюстрации — Марина Черникова.

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

А чтобы ничего не пропустить, следи за развитием цифры вместе с нами:

Да пребудет с тобой сила роботов! 🤖

1515
1 комментарий

Спасибо, полезная статья. Тоже столкнулись с пересечением ответственностей аналитика и ПМа на проектах)

Ответить