Контакты

Что значит быть бизнес-аналитиком в мире ИТ

Статьи
бизнес
аналитика
20.06.2024
Что значит быть бизнес-аналитиком в мире ИТ
Время чтения 12 мин
Просмотров: 20

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

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

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

1. Идеальные отношения — это то, что мы знаем, но не говорим друг другу;

2. Реальные отношения бизнес-аналитика и разработчика — глава, основанная на моём опыте работы и реальных проблемах;

3. Заключение: бизнес-аналитика — улучшение отношений с разработчиками.

В этой главе я хочу поделиться своими мыслями о том, как мы можем избежать использования терминов «ошибки» или «исправления».

Идеальные отношения

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

Все эти роли важны для успешной реализации проекта, но мы сосредоточимся на отношениях между бизнес-аналитиком и разработчиком. Сотрудничество между этими ролями часто является решающим, по крайней мере, с моей точки зрения.

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

Я считаю, что идеальный БА с точки зрения разработчика — это человек, обладающий следующими качествами:

- Он пишет безупречные истории пользователей, которые охватывают все возможные сценарии и кратко объясняются в критериях приемлемости;

- При этом он не пишет слишком много AC, чтобы не перегружать коллег;

- Он получает мгновенные ответы и предоставляет обратную связь по первому запросу;

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

- Если для принятия решения нужно два часа или пять рабочих дней, он всегда выбирает первый вариант;

- Он понимает, о чём говорят разработчики;

- Он не спрашивает о статусе задачи, пока она не завершена, не протестирована и не подтверждена;

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

С точки зрения бизнес-аналитика, идеальным разработчиком можно считать того, кто:

- перед планированием спринта изучает истории пользователей и критерии отбора, чтобы подготовиться к следующему спринту;

- понимает всё о планировании спринта и не задаёт вопросов;

- во время спринта не задаёт вопросов, поскольку всё было ясно с планированием;

- если и требуются обсуждения, то они касаются только тем, на которые есть немедленный ответ;

- общается понятным образом, если возникает какая-либо техническая проблема с задачей или функцией;

- предлагает альтернативные решения самостоятельно;

- пишет код без ошибок;

- если обнаружены ошибки (которых не должно быть, исходя из предыдущего пункта), они не нарушают первоначальные оценки;

- предоставляет точные оценки, которые отражают реальное положение дел, и все заявки закрываются к концу спринта.

На мой взгляд, это идеальные критерии для разработчиков. Однако в реальной жизни эти два мира вряд ли могут существовать таким образом, как мы себе представляем. Давайте рассмотрим, с какими трудностями мы можем столкнуться в повседневной работе.

Отношения бизнес-аналитика и разработчика

Мы пришли к выводу, что идеальная ситуация, о которой мы говорили ранее, вряд ли осуществима. Но почему так? Какие трудности и препятствия нам нужно преодолеть, чтобы максимально приблизиться к идеалу?

Первое, что я хотел бы отметить, это различие в нашем мышлении.

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

Почему важно общаться

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

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

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

Уважаемые разработчики, пожалуйста, не стесняйтесь сообщать о любых проблемах, с которыми вы сталкиваетесь и не знаете, как действовать дальше. Наша работа — решать их самостоятельно или путем дальнейшего общения с другими заинтересованными сторонами.
Командная работа — лучшая работа!

Пока я писал этот текст, мне пришло в голову ещё кое-что: члены команды должны ладить между собой. Из моего опыта следует, что начало каждого проекта — самая сложная часть. Довольно очевидно, не правда ли?

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

Вывод:

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

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

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

В завершение нужно подчеркнуть важность взаимопонимания, коммуникации, сотрудничества и координации. Эти принципы являются основой успеха. Работа команды строится не для того, чтобы бороться за первенство, а чтобы работать сообща, каждый в своей сфере ответственности. Только объединив усилия, мы сможем успешно завершить проект.