“Один раз мы зарелизили неправильную фичу из-за того, что бизнес аналитик ее неправильно описал”
Когда я выбирала тему для статьи, то думала о том, что могло бы помочь мне быть эффективнее как бизнес-аналитику, узнай я об этом лет так на 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. Разработка.
Я не буду детально описывать, что происходит на данном этапе, но хочу сказать, что работа бизнес-аналитика на нем не заканчивается. Для меня этот этап отличается уже полноценным и регулярным “выходом в свет”. Вы уже не сидите день и ночь, прорабатывая требования, а посещаете стендапы, митинги с отдельными членами команды и заказчиками, и теперь можно начинать анализировать свою работу, как бизнес-аналитика. Много ли возникло дополнительных вопросов? Много ли было внесено изменений в требования? Сколько было потрачено времени на довыяснения? Эти и много других вопросов и метрик помогут вам увидеть если не пробелы в вашей работе, то как минимум вещи, которым в следующий раз стоит уделить больше внимания.
Давайте подведем итог и отдельно выделим профит для бизнес аналитика и для команды:
Выгода | Для команды | Для бизнес-аналитика |
Ощущение уверенности | Помогает улучшить понимание основных требований и сократить время на разработку продукта, повышает доверие и уверенность в команде | Позволяет оценить, насколько точно были поняты требования и насколько продукт соответствует ожиданиям |
Возможность влиять на продукт на ранних этапах | Позволяет сделать правильные выводы и улучшить продукт на ранних этапах разработки | Позволяет повысить значимость своей роли в команде, продемонстрировать и закрепить свои профессиональные навыки |
Валидация принятых решений | Помогает убедиться, что принятые решения соответствуют требованиям и не противоречат бизнес-целям | Позволяет проверить, насколько успешно были реализованы задачи, и сделать выводы на будущее |
Получение общей картинки продукта до начала этапа разработки | Позволяет точно определить цели и задачи проекта, а также убедиться, что все участники команды находятся на одной волне | Позволяет более глубоко понять бизнес-задачи и их решение, а также получить более четкое видение проекта |
Обсуждение проблемы с экспертом | Помогает найти наилучшее решение проблемы, учитывая мнение и опыт эксперта | Позволяет получить дополнительную информацию и углубить понимание проблемы |
Проработка пользовательских сценариев для дальнейшего использования при создании тест кейсов | Помогает более точно определить требования пользователя и разработать эффективные тест-кейсы | Позволяет на основе пользовательских сценариев определить функциональность продукта и сделать выводы о его работоспособности |
Налаживание отношений внутри команды, создание доверительной атмосферы | Позволяет улучшить коммуникацию между участниками команды и повысить качество взаимодействия | Позволяет создать доверительные отношения и улучшить процесс обсуждения требований. |