Профессия системный аналитик: развитие сообществ, популяризация профессии и подготовка
Недавно на нашем ютуб-канале выступил Алексей Лобзов — главный системный аналитик Альфа-Банка, техлид аналитиков корпоративного направления. Алексей занимается подбором, онбордингом и развитием системных аналитиков. Так же, он известен на Хабре как alobzov, регулярно выступает с докладами, обучает системных аналитиков онлайн.
Делимся записью эфира и расшифровкой.
Меня зовут Алексей Лобзов, я являюсь главным системным аналитиком в компании Альфа-Банк. Я одновременно выполняю роль технического лидера аналитиков корпоративного направления нашего банка.
Я хочу рассказать о профессии системного аналитика и рассмотреть три вопроса: сообщество аналитиков, популяризацию профессии и подготовку аналитиков, в первую очередь — без опыта работы, то есть, аналитиков начального уровня.
Есть ли какое-то официальное определение системного аналитика и его области ответственности?
Это роль на проекте, в продукте или компании, или профессия/должность?
Системный аналитик — это профессия. На сайте Минтруда есть раздел «Справочник профессий», где можно найти профессию системного аналитика и прочитать, в чем состоит ее описание. Также с этой страницы можно перейти на профессиональный стандарт и узнать, какие функции ожидаются от человека этой профессии.
Хотя, на практике могут быть отклонения. Так или иначе, если вы устраиваетесь на работу на должность системного аналитика, то у вас будет должностная инструкция с обязанностями, которые работодатель ожидает от вас. Отклонения от стандарта, скорее всего, не будут существенными.
Встречались ли на практике разные понимания этой профессии у разных людей, были ли конфликты на этой почве?
Разные понимания этой профессии встречаются повсеместно, и в различных компаниях к аналитику могут предъявляться разные требования. Один из факторов здесь — размер компании. Небольшая компания может быть не готова к тому, чтобы нанять в штат одновременно системного аналитика, бизнес-аналитика, тестировщика и техписателя. Ряд функциональных обязанностей других специалистов может отразиться на системном аналитике.
Если вы общались с людьми, которые имели опыт работы в компании, где системный аналитик занимался проработкой бизнес-процессов, работой с бизнес-требованиями и составлением ТЗ, но не занимался проектированием архитектуры будущей системы и разработкой технических спецификаций на отдельные модули, то может возникнуть непонимание.
На практике встречались кейсы, когда к нам приходил владелец продукта и просил проработать требования по определенным фичам — например, списание за услугу плюс уведомление клиента о списании — и в постановке содержались требования вплоть до того, какой должен быть текст уведомления. Такие примеры задач мы относим к задачам бизнеса, и в системный анализ мы их не берем. Мы ожидаем, что владельцы продуктов дадут нам бизнес-требования — покажут, что нужно сделать — и мы, как системные аналитики и члены команды разработки, совместно с остальными членами команды подумаем, как эти требования лучше реализовать.
Если говорить о конфликтах — до настоящих конфликтов, когда все бы переругались и эскалировали ситуацию до уровня руководителей, на моей практике не доходило. Непонимания решались в разговоре. Я допускаю, что в каких-то компаниях непонимание может принимать более ожесточенный вид.
Я хочу рассказать о сообществах системных аналитиков — существуют ли они вообще, и что из себя представляют. Конечно, ответ «они существуют» слишком простой — я расскажу, как я сам с ними познакомился.
Это произошло относительно недавно; это было тогда, когда я пришел в Альфа-Банк, в начале 2017 года. Тогда моя команда (и еще 4 таких же команды) занималась созданием интернет-банка для юридических лиц и ИП. Каждая команда развивала свой программный продукт, и интернет-банк в целевой картине должен был состоять из этих продуктов. Мы пришли к пониманию того, что все эти продукты невозможно развивать независимо, каждый по-своему.
Например, с интерфейсом пользователь сталкивается в первую очередь, и у одного продукта цвет UI может быть условно песочный, а у другого — серый, а у третьего — еще какой-то; такого нельзя было допускать. Мы пришли к пониманию того, что разрабатывать наши пять продуктов нужно скоординированно. Команды изначально работали по методике, близкой к SCRUM, но с особенностями, которые накладывает банковская специфика. Так или иначе, мы масштабировали SCRUM на пять команд, поработали в таком режиме и выпустили интернет-банк, открыли его на пользователей. Появился любопытный опыт, который я до этого нигде не встречал — в том числе, и в текстах. Поэтому у меня появилась идея поделиться этим опытом.
Я хотел поделиться конкретно с сообществом аналитиков, и передо мной встала задача: найти такое сообщество. Я поспрашивал у коллег из «Альфы»; мне сказали, что есть популярная конференция аналитиков — Analyst Days. Она проходит каждый год, и можно пойти туда и выступить, или хотя бы поучаствовать, узнать какие-то интересности, которые можно будет потом применить в работе.
Я начал анализировать возможность посещения этой конференции — и как спикер, и как обычный участник; в итоге я пришел к выводу, что эта конференция мне не подходит. Этому было две причины: во-первых, в моем понимании, на конференцию приходят серьезные люди с серьезными темами, и участники платят за то, чтобы послушать их и задать вопросы. Во-вторых, я просто не был готов платить за билет участника; у меня был пример — Московское сообщество разработчиков на Python (Moscow Python Meetup), которое ежемесячно проводит митапы со свободным входом. Там можно бесплатно прийти, послушать спикера, задать вопрос, пообщаться с питонистами, съесть пиццу в пицца-паузе; если у тебя есть тема, то ты можешь самостоятельно записаться, заявить тему перед оргкомитетом, и, если тема подходящая, тебя с высокой вероятностью включат в план выступлений. Поэтому я стал искать что-то похожее на MPP, но для сообщества аналитиков.
Поиск выдал мне информацию о сообществе аналитиков с сайтом uml2.ru. Я ознакомился с сайтом, мне все понравилось; даже попробовал сходить на несколько встреч сообщества. В принципе, было все интересно: контент, люди. Не устраивала меня регулярность встреч: по сравнению с сообществом питонистов эти встречи проходили нерегулярно (или я не получал информацию о том, когда будет очередная встреча). Плюс, с сообществом аналитиков у меня не срослось — возможно, были дополнительные факторы. Мне пришлось выступать с докладом у разработчиков на Python.
Время шло; потребность в сообществе осознал не только я, но и мои коллеги из Альфы. В 2018 году родилась внутренняя инициатива: создать собственные митапы для аналитиков.
Мы собрались с коллегами и создали митап AnalyzeIT: первый раз он прошел 20 сентября 2018 года. В 2019 году было еще два митапа, мы планировали проводить их раз в полгода. В том же году прошел митап от сообщества аналитиков Райффайзенбанка — я узнал о нем от коллег из Райфа, которые предложили мне поучаствовать в качестве докладчика. Я не мог отказать; таким образом, я узнал про новое сообщество системных аналитиков, которое мне подходило. Со временем, с моим ростом, с приобретением новых знаний, с общением внутри сообществ я стал узнавать о новых и новых площадках, на которых можно было обмениваться опытом, заводить контакты, организовывать проекты, даже искать новую работу. Из таких площадок я могу выделить Открытый митап для аналитиков: он проходит онлайн, недавно прошла первая встреча, и следующая планируется на 26 ноября. Его идея состоит в том, что, на самом деле, сообществ аналитиков по России очень много; если брать региональную разбивку — они есть в Москве, Петербурге, Екатеринбурге, Перми, других городах, и требовалась площадка, на которой люди из разных сообществ могли бы коммуницировать друг с другом.
Как я уже сказал, 26 ноября будет вторая встреча этого сообщества — IT Analyst Online Meetup. Если вам интересно — зарегистрируйтесь; думаю, она пройдет полезно.
Что делать системному аналитику, когда он пришел на новый проект, а там — плохое покрытие документации, конфликты между пользовательским интерфейсом и бэком? С чего правильнее начать в такой ситуации?
Универсального средства для решения таких проблем нет. Аналитик должен разобраться в текущей ситуации и навести порядок; как именно — зависит от конкретной ситуации. Если нет документации — возможно, стоит выделить время и сформировать ее. Если есть проблемы между интерфейсом и бэком — возможно, стоит состыковаться с фронт- и бэк-разработчиком, привлечь архитектора и вместе решать проблему. Сходу ответить на вопрос невозможно, я думаю.
Я рассказал, что есть несколько митапов для аналитиков, где можно свободно выступить, задать вопрос спикеру, пообщаться с членами сообщества. Помимо митапов, есть и другие площадки; сейчас очень популярны телеграм-группы: у того же Райффайзенбанка есть группа для системных аналитиков, я в ней состою. Там, хотя и не так часто, появляются вопросы, и сообщество с удовольствием предлагает варианты решения проблем. Группа называется Open SA Community Raiff; если вам интересно, тоже заходите. Как пример вопроса: недавно заходила девушка и писала, что работает в системном анализе, но чувствует, что в знаниях не хватает структуры, общей методологии аналитика. Она спрашивала мнения сообщества о том, как получить такую структуру; с одной стороны, можно пойти получить высшее образование, с другой — сейчас есть много онлайн-курсов, в том числе и по системному анализу, и, возможно, стоит идти туда. А, возможно, стоит попросить руководителя или лида побыть ментором и помочь прокачать аналитику. Различные варианты, возможности; в сообществе как раз и обсудили, что может быть лучшим вариантом.
На митапах можно найти работу джуном?
Да, на митапах можно найти работу. Если мы берем митапы от Альфа-банка — там всегда есть HR-специалисты, у них можно получить информацию по вакансиям и передать им свое резюме для рассмотрения. Если в компании есть джуниорские позиции, то можно на них претендовать. Сейчас в Альфе есть оплачиваемые стажировки; конечно, их немного, но они доступны — если бы сейчас проводились митапы, можно было бы на них претендовать. Я думаю, на любом митапе, где присутствуют представители HR компании-организатора, есть шанс найти джуниорскую позицию. Поэтому, ходя по митапам, нужно спрашивать.
Я упомянул телеграм-группу Райффайзенбанка; на самом деле, есть и другие группы. В том числе, можно найти отдельные группы по городам. Недавно на Хабре я видел статью, которую написала Анна Михайлова из консорциума «Кодекс» — статья посвящена теме развития аналитиков. Она упоминала сообщества, приводила ссылки на них; в комментариях читатели накидали других ссылок, на телеграм-группы разных сообществ. Статья называется «Развитие аналитиков». Ссылок там очень много; все вряд ли можно перечислить.
Обмен знаниями проводится и на других интернет-ресурсах. На том же Хабре, в корпоративных блогах, публикуются статьи от аналитиков компаний; также аналитики пишут собственные статьи, без привязки к компаниям. Мне доставляет удовольствие читать Хабр, и время от времени я нахожу полезный материал.
Чем бизнес-аналитик отличается от системного?
Непростой вопрос, потому что есть разные компании. Должности в них называются по-разному, и обязанности системных и бизнес-аналитиков в разных компаниях могут во многом пересекаться, или даже совпадать. Я уже упоминал профессиональный стандарт системного аналитика — для бизнес-аналитика также есть профессиональный стандарт. Можно посмотреть эти стандарты и понять, чем эти профессии отличаются друг от друга. Также я могу порекомендовать статью Ярослава Вартохова, написанную в этом году — она посвящена разнице между системным и бизнес-аналитиком. Всё описано в деталях.
Если кратко — бизнес-аналитик больше работает с бизнес-составляющей. Это работа с бизнес-требованиями, создание процессов, реинжиниринг существующих процессов. Больше процессов и бизнеса. Системный аналитик больше работает с техникой: проектирование архитектуры будущей системы, проектных решений, написание технических спецификаций, плотное взаимодействие с командой разработки. В моем понимании, бизнес-аналитик больше взаимодействует с бизнесом, а системный — с командой разработки. Более формальная граница проводится в профессиональных стандартах. Но, так или иначе, от компании к компании обязанности будут отличаться, и это остается спорным вопросом.
Используется ли вы EPС, или достаточно UML и BPMN?
Если мы говорим про то подразделение, в котором работаю я, то в архитектурных и технических документах мы используем все эти нотации. UML Sequence — наверно, наиболее популярные. EPC мы используем в архитектурных документах, при описании функциональных моделей процессов. BPMN — я лично еще не использовал его, но некоторые коллеги в Альфе используют в описании архитектурных документов.
Если аналитик ищет в enum переменные на C# и сопоставляет их с документацией — это не слишком ли большой отход от обязанностей системного аналитика?
Если таково требование работодателя — я думаю, это отход от обязанностей системного аналитика. Если это ваша собственная инициатива, то тем самым вы показываете, что вам интересно то, чем вы занимаетесь; вы развиваетесь, вы хотите лучше понимать, что делают ваши коллеги по команде — например, .NET-разработчики. В таком случае это — ваше преимущество. То есть, если аналитик разбирается в коде, то это должно быть по его собственной инициативе, а не по требованию сверху. Это на мой взгляд.
Могу сказать, что в Альфе многие аналитики погружаются в код, и даже в ходе анализа кода находят логические ошибки, которые не всегда устраняются на этапе ревью со стороны разработчиков. Например, у нас есть единый сервис, определяющий тип клиента банка. Был написан код, который разделяет организации и индивидуальных предпринимателей, и там был прописан анализ ИНН (12 символов — ИП, 10 символов — организация). Но зачем писать собственную логику, если есть готовый сервис, и все системы банка используют его — это единая точка входа. Если у нас логика как-то меняется, то мы вносим изменения в этот сервис. Если есть альтернативные реализации, то мы должны о них знать и в случае изменения менять код не в одном месте, а в двух. Поэтому, если аналитик погружается в код, то он может выявить неточности в логике работы и помочь их устранить своевременно.
Что лучше использовать для верхнеуровневого проектирования системы? Компонентную диаграмму или диаграмму deployment?
Не могу сказать, потому что требования бывают разные. Даже если говорить о постановке на разработку; у нас есть опытный разработчик, который поймет с полуслова, и есть неопытный разработчик, которому требуется детальная спецификация. Поэтому в данном случае вопрос в том, для кого разрабатывается эта схема, кто является потребителем; в каком виде он хочет получить информацию. Второй момент: в компаниях должны быть стандарты по оформлению документов и моделированию. Каких стандартов придерживается ваша компания? Возможно, у вас принято использовать компонентную диаграмму.
Про сообщества аналитиков поговорили. Если резюмировать, то сообществ на самом деле очень много. Есть конференции — я назвал одну, Analyst Days, но на самом деле их много, та же «Точка сборки» в Питере чего стоит. Помимо конференций, есть митапы аналитиков, телеграм-группы, ресурсы в интернете, где можно общаться и обмениваться опытом.
Что, если вы просмотрели множество сообществ, но не нашли ничего для себя? Вам все еще хочется поделиться информацией с другими или узнать, чем занимаются коллеги из других профессиональных сообществ. В этом случае вы свободны в выборе сообщества из другой области. Например, вы можете посетить сообщество разработчиков, посмотреть, чем они занимаются. Или сообщество тестировщиков, или QA-инженеров — и обменяться опытом там. Я достаточно долго ходил на митапы сообщества питонистов, мне было там интересно; я даже задумывался о том, чтобы стать разработчиком на Python. Также я участвовал в старте сообщества QA-инженеров компании Додо Пицца. Это было в 2018 году; ребята только начинали свои митапы, прошел один митап и готовился второй в феврале. Они искали спикеров и предложили мне выступить с докладом — несмотря на то, что я не являюсь QA-инженером и отношение к тестированию имею опосредованное, только с точки зрения аналитика.
В случае, если вас приглашают в другое сообщество, или у вас есть желание посетить другое сообщество — не стесняйтесь, посещайте, выступайте. Мы все работаем в IT, у нас много точек соприкосновения и общих тем для общения. Например, на втором митапе от Додо Пиццы я выступил с докладом, рассказал, как я (как аналитик) участвую в процессе QA, рассказал о техниках, которые аналитики применяют в своей работе, о тестировочных техниках. Должен заметить, что в наших командах приветствуется развитие Т-компетенций. Это когда у тебя есть основная компетенция (у меня — системная аналитика) и смежная компетенция (разработка, тестирование). Это помогает лучше понимать, чем занимаются коллеги, и иногда подстраховывать их в выполнении простых задач, если они отсутствуют. То есть, можно прокачать компетенции и, например, разработать несколько автотестов с использованием существующего фреймворка. Поэтому, если у вас есть возможность и желание посещать другие сообщества — я очень рекомендую это делать.
Также я хотел упомянуть об организации собственного сообщества. В чем проблема: вы можете пройтись по существующим сообществам, посмотреть сообщества смежных направлений, но вас ничего не устроит; вы видите для себя определенную нишу и готовы запустить собственное сообщество. Если у вас такая ситуация — это хороший опыт; вы можете попробовать войти в эту историю и, возможно, из этого что-то вырастет. На примере Альфы — как я уже говорил, мы запускали собственное сообщество, свои митапы AnalyzeIT. У нас было всего три митапа. Как мы их запускали: у нас была команда аналитиков, которые отвечали за контент, и команда из отдела развития бренда, которая отвечала за организацию помещения, привлечения участников и слушателей и за организацию бургер-пати (потому что какой митап без бургер- или пицца-пати; очень важный компонент — можно перекусить и пообщаться с коллегами, которые пришли на мероприятие). Организация первого митапа потребовала много времени; мы тщательно готовились, отобрали несколько докладов и 3–4 недели проводили их репетиции. Была безумная подготовка, потом — выступили и выдохнули. Остальные митапы были полегче, потому что мы получили опыт, но первый был самым сложным и запоминающимся.
Конечно, сейчас митапы не проводятся из-за эпидемии; в онлайн мы ещё не вышли, но следующем году, возможно, будет развитие.
Мне очень понравилось участвовать в организации сообщества системных аналитиков от Альфа-банка, и — в качестве спикера — в старте сообщества аналитиков от Райффайзенбанка, и в организации митапов для QA-специалистов от Додо Пицца. Все это — полезный опыт.
Я хочу перейти к следующей теме — популяризации профессии. Я, как системный аналитик, хотел бы популяризовать нашу профессию. Зачем это нужно? Я выделил для себя две главных причины того, почему стоит этим заниматься.
Первая из них состоит в том, что до сих пор ощущается острое непонимание рядом специалистов сути того, чем все-таки занимаются аналитики. Оно возникает по нескольким причинам. Во-первых, в разных компаниях под должностью аналитика подразумевает различные вещи — не кардинально, но различия есть.
В одних компаниях аналитики занимаются только работой с требованиями и написанием верхнего уровня в их ТЗ, в других они лезут в БД, делают запросы и пишут хранимые процедуры.
Все относительно и зависит от самой компании. Если она может позволить себе иметь выделенную должность техписателя, то аналитик будет заниматься работой с требованиями и проектирование, а не описанием существующих решений и документированием системы. В разных компаниях — разные требования и ожидания для аналитика, поэтому порой возникает непонимание: чем должен заниматься «эталонный» аналитик?
Если читать интернет-ресурсы — тот же самый Хабр — то можно найти относительно много публикаций на одну и ту же тему: какие типы аналитиков бывают и чем они отличаются. Я видел такие публикации и в 2013 году, и сейчас. Вроде бы прошло 7 лет, но об этом продолжают писать — значит, непонимание сохраняется.
Например, статей о том, какие типа разработчиков на Python бывают и чем они отличаются, нет; понятно, что среди них есть такие, кто занимается разработкой софта, или аналитикой данных с использованием Python для анализа, но статей с разделением их на типы я не встречал. Наверно, с этой специальностью-профессией все понятно, а вот с аналитиками — нет.
Собственно, поэтому я хожу и рассказывают о наших аналитиках. У меня есть опыт системного анализа в Альфа-Банке, и поэтому я фокусируюсь на том, кто же такой системный аналитик в Альфе, чем мы живем, чем занимаемся, как пишем документацию, как оцениваем ее качество, работаем ли мы с метриками продуктов, как происходит развитие наших аналитиков. Я пишу обо всем этом, но с примечанием, что это происходит именно в Альфе; какую-то обобщенную точку зрения на то, кто такой системный аналитик, я не могу дать — для этого лучше воспользоваться профессиональными стандартами. В них написан эталон.
Очень интересный кейс, связанный с популяризацией профессии — я его назвал «кейсом о том, как на двух разработчиков стало меньше». У меня есть два знакомых — девушка и парень; девушка закончила технический университет и искала место для стажировки, парень имел большой опыт работы, последние несколько лет работал в продажах, но хотел сменить деятельность — перейти в ИТ.
То есть, оба искали возможности в ИТ-сфере; конечно, первое, что приходит на ум в связи с ИТ — это программирование, поэтому они смотрели, в том числе, на то, могут ли они зайти на рынок разработчиков информационных систем, и, если могут, то — куда: front, middle. У них были свои предпочтения и обстоятельства. И ребята, на самом деле, не до конца понимали, чем занимается системный аналитик;, но после того, как мы с ними побеседовали, у них появился интерес. Вслед за беседой я привел их на второй митап от Альфы, они пообщались с нашими аналитиками, послушали доклады. Девушка потом устроилась на стажерскую программу в Альфа-банке, прошла ее и теперь работает в одном из подразделений системным аналитиком. Парень прошел через школу системного анализа, тоже у нас, устроился в штат и сейчас работает в другом подразделении.
Популяризовать профессию — надо; это полезно не только с точки зрения снятия неопределенности и внесения ясности в то, чем занимаются системные аналитики, но и с точки зрения привлечения кадров в профессию. Ребята работают уже больше года, у них положительные отзывы — то есть, им нравится; системная аналитика — для них. Без популяризации профессии они могли бы уйти не туда, например — в разработку.
Следующий поинт — откуда приходят в аналитику и куда уходят из неё; это пересекается с одним из вопросов из зала: какая следующая ступень после системного аналитика.
Если брать непосредственно Альфу и бэкграунд некоторых ребят, которые сейчас работают аналитиками, то можно сказать, что в аналитику обычно приходят из нескольких определенных областей. Тестирование — поработал тестировщиком, набрался опыта, хочет заняться требованиями. Сопровождение (в частности, функциональное сопровождение) — «нам надоело поддерживать ваши системы, мы хотим сами разрабатывать новые системы»; ребята хотят войти в команду разработки, и, за счет неплохого технического бэкграунда, они могут успешно зайти на рынок аналитики.
И разработка: ребята, которым надоело писать код и которые хотят заняться проектированием. Все три направления ИТ-шные, смежные, у всех у них есть шанс попасть в аналитику. Также велик пласт ребят, которые приходят к нам с резюме как кандидаты. Достаточно много приходит из бизнес-анализа: они позанимались бизнес-анализом, хотят глубже погрузиться в технику. Также часто встречаются ребята, которые приходят к нам с управленческих позиций: руководители проектов и владельцы продуктов.
На самом деле, ограничений никаких нет. Прийти в системный анализ можно из любой сферы — как я уже говорил, мой знакомый пришел из продаж. Но, наверно, технический бэкграунд и опыт в ИТ — это плюс; больше вероятности найти работу системным аналитиком.
Куда системные аналитики уходят дальше? Если брать модель Альфы, то можно выделить бизнесовое и техническое направление. Бизнесовое направление — это развитие в сторону владельца продукта; будучи аналитиком, ты развивался как член команды разработки, но теперь ты хочешь выйти из команды разработки, взять ответственность за продукт на себя, хочешь, чтобы тебе выделили бюджет, на который ты бы собрал собственную команду разработки и занялся бы развитием интересующего тебя продукта. Техническое направление — это путь к становлению solution-архитектора. Кто это такой? Если взять за пример интернет-банк для юридических лиц, то, с точки зрения клиента, этот банк — большая единая система;, но с точки зрения нас (как команд разработки) он — совокупность программных продуктов, развитием которых занимаются разные команды. Есть команды, которые занимаются развитием приложений по рублевыми платежам, или по депозитам, или по другим направлениям. Много приложений и много команд. Аналитик у нас — во-первых, член команды разработки, и, во-вторых, позиционируется как архитектор в рамках своего программного продукта. Solution-архитектор отвечает за архитектуру всего интернет-банка в целом, работая в более широком контексте, чем аналитик. Аналитик — эксперт в своем продукте, а архитектор должен разбираться во всем банке. Это — второй путь развития аналитика.
Естественно, не забываем про организационную структуру. Если у вас есть возможность, то можно после рядового аналитика или аналитика высокого уровня можно стать руководителем направления, руководителем центра компетенции системной аналитики и далее — руководителем дирекции и так далее, как позволит структура.
Чем отличается старший аналитик от ведущего?
Отличается рядом факторов. В разных компаниях требования к старшему и ведущему аналитикам различаются, но глобально различия включают в себя опыт работы, ряд технических навыков, которые он продемонстрировал в ходе выполнения задач, и набор дополнительных обязанностей, которые аналитик выполняет в дополнение к работе над проектом. Это могут быть обязанности по проведению технических интервью, например: опытный аналитик может общаться с кандидатами и давать взвешенную оценку их скиллов аналитики. Если мы считаем, что он способен это делать, то он явно выше, чем обычный старший аналитик. Или он может отвечать за дополнительный блок работ. В общем, у него обычно больше обязанностей — соответственно его более высокой компетенции. Но от компании к компании требования, которые разграничивают одного аналитика от другого, различаются.
Расскажите про микросервисную архитектуру
Да, в Альфе используется микросервисная архитектура. У нас есть как монолитные, так и микросервисные системы. Мы идем в микросервис.
Третий блок моего выступления относится к подготовке аналитиков, в первую очередь — к подготовке аналитиков с нуля, или подготовке людей, которые еще не имеют определенного опыта в профессии.
У нас одно время была потребность в новых специалистах: банк рос, наше подразделение росло. В какой-то момент мы столкнулись с осознанием проблемы: на рынке не хватало людей, которые удовлетворяли бы нашим критерием. Эта проблема возникла потому, что мы в те времена пользовались, в основном, нашим локальным рынком — то есть, рынком тех городов, где у нас находятся офисы (например, Москва и Санкт-Петербург). То есть, большую часть ребят мы тогда смотрели именно в этих городах и не шли в регионы.
И мы осознали, что в «наших» городах закончились подходящие специалисты. Возникла идея самостоятельного «выращивания» аналитиков с нуля с доведением до такого уровня компетенции, чтобы они могли спокойно выполнять наши аналитические задачи.
Мы провели «пилот» в 2018 году; я познакомился с первым кандидатом — мне предложили провести онбординг. Девушку посадили в мою команду на период испытательного срока; идея состояла в том, чтобы, работая в команде и взаимодействуя с опытными аналитиками, она бы приобрела необходимые знания для джуна и потом уже, в ходе работы, развилась бы в серьезного аналитика. По результатам 3 месяцев девушка показала достаточно неплохой результат; по ее отзыву, она бы прошла план, который мы составили на 3 месяца, за 2 недели, если бы была опытным аналитиком: то есть, у нее уже возникло осознание того, какие навыки и знания она приобрела за это время.
Она почувствовала свой рост, это неплохо. Далее, на протяжении некоторого времени, мы вместе работали. Потом девушку вывели в отдельную команду, и она стала самостоятельным аналитиком. Она до сих пор растет и развивается в банке. Таким образом, мы подтвердили гипотезу того, что мы в состоянии вырастить аналитика с нуля собственными силами.
СОА или монолит?
Могу сказать, что в банке много разнообразных систем. Если вы работали в банке или сталкивались с похожими системами, то вы представляете, сколько их может быть. У нас есть и СОА, и монолиты, и микросервисы — полный набор.
Как эффективно найти работу начинающему системному аналитику?
Много факторов влияет на успех в поисках работы. Немалое значение имеет желание самого кандидата найти эту работу и развиться в области. Бывает так, что человек приходит на курсы, говорит: научите меня. Заканчивает его, получает сертификат, потом ходит по собеседованиям и показывает его. Но если при этом у него нет желания, нет огня в глазах — тогда поиск будет затруднительным.
Как эффективно найти работу начинающему системную аналитику? Прокачивать себя и ходить по собеседованиям. Но не просто ходить: надо определить для себя, в какой компании или в какой сфере ты хочешь работать. Не иметь четкой цели и ходить с желанием попасть хоть куда-нибудь — это не подходит.
Можно наметить, что вы хотите работать в банке, например. Найти стажерские программы, которые предоставляет банк. Если таких нет, то, может быть, банк проводит обучение для внешних специалистов с возможностью трудоустройства. Или, возможно, у банка есть юниорские вакансии, на которые можно претендовать.
То есть, определите для себя компанию, посмотрите, какие возможности по трудоустройству она предоставляет, найдите сотрудников этой компании — наверняка в сообществах аналитиков их можно встретить. Такой комплекс мероприятий может помочь ускорить поиск работы.
На что смотрят при приеме джуна на работу, какой минимум нужен?
Вопрос непростой, потому что до недавнего времени в Альфе начальная позиция называлась «старший системный аналитик». Она подразумевала, что в центр компетенции приходит не джун, а опытный специалист с определенным набором знаний и умений. Просто джунов мы не брали. Были стажерские программы (я уже рассказывал про свою знакомую); там было собеседование и задачи — в частности, на SQL. Я думаю, если вы ищете джуниорскую работу, то надо почитать, что обычно спрашивают на джуниорские позиции. Моей знакомой знаний из института и предварительной подготовки по SQL оказалось достаточно.
На более высокие позиции, на которые собеседую я, мы не рассматривали джунов до недавнего времени; джуны скорее приравнивались к стажерам.
Что является результатом работы системного бизнес-аналитика, с вашей точки зрения?
С моей точки зрения, беря опыт моего текущего места работы, для системного аналитика можно выделить 3 области работы. Проектирование информационных систем, документирование разработанного и разбор боевых ошибок. Если мы говорим про проектирование, то результат — архитектурное решение плюс спецификации на разработку. Для документирования — документация по слоям приложения (фронт, мидл, бэк); часто документация и спецификация пересекаются — то есть, иногда это один документ. Если мы говорим про разбор дефектов — мы, как продуктовая команда, работаем на качество и заинтересованы в том, чтобы наш программный продукт не имел дефектов. Мы стараемся устранить их. Аналитик, в том числе участвует в разрешении дефектов прода.
Какие хорошие команды по системному анализу вы знаете, чтобы джун формировал у себя правильный подход?
На самом деле, я буду рекомендовать св
