Smart-аналитик: ищем общий язык с заказчиком и руководителем проекта
Поговорим о трудностях перевода. Из этого поста вы узнаете, когда нужно подключать к проекту бизнес-аналитиков, как выстроить коммуникацию в команде и можно ли дублировать задачи между руководителем проекта и бизнес-аналитиком.
Ожидание и реальность не всегда совпадают. Зачастую, начиная новый проект, мы в предвкушении потираем руки и радуемся, как дети, которым купили новую игрушку. А потом спустя несколько месяцев, полгода или год эйфория испаряется… Что нужно сделать, чтобы ее сохранить? Как найти общий язык с заказчиком и партнерами, не испортить впечатление друг о друге и успешно продолжать работать вместе?
Сегодня мы попробуем определить правила игры — гласные и негласные. Поделимся опытом и разберемся, почему менеджер проекта и бизнес-аналитик — близкие, но при этом разные роли.
Тарабарский бизнесовый
Зачастую аналитик подключается к проекту на стадии сбора требований. Контракт подписан, сроки и объемы работ согласованы, все нюансы оговорены — время собирать хотелки заказчика и писать ТЗ. Сюрпризы могут начаться уже на этом этапе. Например, иногда оказывается, что проект был продан по демпинговой цене, и обрисованный крупными мазками функционал не бьется с реальными сроками и бюджетом. Как результат, мы получает конфликт. Но пока только внутри команды, и только если у нас грамотный аналитик, который не боится подсвечивать промахи пресейл-консультантов. Тем не менее скоро все это может вылиться и в конфликт с заказчиком: «На это мы не подписывались!» или «Но здесь же черным по белому написано…».
Отсюда вытекает первое правило (и наша стандартная практика):
аналитик должен участвовать в пресейле и, как минимум, отстаивать свои трудозатраты
Например, в наших ML-проектах основной объем работ в рамках пресейла обычно выполняет дата-сайентист. Он ездит к заказчику вместе с пресейл-менеджером и определяет, чем и как мы сможем помочь. Но с результатами его работы всегда знакомится бизнес-аналитик (и довольно пристально). Ведь именно на него в итоге лягут задачи по сбору требований, подготовке ТЗ и прочей документации. Нередко наши аналитики сами участвуют в ОПЭ, демо и тестировании. Проще говоря:
чем раньше вы подключите аналитика к проекту, тем лучше!
Теперь представим, что проект был продан по всем правилам: аналитики оценили и согласовали объем работ, менеджеры договорились о сроках и бюджете, «и все идет по плану». Начинаем мы по традиции и по всем правилам с детальной проработки требований. Как в данном случае общаться с заказчиком? Можно попробовать говорить «на техническом», но скорее всего, представитель бизнеса окажется не настолько подкован, и в определенный момент начнет отвечать «да», не вникая в детали. Или обратная ситуация: «Раз вы со мной на тарабарском техническом, буду отвечать на тарабарском бизнесовом — посмотрим, кто кого». Тогда нас ждет диалог с миллионом терминов, а в худшем случае — с фразами в стиле «Ну это же и так очевидно…». Хороший бизнес-аналитик этого не допустит. Один из его ключевых навыков — это билингвальность — умение общаться с заказчиком на языке бизнеса, а с разработчиками и при подготовке ТЗ использовать сугубо технический.
Отметим, что и в рамках проектной команды важно говорить на языке, который предельно понятен всем исполнителям. Представьте: вы в чужой стране, не знаете местного языка и оказываетесь на приеме у врача. Он, конечно, знает английский на четыре с минусом, поэтому вы сможете кое-как объясниться, но можно ли назвать такую коммуникацию эффективной? Нет, поэтому бизнес-аналитик должен быть билингвальным.
Как подобные вопросы решаем мы?
Зачастую наши аналитики вырастают из разработчиков или тестировщиков, поэтому прекрасно понимают, как сложно писать код по требованиям, выраженным на непонятном бизнесовом языке. Иногда в их послужном списке бывает даже опыт ведения проектов. Такой бизнес-аналитик — это бесценный полиглот, который и с заказчиком сможет поговорить, и перед разработчиками в грязь лицом не ударит. Кроме того, мы регулярно проводим обучение специалистов и погружаем их в предметные области. К примеру, бизнес-аналитики из центра машинного обучения активно прокачивают компетенции в части ML. Для них Python, анализ текстов и градиентный спуск — далеко не пустые слова.
Кто, кому и что сказал?
Даже если все участники проекта понимают друг друга с полуслова, нельзя забывать про best practices в части коммуникаций. Здесь бизнес-аналитик должен играть на одном поле с руководителем проекта.
Как часто вы сталкивались с «подвисанием» переписки? Например, когда кто-то не подтвердил получение информации или не отправил свежий статус. Вроде бы без этого процесс не остановился, но остается ощущение недосказанности — приходится что-то додумывать. Такие моменты напрямую влияют на качество коммуникаций и являются одним из краеугольных камней в проектном огороде.
На старте руководитель проекта должен провести «установочную встречу» (Kickoff meeting), чтобы:
- Познакомить всех участников команды
- Донести до них цели, объем работ и сроки проекта
- Установить правила коммуникации
Остановимся на последнем пункте. С одной стороны, коммуникации — зона прямой ответственности руководителя проекта. С другой, именно бизнес-аналитик больше других общается c заинтересованными лицами (стейкхолдерами).
Таким образом, в части выстраивания проектных коммуникаций роль аналитика сводится к двум важным задачам: согласование правил коммуникации вместе с руководителем проекта, тщательное следование принятым схемам и их улучшение.
Для этого существуют устоявшиеся практики — матрица проектных коммуникаций и матрица RACI. С первой все довольно просто: выделяем группы пользователей (в каждой может быть от одного до N человек) и обозначаем, какую информацию они должны получать и с какой периодичностью.
Матрица RACI — это методика распределения полномочий и ролей в бизнес-процессах:
- Responsible — выполняет задание
- Accountable — принимает работу и несет ответственность за результат
- Consulted — консультирует
- Informed — осведомлен о принимаемых решениях и ходе выполнения задач
Можно сказать, что RACI — это расширенный вариант матрицы коммуникаций. В том числе она помогает выстроить прозрачные схемы согласования или эскалации, а также проанализировать распределение полномочий и ответственности среди участников проекта.
Эти инструменты применяют и бизнес-аналитики, и руководители проектов. При этом каждый из них может работать в своей области матрицы, но в определенных моментах их зоны ответственности будут пересекаться.
Дублирование недопустимо
Если области действия бизнес-аналитика и руководителя проектов могут пересекаться, как избежать дублирования обязанностей? Ответ парадоксален: если речь идет о коммуникациях с заказчиком, дублирование допустимо.
Глубоко погруженный в детали работы команды руководитель сможет самостоятельно ответить на вопросы заказчика. Как результат, вы сэкономите время и сможете быстрее принимать локальные решения. С другой стороны, глубоко погруженный в проект аналитик, понимающий общую картину процесса, сроки, очередность задач и т.д., тоже будет намного эффективнее общаться с заказчиком. Синергия между руководителем и аналитиком поможет выстроить прозрачную и единообразную модель коммуникаций с заказчиком.
Каким должен быть Smart-аналитик?
Так какой же он — хороший Smart-аналитик — и почему он жизненно необходим в любом проекте? Это эффективный коммуникатор, хорошо понимающий и бизнес-терминологию, и технические аспекты проекта. Он помогает выстраивать доверительные отношения с заказчиком и внутри команды и в нужный момент применяет инструменты из арсенала руководителя проектов. Кроме того, хороший Smart-аналитик должен постоянно наращивать и обновлять свои компетенции. Все-таки Smart значит «интеллектуальный».
Автор: Юрий Попков, старший бизнес-аналитик центра машинного обучения компании «Инфосистемы Джет»