7 августа в Санкт-Петербурге прошел Meetup, посвященный роли аналитика в SCRUM (https://events.epam.com/events/ba-meetup-spb). Встреча проходила в формате деловой игры. О своих впечатлениях нам расскажет Константин Семенов — старший бизнес-аналитик и преподаватель в школе бизнес-аналитиков из компании EPAM.
«Идея устроить мастер-класс родилась, как только в отзывах к апрельскому Meetup вопрос о роли аналитика в SCRUM составил чуть ли не половину от общего количества.
То, что по формату подойдет именно деловая игра, сомнений не было никаких. SCRUM в описании довольно прост и неказист, еще раз перечитывать, кто есть, кто и что делает, толку никакого. Иначе бы сами аналитики всё уже поняли бы. А так, понимание, может и есть, а вот осознания нет.
Решил погрузить всех в командную работу. Чтобы заодно было весело и интересно.
Сам я в SCRUM не первый год, так что обилие типовых реальных ситуаций быстро вылилось в пять кейсов, которые я и представил командам. Изначально мы планировали 40-45 человек, пять команд по восемь. Однако реальность превзошла наши ожидания, и на встречу пришло 52 человека.
Для того чтобы справиться с такой толпой, я привлек двух ведущих, которые, успешно разделив обязанности, успевали и помогать командам, и модерировать общение, и поддерживать регламент. Два ведущих — это круто! Для ускорения процесса, как только команда выходила рассказывать о своем кейсе, её вариант выводился на проектор, чтобы ни дай бог не тратить время на чтение вслух. А так, пока вылезут из-за стола, пока ватман раскроют, все уже и прочтут, с чем имеют дело. Да и вопросы по кейсу так задавать удобнее.
Команды сходу включились в работу так яростно, что даже когда вышло время на подготовку ответа, не сразу удалось отвлечь их от взбудораженного обсуждения. Аудитория из других команд прекрасно контактировала с отвечающими. Задавали каверзные вопросы, ставили под сомнение выбранные методы, указывали на недостатки решения.
Поработали хорошо. И я надеюсь не зря. Но есть момент, достойный упоминания.
Все кейсы предполагали, что аналитики возьмут на себя роль Product Owner’a, как это и должно быть в реальности, и таким образом возглавят решение всех описанных в кейсе проблем. Однако многие до последнего отказывались отождествлять себя с человеком, отвечающим за ценность, которую продукт приносит заказчику.
И даже когда наши ведущие, подводя итог, озвучили этот тезис вслух, что Аналитик, PO (Product Owner) и proxy PO — это тождественные понятия, некоторые готовы были это отрицать.
Я надеюсь, коллеги продолжат осмысление этой нехитрой истины и после встречи.
И в конце я десять минут поговорил о том, что БА, по сути, ничем не отличается от СА. Это один и тот же человек, который применяет одни и те же навыки аналитика, но в разных ситуациях и на разных уровнях абстракции. А если СА вынужден заниматься проектированием системы, то не потому, что это его обязанность, а исключительно от бедности ума команды разработки, неспособной выполнить свои прямые обязанности».
Ссылка на кейсы: https://drive.google.com/open?id=1FXnspvvAHTHfpM-EHgJ6-YDgKV6_WN-0