27 и 28 мая в г.Москва прошла 14-я Международная конференция по системному и бизнес-анализу Analyst Days 14, в которой я приняла участие в онлайн-формате. На конференции было 4 секции, в каждой из которых выступали одновременно по 4 докладчика. Следовательно, в один момент времени послушать можно было только один доклад из 4-х, хотя и была возможность переключаться между вкладками видео (а для участников оффлайн – перемещаться из зала в зал). Тем не менее, я выбрала для себя изначально наиболее интересные темы докладов (заранее была выложена программа конференции), и прослушала каждый выбранный доклад от начала и до конца. Презентации всех представленных на конференции докладов размещены организаторами по ссылке https://disk.yandex.ru/d/2Is7_kr0DZ34hA
Далее приведу свой субъективный краткий обзор по наиболее интересным из прослушанных мной докладов и впечатления от конференции в целом.
Первый доклад Елизаветы Головановой (представителя Лиги Цифровой Экономики) был о наставничестве надо новыми сотрудниками. Выбрала для себя эту тему по причине того, что наша Компания постоянно растет, особенно в нынешних реалиях при востребованности IT-специалистов в принципе. Приходят новые аналитики, в том числе молодые специалисты – так называемые, джуны (далее по тексту постараюсь по минимуму использовать неологизмы, либо их расшифровывать J). Елизавета говорила о том, как быстро и качественно адаптировать нового члена команды, при этом не теряя продуктивности по основным задачам. Были приведены примеры из собственного опыта наставничества над начинающими сотрудниками, озвучены основные проблемы адаптации новых сотрудников и способов их решения. Основной вывод: адаптация нового сотрудника – это инвестиция в работу своей команды. Важно обеспечить новичку понимание своей роли в команде, обозначить его зону ответственности, основные внутренние процессы. И, что самое важное, при допущении новичком ошибок – решать проблему и обозначить важность их последствий для проекта, а не «проходиться по личности» сотрудника, давать подопечному обратную связь и показывать свою заинтересованность в адаптации.
Следующий доклад стал лично для меня (да и для многих других, судя по отзывам в Telegram-канале конференции), одним из ключевых. Это был не просто доклад, а воркшоп, т.е. проходил он в формате мастер-класса. Вместе с ведущим Андреем Бураковым (Компания ArchWays), мы, участники, обсудили и «пощупали на практике» два способа собрать процесс из нескольких сервисов: оркестрацию и хореографию. Очень полезно специалистам, участвующим в проектировании архитектурных решений и тем, кому интересна работа с микросервисной архитектурой. Поскольку мой Департамент последнее время занимается взаимодействием систем линейки АЦК и продуктов платформы ICE, мне это стало особенно интересно. Вот какие особенности обоих подходов я и остальные участники для себя извлекли:
1. Оркестрация (оркестратор) по сути своей синхронен, так как в него заложена идея последовательности обработки запроса, передающегося в соответствующие сервисы. Нам были озвучены популярные продукты для реализации подхода оркестрации, такие как Camunda (есть еще много, но в условиях санкций нас интересует только открытый код). Оркестрацию можно (и нужно, как я поняла), применять, когда бизнес-процесс предсказуем. В случае автоматизации деятельности финансовых органов, на мой взгляд, это оптимальное решение.
2. Хореография – это, в первую очередь, межсервисное взаимодействие без единого управляющего центра. Это подход для «более непредсказуемых систем» а-ля автоматизация заказов такси и ритейла J
Еще один наиболее понравившийся мне доклад, опять-таки, на тему организации взаимодействия микросервисов. Это доклад Валерия Разномазова (Южный федеральный университет, Ростов-на-Дону) «Аналитика микросервисов. Практический опыт аналитика в enterprise»
В докладе рассказывалось о практическом опыте работы аналитика на проектах российских банков уровня ТОП-5. В условиях Agile сопровождать "монолитные" решения стало проблематично, и в последнее время все чаще крупные банки (как впрочем, и многие крупные компании) переходят к микросервисному архитектурному стилю. В связи с этим к аналитикам начали предъявляться новые требования. Аналитик больше не "технический писатель", занимающийся документацией, а больше архитектор и центральная фигура в команде, отвечающая как за выбор решения, так и за постановку задачи разработке. Очень интересно была раскрыта тема про «плавный» переход от монолитной архитектуры к микросервисной (касается все того же взаимодействия наших внедряемых продуктов на новой платформе).
И еще один доклад, впечатлениями от которого я не могу не поделиться, т.к. я позиционирую себя как «аналитик-связочник», в особенности занимающийся связкой с АЦК-Госзаказ, БФТ.Закупки и т.д. J Это доклад «Опасные интеграции». Спикер – Ананьева Екатерина, GetAnalyst.ru.
В докладе говорилось, как застраховать свою систему от неприятных последствий организации связей с другими внешними системами, основные тезисы – своевременная документация от систем-приемников, грамотное решение проблем в случае отказа одной из интегрированных систем (ошибка пользователю с «универсальным» текстом, логирование). И опять-таки (да да!) переход интегрируемых систем от монолитных архитектур к микросервисным, во избежание рисков «падения» одной из «сторон» интеграции. ОЧЕНЬ приятным бонусом для аудитории стал подарок от спикера – бесплатный чек-лист в виде pdf-документа по страхованию от опасных интеграций (приложила к письму).
Еще не менее интересными были доклады о возможностях использования продукта Postman при проектировании и тестировании REST API (взаимодействие клиентского приложения и сервера), что, кстати, мы и используем сейчас в работе. Но открытием для меня стало то, что Postman позволяет не только протестировать реализацию, но и написать спецификацию для последующей реализации, на основании которой разработчики уже будут писать код, который, по факту, не придется писать «с нуля», а опираться на спецификацию - так называемый подход «спецификация раньше кода». Это все из области low-code и zero-code, когда процесс описывается аналитиком, а разработчик просто «перекладывает» его на код, не «изобретая велосипед, исходя из текстовой постановки аналитика на Confluence». Данная тема, конечно, раскрыта была не полностью, но очень надеюсь на ее более развернутое представление на последующих конференциях.
Как аналитик, выполняющий функциональное тестирование, я конечно же, прослушала доклад об участии аналитика в тестировании задач. Еще раз убедилась, как важно составлять грамотные ПМИ, которые должны обязательно содержать:
- основной кейс («ради которого», собственно, и делалась доработка)
- дополнительные кейсы (различные не «совсем тривиальные» случаи, которые могут произойти, и реализуемая доработка должна закрывать и такие проблемы)
- «ошибочные» кейсы, т.е. ситуации, которые «не должны происходить», но нужно обязательно проверить, как система в результате доработки поведет себя в таких случаях.
Еще я «была» на мастер-классе по наполнению базы знаний в IT-компании. Здесь я могу сказать, что наш БФТ-Холдинг – первоклассный мастер по ведению базы знаний и документации! На мастер-классе были озвучены рекомендуемые подходы к ведению таких баз, ее основные элементы, регламенты, применяемые к ее ведению (кто использует, кто наполняет). Здесь могу сказать – наша Компания на все 100% может похвалиться идеальным подходом к ведению базы знаний. И я имею в виду здесь все в совокупности - Confluence, внешний сайт, контент в соцсетях, и многое другое.
Импортозамещение в инструментах пока что выглядит скромно. Продукты с открытым кодом были освещены недостаточно полно, но слушателям было обещано максимально раскрыть эту тему в последующих конференциях, которые состоятся уже в этом году.
В общем и целом – развиваем микросервисную архитектуру, прокачиваем навыки в сторону моделирования бизнес-процессов с минимальным участием разработки, будем неравнодушны к молодым специалистам, и… ждем новых интересных конференций J
