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

Это только часть вопросов и задач, которые были освещены на очередной встрече сообщества analyst.by 12 ноября 2018 года в Imaguru. Эта встреча была продуктивной и полезной как для тех, кто только пробует свои силы в бизнес-анализе, так и для тех, кто уже доедает очередную собаку в этом домене.

Встреча состоялась (и была как всегда отлично организована) благодаря партнерам сообщества:

Встреча сообщества analyst.by стала рекордной сразу по нескольким показателям:

104 участника;
65 участников смотрели трансляцию встречи вживую на нашем канале YouTube;
15 новых участников пришли в наш канал в Telegram;
50 новых подписчиков приобрел наш Instagram.

Ну, как сходил на митап analyst.by?

Встречу вели Виктор Старостенко, бизнес-аналитик в компании ISsoft, и Дмитрий Ялтыхов, ведущий бизнес-аналитик в компании LLSOFT.

Формат встречи немного отличался от предыдущих встреч: экспертам на этот раз отдали больше времени для докладов, а вот на экспертных столах участникам удалось пообщаться несколько меньше.

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

Презентация сообщества

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

Кроме митапов (встреч) для практикующих бизнес-аналитиков, сообщество проводит также и встречи для тех, кто интересуется профессией “бизнес-аналитик” или желает им стать: от выбора курсов до путей прихода в профессию. Сообщество проводит много различных мероприятий: встречи для студентов, аналитические игры, встречи дискуссионного клуба.

В 2019 году сообществу исполняется 9 лет, поэтому оргкомитет уже вовсю занят планированием праздничной встречи, которая состоится 26 января 2019-го. На ней планируется три “стрима”: доклады, воркшопы и “фан” – аналитические игры “и все такое”. Анонс уже опубликован: https://www.facebook.com/events/1865186473594155/

Вы можете стать докладчиком, куратором докладчика, придумать аналитическую игру или даже просто предложить “что-нибудь эдакое” для программы будущего события. Есть желание – пишите оргкомитету сообщества (почта analyst.by.org@gmail.com).

Мини-доклады про организацию работ по бизнес-анализу

Настало время докладов. Первой взяла слово Елена Горопека, Chief BA из компании Oxagile. Темой доклада Елена выбрала “Как построить отношения со всеми заинтересованными лицами на проекте и не умереть”.

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

Елена поделилась своим опытом выстраивания отношений с “владельцем продукта” и рассказала, как решила проблему неопределенности относительно объема минимально жизнеспособного продукта.

Алеся Глебова, бизнес-аналитик SolbegSoft, рассказала, каково это – быть “следующим” аналитиком на проекте. Было здорово получить кусочек опыта “чужих граблей” – как эффективно и в сжатый срок восстановить документацию, понять ответственность различных членов команды и прочие “прелести” запущенного проекта.

Кульминацией доклада Алеси был способ, который она придумала для решения проблемы “команда не читает документацию”. Отдельные аплодисменты за этот хак: в требованиях к одному из больших модулей Алеся в четырех разных местах вставила фразу “Приди ко мне, я дам тебе сникерс”. Оказалось, за сникерсом не пришел никто. Это помогло самой команде понять, что требования нужно читать.

Светлана Чуйкова из компании “Анализ и Дизайн ИТ” поделилась опытом работы бизнес-аналитиком на удаленке: начиная с того, кто обычно ищет бизнес-аналитика на удаленке, как организован процесс бизнес-анализа на удаленном проекте, какие проблемы могут возникать при таком типе вовлечения в проект и как с ними справляться.

Экспертные столы

За экспертным столом “Приход БА на проект без БА” обсудили следующие темы:

До прихода БА, скорее всего, разработчики “пилили” фичи, но не понимали зачем.
БА должен выступить в качестве фасилитатора и понять “боль” каждого.
Начинать следует с определения бизнес-целей проекта, выявления, на
какой стадии находится проект, и определения шагов, которые отделяют текущее состояние проекта от цели.
Важно проявить компетентность, потому что это формирует доверие и заказчика, и команды разработки.
Команде нужен БА, если у всех нет понимания того, что происходит на проекте или не могут договориться между собой/заказчиком.

Основные тезисы экспертного стола “Я – junior бизнес-аналитик, и я один”:

Даже если ты один, то это не так. У тебя есть команда;
Очень важно тестирование требований тестировщиками;
Главное – реагировать на фидбэк, иначе команда не будет тебе доверять;
Обратную связь ты получишь всегда!
Иногда быть одним БА вовсе не плохо!
Лучше работать в одном помещении с командой.

За экспертным столом “Бизнес-аналитик на удаленной работе” обсудили, кому не подходит/подходит удаленная работа бизнес-аналитиком и что уже должен уметь бизнес-аналитик перед принятием решения стать членом команды удаленно.

Темой следующего экспертного стола было выстраивание работы между аналитиком и UX-специалистом: на каких задачах сосредоточен бизнес-аналитик, на каких – UX-специалист, и какое оно – идеальное сотрудничество этих людей на проекте.

За экспертным столом “Бизнес-аналитик, он же – менеджер проекта” были освещены такие вопросы: как на проекте появляется такая должность, как PM/BA, кто способен совместить две эти роли на проекте и что помогает успешно вести в роли BA/PM несколько проектов одновременно.

За экспертным столом “Agile бизнес-аналитик” мы поговорили о том, каким проектам подойдет Scrum, почему так происходит, что от методологии остается только название, и выйдет ли в конце концов из-под контроля сложный многолетний проект, если систему не документировать.