Зоны ответственности бизнес-аналитика
Если говорить общими словами, то бизнес-аналитик связывает бизнес и команду разработки. Его основная обязанность — спроектировать цифровой продукт таким образом, чтобы задачи пользователя решались, цели бизнеса достигались, а интересы команды разработки и требования к удобству и простоте были учтены.
Важно отметить, что мы в red_mad_robot используем практику фулстек-аналитика, совмещая роль системного и бизнес-аналитика. Такой формат позволяет сократить время проектирования и количество коммуникации, а также позволяет одному человеку погружаться как в техническую, так и в бизнес-составляющую проекта.
Основные обязанности аналитика в red_mad_robot:
1_
Проведение вторичных исследований рынка.
2_
Анализ потребностей целевой аудитории.
3_
Интервьюирование бизнеса для понимания целей и задач.
4_
Проработка верхнеуровневой архитектуры продукта.
5_
Проектирование бизнес-процесса разрабатываемой функциональности.
6_
Проработка функциональных и нефункциональных требований к системе.
7_
Подготовка необходимых диаграмм для команды разработки.
8_
Передача материалов командам дизайна и разработки.
9_
Проектирование спецификаций API.
В начале карьеры я проходила стажировку на роль проектного менеджера и ожидала освоить новые навыки в управлении проектами. Но со временем стала понимать, что это не моё, что мне хочется ближе взаимодействовать с продуктом, определять и выявлять бизнес-требования, формулировать решения для проблем. Управление временем и деньгами меня пугало, всё время закапывалась в проработку технических требований, изучение рынка и пользователей. Сейчас я ясно понимаю разницу между этими ролями, могу чётко провести черту в зонах ответственности и не конфликтовать с PM.
Зоны ответственности проектного менеджера
Проектный менеджер управляет процессами проектирования и разработки, устраняет узкие места и неэффективности. Он же транслирует в команду ограничения со стороны бюджета и сроков и следит за тем, чтобы принимаемые решения учитывали эти ограничения. А ещё обеспечивает клиенту прозрачность хода проекта и результатов и свободное движение информации между всеми участниками.
Обязанности менеджера:
1_
Выбор подходящего фреймворка и адаптация производственного процесса под проект или команду.
2_
Выявление основных метрик проекта и управление ими.
3_
Повышение эффективности обмена информацией между участниками проекта, контроль за её систематизацией и тщательным сохранением.
4_
Формулировка цели вместе с командой и бизнесом, фокусировка команды на целях.
5_
Управление ожиданиями.
6_
Управление проектными рисками.
7_
Доведение всех задач проекта до результата.
8_
Критический взгляд на всё и регулярная рефлексия.
На предыдущих проектах, вне Роботов, мне часто приходилось совмещать роли менеджера и аналитика. С одной стороны, это научило разбираться в нюансах процессов бизнеса и разработки, говорить на одном языке с командой, точнее формулировать мысли и задачи, задавать нужные вопросы и принимать оптимальные решения. С другой, смешивать роли — не самый лучший сценарий. Потому что из фокуса постоянно что-то выпадает, иногда не хватает времени и ёмкости, а это влияет на качество результата. На проектах Роботов зоны чётко разделены. Это позволяет полноценно заниматься своими менеджерскими делами и не переживать за то, как разгадываются фичи и ставятся задачи разработке. Знаю, что всё будет в порядке. Тем не менее, думаю, что РМ полезно погружаться в смежные области и нарабатывать навыки — тогда в ротациях получается подсаппортить команду и не теряются контекст и скорость.
Как обязанности 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-матрицы, встречи по распределению зон ответственности и образу результата — как с командой, так и с клиентом. Чтобы в проект не летели несогласованные стихийные задачи, мы отстраиваем внятный и понятный всем сторонам процесс управления бэклогом и приоритезации фичей. Порядок в бэклоге — первый шаг к нормальной управляемости всего проекта в целом.
Бонус: как понять, что мне ближе — 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.
Над материалом работали:
текст — Настя Романцова, Серёжа Шмаков,
редактура — Виталик Балашов,
иллюстрации — Марина Черникова.