📊 Аналитика проекта: что это и зачем вам это нужно — Блог Live Typing

📊 Аналитика проекта: что это и зачем вам это нужно — Блог Live Typing Аналитика

«аналитик и» проектный менеджер

📊 Аналитика проекта: что это и зачем вам это нужно — Блог Live Typing

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


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

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

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

Бизнес-аналитик

Менеджер проектов

Основные обязанности

Извлечение, анализ, формализация, визуализация и документирование требований.

Внедрение и реализация организационных процедур на проекте

Кларификация неясных требований/внесение предложений по улучшению требований.

Мониторинг технических навыков команды, предоставление обучения при необходимости

Валидация требований (поиск валидирующих сторон и координация этого процесса).

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

Разъяснение требований остальным участникам команды разработки.

Определение и документирование факторов, препятствующих успешной реализации проекта

Участие в процессе управления требованиями (обработка запросов на изменение требований, оценка влияния на проект).

Управление ресурсами

Планирование коммуникаций на проекте.

Организация и проведение встреч («митингов», «брифов» и других собраний, имеющих сходные англоязычные названия)

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

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

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

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

Мотивация команды

Мотивация команды

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

Мониторинг и управление ежедневной активностью команды. Мониторинг статуса проекта, оценка производительности команды

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

Разрешение споров как внутри команды, так и между внешними участниками.

Разработка стратегии по управлению рисками на проекте.

Управление запросами на изменение: анализ изменения масштаба (вместе с аналитиком), издержек, плана и расписания.

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

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

Дополнительные обязанности (опционально зависит от опыта и стажа)

Координация проекта и постановка процессов (фактически выполнение роли менеджера проекта, не считая критических решений и вопросов).

Разработка устава проекта

Участие в «предпродажной» стадии проекта вместе с маркетологами и менеджером проекта

Управление завершением контракта: контроль выполненных обязательств, административная работа по закрытию контракта

Обучение аналитиков-стажеров.

Утверждение методики разработки ПО. Перевод «задокументированных» требований в необходимый формат, который будет соответствовать используемой методике.

Координация команды аналитиков.

Организация инфраструктуры проекта

Участие в написании документации для тестировщиков.

Помощь в написании любого рода иной проектной документации (аналитик выступает как технический писатель).

Участие в стратегическом планировании деятельности организации

Управление базой знаний компании

Управление базой знаний компании

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

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

  • Выполнения «аналитических» активностей на проекте (менеджер может не знать всех потенциально возможных вариантов активностей, но будет хотеть, чтобы аналитик мог их выполнять и выполнял в конечном итоге, если это уместно)
  • Советов и рекомендаций по работе с требованиями и по другим аспектам аналитических активностей
  • Оценок трудоёмкости или длительности выполнения работы
  • Отчетности, причем как промежуточной, так и финальной
  • Уведомлений, если что-то идёт не так (например, не получается достигнуть целей по срокам или качеству)
  • Запросов, если чего-то не хватает для выполнения задач
  • Вопросов и уточнений, если что-то непонятно
  • Выполнения поставленных задач в установленный срок и с нужным качеством
  • Дополнительный анализ:  ★★★★★ Машинное обучение и предиктивная аналитика в малом бизнесе — Олег Солозобов

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

  • Анализа и разъяснений результатов (обратная связь)
  • Помощи, если что-то идёт не так или если не хватает полномочий
  • Предоставления всего необходимого (условия, информация, ресурсы, люди, процессы, инструменты и т.д.) для выполнения задач в срок и с нужным качеством
  • Уведомлений об изменений условий проекта / работы (например, сроков или объема задач)
  • Контроля за выполнением задач
  • Назначения сроков выполнения задач
  • Распределения и разъяснение задач
  • Ввода в курс дела (организационные и административные аспекты, инфраструктура проекта)
  • Когда один человек пытается носить сразу две шляпы (объединение функций аналитика и менеджера в одном человеке).

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

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

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

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

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

    Опытный менеджер

    Неопытный менеджер

    Опытный аналитик

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

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

    Неопытнй аналитик

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

    Вздохнув, пожелаем удачи проекту и побольше терпения разработчикам.

    Дополнительный анализ:  What is ad hoc analysis?

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

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

  • «Слишком эффективная» коммуникация с заинтересованными лицами (ВА и РМ, часто являясь экстравертами с ярко выраженными коммуникационными способностями, могут сами того не желая мешать друг другу при одновременном общении с участниками проекта)
  • Разное понимание рисков проекта (для аналитика это в первую очередь неточныенеполные требования, для менеджера проекта – сроки, ресурсы, административные аспекты)
  • Несинхронизированные ожидания (например, менеджер хочет, чтобы аналитик управлял командой, или аналитик хочет, чтобы менеджер рассказывал, как написать ТЗ)
  • Нереалистичные ожидания (сделать за день то, что надо делать 2 месяца)
  • Некачественное или неполное выполнение ожиданий
  • Невыполнение ожиданий (не в срок, не то вообще или вообще ничего)
  • Непонимание (отсутствие обратной связи, нежелание или невозможность уточнить детали)
  • Как наладить, улучшить или построить отношения с менеджером?

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

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

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

    Бизнес аналитика

    image

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

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

    Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.

    Дополнительный анализ:  АО "МС-АНАЛИТИКА", ИНН 7736111312


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

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

    Записывайте цели вместе с заказчиком, чтобы абсолютно все участники процесса в любой момент времени понимали, зачем они выполняют свою работу.

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

    Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.

    Взгляд с позиции руководителя проекта

    Через 1,5 года, заняв позицию РП в той же компании, на проблематику удалось взглянуть со стороны. Имея в подчинении 3 разных бизнес-аналитиков, стало очевидным, без преувеличения, колоссальное влияния компетенций бизнес-аналитика на все параметры проекты:

    • Функциональные границы проекта — без комментариев.
    • Рабочая атмосфера. Как показывает практика, обычно проектная команда, пусть и не в открытую, считает главным виновником всех проблем почему-то именно бизнес-аналитика (ну если не считать РП естественно). Умение не допускать больших «погрешностей», а главное умение достойно выйти из напряженной ситуации взаимных претензий внутри команды, сглаживать конфликты во многом позволяет БА существенно повысить мотивацию всей группы.
    • Сроки проекта. Зачастую этап, назовем его «анализ» (обследование, проектирование), существенная часть проекта по длительности, в среднем 10-30%, который зачастую нельзя поставить параллельно с другими работами по этому проекту, даже при большом желании. Соблюдение срока этого этапа, прямо влияющего на срок всего проекта, почти полностью зависит от организованности и компетенций БА (или ведущего БА или РП, если в одном проекте их несколько).
    • Решение организационных проблем путем облегчения коммуникаций. Как правило, бизнес-аналитик лучше, чем кто-либо еще знаком и пользуется доверием большинства сотрудников у заказчика. Организовать оперативно взаимодействие с сотрудниками клиента, не дожидаясь формальной эскалации — через него гораздо проще.
    • Незаменимый ресурс в ходе проекта. Думаю, что смена руководителя проекта в ходе проекта среди топ-5 основных причин появления некачественных проектов в этой сфере (за исключением наверное совсем уж типовых проектов). Смена бизнес-аналитика в ходе проекта — вероятно на соседней строчке такого рейтинга. На аргумент о необходимости качественного документирования, ответил бы так: к сожалению все не задокументируешь. В проекте помимо понятных вещей, в виде функциональных требований, целей, описания задач, очень часто важны атмосфера, эмоции, «тайные» ожидания заказчика. Формализовать и перенести это на бумагу в принципе далеко не всегда возможно.
    • Приемка проекта и его бюджет. Обычно в практике внедрения на рынке компания-заказчик по выручке и другим показателям в десятки, сотни раз крупнее компании-внедренца. Слон и Моська так сказать. Зачастую «Слон» считает вполне приемлемым опираться в таких отношениях не только на задокументированные договоренности, но и на кулуарные разговоры, обещания «фишечек», «плюшечек», которые когда-то по его мнению звучали, но почему в документацию не попали. Аргументация вида, что «Вы же профессионалы, должны были это учесть, мы естественно могли что-то пропустить, согласовывая сотни страниц документации, но это Вы же мне лично обещали» вполне состоятельная, как минимум потому, что он — «Слон», а Вы — «Моська», а проект сдавать как-то надо. Недопущения таких ситуаций, вероятно это часть так называемого управления требованиями и ожиданиям, и — одна из главнейших задач БА совместно с РП. Самое печальное, что этому, на мой взгляд, в принципе невозможно научить, это своего рода искусство и талант, ну и естественно опыт.
    Оцените статью
    Аналитик-эксперт
    Добавить комментарий

    Adblock
    detector