**ОФФЕР 250к! Собеседование на СИСТЕМНОГО АНАЛИТИКА — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/system-analyst-job-interview-offer-250k/

Собеседование на системного аналитика: разбор опыта кандидата, Agile-процессов, артефактов (user story, BPMN, ER, API-контракты) и подходов к работе с заказчиком.

## Key Takeaways

- Кандидат имеет около 4 лет опыта системного анализа, работал в проектной деятельности и аутстаффе
- Предпочитает развиваться в одной компании на одной системе с экспертной глубиной
- Знает базовые артефакты и процессы, но технические ответы о REST/SOAP и HTTP-методах были неуверенными
- Опыт Agile есть, но без полноценного скрам-мастера и регулярных ритуалов

## What the video covers

- Интервьюер представляет проект по развитию большой системы с интеграциями с госструктурами и подрядчиками, открыты вакансии системных аналитиков
- Кандидат рассказывает о выборе системного анализа, учёбе (БД, Project Management) и первом опыте работы в стартапе
- Обсуждаются причины смены работы: компания-аутстаффер завершает проект, новых нет
- Кандидат хотел бы развиваться в системном анализе с перспективой стать архитектором через пять лет
- Разбирается опыт работы по двухнедельным Agile-спринтам, без скрам-мастера (роль PM), с ретроспективами и демо не всегда
- Описывается процесс: сбор требований, user story, use case, бизнес-правила, критерии приёмки, затем BPMN, ER-диаграммы, API-контракты
- Обсуждаются самостоятельность аналитика, приоритизация на планировании спринта, передача в разработку и тестовые сценарии
- Интервьюер задаёт технические вопросы по REST и SOAP, отличиям GET и POST, ограничениям GET, rate limiting и безопасности
- Кандидат отмечает, что документация велась в свободной структурированной форме без строгой привязки к ГОСТ

## Chapters

1. 00:00 Введение и описание проекта
2. 01:07 Мотивация и выбор системного анализа
3. 03:44 Опыт работы и смена места
4. 05:08 Agile, спринты и ритуалы
5. 07:28 Самостоятельность и процесс сбора требований
6. 15:48 Технические вопросы: REST, SOAP, HTTP
7. 25:17 Документация и артефакты

Answers

## Questions about this video

Какой опыт работы у кандидата?

Кандидат работает системным аналитиком около 4 лет, начинал в стартапе и работал в проектной деятельности через аутстаф-компанию. Опыт включает работу по двухнедельным Agile-спринтам.

Какие артефакты системного аналитика упоминаются?

Упоминаются user story, use case, бизнес-требования, бизнес-правила, критерии приёмки, BPMN- и ER-диаграммы, API-контракты, модели данных, тестовые сценарии и пользовательские инструкции.

О чём спрашивал интервьюер в техническом блоке?

Интервьюер спрашивал о REST и SOAP интеграциях, отличиях GET и POST, ограничениях GET, безопасности и rate limiting. Кандидат отвечал частично и не всегда уверенно.

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

Общение с нашими коллегами мы прослушали. А соответственно, у нас тоже есть вакансии на наш проект по развитию систем.

00:12

Speaker A

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

00:25

Speaker A

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

00:32

Speaker A

Э-э, первый собственно, общий вопрос, а-а, почему собственно, системный анализ? Угу. Именно вот почему это я выбрал там с самого начала?

00:41

Speaker A

У меня, собственно, есть пара вопросов по резюме, с вашего позволения. Угу. По нему и пойдём.

00:53

Speaker A

Так, ну на самом деле, почему наверное, выбрал, э-э, такой вопрос, э-э, то есть я вот учился и у нас э-э, было ну, достаточно много предметов связанных с тем анализом, там база данных, э-э, ну, что-то связанное с ну, условно там с Project Management'ом,

01:07

Speaker A

Первый, собственно, общий вопрос: почему, собственно, системный анализ? Угу. Именно почему вы это выбрали там с самого начала?

01:14

Speaker A

Вот, э-э, ну, и в какой-то момент э-э, ну, у нас ещё да, немножко подскажу, были э-э, три трека, типа один трек был аналитический, один там был для разработчиков, один там был для что-то PM'ов, что-то такое, ну, примерно там я

01:28

Speaker A

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

01:43

Speaker A

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

02:03

Speaker A

Ну, на самом деле, почему, наверное, выбрал... такой вопрос. То есть я учился, и у нас было достаточно много предметов, связанных с этим анализом: база данных, что-то связанное с Project Management'ом,

02:10

Speaker A

Вот. Вот так. Угу. Всё, спасибо. Э-э, по поводу поиска работы, э-э, у вас, я так понимаю, проектная деятельность сейчас?

02:24

Speaker A

что-то про Agile, что-то про метрики. Вот, примерно последовательно было связано.

02:44

Speaker A

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

02:54

Speaker A

И в какой-то момент, да, немножко подскажу, у нас были три трека: один аналитический, один для разработчиков, один для PM'ов, что-то такое. Примерно так я говорю. Я выбрал аналитический, мне там было ещё больше предметов, связанных с аналитикой. В какой-то момент я понял, что нужно искать работу, нашёл первую компанию, тогда это был стартап, меня позвали. И вот, мне это понравилось. Что касается развития, то да, я хотел бы развиваться больше в системном анализе, если сравнивать с условным бизнес-анализом.

03:05

Speaker A

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

03:11

Speaker A

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

03:29

Speaker A

развиваться, в одной компании, на какой-то одной системе и её изучать уже там на экспертном уровне?

03:37

Speaker A

Вот. Так. Угу. Всё, спасибо. По поводу поиска работы, я так понимаю, проектная деятельность сейчас?

03:44

Speaker A

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

03:53

Speaker A

Угу. Это основная причина или какая-то другая? То есть, ещё раз повторю: я работаю в компании, которая предоставляет аутстафф в другие компании. Текущий проект завершается, новых не предвидится. Но это не в плане, что для меня их нет, а их нет вообще у всей компании. Я не знаю, какая там ситуация, может быть, у самой компании какие-то

04:15

Speaker A

То есть такой вариант, э-э, больше нравится. Угу, да. Отлично. Так, а-а, по поводу, собственно, предыдущей вашей встречи, а-а, у меня остался вопрос по артефактам системного аналитика.

04:33

Speaker A

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

04:51

Speaker A

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

05:08

Speaker A

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

05:28

Speaker A

уже идёт, э-э, э-э, проработка нашего решения. Вот, э-э, что это это это что касается там, э-э, м-м, BPMN диаграммы, м-м, ER-диаграммы вот э-э API-контракты.

05:42

Speaker A

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

06:02

Speaker A

А вы работали по спринтам, по Agile или как? Да, да, у нас был Agile, двухнедельный.

06:08

Speaker A

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

06:14

Speaker A

Нет, скрам, именно название скрам-мастера не было, был PM. Вот. Ну, то есть, ретро, демо?

06:22

Speaker A

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

06:35

Speaker A

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

06:48

Speaker A

То есть такой вариант больше нравится. Угу, да. Отлично. По поводу предыдущей вашей встречи у меня остался вопрос по артефактам системного аналитика.

07:04

Speaker A

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

07:15

Speaker A

Был такой вопрос, но я чёткого ответа не услышал. Угу. Можно по порядку, с этапа сбора требований и до внедрения фичи в продакшн? Какие артефакты возникали и какие вы готовили?

07:23

Speaker A

Получается, да, я хочу понять, насколько вы самостоятельны в своей, э-э, деятельности как системный аналитик.

07:31

Speaker A

Хорошо. Получается, появляется какая-то фича. Точнее, нет, давайте начнём так. Сначала идёт сбор и фиксация требований: интервью с заказчиком, уточнение бизнес-цели, уточнение ограничений. После этого возникают уже всем известные артефакты: user story, use case'ы, бизнес-требования, бизнес-правила, критерии приёмки.

07:49

Speaker A

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

08:02

Speaker A

Дальше идёт проработка нашего решения: BPMN-диаграммы, ER-диаграммы, API-контракты.

08:18

Speaker A

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

08:35

Speaker A

Потом передача в разработку, для команды разработчиков. Наверное, пока так. И ещё потом тестовые сценарии для тестировщиков.

08:47

Speaker A

Вот. А представьте, вот вам, допустим, заказчик говорит, вот вот, соответственно, фича, да, вы её с ним поговорили, срок 2 месяца.

08:54

Speaker A

А вы работали по спринтам, по Agile или как?

09:12

Speaker A

Вот вам такой подход ближе или всё же вам задачи спускают более дискретно, и вы их, просто одну за одной делаете?

09:20

Speaker A

Да, у нас был Agile, двухнедельный.

09:38

Speaker A

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

09:53

Speaker A

То есть у вас был полноценный Agile, был скрам-мастер, который соблюдал все активности?

10:00

Speaker A

Приходилось ли эскалировать какие-то проблемы наверх? Угу. Э-э так. Ну, условно так, хорошо. То есть когда у нас случается ситуация, м-м ну, смотрите, то есть было м-м наверное, что касается м-м сроков, наверное, так скажу. То есть э-э когда у нас э-э

10:25

Speaker A

Нет, именно названия скрам-мастера не было, был PM. Ретро, демо?

10:37

Speaker A

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

10:52

Speaker A

Смотрите, у нас было планирование спринтов, дейлики постоянно, демо тоже было, но не каждую неделю. Ретро не было.

11:07

Speaker A

высшем уровне, чтобы у нас э-э эти риски как бы все были предусмотрены, проработаны. А как вы работаете вот с изменениями?

11:14

Speaker A

Полноценным, наверное, никто до конца не соблюдает все ритуалы.

11:29

Speaker A

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

11:47

Speaker A

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

12:02

Speaker A

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

12:18

Speaker A

Угу. То есть вы спрашиваете что-то на стыке работы системного аналитика и проджект-менеджера? Про это?

12:32

Speaker A

нас там не полтора, а 1,2 по, м, объёму, то, в принципе, наверное, можно и, наверное, вместить вот этот буфер по времени, ну, если мы заранее запланировали.

12:44

Speaker A

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

13:00

Speaker A

Э, давайте представим ситуацию, когда заказчик, э, даёт вам 2 месяца, но вы понимаете, что те технологии, которые вы мы сейчас используем, допустим, да, в проекте, э, с их помощью срока 2 месяца за 2 месяца, э, эту задачу не выполнить.

13:17

Speaker A

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

13:24

Speaker A

Угу. Так, ну, смотрите, давайте подумаем. Если Так, технологии новые, 2 месяца. Ну, смотри, я не понимаю, наверное, нужно больше на примере на каком-то отталкиваться. Ну, допустим, э-э можно подумать так, э-э ну, с двух двух сторон посмотреть. Если технология

13:44

Speaker A

Угу. Ну, если отвечать прямо, то в своей зоне, наверное, достаточно самостоятельно. То есть после согласования требований с заказчиком я сам эти требования прорабатываю, потом декомпозирую их на артефакты, ещё раз согласуем с заказчиком и с командой. Также, конечно, я контролирую, чтобы решение, которое касается ТЗ, было реализовано. Сроки, приоритеты. У нас есть планирование спринта, и там мы с продактом и PM'ом сидим и решаем, как будем приоритизировать. То есть я не то чтобы на первых бюджетах участвую, но участвую. Мы приоритизируем по мозгу.

13:52

Speaker A

Давайте Давайте пример. То есть мы используем REST, а заказчик говорит: "Хочу Хочу SOAP, XML".

13:59

Speaker A

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

14:07

Speaker A

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

14:28

Speaker A

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

14:38

Speaker A

Просто, возможно, вдруг у нас как бы никто с SOAP'ом не работал, но у нас, э-э, очень опытные все там здесь все с годами опыта, быстро обучаются, возможно. И тогда Допустим.

14:47

Speaker A

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

15:02

Speaker A

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

15:14

Speaker A

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

15:30

Speaker A

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

15:44

Speaker A

безопасности. Самый главный аргумент ещё э-э если у нас есть 56 интеграций REST и одна интеграция SOAP.

15:53

Speaker A

Угу. М-м ну, да, то есть, тут, наверное, с точки зрения поддержки под- поддержки и там э-э м-м ну да.

16:03

Speaker A

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

16:20

Speaker A

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

16:39

Speaker A

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

16:56

Speaker A

Угу. Между двумя организациями, ну, вы имеете в виду э-э там на- нашим сервисом и другой организацией? Вот так вот?

17:04

Speaker A

Да. Да-да-да. Ага. М-м ну, да, то есть, э-э обычно ну, я делал в ну, такой протокол какой-то такой ну, условно там формальный документ, где у нас там фиксируется, кто там что м-м как ну, в каком формате передаёт. То есть, обычно там э

17:19

Speaker A

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

17:28

Speaker A

Вот э наверное, вот так. Ну, а так наверное, ещё по ошибкам, типа отклик на ошибки.

17:35

Speaker A

Так ну можем наверное по так скажем попрактиковаться. Угу. С точки зрения э интеграции у вас куда больше перекос?

17:48

Speaker A

Всё же на REST или на какие-то другие типы? М больше на REST. А какие методы знаете?

17:57

Speaker A

Угу. Э ну, у REST GET, PUT, DELETE это что касается там идемпотентных, POST, PATCH там неидемпотентные. Ну, ещё там из мало используемых, не знаю, там HEAD, OPTIONS например.

18:12

Speaker A

Основные отличия GET и POST можете озвучить? Угу. Ну, GET там э нужен для получения м данных в основном, а ещё второй POST.

18:22

Speaker A

Да. POST для создания записи. Э можно ли с помощью POST э осуществлять поиск данных?

18:32

Speaker A

Да. Что для этого нужно тогда? Угу. Так ну э если мы через POST э ищем э так скажем, получаем данные, то м чего?

18:47

Speaker A

Ну, нам нужно условно внутрь э добавить э условно фильтр, то есть э где мы будем условно вытаскивать э данные. То есть, или вы имеете в виду там условно э как вот это уже на с точки зрения URL там э

19:03

Speaker A

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

19:18

Speaker A

запросы, которые там э-э меняли состояние системы. Хорошо, такой вопрос. Вот у вас э-э допустим десяток query params, по которым надо осуществить поиск. Какой метод выберете?

19:34

Speaker A

Угу. Так, ну по query параметрам угу. Ну, наверное, в том в этом случае, наверное пост точно.

19:46

Speaker A

Почему не get? Э-э ну, потому что м-м мы вот э-э сможем э-э м-м так скажем Смотрите, если у нас много фильтров, то в этом случае нам больше э-э точнее, точно лучше выбрать пост, потому что м-м у нас э-э

20:05

Speaker A

get больше для когда для того, когда у нас э-э меньше параметров и это просто поиск, а пост больше для условно, когда у нас много фильтров э-э и они там какие-то вложенные там или сложные.

20:17

Speaker A

Вот, то есть там Есть ли у get ограничения на длину строки? М-м да, то есть там удобнее э-э всё, я понял причину, э-э нам короче, мы выбираем пост, потому что в нём проще передавать э-э JSON там в body.

20:30

Speaker A

Не мы не зависим, в общем, от длины нашего URL'а. Повторю вопрос, у get есть ограничения по длине строки?

20:37

Speaker A

М-м да. Хорошо есть. Нет, это вопрос. Ну, вот 10 параметров, они влезут или нет? Или 11 влезет или 12?

20:51

Speaker A

Угу. У get есть ограничения? Э-э да, я я я точно знаю, что оно есть, но вот сколько именно, вот я, наверное, не подскажу.

20:58

Speaker A

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

21:13

Speaker A

Так а-а Мне ещё интересно ваш опыт по поводу validation layer'а. Вот. То есть, можете поподробнее рассказать, как он устроен, а-а и какие правила валидации вы там закладывали.

21:30

Speaker A

Угу. Э-э Что из себя представляет? Да, то есть то, скажем, м-м validation layer, ну, это, так скажем, такой условно слой безопасности, то есть между м-м опишкой и м-м бизнес-логикой. То есть, если проще, в общем, его задача, условно, отсеять э-э

21:49

Speaker A

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

22:06

Speaker A

м-м длину э-э записи, м-м вот. Там за Это сервис ФЛК, по сути. М-м Ну, ФЛК не слышал. Ну, Форматно-логический контроль.

22:18

Speaker A

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

22:32

Speaker A

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

22:50

Speaker A

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

22:59

Speaker A

Э-э так, вот так. Ну, наверное, что ещё? Не, в принципе мне понятно, спасибо. А, вопрос про безопасность в API, как обеспечивали, какими средствами?

23:10

Speaker A

Угу. Так, ну, что касается м, безопасности, ну, тут, наверное, можно м затронуть э м не знаю, то есть э аутентификацию, авторизацию. Вот э аутентификацию через э токены, то есть э JWT или OAuth 2. Вот, чтобы понять, кто вызывает апишку. Что

23:32

Speaker A

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

23:52

Speaker A

атак, то есть э условно там э rate limiting, чтобы у нас э м Угу.

23:59

Speaker A

так скажем э В общем, мы мы контролируем количество запросов, чтобы у нас не было перегрузки нашего сервера. Вот, что касается, наверное, ещё э м не знаю, HTTP, то ну, у нас точ- только HTTPS был. Вот э Так, наверное, вот так, что по

24:15

Speaker A

безопасности. Всё, спасибо. У меня пока, наверное, все вопросы. Алексей, есть вопросы какие-то? А, у меня вопросы по документированию.

24:25

Speaker A

Вы ведь, наверняка, когда сервисы там, да, или там систему модернизировали а, как-то описывали эти сервисы там, что делали, да?

24:36

Speaker A

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

24:47

Speaker A

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

25:06

Speaker A

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

25:20

Speaker A

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

25:40

Speaker A

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

25:59

Speaker A

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

26:20

Speaker A

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

26:26

Speaker A

Те, кто использует систему? Да. А, вот, в каком формате эту документацию делали, были какие-то к ней требования, э, ну, чуть-чуть расширю или подскажу, там, использовали ли какие-то, э скажем ГОСТ Хм.

26:42

Speaker A

стандарты для документации? Или она в свободном виде была? Ну, на самом деле, была в, в свободном, я знаю, что существует, э, ГОСТ, но у нас была, хм, в свободном таком, ну, в более-менее структурированном, но в свободном, то есть без жёсткой там привязки ГОСТ.

27:00

Speaker A

Угу. Я понял. Ну, на самом деле, ГОСТ это не звучит как что-то такое дремучее, сложное и страшное, да? Это просто требования некоторых заказчиков, особенно государственных.

27:10

Speaker A

Вот поэтому ну такое тоже бывает в жизни. Понял спасибо. К тебе пока все, да, вопросы?

27:19

Speaker A

Ну, да. Да.

Topics: системный аналитик собеседование Agile user story API-контракт BPMN REST SOAP требования IT-карьера

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

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

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


---
This is the markdown twin of https://sozai.app/transcript/system-analyst-job-interview-offer-250k/ — 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/