Привет! Я - новый бизнес-аналитик!
Когда все курсы, стажировки, собеседования, офферы и подписание контракта остаются позади и вы приходите в компанию, чтобы “сворачивать горы”, важно понимать, с чего и как начать процесс своего онбординга для эффективной работы на новой позиции. Будет прекрасно, если ваш проджект-менеджер или HR уже подготовили всю документацию и ментора для первого времени, но в реальности вы можете оказаться “брошенным котенком” - и лучше быть подготовленным к такому варианту, чем “выгореть” еще на первом проекте. Итак, вы открываете двери офиса, входите и...
Четко определяете круг своих обязанностей.
Конечно, еще до собеседования у вас была возможность познакомиться со своими задачами в описании вакансии - но, как правило, это было high-view. Важно для себя понимать, какие задачи входят в круг обязанностей Business Analyst (к примеру, работа с бэклогом и управление требованиями), а какие - зона ответственности других ролей (планирование бюджета или распределение задач между разработчиками). Однако на практике в одной компании на разных проектах ожидания от работы BA могут отличаться.
Какие шаги предпринять?
- Проанализировать всех стейкхолдеров и составить матрицу RACI. То есть понять, кто и с кем взаимодействует, кто и кому отчитывается.
- Изучить клиента: его домен, пожелания, запросы, ожидания.
- Обсудить с проджект-менеджером своего проекта, как он видит роль БА и какие у него ожидания.
“Заявляете миру” о том, чем будете заниматься на проекте.
Часто начинающие специалисты и не только находятся в заблуждении, что каждый член команды отлично понимает, чем занимаются остальные. На самом деле это далеко не так. Если вы пришли на небольшой проект, в котором до этого функции ПМ и БА были, так сказать, в одном флаконе, и сейчас их разделили на 2 отдельные роли - то команда может не понимать, к кому и с каким вопросом бежать.
Какие шаги предпринять?
- Подготовить для команды выступление на 10-15 минут, в котором вы детально расскажете, кто вы, чем будете заниматься, с какими вопросами к вам обращаться и как будет проходить процесс коммуникации. К примеру, чтобы не терять время и не объяснять один Use Case каждому коллеге, вы будете собирать вместе всех тех, кто имеет к нему отношение, чтобы у каждого было одинаковое видение.
- Также важно доступно объяснить клиенту, что и как вы будете делать на проекте и настроить максимально эффективный процесс общения между вами.
Разбираетесь со спецификой проекта.
1. Важно знать тип контракта:
- Time and Material - Время и Материалы. При таком варианте клиент платит за время, которое проработала команда. Новые желания и запросы клиента “легко” вписываются в бэклог, так как нет строгих временных и финансовых рамок.
- Fixed Price - Фиксированная Цена. Здесь есть четко описанный объем работы, который нужно закончить в определенный срок за четко установленную стоимость. Такой вариант требует от бизнес-аналитика, в первую очередь, пристального внимания к объему проекта - так как любое новое пожелание клиента может потенциально повлиять на срок окончания работ или их стоимость. И тут нужно будет или отказываться от чего-то, или подписывать дополнительные соглашения.
- Cost Reimbursable - С возмещением затрат. При этом типе контракта покупатель оплачивает исполнителю фактические затраты при выполнении проекта.
- Dedicated Development Center - Центр Разработки. Здесь клиент увеличивает свой штат, нанимая себе сотрудников с оффшорной компании.
2. Также имеет значение, будет ли проект долгосрочным (что подразумевает создание нескольких команд разработки и общение с большим количеством специалистов со стороны клиента) или краткосрочным (к примеру, создание отдельной фичи к уже существующему приложению).
3. И не менее важный пункт - какая методология или фреймворк используются на проекте.
Первоначальный анализ сделан, что дальше?
А дальше вы приступаете к одному из основных своих видов деятельности - коммуникации. Важно понять, где заказчик находится сейчас (тут пригодится понимание бэкграунда - домена, бизнес-процессов в компании) и куда он хочет прийти. Оформить это в требования - и донести максимально ясно команде. А затем постоянно держать руку на пульсе и вносить необходимые изменения.
- Всегда спрашивайте, если вам что-то непонятно (особенно на первых этапах). Недопонимание в начале может привести к огромным проблемам в конце: вплоть до непринятия релиза клиентом и отказа платить за выполненную работу.
- Важно оставаться в курсе последних тенденций - посещать конференции, проходить курсы, общаться с коллегами.
- Также старайтесь участвовать на разных этапах проекта - presale, discovery, evaluation - чтобы не получить проект, который нереально выполнить в установленные сроки с оговоренным бюджетом.
И всегда помните, что Business Analyst - это посредник между командой разработки и клиентом, главным результатом которого будет понимание клиента и команды куда и как нужно двигаться, что помочь бизнесу стать успешнее.