Функции бизнес аналитика в проекте

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

1122 просмотров

Руководитель отдела бизнес-аналитики Настя Романцова и руководитель отдела управления проектами Серёжа Шмаков рассказывают, как мы в 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 года поучаствовать в нескольких проектах с разными командами и клиентами, научиться у каждого уникальным навыкам.

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

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

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

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

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

Источник: vc.ru

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

Аналитика

Автор Аналитик На чтение 15 мин. Просмотров 270 Опубликовано 26.06.2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительный анализ: Аналитик опусов 6 букв первая К

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

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

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

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

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

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

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

Несмотря на казалось бы выигрышный вариант, и здесь есть определенные риски. Порой начинается «раздел территории».

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

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

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

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

Дополнительный анализ: Сопровождение и развитие Парус 8. Центр поддержки пользователей Парус от официального дилера

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

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

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

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

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

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

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

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

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

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

Дополнительный анализ: CFA Russia — Ассоциация CFA (Россия)

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

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

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

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

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

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

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

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

Источник: analitik-expert.ru