Flow. Вопросы к бизнес-анализу и системным требованиям?
#конференции #мысливслух

Вчера была возможность освободить день, удобно устроиться перед экраном и поучаствовать в конференции Flow, на этот раз JUG RU предложили только онлайн. Приманкой были не записываемые пара воркшопов и дискуссии после докладов.

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

▫️Нажала плашку с названием «Бизнес-анализ: Ремесло или искусство». Александр Белин выступал в формате живой беседы без презентации. Разговор пошел о том, что бизнес-анализ не должен быть ни ремеслом, ни творчеством. Анализ как часть процесса проектирования продукта должен быть воспроизводимым, в отличие от свободного творчества. Аналитик тратит время на создание объемных артефактов и делает это в отрыве от команды. Вся информация бизнес-анализа, кроме конечной постановки, остается не востребованной другой частью команды. Чтобы этого не происходило, нужно анализ превратить в инженерию разработки систем.

Стало живее, когда у спикера случился сбой связи, тут у ведущего появилось время на коменты из чатика, а у аудитории набросать еще вопросов. Что сделать, чтобы анализ стал инженерией, обсуждали в дискуссии после доклада. Перенять практики INCOSE и использовать автоматизированные платформы для создания моделей и хранения информации в актуальном состоянии. Средствами платформы каждый может получить информацию в том виде, какой ему нужен, в том числе и документ заданного формата.

В ожидании записи вчерашнего интервью можно посмотреть доклад Александра Белина на Flow 2023

▫️Еще была плашка с провокационным названием «Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту». Не уверена, что провокация удалась. Иннокентий Бодров поделился наблюдением, что ТЗ обычно содержит 0,1% информации про проблему, еще 20% - пользовательские требования, а остальное — системные требования. Причины: 1) решаемая проблема мало изучена, команда предпочитает находиться в области решений 2) на согласование выносится много деталей решения, чтобы основную ответственность за проектирование перенести на согласующих. В случае экспертной, зрелой команды аналитику лучше оставить проектирование системы архитекторам и разработчикам, сосредоточиться на исследовании проблем бизнеса и не тратить время на мега-детальные описания решений. В презентации был показан пример классического верхнеуровневого Use Case в табличном формате. Подход не предлагает отказаться от системных требований, а предлагает сместить фокус работы аналитика на задачи более важные в его роли, если того позволяет зрелость команды.

Подключилась послушать дискуссию после доклада. Когда взглянула на иконку с человечком под основным экраном, она показала 32 участника. В разговоре выяснили, что детальные описания совсем не плохо, просто дорого. В нынешней команде спикера не ведется описания объектов, есть только глоссарий, атрибуты можно найти в коде. Не обошлось без карьерных вопросов. Погрустили о том, что никто не знает, чем занимается аналитик, настолько сильно тренд ушел в сторону проектирования. Закончится ли это? Кажется, закончится с развитием ИИ, который вытеснит рутинную работу и тех, кто умеет делать только ее.

Тут я заслушалась и пропустила закрытие ☺️

7 часов онлайна — это тяжко. Очень не хватало контакта между спикерами и аудиторией, того самого нетворкинга, ради которого мы и ходим на конференции. Не нашла в этот раз даже какого-нибудь шумного холиварного чатика. Просто выключила монитор, закрыла ноут и пошла сочинять этот пост 🌱