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

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

Когда я выбирала тему для статьи, то думала о том, что могло бы помочь мне быть эффективнее как бизнес-аналитику, узнай я об этом лет так на 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. Разработка.

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

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