Сегодня наш бизнес-аналитик Иван приоткроет занавес этой профессии и расскажет, каково быть бизнес-аналитиком в ИТ-компании.
Будучи бизнес-аналитиком на протяжении большей части своей профессиональной карьеры, я имел возможность сотрудничать с разработчиками разных направлений. Наше сотрудничество было успешным, несмотря на то, что у нас часто были разные точки зрения. Это не приводило к потере доверия и связи, которые являются ключевыми в совместной работе.
1. Идеальные отношения — это то, что мы знаем, но не говорим друг другу;
2. Реальные отношения бизнес-аналитика и разработчика — глава, основанная на моём опыте работы и реальных проблемах;
3. Заключение: бизнес-аналитика — улучшение отношений с разработчиками.
В этой главе я хочу поделиться своими мыслями о том, как мы можем избежать использования терминов «ошибки» или «исправления».
В целом, роль БА (бизнес-аналитика) заключается в том, чтобы преобразовывать требования заинтересованных сторон в техническую реализацию. Для этого необходимо постоянно взаимодействовать со всеми участниками проекта: заинтересованными сторонами, менеджерами проектов, дизайнерами, тестировщиками и разработчиками.
Давайте рассмотрим идеальный сценарий: у нас есть заинтересованные стороны, и проекты не претерпевают внезапных изменений. Что же мы ожидаем друг от друга в такой ситуации?
Я считаю, что идеальный БА с точки зрения разработчика — это человек, обладающий следующими качествами:
- Он пишет безупречные истории пользователей, которые охватывают все возможные сценарии и кратко объясняются в критериях приемлемости;
- При этом он не пишет слишком много AC, чтобы не перегружать коллег;
- Он получает мгновенные ответы и предоставляет обратную связь по первому запросу;
- Если есть несколько возможных подходов, он безоговорочно соглашается с разработчиком;
- Если для принятия решения нужно два часа или пять рабочих дней, он всегда выбирает первый вариант;
- Он понимает, о чём говорят разработчики;
- Он не спрашивает о статусе задачи, пока она не завершена, не протестирована и не подтверждена;
- Он не подвергает сомнению оценки и не ожидает, что они будут отражать фактическое время, затраченное на выполнение задач.
- перед планированием спринта изучает истории пользователей и критерии отбора, чтобы подготовиться к следующему спринту;
- понимает всё о планировании спринта и не задаёт вопросов;
- во время спринта не задаёт вопросов, поскольку всё было ясно с планированием;
- если и требуются обсуждения, то они касаются только тем, на которые есть немедленный ответ;
- общается понятным образом, если возникает какая-либо техническая проблема с задачей или функцией;
- предлагает альтернативные решения самостоятельно;
- пишет код без ошибок;
- если обнаружены ошибки (которых не должно быть, исходя из предыдущего пункта), они не нарушают первоначальные оценки;
- предоставляет точные оценки, которые отражают реальное положение дел, и все заявки закрываются к концу спринта.
На мой взгляд, это идеальные критерии для разработчиков. Однако в реальной жизни эти два мира вряд ли могут существовать таким образом, как мы себе представляем. Давайте рассмотрим, с какими трудностями мы можем столкнуться в повседневной работе.
Мы пришли к выводу, что идеальная ситуация, о которой мы говорили ранее, вряд ли осуществима. Но почему так? Какие трудности и препятствия нам нужно преодолеть, чтобы максимально приблизиться к идеалу?
Первое, что я хотел бы отметить, это различие в нашем мышлении.
Бизнес-аналитики должны понимать потребности бизнеса и преобразовывать их в функциональные требования. Важно, чтобы весь процесс был осмысленным и мог быть реализован в установленные сроки. Разработчики же больше сосредоточены на конкретных задачах, подходах к их решению, процессе внедрения и действиях, которые нужно предпринять, чтобы соответствовать требованиям.
Общение — это следующий шаг в процессе работы. Хотя я не считал его самым важным, теперь я понимаю, что это самое главное.
Однако существует множество ситуаций, в которых могут возникнуть различные проблемы. Масштаб проблемы или ожидания могут внезапно измениться, оценка ситуации может оказаться неточной, а история пользователя может упустить какие-то важные действия и так далее.
Поэтому важно установить контакт как можно скорее, поскольку это самый быстрый способ решения даже самых сложных проблем.
Пока я писал этот текст, мне пришло в голову ещё кое-что: члены команды должны ладить между собой. Из моего опыта следует, что начало каждого проекта — самая сложная часть. Довольно очевидно, не правда ли?
Это может показаться сложным, но именно в такие моменты команда лучше узнаёт друг друга. Бизнес-аналитик понимает, чего ожидать от разработчиков, а разработчики осознают, что от них требуется, и какова роль бизнес-аналитика в общем процессе. Даже если что-то пойдёт не так (и это будет не проблемой), обе стороны знают, что они могут положиться друг на друга.
Невозможно создать качественный продукт без участия аналитиков и разработчиков. Они должны работать сообща, чтобы достичь успеха.
Аналитики играют ключевую роль в проекте. Они предоставляют задачи, запрашивают оценки и статусы. Они также являются центральным источником информации о проекте. Если что-то непонятно, ответственность за это лежит на аналитиках, а не на разработчиках.
Аналитикам нравится работать с разработчиками, потому что они превращают слова в функциональную программу. Это требует не только программирования, но и понимания того, что имел в виду аналитик, и воплощают это в жизнь.
В завершение нужно подчеркнуть важность взаимопонимания, коммуникации, сотрудничества и координации. Эти принципы являются основой успеха. Работа команды строится не для того, чтобы бороться за первенство, а чтобы работать сообща, каждый в своей сфере ответственности. Только объединив усилия, мы сможем успешно завершить проект.