top of page

Бизнес-аналитик и команда

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


Когда я выбирала тему для статьи, то думала о том, что могло бы помочь мне быть эффективнее как бизнес-аналитику, узнай я об этом лет так на 5 раньше. И самой близкой оказалась тема взаимодействия с командой. Нет, не потому что отношения с командами не складывались - все мои команды были настолько дружелюбными и готовыми помочь, насколько это вообще возможно. На тот момент, в моем понимании, профессионализм заключался в том, чтобы закрывать максимум вопросов самостоятельно, не вовлекая команду. Давайте разберем, почему это не работает?


1. Бизнес аналитик - не разработчик.


Имея степень магистра в области разработки программного обеспечения, я признаю, что любой Junior developer обладает теми техническими скиллами, о которых я и думать забыла. И вот именно они со своей стороны ответят на технические вопросы точнее и быстрее, именно они из нескольких вариантов предложат именно тот, который будет оптимальнее и правильнее с точки зрения реализации, и именно они будут стоять на страже всех наших non-functional requirements.

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


2. Бизнес-аналитик - не QA.


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


3.Бизнес-аналитик - не PM.


Как бы я не изучала риск-менеджмент, сколько бы я не составляла себе списков возможных рисков, на которые стоит обратить внимание, проектные менеджеры всегда найдут, что добавить со своей стороны. Более того, в то время когда разработчики и тестировщики вдаются в детали, PMы всегда держат у себя в голове целостную картину проекта, и именно они не дадут отойти от initial vision и взять что-то out of scope.

Быть на одной волне с ПМами - это всегда показывать отличный комнадный дух (team spirit) заказчику, на важных коллах ваш самый главный союзник и даже иногда спаситель - это проектный менеджер (и работает это в обе стороны).

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


4. Бизнес-аналитик - не дизайнер.

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



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


1. Анализ требований.


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


2. Спецификация требований.


На этом этапе бизнес аналитик снова ненадолго возвращается в свой мир для написания требований уже в более детальном формате (например, user stories + acceptance criteria). Сразу после этого - одна из важнейших, как по мне, частей - обсуждение требований с командой. На этом этапе у нас уже будут отброшены те требования, которые мы не можем реализовать из-за технических ограничений, поэтому мы работаем уже с готовым и детально описанным списком требований. Чтобы показать какую реально пользу может принести команда, я бы хотела предоставить список вещей, которые были бы упущены, если бы я не набиралась смелости для того чтобы прийти к команде со своими наработками:


  • всевозможные валидации;

  • корректная обработка исключений в работе системы;

  • аналитика для отслеживания метрик;

  • нефункциональные требования;

  • кросс-платформенность.


И это далеко не весь список. Такие сессии для проработки требований особенно актуальны на начальных стадиях проекта, а потом они зачастую переносятся в грумминг беклога.

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


3. Проектирование.


На этапе проектирования мы продолжаем детализировать требования, но что более интересно - это описание сложных потоков выполнения. Вместе с командой бизнес-аналитик занимается созданием (или ревью заранее созданных) диаграмм - например, диаграммы последовательностей и диаграммы активностей. Зачем нам команда, если мы прошли уже столько курсов, прослушали столько вебинаров по Use case диаграммам? Обсуждение поможет нам дополнить диаграмму, если мы что-то упустили, и так же поможет нам упростить ее, ведь еще не раз эту диаграмму мы будем использовать при онбординге новых членов команды или для презентаций техническим специалистам со стороны заказчика.

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


4. Разработка.


Я не буду детально описывать, что происходит на данном этапе, но хочу сказать, что работа бизнес-аналитика на нем не заканчивается. Для меня этот этап отличается уже полноценным и регулярным “выходом в свет”. Вы уже не сидите день и ночь, прорабатывая требования, а посещаете стендапы, митинги с отдельными членами команды и заказчиками, и теперь можно начинать анализировать свою работу, как бизнес-аналитика. Много ли возникло дополнительных вопросов? Много ли было внесено изменений в требования? Сколько было потрачено времени на довыяснения? Эти и много других вопросов и метрик помогут вам увидеть если не пробелы в вашей работе, то как минимум вещи, которым в следующий раз стоит уделить больше внимания.


Давайте подведем итог и отдельно выделим профит для бизнес аналитика и для команды:


Выгода

Для команды

Для бизнес-аналитика

Ощущение уверенности

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

Позволяет оценить, насколько точно были поняты требования и насколько продукт соответствует ожиданиям

Возможность влиять на продукт на ранних этапах

Позволяет сделать правильные выводы и улучшить продукт на ранних этапах разработки

Позволяет повысить значимость своей роли в команде, продемонстрировать и закрепить свои профессиональные навыки

Валидация принятых решений

Помогает убедиться, что принятые решения соответствуют требованиям и не противоречат бизнес-целям

Позволяет проверить, насколько успешно были реализованы задачи, и сделать выводы на будущее

Получение общей картинки продукта до начала этапа разработки

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

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

Обсуждение проблемы с экспертом

Помогает найти наилучшее решение проблемы, учитывая мнение и опыт эксперта

Позволяет получить дополнительную информацию и углубить понимание проблемы

Проработка пользовательских сценариев для дальнейшего использования при создании тест кейсов

Помогает более точно определить требования пользователя и разработать эффективные тест-кейсы

Позволяет на основе пользовательских сценариев определить функциональность продукта и сделать выводы о его работоспособности

Налаживание отношений внутри команды, создание доверительной атмосферы

Позволяет улучшить коммуникацию между участниками команды и повысить качество взаимодействия

Позволяет создать доверительные отношения и улучшить процесс обсуждения требований.



590 просмотров0 комментариев

Недавние посты

Смотреть все

Comments


bottom of page