**380к! Реальное собеседование на СИСТЕМНОГО АНАЛИТИКА: Выдержала ли я? — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/380k-real-systems-analyst-job-interview-did-i-pass/

Интервью кандидата на системного аналитика: опыт, методологии 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).

## Chapters

1. 00:00 Представление и опыт кандидата
2. 04:00 Методологии разработки: Kanban и Scrum
3. 08:00 Груминг и техники оценки задач
4. 13:00 Техники выявления и типы требований
5. 18:00 Нефункциональные требования и безопасность
6. 22:00 Миграция на микросервисы и спецификации
7. 30:00 Интеграции: SOAP, Kafka, тестирование

Answers

## Questions about this video

Какие методологии разработки использовала кандидат?

Кандидат работала по Kanban в X5 Retail Group, где разрабатывала исполняемые BPMN-схемы в Camunda, и по классическому Scrum на последних двух проектах с двухнедельными спринтами и стандартными церемониями.

Как проходит груминг на последнем проекте?

Груминг проводят лиды направлений: аналитики, тестирования и разработки. Стори обсуждаются, описываются DoD и критерии приёмки, а оценка выставляется методом покера.

С какими нефункциональными требованиями работала кандидат?

Работала с требованиями доступности, надёжности, масштабируемости и безопасности, особенно для финтех-систем с конфиденциальными банковскими данными, в тесной связке с командой безопасности.

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

про свой опыт и то, с чем приходилось сталкиваться, чем занималась.

00:17

Speaker A

Угу.

00:35

Speaker A

В IT уже системным аналитикам опыта более 6 лет.

00:48

Speaker A

Работала с такими видами архитектур, как микросервисы, монолиты, переход с монолита на микросервисы.

01:06

Speaker A

По стеку, по нотациям это использую для бизнес-процессов: BPMN, UML Use Case, UML-классы для отрисовки моделей для базы данных, а также C4 для архитектуры.

01:16

Speaker A

Сейчас активно замещаю архитектора, поэтому все четыре дополняю, наши новые сервисы, топики и так далее.

01:30

Speaker A

А по интеграции за весь опыт использовала синхронные: REST, SOAP, gRPC, вебсокеты, вебхуки, SSE, а Kafka, а также интеграцию через базу данных, у нас была с файловым хранилищем.

01:46

Speaker A

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

02:00

Speaker A

А дальше уже на основании этих требований я строю спецификации, например для фронта, для бэкенда, то есть в таком full-stack аналитике, не только для описания фронтовой части или бэкендовой.

02:16

Speaker A

Вот.

02:29

Speaker A

Ну и, собственно, в опыте есть разработка как веб-приложений, так и мобильных приложений.

02:34

Speaker A

Дополнительно также являюсь преподавателем для junior и middle аналитиков.

02:50

Speaker A

Тоже провожу собеседования, провожу онбординг сотрудников, ну и набираю к нам в команду аналитиков.

03:03

Speaker A

Был опыт такой на двух последних проектах.

03:17

Speaker A

Начнём с методологии разработки, по которым приходилось работать.

03:31

Speaker A

Расскажи, пожалуйста.

03:43

Speaker A

Угу.

04:02

Speaker A

Методологии были канбан и скрам.

04:17

Speaker A

Канбан мы использовали в X5 Retail Group, так как у нас там не совсем такая продуктовая разработка была.

04:34

Speaker A

Мы там больше были как системные аналитики-разработчики, потому что в Camunda отрисовывали бизнес-процессы, а дальше через JavaScript делали уже эти схемы исполняемыми, заливали на стенды, сами тестировали.

04:51

Speaker A

А здесь у нас не было таких итераций.

05:12

Speaker A

Ну, там два недели проходит спринт-релиз, мы там релизились раз в три недели либо раз в неделю, как у нас было, готово в неделю, да, как была готова функциональность.

05:29

Speaker A

А последние два проекта у нас классический скрам.

05:44

Speaker A

Мы работаем итерациями в две недели.

05:57

Speaker A

Спринты, планинги, груминги, ретро, демо — вот это все церемонии.

06:12

Speaker A

Угу.

06:27

Speaker A

А, хорошо, поняла.

06:45

Speaker A

А у вас по поводу груминга?

07:00

Speaker A

Расскажи поподробнее, какая твоя роль?

07:17

Speaker A

А рассказать, Семён, на последнем проекте или, ну, давай в целом вообще, вот как ты видишь роль?

07:34

Speaker A

Угу.

07:49

Speaker A

А, расскажу, наверное, два прямо противоположных, отличающихся груминга.

08:04

Speaker A

Мы собирались всей командой, то есть все лиды направлений и все, ну, там разработчики, аналитики, тестировщики, продукт.

08:11

Speaker A

А в главе выступал бизнес-аналитик, который говорил: «Ребята, вот есть стори, давайте её разобьём там на подзадачи».

08:33

Speaker A

Ну и в общем, мы разбивали, какие роли, какие интерфейсы, а вернее, какие каналы разработки нам нужно, делили стори на подзадачи, подзадачи для каждого направления.

08:43

Speaker A

Дальше уже, например, аналитики обсуждали, что на эту подзадачу надо три дня, разработчики обсуждали, что надо два дня, и в общем формировалась полноценно оценочка, да, получалась конкретная оценка, и мы после этого груминга могли уже задачи планировать, бэклог, то есть они уже были готовыми, оценёнными, можно было заводить.

09:00

Speaker A

Сейчас у нас проходит груминг так, что собираются только лиды направлений, то есть лид аналитики, лид тестирования, лид разработки, project.

09:14

Speaker A

Мы также смотрим стори, плюс-минус оцениваем, что там нужно сделать, расписываем DoD, расписываем критерии приёмки и через покер оцениваем пальцем.

09:26

Speaker A

О, даже через покер играете, да?

09:38

Speaker A

Да.

09:53

Speaker A

Оцениваем, сколько будет занимать время на эту стори.

10:04

Speaker A

Угу, поняла.

10:21

Speaker A

А по поводу других техник оценки задач, с какими ещё знакомы?

10:30

Speaker A

Мы ещё делали эпики, тоже декомпозировали большой-большой эпик на там много-много задач, тоже описывали, давали некоторое описание этим задачам.

10:50

Speaker A

И концептуально, да, нужно было собрать всё воедино и дать оценку.

11:01

Speaker A

Ну, собственно, главная встреча груминга — это погрумить, подумать, как это реализовывать, дать оценку.

11:15

Speaker A

Ну, плюс локальные ещё груминги бывали, когда уже задача, например, на системном аналитике, и он может не знать, например, как это делать, может выносить на груминг свои вопросы, задачи, предложения, и командой прорабатываем и решаем.

11:23

Speaker A

Угу.

11:36

Speaker A

О'кей.

11:46

Speaker A

А, ну то есть по ещё можно там по... да, декомпозицию WBS строить, можно как-то экспертную оценку просить, можно на основе своего опыта сравнивать, ещё параметрические подходы.

12:04

Speaker A

Вот.

12:11

Speaker A

Ну, о'кей.

12:28

Speaker A

Тогда по техникам выявления: услышала, что интервьюирование практикуешь.

12:33

Speaker A

Ещё какие техники, с какими техниками сталкивалась на своём опыте?

12:39

Speaker A

Я думаю, что опыт у вас такой большой, это наверняка не только такие вот встречи one-to-one проводила.

12:54

Speaker A

Да.

13:01

Speaker A

Да, в общем, интервью, там вопросы, ответы, чаты, звонки, это всё понятно.

13:13

Speaker A

Были давно анкеты.

13:29

Speaker A

Потом недавно мы проводили огромный просто ивент-шторминг четырёхчасовой, потом ещё шестичасовой.

13:36

Speaker A

А здесь мы просто на доске каждый шаг клиента продумывали, делали его развилку, ну и на доске всё это через стикеры оформляли.

13:44

Speaker A

А какие ещё были сборы требований?

14:03

Speaker A

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

14:10

Speaker A

Ну и да, и собственно проводили, грубо говоря, тоже такое вот общение: «Что есть вот ещё тут такие фичи, тут такие... А чего вам не хватает? А для чего вам это? А если мы сделаем так, то повысит ли здесь конверсию? Повысим ли мы такую-то, например, метрику?»

14:28

Speaker A

Вот.

14:34

Speaker A

А бизнес-аналитики у нас ещё, например, делали через трассировку требований.

14:50

Speaker A

Я тоже в этом участвовала, но уже косвенно.

14:57

Speaker A

Вот чисто посмотреть, что действительно по ревью трассировка проходит, то есть табличный вид, выписываются юзкейсы, выписываются шаги, и посмотрели, чтобы они не пересекались там друг с другом, не блокировали друг друга.

15:13

Speaker A

А, прикольно.

15:23

Speaker A

Так, ну, соответственно, тут, наверное, вопросов нет.

15:33

Speaker A

По типам требований, по иерархии требований, тут можешь что-то рассказать по теории или по практике своей, из того, с какими уровнями требований работала, какие собирала, документировала?

15:46

Speaker A

Да, получается, у нас есть бизнесовые требования, есть пользовательские требования.

15:57

Speaker A

Если дальше раскручивать по иерархии, там функциональные, нефункциональные требования, вот с ними, наверное, чуть ли не каждый день работаю.

16:13

Speaker A

С пользовательскими требованиями здесь мы совместно с дизайнером это всё прорабатываем.

16:26

Speaker A

Вот.

16:36

Speaker A

Ну, бизнесовые требования здесь всё-таки больше бизнес-аналитик либо продакт-менеджер.

16:47

Speaker A

А, ну есть БТР, по сути.

17:02

Speaker A

Ну, конечно, я понимаю, что БТ — это всё-таки не твоя зона ответственности.

17:18

Speaker A

И тоже Екатерину могу иногда перебивать, потому что времени у нас очень мало, а хочется поговорить на разные темы и успеть достаточно много чего покрыть.

17:26

Speaker A

О'кей.

17:34

Speaker A

По функциональным, нефункциональным: вот тут хотелось бы поподробнее остановиться именно на нефункциональных требованиях.

17:42

Speaker A

Мне кажется, я даже в твоём резюме видела, что ты собирала там требования к безопасности.

17:59

Speaker A

Вот расскажи тоже поподробнее: какие, что ты как аналитик делала с вот с нефункциональными требованиями?

18:13

Speaker A

Просто ли документировала, или действительно собирала метрики какие-то, анализировала, сама выставляла какие-то требования, NFR, вот, или там ещё что-то?

18:32

Speaker A

Да, как системный аналитик, особенно в части проработки интеграции, нам нужно было собрать много нефункциональных требований, и по доступности системы, и по надёжности, и по масштабируемости.

18:45

Speaker A

Ну и, в частности, в безопасности.

18:53

Speaker A

А так как ещё работала на парочке финтехов, у нас была информация, которая маркировалась К1, К2, то есть конфиденциальная персональная банковская информация.

19:04

Speaker A

Поэтому у нас было плотное и тесное взаимодействие с командой безопасности, чтобы мы прорабатывали такие решения, которые не нарушали бы, ну, в общем, не могли бы мы потерять данные, кто-то, да, смо

19:24

Speaker A

потом использовала агрегированные значения. Это там сумма countт, а из сложных, ну, использовала джойны, использовала группай, ну, и под запросы тоже делал. Это когда селектну три селекта.

19:37

Speaker A

А можешь рассказать, зачем нужен? Закруто. Винхвин - это значит условие уже идёт на агрегатные значения, и он используется после операции группировки для фильтрации вот агрегатных функций. Если мы используем вот АГ там сум, то он нужен для именно них.

19:55

Speaker A

А, о'кей. Тогда давай перейдём к архитекторам. Ты говоришь, что говорила, что сейчас замещаешь архитектора. Какие конкретно задачи ты выполняешь вот при проектировании архитектуры? То есть, а какие задачи выполняют?

20:11

Speaker A

Соответственно, приходит бизнес, говорит: "Нам нужно это, а мы, ну, какую-то какую-то задачу". Мы понимаем, что пока наша архитектура, например, такое не может, и мы, а, ну, я начинаю думать о том, что как нам это реализовать там например добавить

20:22

Speaker A

новый сервис, либо там сделать интеграцию с таким-то сервисом. Соответственно, иду в ту команду, общаюсь, э, м, понимаю, могут ли они обеспечить там эти данные или нет. Вот, допустим, если нужно разрабатывать свой сервис, то отрисовываю его уже на архитектуре. Ну и, собственно, уже

20:38

Speaker A

описываю в документации, там из чего будет состоять сервис, там какие у него будутпоинты либо там JRPC методы.

20:45

Speaker A

Ну, зависимости от задачи, то есть что там нужно, то и описываю. Если, например, к нему кавка должна быть с ним подключена, то тоже отображаю кавку.

20:51

Speaker A

Какие топики, по каким топикам он там, например, будет писать, читать. Угу. О'кей. Тогда увидела у тебя в резюме, что был опыт работы с монолитами, в частности, задачи по декомпозиции монолита на микросервисы.

21:05

Speaker A

Вот. можешь поподробнее рассказать про этот опыт, какая и какая была твоя роль как аналитика вот при решении этой задачи?

21:11

Speaker A

А нам нужно было большой монолит перевести чуть-чуть по кусочкам на современный стек. А что для этого я делала как аналитик? Во-первых, изучала документацию всего монолита, всей его базы данных и свагера, что у него там был, какие были, а, раззапросы. Вот.

21:26

Speaker A

Дальше дальше я уже составляла списком его функциональности. Мы определяли по приоритетам, что с чего мы начнём переносить там с монолита на микросервисы. По приоритетам мы определили, и здесь нужно всегда монолит переносить с наименее там сложных функций, а для того, чтобы постепенно

21:45

Speaker A

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

22:01

Speaker A

обеспечить требования к миграции данных. То есть в какой момент, когда мы там, например, будем делать репликацию данных, когда мы полностью там отключаемся от этой базы и только в новую ходим. Вот. Вот, то есть по задачам это исследование функциональности, это распределение

22:17

Speaker A

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

22:32

Speaker A

Я я поняла. Хорошо. Скажи, с какие какие паттерны ещё ты знаешь по декомпозиции монолита на микросервис помимо удружения?

22:40

Speaker A

А, а технические паттерны или бизнесовые? Давай бизнесовывае, да, есть паттерн деления по доменам, по поддоменам, по бизнес-функциям. А когда снова же мы берём большой-большой монолит наш, э, определяем все его бизнес-функции и начинаем уже, а, собирать из того, какие мы функции,

22:59

Speaker A

например, объединим и положим в один микросервис, какие функции мы начнём разбивать отдельно по, а, по отдельным микросервисам. Определили домены, определили поддомены, определили. Там ещё есть такой класс, как божественный класс, по-моему, он называется. А определили, какие данные могут быть,

23:16

Speaker A

например, и в том сервисе, и в том сервисе, чтобы обеспечить согласованность данных и снова же, чтобы эти данные не дублировать между собой.

23:22

Speaker A

Угу. Супер. А тогда м чтобы не тратить время, вот по поводу проектирования микросервисов с нуля, а расскажи что включала типовая спецификация, которую ты разрабатывала на микросервис? Какие разделы, может быть, ну и в целом, что ты укажешь, да? А значит, спецификация, описание

23:42

Speaker A

микросервиса, что у него входит в шапке, что за микросервис, зачем он нужен, какие, по каким контрактом он работает.

23:48

Speaker A

Ну, вернее, там, например, R jon, там Кавка. Дальше у нас идёт описание самого микросервиса, например, что он там делает. Потом раздел отдельно посвящённый РСТу, какие попоинты в него входят. Полностью описание попоинтов, зачем, для чего там описание алгоритмов, запросов ответов, ошибок.

24:06

Speaker A

Ну, там телозапроса, тело ответа, да, при необходимости. Потом разделы из JRPC у нас были, где мы описывали методы JRPC. Раздел в скавкой, а где в какие топики пишет сервисы, из каких читает.

24:18

Speaker A

Отдельный раздел для интеграций, если он интегрирован с другими сервисами. Снова же там протоколы, контракты, описание работы этой интеграции. Потом а отдел был посвящён нефункциональным требованиям, которые нужно было придерживаться на этом микросервисе.

24:34

Speaker A

отдельно раздел, посвящённый базам данных. Каждая табличка описывается снова же вот на физическом уровне. А, ну что там было? Какие-то, по-моему, просто комментарии. Ну и история версий, версионирование документации.

24:46

Speaker A

О'кей, супер. Всё, достаточно полноты рассказала. Прямо спасибо. А что ещё хотелось бы с тобой обсудить? Я думаю, по микросервисам всё тут понятно. Аа вот по поводу интеграции вижу, что работала с и с синхронными синхронным взаимодействием, и с асинхронным. по

25:01

Speaker A

поводу взаимодействия по росту. Расскажи, то есть как как ты здесь, получается с нуля проектировала или же дорабатывала или какой здесь опыт? Лучше про расскажи. Прямо у меня, наверное, большинство и даже практически, наверное, мало было, когда что-то дорабатывала больше это

25:18

Speaker A

разрабатывала. Наверное, за весь опыт уже больше 100 запросов разработала. С нуля, да, соответственно, с нуля. А где-то мы делали подход Openф, когда в Свагере я через Ямул проектировала опишку. Я получается через о через онапе, да? Угу.

25:35

Speaker A

А и второй момент - это когда просто в конфлюнсе по шаблончику описывала тоже из чего будет состоять запрос. Там метод endpoint а query pass параметры тело запроса тела ответа коды ответов ошибки, алгоритмы обработки запросы или ответа.

25:51

Speaker A

Ну и примеры, наверное, тоже какие-нибудь и примеры контракта, соответственно, да, в Gне, ОК. Скажи, какой у тебя опыт работы с Суапом? СОПМ. Это было только в Сбербанке очень давно. Как раз-таки дорабатывала попоинты, по которым у нас происходили запросы. Что делала? Дорабатывала XML

26:08

Speaker A

схемы с XSD. Ну и, собственно, тестировала, да, через Swager UI SUAP. Ой, через SUAP UI.

26:17

Speaker A

А, то есть даже и с тестированием сталкивалась или так? Точно. Ну, точечно для того, чтобы самой понять, как это работает.

26:25

Speaker A

А, о'кей. Так, ты немножечко расскажи про твой опыт проектирования синхронного взаимодействия. Слышала, что работала с кавкой. Вот что ты здесь делала?

26:34

Speaker A

Поднимала ли кавку с нуля, проектировала или подключалась к рабочим очередям уже? Вот сама с нуля я не девокс, поэтому я неё на стендах не поднимала, не разворачивала кластеры, только подключалась через интерфейс. Есть кавка UI ещё ещё есть какой-то, забыла, уже

26:51

Speaker A

был в Натехи, да. Там я подключалась, соответственно, к брокеру. Ну и, э, смотрела, во-первых, какие у нас есть там топики партицы. Во-вторых, когда сама разрабатывала топики, сначала это просто описывала, документировала, потом уже смотрела, что, ну, что они есть там,

27:06

Speaker A

да, на Кавке UI. Вот. Ну, а дальше уже достировщики сами там отправляли сообщения либо вычитывали их. Ну, пару раз, да, я тоже сама, конечно же, заходила, смотрела, какие сообщения лежат в партиях, что у нас там приходит.

27:17

Speaker A

Либо, например, там, ну, нужно было в какую-то систему зайти, а код от этой системы приходил в Кавку. Ну, соответственно, тоже я его оттуда выгребала.

27:25

Speaker A

получала сама как аналитик, что описывала по Кавке. Ну вот плюс-минус как перечислила по росту, что проектировала только здесь также контракт для Кавки, кто вызывает, когда либо кто вычитывает, когда, что мы с этими данными делаем, откуда их записываем, либо куда складируем. Вот.

27:42

Speaker A

Ну и по нефункциональным требованиям тоже здесь описывала. А что описывала по нефункциональным требованиям? Оче, а, например, о том, что у нас там была одна из интеграций с командой, которая там нельзя было вообще никак терять сообщения. Вот поэтому здесь мы, ну,

27:57

Speaker A

во-первых, сообщение о том, что у нас должна быть гарантированная доставка, а, во-вторых, о том, что мы должны там ответ, например, отправлять на получение этого сообщения. Вот потом конкретные там протоколы, например, что мы должны реализовать, десереализовать и в протобафе передавать эти данные.

28:12

Speaker A

Угу. Да, в принципе, достаточно. Вот расскажи, пожалуйста, каким образом ты рассчитывал количество партиций, которые будут включены в топик? А здесь, во-первых, сначала там мы формулу использовали в зависимости от того, сколько данных мы хотим гнать через капку, а и сколько у нас есть железа на

28:30

Speaker A

это. Вот здесь больше разработчики с девопсами сами считали, но а потом уже девопсы настроили так, что у нас автоматически там при превышении такого-то порогового значения сообщений а добавляется партиция.

28:43

Speaker A

Угу. А, о'кей. Слышала, что ещё сталкивалась с интеграцией через базу, да? А вот скажи, с ещё с какими-нибудь видами асинхронного взаимодействия ты сталкивалась?

28:52

Speaker A

Ну, через файловое хранилище, можно оно сказать. Ну, это тоже база, наверное. Вот. Потом, а, ну, в теории хорошо, наверное, понимаю шину USB Enterprise севиice Bass тоже, потому что соседние команды с ними много работали.

29:06

Speaker A

Угу. О'кей. Но сама с пошине интеграции не прорабатывала, да? У А, хорошо. Расскажи, пожалуйста, про свой опыт тестирования рестапи, то есть про тестирование SUAP. Я уже поняла SUAP.

29:21

Speaker A

Про рестапе приходилось, когда тестировать, например, когда мы хотим интегрироваться с другой командой, то я прихожу к этой команде и, собственно, мы там обсуждаем предмет нашей интеграции и коллеги могут выдавать коллекцию в Посмане, типа вот, ребята, держите, у нас есть ручки, а можете там дёргать

29:37

Speaker A

нас, да, и, собственно, нам там выдавали апи ключи, либо мы там получали двоти токены. И по этим ручкам я уже делала запросы, смотрела, соответствуют ли м эти там запросы документации их. Ну и на основании уже этого тестирования ставила

29:50

Speaker A

задачу у нас своих разработчиков сынгрироваться по этим методам. Угу. Ну, собственно, Свагере ты наверняка тоже работала, да?

29:56

Speaker A

Да, конечно. Ну, тем более Open пишется в Свагере. Угу. Ну, я имею в виду, что там тоже можно тестировать опишки в Я скорее с этого не как чтение документации проектной, а именно как тестирование.

30:07

Speaker A

Ну, я согласна. В целом тогда, наверное, у меня вопросы закончились, потому что уже эта превышаем вот немножечко. Давай перейдём к завершающей части интервью, к твоим вопросам, если такие вдруг возникли. y

Topics: системный аналитик собеседование Scrum груминг Kafka микросервисы нефункциональные требования BPMN UML требования

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=87598)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=87598)
- [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=87598)
- [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=87598)
- [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=87598)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/380k-real-systems-analyst-job-interview-did-i-pass/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/