Speaker A
про свой опыт и то, с чем приходилось сталкиваться, чем занималась.
Интервью кандидата на системного аналитика: опыт, методологии Scrum/Kanban, груминг и покер-оценка, техники выявления требований, нефункциональные требования и работа с Kafka, SOAP, REST.
Key Takeaways
- Кандидат обладает широким опытом системного аналитика: от сбора требований до проектирования микросервисов и интеграций.
- Практикует как командный, так и покерный подход к оценке задач в Scrum.
- Глубоко работает с нефункциональными требованиями, особенно в части безопасности финтех-систем.
- Интервью охватывает типичные темы собеседования системного аналитика: методологии, техники, нотации, интеграции.
What the video covers
- Кандидат-системный аналитик с опытом более 6 лет, работала с монолитами и микросервисами, замещала архитектора.
- Использует нотации BPMN, UML Use Case, UML-классы и C4; интеграции REST, SOAP, gRPC, WebSocket, webhooks, SSE, Kafka.
- Опыт работы с веб- и мобильными приложениями, преподаёт junior и middle аналитиков, проводит собеседования и онбординг.
- Работала по Kanban в X5 Retail Group (Camunda, исполняемые BPMN) и по классическому Scrum на последних проектах с двухнедельными спринтами.
- Описывает два типа груминга: командный с разбиением стори на подзадачи и оценкой, и груминг лидов с оценкой методом планирования покером.
- Техники выявления требований: интервью, анкетирование, ивент-шторминг (4–6 часов), выезды к пользователям, трассировка требований.
- Работа с нефункциональными требованиями (доступность, надёжность, масштабируемость, безопасность) в финтех-проектах с данными класса К1/К2 в тесном взаимодействии с командой безопасности.
- Обсуждается миграция с монолита на микросервисы: приоритизация, сбор требований, миграция данных, поддержание старых интеграций.
- Состав спецификации микросервиса: разделы, описание БД на физическом уровне, история версий, примеры контрактов.
- Опыт с SOAP (Сбербанк) и Kafka (брокер, партиции, топики, гарантированная доставка, protobuf).
Full Transcript — Download SRT & Markdown
Speaker A
Угу.
Speaker A
В IT уже системным аналитикам опыта более 6 лет.
Speaker A
Работала с такими видами архитектур, как микросервисы, монолиты, переход с монолита на микросервисы.
Speaker A
По стеку, по нотациям это использую для бизнес-процессов: BPMN, UML Use Case, UML-классы для отрисовки моделей для базы данных, а также C4 для архитектуры.
Speaker A
Сейчас активно замещаю архитектора, поэтому все четыре дополняю, наши новые сервисы, топики и так далее.
Speaker A
А по интеграции за весь опыт использовала синхронные: REST, SOAP, gRPC, вебсокеты, вебхуки, SSE, а Kafka, а также интеграцию через базу данных, у нас была с файловым хранилищем.
Speaker A
Ну и в целом основные задачи — это сбор и описание требований, интервью заказчиков, бизнес-аналитиков, product-менеджеров, в зависимости от того, от кого приходят требования.
Speaker A
А дальше уже на основании этих требований я строю спецификации, например для фронта, для бэкенда, то есть в таком full-stack аналитике, не только для описания фронтовой части или бэкендовой.
Speaker A
Вот.
Speaker A
Ну и, собственно, в опыте есть разработка как веб-приложений, так и мобильных приложений.
Speaker A
Дополнительно также являюсь преподавателем для junior и middle аналитиков.
Speaker A
Тоже провожу собеседования, провожу онбординг сотрудников, ну и набираю к нам в команду аналитиков.
Speaker A
Был опыт такой на двух последних проектах.
Speaker A
Начнём с методологии разработки, по которым приходилось работать.
Speaker A
Расскажи, пожалуйста.
Speaker A
Угу.
Speaker A
Методологии были канбан и скрам.
Speaker A
Канбан мы использовали в X5 Retail Group, так как у нас там не совсем такая продуктовая разработка была.
Speaker A
Мы там больше были как системные аналитики-разработчики, потому что в Camunda отрисовывали бизнес-процессы, а дальше через JavaScript делали уже эти схемы исполняемыми, заливали на стенды, сами тестировали.
Speaker A
А здесь у нас не было таких итераций.
Speaker A
Ну, там два недели проходит спринт-релиз, мы там релизились раз в три недели либо раз в неделю, как у нас было, готово в неделю, да, как была готова функциональность.
Speaker A
А последние два проекта у нас классический скрам.
Speaker A
Мы работаем итерациями в две недели.
Speaker A
Спринты, планинги, груминги, ретро, демо — вот это все церемонии.
Speaker A
Угу.
Speaker A
А, хорошо, поняла.
Speaker A
А у вас по поводу груминга?
Speaker A
Расскажи поподробнее, какая твоя роль?
Speaker A
А рассказать, Семён, на последнем проекте или, ну, давай в целом вообще, вот как ты видишь роль?
Speaker A
Угу.
Speaker A
А, расскажу, наверное, два прямо противоположных, отличающихся груминга.
Speaker A
Мы собирались всей командой, то есть все лиды направлений и все, ну, там разработчики, аналитики, тестировщики, продукт.
Speaker A
А в главе выступал бизнес-аналитик, который говорил: «Ребята, вот есть стори, давайте её разобьём там на подзадачи».
Speaker A
Ну и в общем, мы разбивали, какие роли, какие интерфейсы, а вернее, какие каналы разработки нам нужно, делили стори на подзадачи, подзадачи для каждого направления.
Speaker A
Дальше уже, например, аналитики обсуждали, что на эту подзадачу надо три дня, разработчики обсуждали, что надо два дня, и в общем формировалась полноценно оценочка, да, получалась конкретная оценка, и мы после этого груминга могли уже задачи планировать, бэклог, то есть они уже были готовыми, оценёнными, можно было заводить.
Speaker A
Сейчас у нас проходит груминг так, что собираются только лиды направлений, то есть лид аналитики, лид тестирования, лид разработки, project.
Speaker A
Мы также смотрим стори, плюс-минус оцениваем, что там нужно сделать, расписываем DoD, расписываем критерии приёмки и через покер оцениваем пальцем.
Speaker A
О, даже через покер играете, да?
Speaker A
Да.
Speaker A
Оцениваем, сколько будет занимать время на эту стори.
Speaker A
Угу, поняла.
Speaker A
А по поводу других техник оценки задач, с какими ещё знакомы?
Speaker A
Мы ещё делали эпики, тоже декомпозировали большой-большой эпик на там много-много задач, тоже описывали, давали некоторое описание этим задачам.
Speaker A
И концептуально, да, нужно было собрать всё воедино и дать оценку.
Speaker A
Ну, собственно, главная встреча груминга — это погрумить, подумать, как это реализовывать, дать оценку.
Speaker A
Ну, плюс локальные ещё груминги бывали, когда уже задача, например, на системном аналитике, и он может не знать, например, как это делать, может выносить на груминг свои вопросы, задачи, предложения, и командой прорабатываем и решаем.
Speaker A
Угу.
Speaker A
О'кей.
Speaker A
А, ну то есть по ещё можно там по... да, декомпозицию WBS строить, можно как-то экспертную оценку просить, можно на основе своего опыта сравнивать, ещё параметрические подходы.
Speaker A
Вот.
Speaker A
Ну, о'кей.
Speaker A
Тогда по техникам выявления: услышала, что интервьюирование практикуешь.
Speaker A
Ещё какие техники, с какими техниками сталкивалась на своём опыте?
Speaker A
Я думаю, что опыт у вас такой большой, это наверняка не только такие вот встречи one-to-one проводила.
Speaker A
Да.
Speaker A
Да, в общем, интервью, там вопросы, ответы, чаты, звонки, это всё понятно.
Speaker A
Были давно анкеты.
Speaker A
Потом недавно мы проводили огромный просто ивент-шторминг четырёхчасовой, потом ещё шестичасовой.
Speaker A
А здесь мы просто на доске каждый шаг клиента продумывали, делали его развилку, ну и на доске всё это через стикеры оформляли.
Speaker A
А какие ещё были сборы требований?
Speaker A
Ну было даже до того, что там командировки, то есть выход в поле, когда, господи, с пользователем работала, или да, да, прямо к заказчикам мы приезжали, за компьютер садились и смотрели, как ребята выполняют, вообще делают то, что мы задумывали для системы, или не то.
Speaker A
Ну и да, и собственно проводили, грубо говоря, тоже такое вот общение: «Что есть вот ещё тут такие фичи, тут такие... А чего вам не хватает? А для чего вам это? А если мы сделаем так, то повысит ли здесь конверсию? Повысим ли мы такую-то, например, метрику?»
Speaker A
Вот.
Speaker A
А бизнес-аналитики у нас ещё, например, делали через трассировку требований.
Speaker A
Я тоже в этом участвовала, но уже косвенно.
Speaker A
Вот чисто посмотреть, что действительно по ревью трассировка проходит, то есть табличный вид, выписываются юзкейсы, выписываются шаги, и посмотрели, чтобы они не пересекались там друг с другом, не блокировали друг друга.
Speaker A
А, прикольно.
Speaker A
Так, ну, соответственно, тут, наверное, вопросов нет.
Speaker A
По типам требований, по иерархии требований, тут можешь что-то рассказать по теории или по практике своей, из того, с какими уровнями требований работала, какие собирала, документировала?
Speaker A
Да, получается, у нас есть бизнесовые требования, есть пользовательские требования.
Speaker A
Если дальше раскручивать по иерархии, там функциональные, нефункциональные требования, вот с ними, наверное, чуть ли не каждый день работаю.
Speaker A
С пользовательскими требованиями здесь мы совместно с дизайнером это всё прорабатываем.
Speaker A
Вот.
Speaker A
Ну, бизнесовые требования здесь всё-таки больше бизнес-аналитик либо продакт-менеджер.
Speaker A
А, ну есть БТР, по сути.
Speaker A
Ну, конечно, я понимаю, что БТ — это всё-таки не твоя зона ответственности.
Speaker A
И тоже Екатерину могу иногда перебивать, потому что времени у нас очень мало, а хочется поговорить на разные темы и успеть достаточно много чего покрыть.
Speaker A
О'кей.
Speaker A
По функциональным, нефункциональным: вот тут хотелось бы поподробнее остановиться именно на нефункциональных требованиях.
Speaker A
Мне кажется, я даже в твоём резюме видела, что ты собирала там требования к безопасности.
Speaker A
Вот расскажи тоже поподробнее: какие, что ты как аналитик делала с вот с нефункциональными требованиями?
Speaker A
Просто ли документировала, или действительно собирала метрики какие-то, анализировала, сама выставляла какие-то требования, NFR, вот, или там ещё что-то?
Speaker A
Да, как системный аналитик, особенно в части проработки интеграции, нам нужно было собрать много нефункциональных требований, и по доступности системы, и по надёжности, и по масштабируемости.
Speaker A
Ну и, в частности, в безопасности.
Speaker A
А так как ещё работала на парочке финтехов, у нас была информация, которая маркировалась К1, К2, то есть конфиденциальная персональная банковская информация.
Speaker A
Поэтому у нас было плотное и тесное взаимодействие с командой безопасности, чтобы мы прорабатывали такие решения, которые не нарушали бы, ну, в общем, не могли бы мы потерять данные, кто-то, да, смо
Speaker A
потом использовала агрегированные значения. Это там сумма countт, а из сложных, ну, использовала джойны, использовала группай, ну, и под запросы тоже делал. Это когда селектну три селекта.
Speaker A
А можешь рассказать, зачем нужен? Закруто. Винхвин - это значит условие уже идёт на агрегатные значения, и он используется после операции группировки для фильтрации вот агрегатных функций. Если мы используем вот АГ там сум, то он нужен для именно них.
Speaker A
А, о'кей. Тогда давай перейдём к архитекторам. Ты говоришь, что говорила, что сейчас замещаешь архитектора. Какие конкретно задачи ты выполняешь вот при проектировании архитектуры? То есть, а какие задачи выполняют?
Speaker A
Соответственно, приходит бизнес, говорит: "Нам нужно это, а мы, ну, какую-то какую-то задачу". Мы понимаем, что пока наша архитектура, например, такое не может, и мы, а, ну, я начинаю думать о том, что как нам это реализовать там например добавить
Speaker A
новый сервис, либо там сделать интеграцию с таким-то сервисом. Соответственно, иду в ту команду, общаюсь, э, м, понимаю, могут ли они обеспечить там эти данные или нет. Вот, допустим, если нужно разрабатывать свой сервис, то отрисовываю его уже на архитектуре. Ну и, собственно, уже
Speaker A
описываю в документации, там из чего будет состоять сервис, там какие у него будутпоинты либо там JRPC методы.
Speaker A
Ну, зависимости от задачи, то есть что там нужно, то и описываю. Если, например, к нему кавка должна быть с ним подключена, то тоже отображаю кавку.
Speaker A
Какие топики, по каким топикам он там, например, будет писать, читать. Угу. О'кей. Тогда увидела у тебя в резюме, что был опыт работы с монолитами, в частности, задачи по декомпозиции монолита на микросервисы.
Speaker A
Вот. можешь поподробнее рассказать про этот опыт, какая и какая была твоя роль как аналитика вот при решении этой задачи?
Speaker A
А нам нужно было большой монолит перевести чуть-чуть по кусочкам на современный стек. А что для этого я делала как аналитик? Во-первых, изучала документацию всего монолита, всей его базы данных и свагера, что у него там был, какие были, а, раззапросы. Вот.
Speaker A
Дальше дальше я уже составляла списком его функциональности. Мы определяли по приоритетам, что с чего мы начнём переносить там с монолита на микросервисы. По приоритетам мы определили, и здесь нужно всегда монолит переносить с наименее там сложных функций, а для того, чтобы постепенно
Speaker A
потихонечку можно было распутывать этот клубок. Вот выделяли один отдельный сервис. Ну и в в микросервисной архитектуре есть паттерн удушение, называется. И вот через удушение, собственно, постепенно перевод на микросервис, мы переводили сначала одну функциональность, потом другую, потом третью. Потом нужно было обязательно
Speaker A
обеспечить требования к миграции данных. То есть в какой момент, когда мы там, например, будем делать репликацию данных, когда мы полностью там отключаемся от этой базы и только в новую ходим. Вот. Вот, то есть по задачам это исследование функциональности, это распределение
Speaker A
приоритизации, что сначала переносим, потом а сбор требований для новых уже микросервисов, ну, миграция данных, потом там уже дальше накидываем разработку новых интеграций, ну, либо старых, да, поддержание старых интеграций уже через микросервис.
Speaker A
Я я поняла. Хорошо. Скажи, с какие какие паттерны ещё ты знаешь по декомпозиции монолита на микросервис помимо удружения?
Speaker A
А, а технические паттерны или бизнесовые? Давай бизнесовывае, да, есть паттерн деления по доменам, по поддоменам, по бизнес-функциям. А когда снова же мы берём большой-большой монолит наш, э, определяем все его бизнес-функции и начинаем уже, а, собирать из того, какие мы функции,
Speaker A
например, объединим и положим в один микросервис, какие функции мы начнём разбивать отдельно по, а, по отдельным микросервисам. Определили домены, определили поддомены, определили. Там ещё есть такой класс, как божественный класс, по-моему, он называется. А определили, какие данные могут быть,
Speaker A
например, и в том сервисе, и в том сервисе, чтобы обеспечить согласованность данных и снова же, чтобы эти данные не дублировать между собой.
Speaker A
Угу. Супер. А тогда м чтобы не тратить время, вот по поводу проектирования микросервисов с нуля, а расскажи что включала типовая спецификация, которую ты разрабатывала на микросервис? Какие разделы, может быть, ну и в целом, что ты укажешь, да? А значит, спецификация, описание
Speaker A
микросервиса, что у него входит в шапке, что за микросервис, зачем он нужен, какие, по каким контрактом он работает.
Speaker A
Ну, вернее, там, например, R jon, там Кавка. Дальше у нас идёт описание самого микросервиса, например, что он там делает. Потом раздел отдельно посвящённый РСТу, какие попоинты в него входят. Полностью описание попоинтов, зачем, для чего там описание алгоритмов, запросов ответов, ошибок.
Speaker A
Ну, там телозапроса, тело ответа, да, при необходимости. Потом разделы из JRPC у нас были, где мы описывали методы JRPC. Раздел в скавкой, а где в какие топики пишет сервисы, из каких читает.
Speaker A
Отдельный раздел для интеграций, если он интегрирован с другими сервисами. Снова же там протоколы, контракты, описание работы этой интеграции. Потом а отдел был посвящён нефункциональным требованиям, которые нужно было придерживаться на этом микросервисе.
Speaker A
отдельно раздел, посвящённый базам данных. Каждая табличка описывается снова же вот на физическом уровне. А, ну что там было? Какие-то, по-моему, просто комментарии. Ну и история версий, версионирование документации.
Speaker A
О'кей, супер. Всё, достаточно полноты рассказала. Прямо спасибо. А что ещё хотелось бы с тобой обсудить? Я думаю, по микросервисам всё тут понятно. Аа вот по поводу интеграции вижу, что работала с и с синхронными синхронным взаимодействием, и с асинхронным. по
Speaker A
поводу взаимодействия по росту. Расскажи, то есть как как ты здесь, получается с нуля проектировала или же дорабатывала или какой здесь опыт? Лучше про расскажи. Прямо у меня, наверное, большинство и даже практически, наверное, мало было, когда что-то дорабатывала больше это
Speaker A
разрабатывала. Наверное, за весь опыт уже больше 100 запросов разработала. С нуля, да, соответственно, с нуля. А где-то мы делали подход Openф, когда в Свагере я через Ямул проектировала опишку. Я получается через о через онапе, да? Угу.
Speaker A
А и второй момент - это когда просто в конфлюнсе по шаблончику описывала тоже из чего будет состоять запрос. Там метод endpoint а query pass параметры тело запроса тела ответа коды ответов ошибки, алгоритмы обработки запросы или ответа.
Speaker A
Ну и примеры, наверное, тоже какие-нибудь и примеры контракта, соответственно, да, в Gне, ОК. Скажи, какой у тебя опыт работы с Суапом? СОПМ. Это было только в Сбербанке очень давно. Как раз-таки дорабатывала попоинты, по которым у нас происходили запросы. Что делала? Дорабатывала XML
Speaker A
схемы с XSD. Ну и, собственно, тестировала, да, через Swager UI SUAP. Ой, через SUAP UI.
Speaker A
А, то есть даже и с тестированием сталкивалась или так? Точно. Ну, точечно для того, чтобы самой понять, как это работает.
Speaker A
А, о'кей. Так, ты немножечко расскажи про твой опыт проектирования синхронного взаимодействия. Слышала, что работала с кавкой. Вот что ты здесь делала?
Speaker A
Поднимала ли кавку с нуля, проектировала или подключалась к рабочим очередям уже? Вот сама с нуля я не девокс, поэтому я неё на стендах не поднимала, не разворачивала кластеры, только подключалась через интерфейс. Есть кавка UI ещё ещё есть какой-то, забыла, уже
Speaker A
был в Натехи, да. Там я подключалась, соответственно, к брокеру. Ну и, э, смотрела, во-первых, какие у нас есть там топики партицы. Во-вторых, когда сама разрабатывала топики, сначала это просто описывала, документировала, потом уже смотрела, что, ну, что они есть там,
Speaker A
да, на Кавке UI. Вот. Ну, а дальше уже достировщики сами там отправляли сообщения либо вычитывали их. Ну, пару раз, да, я тоже сама, конечно же, заходила, смотрела, какие сообщения лежат в партиях, что у нас там приходит.
Speaker A
Либо, например, там, ну, нужно было в какую-то систему зайти, а код от этой системы приходил в Кавку. Ну, соответственно, тоже я его оттуда выгребала.
Speaker A
получала сама как аналитик, что описывала по Кавке. Ну вот плюс-минус как перечислила по росту, что проектировала только здесь также контракт для Кавки, кто вызывает, когда либо кто вычитывает, когда, что мы с этими данными делаем, откуда их записываем, либо куда складируем. Вот.
Speaker A
Ну и по нефункциональным требованиям тоже здесь описывала. А что описывала по нефункциональным требованиям? Оче, а, например, о том, что у нас там была одна из интеграций с командой, которая там нельзя было вообще никак терять сообщения. Вот поэтому здесь мы, ну,
Speaker A
во-первых, сообщение о том, что у нас должна быть гарантированная доставка, а, во-вторых, о том, что мы должны там ответ, например, отправлять на получение этого сообщения. Вот потом конкретные там протоколы, например, что мы должны реализовать, десереализовать и в протобафе передавать эти данные.
Speaker A
Угу. Да, в принципе, достаточно. Вот расскажи, пожалуйста, каким образом ты рассчитывал количество партиций, которые будут включены в топик? А здесь, во-первых, сначала там мы формулу использовали в зависимости от того, сколько данных мы хотим гнать через капку, а и сколько у нас есть железа на
Speaker A
это. Вот здесь больше разработчики с девопсами сами считали, но а потом уже девопсы настроили так, что у нас автоматически там при превышении такого-то порогового значения сообщений а добавляется партиция.
Speaker A
Угу. А, о'кей. Слышала, что ещё сталкивалась с интеграцией через базу, да? А вот скажи, с ещё с какими-нибудь видами асинхронного взаимодействия ты сталкивалась?
Speaker A
Ну, через файловое хранилище, можно оно сказать. Ну, это тоже база, наверное. Вот. Потом, а, ну, в теории хорошо, наверное, понимаю шину USB Enterprise севиice Bass тоже, потому что соседние команды с ними много работали.
Speaker A
Угу. О'кей. Но сама с пошине интеграции не прорабатывала, да? У А, хорошо. Расскажи, пожалуйста, про свой опыт тестирования рестапи, то есть про тестирование SUAP. Я уже поняла SUAP.
Speaker A
Про рестапе приходилось, когда тестировать, например, когда мы хотим интегрироваться с другой командой, то я прихожу к этой команде и, собственно, мы там обсуждаем предмет нашей интеграции и коллеги могут выдавать коллекцию в Посмане, типа вот, ребята, держите, у нас есть ручки, а можете там дёргать
Speaker A
нас, да, и, собственно, нам там выдавали апи ключи, либо мы там получали двоти токены. И по этим ручкам я уже делала запросы, смотрела, соответствуют ли м эти там запросы документации их. Ну и на основании уже этого тестирования ставила
Speaker A
задачу у нас своих разработчиков сынгрироваться по этим методам. Угу. Ну, собственно, Свагере ты наверняка тоже работала, да?
Speaker A
Да, конечно. Ну, тем более Open пишется в Свагере. Угу. Ну, я имею в виду, что там тоже можно тестировать опишки в Я скорее с этого не как чтение документации проектной, а именно как тестирование.
Speaker A
Ну, я согласна. В целом тогда, наверное, у меня вопросы закончились, потому что уже эта превышаем вот немножечко. Давай перейдём к завершающей части интервью, к твоим вопросам, если такие вдруг возникли. y
Topics:системный аналитиксобеседованиеScrumгрумингKafkaмикросервисынефункциональные требованияBPMNUMLтребования
