Взаимодействие бизнес-аналитика с командой: подходы в Agile
Всем привет.
Сегодня хочу поговорить о разных подходах к схемам взаимодействия бизнес-аналитика и команды разработки в гибких методологиях. Обсудим плюсы и минусы этих подходов.
Итак, погнали!
Как мы знаем, бизнес-аналитик в IT — это связующее звено между заказчиком и командой. Чтобы не допустить сценария, который изображен на картинке выше, существует три основных подхода(схемы) взаимодействия.
- Аналитик — это владелец продукта.
Простой случай, который я пока в своей работе не видела.
Кратко: аналитик+ владелец продукта = ответственность за продукт, сбор и приоретизацию ФТ. По сути в такой схеме аналитик находится за рамками команды и является представителем заказчика.
Плюсы: удобно, дешево, понятно.
Минусы: такой аналитик может помереть от усталости и унести свои знания о проекте в могилу (sad and dangerous)
Как мне кажется, такой подход чуть менее приоритетен для команды разработки и более приоритетен для бизнеса: по сути аналитик выдает то решение, которое, как кажется ему, самое лучшее, не оценивая техническую сторону вопроса. Снова смотрим на картинку с деревом:) - Аналитик — помощник владельца продукта.
Сложности пункта 1 можно исключить, (аналитик не выйдет в окно, если проект крупный) если поделить обязанности владельца продукта и аналитика между двумя людьми — достаточно распространенная практика. Владелец продукта играет роль «решалы», а аналитик больше пишет ФТ.
Минусы: Команда не понимает, что делает аналитик и почему он ей указывает. Могут возникнуть сложности в исполнении задач, аналитик не очень переживает, если его поняли не так. - Аналитик внутри команды разработки.
Звучит круто!
Что это значит: Аналитик сидит вместе со всеми, т. е. в одной лодке с командой разработки. Он полноценный член команды, помогает команде во всем и старается соблюсти баланс между бизнес-потребностью и грамотным техническим решением.
Плюсы: Работает надежно, как швейцарские часы!
Минусы: Если проект очень технически сложный, одних навыков бизнес-анализа не хватит, нужно однозначно знание системного анализа.
Всем успехов, и помните — наша главная профессиональная задача, чтобы не сделать так, как на картинке с деревьями!:)
Мой опыт: сейчас я работаю на крупном продукте и нахожусь внутри команды разработки (пункт 3), product owner’ы у нас — менеджеры проектов и представители заказчика, которые пишут бизнес-требования. Как мне кажется — это очень удобный подход, когда процессы в компании уже налажены и недостатка в кадрах нет.
Ксения, поменяли бы скорее мем с матом на более пристойное изображение, пока не забанили. А по опыту разделения обязанностей сталкивались с различными вариациями: зависит от сложности проекта, компетенций аналитика, как и обозначили. Роль Аналитика может пересекаться с дизайнером, руководителем проекта, владельцем продукта, системным аналитиком, архитектором и даже может быть от Заказчика. В любом случае, команду нужно подбирать по критериям, а также в команде договариваться и чётко распределять, кто и за что отвечает.
Спасибо! Поменяла.
Да, все верно, я с вами полностью согласна, аналитик - роль плавающая, и зависит от специфики. Иногда нам на продукте приходится брать на себя задачи менеджера(продуктового или проектного).