«Аналитик и» Проектный Менеджер

Данная статья продолжает цикл статей «Аналитик и» , и в честь надвигающегося дня проектного менеджера в ней мы затронем некоторые аспекты совместной работы бизнес-аналитика (аналитик, Business Analyst, BA) и менеджера проектов (менеджер, Project Manager, PM). Для этого мы вспомним, кто такой аналитик, а потом определим, кто такой PM и какие у него основные функции и обязанности. Различия, как и сходства, будут на лицо, однако кроме этого мы также расскажем о том, что хотят менеджеры от аналитиков, что менеджеры должны делать по отношению к аналитикам, рассмотрим основные проблемные точки взаимодействия. Также мы затронем такую важную тему, как объединение двух ролей (BA и PM) в одном человеке, какие от этого могут быть плюсы и какие минусы.

Кто такой аналитик и кто такой проектный менеджер.

Для начала определим, кто есть ВА и РМ. Да-да, про это совсем недавно было упомянуто в статье «Курс молодого БА: Кто такой бизнес-аналитик?», но, как говорится, «повторение мать учения». Согласно BABOK ’у бизнес-аналитик – «роль, которую выполняет любой человек, когда пользуется набором техник и методик для помощи заинтересованным лицам в решении бизнес-проблем или достижении поставленных задач». РМВОК определяет менеджера проекта (-ов) как «лицо, ответственное за управление проектом», а следовательно, и за его успешность в целом.

Ниже приведены обязанности обоих специалистов:

Бизнес-аналитик	Менеджер проектов
Основные обязанности
Извлечение, анализ, формализация, визуализация и документирование требований.	Внедрение и реализация организационных процедур на проекте
Кларификация неясных требований/внесение предложений по улучшению требований.	Мониторинг технических навыков команды, предоставление обучения при необходимости
Валидация требований (поиск валидирующих сторон и координация этого процесса).	Определение целей, задач проекта и критериев успешности
Разъяснение требований остальным участникам команды разработки.	Определение и документирование факторов, препятствующих успешной реализации проекта
Участие в процессе управления требованиями (обработка запросов на изменение требований, оценка влияния на проект).	Управление ресурсами
Планирование коммуникаций на проекте.	Организация и проведение встреч («митингов», «брифов» и других собраний, имеющих сходные англоязычные названия)
Коммуникация с заказчиком по любым рабочим вопросам, связанным с проектом (за исключением вопросов, находящихся в компетенции менеджера проекта).	Создание плана проекта и управление данным планом. Создание дополнительных планов, связанных с масштабом проекта, издержками, рисками, качеством, ресурсами и т.д.
Получение одобрения плана проекта от всех заинтересованных лиц. Получение одобрения на инициализацию проекта у заказчика и одобрения конечных пользователей при приемочном тестировании.	Получение одобрения плана проекта от всех заинтересованных лиц. Получение одобрения на инициализацию проекта у заказчика и одобрения конечных пользователей при приемочном тестировании.
Мотивация команды	Мотивация команды
	Контроль ресурсов для соблюдения временных рамок, условий качества и ограничений бюджета.
	Мониторинг и управление ежедневной активностью команды. Мониторинг статуса проекта, оценка производительности команды
	Донесение до всех заинтересованных лиц общего видения проекта, контроль за тем, чтобы данное видение разделялось всеми участниками Разрешение споров как внутри команды, так и между внешними участниками.
	Разработка стратегии по управлению рисками на проекте.
	Управление запросами на изменение: анализ изменения масштаба (вместе с аналитиком), издержек, плана и расписания.
Ретроспективный анализ проекта с точки зрения использованных технологий разработки ПО, приемов и методик для извлечения требований и управления ими, успешности примененных бизнес-решений.	Ретроспективный анализ проекта с организационной точки зрения, разработка рекомендаций для команды с целью повышения ее производительности и снижения издержек.
Дополнительные обязанности (опционально + зависит от опыта и стажа)
Координация проекта и постановка процессов (фактически выполнение роли менеджера проекта, не считая критических решений и вопросов).	Разработка устава проекта
Участие в «предпродажной» стадии проекта вместе с маркетологами и менеджером проекта	Управление завершением контракта: контроль выполненных обязательств, административная работа по закрытию контракта
Обучение аналитиков-стажеров.	Утверждение методики разработки ПО. Перевод «задокументированных» требований в необходимый формат, который будет соответствовать используемой методике.
Координация команды аналитиков.	Организация инфраструктуры проекта
Участие в написании документации для тестировщиков.
Помощь в написании любого рода иной проектной документации (аналитик выступает как технический писатель).
Участие в стратегическом планировании деятельности организации
Управление базой знаний компании	Управление базой знаний компании

Как заметит внимательный читатель, некоторые пункты совпадают, поскольку ВА и РМ часто выполняют одинаковые функции на проекте. Порой это приводит к возникновению споров о том, стоит ли вовсе разделять эти две роли, но об этом чуть позже.

Чего же хочет менеджер от аналитика?

Выполнения «аналитических» активностей на проекте (менеджер может не знать всех потенциально возможных вариантов активностей, но будет хотеть, чтобы аналитик мог их выполнять и выполнял в конечном итоге, если это уместно)

Советов и рекомендаций по работе с требованиями и по другим аспектам аналитических активностей

Оценок трудоёмкости или длительности выполнения работы

Отчетности, причем как промежуточной, так и финальной

Уведомлений, если что-то идёт не так (например, не получается достигнуть целей по срокам или качеству)

Запросов, если чего-то не хватает для выполнения задач

Вопросов и уточнений, если что-то непонятно

Выполнения поставленных задач в установленный срок и с нужным качеством

Чего хочет аналитик от менеджера?

Анализа и разъяснений результатов (обратная связь)

Помощи, если что-то идёт не так или если не хватает полномочий

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

Уведомлений об изменений условий проекта / работы (например, сроков или объема задач)

Контроля за выполнением задач

Назначения сроков выполнения задач

Распределения и разъяснение задач

Ввода в курс дела (организационные и административные аспекты, инфраструктура проекта)

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

Если вы решите поискать в интернете статьи на тему, схожую с темой данной статьи, вы безусловно натолкнетесь на споры о том, нужно ли разделять роли BA и РМ, или же все функции может выполнять один человек. Почему так происходит, отчасти становится ясно после сравнения функций, обязанностей, которые выполняют ВА и РМ. На наш взгляд, важную роль играют различия в организационной структуре компании, выбранных методиках разработки ПО, стилях управления и работы в целом.

Рассмотрим несколько вариантов.

1. Роль менеджера проектов выполняет бизнес-аналитик. Даже если мы не будем учитывать тот факт, что аналитику придется, помимо извлечения, анализа, документирования требований и управления ими, тратить время на административные задачи, такой вариант во многих случаях не является оптимальным. ВА по своей природе склонен детализировать любые неясности, стараться как можно более подробно описывать требования и донести до разработчиков. Это, в свою очередь, может негативно сказаться на временных рамках проекта. Конечно, опытный ВА знает, когда нужно остановиться, но опыт к нам приходит не сразу, а заказчик ожидает результаты уже сейчас.

2. Роль аналитика выполняет менеджер проектов. Возможна ситуация, когда РМ, имея приоритеты вовремя закончить (или начать) проект, начинает жертвовать аналитическими активностями на проекте, что в итоге может негативно сказаться на результатах. Ведь, на самом деле, цель менеджера – закончить проект, балансируя между имеющимися ограничениями (объем работ, ресурсы, время, качество и риски).
Есть и положительные стороны. Помимо очевидных плюсов (меньшие финансовые расходы для компании, более быстрое координирование задач, более оперативное принятие решений) хотелось бы выделить возможность развиваться и получать новые навыки, что является замечательным для специалиста и, тем не менее, малополезным для текущего проекта.

Но все ли так гладко на проекте, когда данные роли разделены? Конечно, сложности будут всегда. (… хотя нет: нет проекта – нет сложностей.) Опять же, выделим несколько вариантов. И снова все сводится к опыту:

	Опытный менеджер	Неопытный менеджер
Опытный аналитик	Несмотря на казалось бы выигрышный вариант, и здесь есть определенные риски. Порой начинается «раздел территории». Поскольку и РМ, и ВА взаимодействуют с одними заинтересованными лицами, часто работают с одними и теми же документами, могут возникнуть трения, особенно когда РМ не считает нужным делиться всей информацией по проекту, или аналитик, руководствуясь теми же мотивами, скрывает какие-либо артефакты (документы и пр.). Важным является также и тот факт, что РМ, как уже говорилось выше, имеет больше полномочий и конечное решение принимает именно он. Однако это вовсе не означает, что схема «Руководитель – Подчиненный» эффективна в отношениях РМ’a и BA’я. Гораздо более продуктивная их командная работа, что, впрочем, часто применимо ко всей команде.	Маловероятная ситуация, которая все же несет свои риски для проекта. Практически противоположный предыдущему эффект получится, если РМ не сможет четко придерживаться сроков. Одним из нежелательных вариантов развития событий может быть нежелание РМ’а понять аналитика и согласиться поддержать его при обсуждении сдвига сроков проекта с заинтересованными лицами.
Неопытнй аналитик	Риском для проекта можно считать вероятность давления со стороны РМ’а с целью уложиться в оговоренные временные рамки, бюджет и ресурсы. Неопытный ВА иногда просто неспособен убедить менеджера проекта в том, что необходимо затратить больше времени на извлечение требований (а поскольку ВА неопытен, то ему понадобится гораздо больше времени).	Вздохнув, пожелаем удачи проекту и побольше терпения разработчикам.

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

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

«Слишком эффективная» коммуникация с заинтересованными лицами (ВА и РМ, часто являясь экстравертами с ярко выраженными коммуникационными способностями, могут сами того не желая мешать друг другу при одновременном общении с участниками проекта)

Разное понимание рисков проекта (для аналитика это в первую очередь неточныенеполные требования, для менеджера проекта – сроки, ресурсы, административные аспекты)

Несинхронизированные ожидания (например, менеджер хочет, чтобы аналитик управлял командой, или аналитик хочет, чтобы менеджер рассказывал, как написать ТЗ)

Нереалистичные ожидания (сделать за день то, что надо делать 2 месяца)

Некачественное или неполное выполнение ожиданий

Невыполнение ожиданий (не в срок, не то вообще или вообще ничего)

Непонимание (отсутствие обратной связи, нежелание или невозможность уточнить детали)

Как наладить, улучшить или построить отношения с менеджером?

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

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

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

Берите на себя новые обязательства, выходите за рамки ожиданий (в хорошем смысле). Именно это и есть ваш профессиональный рост. Хороший менеджер (если это будет позволять проект и компания), обязательно отметит ваши стремления и заслуги.

Постарайтесь поставить себя на место менеджера, представить, какие сложности могут волновать его больше всего. Это даст вам понимание того, как эффективно организовать свою работу, чтобы при этом еще и помочь РМ’у. Не все проблемы могут быть озвучены открыто, что совершенно естественно, ведь у нас всех есть недостатки (от которых мы стараемся избавиться, ведь правда?). Иногда некоторые сложности и вовсе не связаны с личностными характеристиками: если РМ завален организационной работой и не имеет возможности часто общаться с разработчиками, в то время как ВА большую часть своего времени проводит именно с командой, то для ВА имеет смысл (не в ущерб своей работе) помочь менеджеру, выполняя некоторые его обязанности. В итоге выиграют все. Главное – чтобы такая ситуация не приняла статус нормальной, и менеджер не «делегировал» все свои обязанности аналитику, вовсе отстранившись от работы.

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

Свои комментарии о статье вы можете оставить на форуме.