Speaker A
Понятно. Я работаю системным аналитиком. Я знаю, что ты как раз А я взаимодействую как с фронтом, так и с мидлом, в бэком в меньшей меньшей степени.
Разбор ошибок в рассказе о своём опыте на техсобеседовании системного аналитика: как структурировать историю карьеры, работа с интеграциями и кредитованием юрлиц.
Key Takeaways
- На собеседовании важно точно описывать свою роль и не выдавать командный результат за личный.
- Знание протоколов интеграции (REST, SOAP, Kafka) и умение унифицировать их — сильный навык системного аналитика.
- Незнакомые термины лучше прямо обозначать, а не угадывать ответ.
- Опыт разработки — существенное преимущество для системного аналитика.
What the video covers
- Кандидат рассказывает о пути в IT: школьное программирование, студенческий стартап по посуточной аренде коттеджей и грант 1 млн руб.
- Первая работа системным аналитиком в Комплексные Инфосистемы над SCADA-системой для управления инженерными системами зданий.
- Переход в банковскую сферу (MBA банк, Москва): отдел кредитования юрлиц, выявление требований, use case, user story, wireframes.
- Основная сложность — проработка интеграций с разным оборудованием и протоколами: REST, SOAP, SDK, XML RPC, gRPC.
- Сбор данных о заказчике из открытых источников (ФНС, судебные приставы, отзывы) и передача заявок скоринговой системе через Kafka.
- Интервьюер разбирает слабые места: неточные формулировки, неуверенность в терминах (лимитный модуль, DaData, JSON-схема).
- Обсуждаются артефакты аналитика: use case со сценариями (основной, альтернативные), критерии приёмки, definition of ready и definition of done.
- Разбор гибкой методологии Scrum и типичных проблем процесса, а также роли аналитика в координации команд.
- Рекомендации по подаче опыта: честно разделять личный вклад и командный, чётко называть технологии и свои задачи.
Full Transcript — Download SRT & Markdown
Speaker A
Вот. Ну, вообще говоря, да, самое перспективное и, а, применяющее новые технологии на про Поэтому, в принципе, я довольна, мы всё время что-нибудь новенькое делаем, вот.
Speaker A
Довольно интересно. Угу. А, расскажи пожалуйста, а, ну, я, кстати, работаю не очень давно, я вот год назад была в ладе, а сейчас уже в проекте вот с прошлого года. Короче, вот так.
Speaker A
Угу. Расскажи пожалуйста о себе, м, какой у тебя есть опыт работы в IT вообще.
Speaker A
Вот. Ну, э, всё, что ты хотела бы рассказать, я видела, что ты программируешь да?
Speaker A
Угу, да. Вот. А, расскажи пожалуйста о себе, а потом перейдём плавно к рассказу и вопросам.
Speaker A
Угу. А, мне в рассказе то, что в резюме указывать, то, что в банке работал, или пока реальный только?
Speaker A
Пока знакомимся. А, свой путь в IT я начал, ну, со школы начал изучать программирование, и потом в студенчестве начал делать проект по сдаче коттеджей посуточно, то есть именно платформу.
Speaker A
И вот за счёт этой платформы я потом выиграл грант 1 млн руб. на её развитие.
Speaker A
Ничего себе. Да, это студенческий стартап, там фонд был. И после университета я уже устроился на работу системным аналитиком в Комплексные Инфосистемы. Там мы разрабатывали SCADA-систему для управления инженерными системами в зданиях, там гражданских, промышленных, это видеонаблюдение, охрана, вентиляция, там водопровод, всё, что хочет заказчик
Speaker A
управлять с одного места, всё можно было проинтегрировать. Вот, там я проработал системным аналитиком где-то 9 месяцев и с конца июня Угу. Ну, что, тогда ты посчитал, что нерелевантный твой опыт там был?
Speaker A
Ну, там, а, была как бы IT-структура, но не такая прям серьёзная, чтобы можно было в ней развиваться как специалисту.
Speaker A
Это тоже больше на стартап похоже был. Угу. А, почему ты решил переквалифицироваться из разработчика в системного аналитика?
Speaker A
Ну, мне понравилось больше задач системного аналитика, то есть это проектирование, взаимодействие с практически со всеми командами.
Speaker A
Вот, вот как бы и проработка интеграции, и вот вот это всё начало привлекать больше, чем просто писать код.
Speaker A
Угу. Тебе нравится быть экспертом по всем вопросам, а не просто тихо сидеть над своей задачей?
Speaker A
Да, это типа такого, да. Правда, это такая палка о двух концах, потому что если никто не знает, как там делать, то кто должен выяснить?
Speaker A
Системный аналитик. Вот. Так что, да, интересного много, но это, конечно, твой большой плюс, то, что у тебя есть опыт разработки, ты знаешь, как пишется код, как, в принципе, это всё делается.
Speaker A
Ну, это круто, это прям большое преимущество. Ну, у меня вот опыт программирования не такой прям, чтоб можно было где-то его серьёзно применять.
Speaker A
Угу. Вот, поэтому не стал его дальше развивать пока так. А [фыркает] как уже проект практически готов. То есть, ну, вот это как пет-проект можно считать.
Speaker A
Угу. Я точно знаю, на самом деле такие есть, но единицы, я немного знаю. Не, хотя, в принципе, есть, да, среди парней есть, но не прямо, конечно, не все.
Speaker A
Далеко. Вот. А-а, хорошо. А-а, давай тогда перейдём, наверное, к твоему рассказу. Да. Потом я тебе позадаю вопросы, а потом ты мне, если станешь говорить.
Speaker A
Так, хорошо, тогда начну. Я работал системным начал работать системным аналитиком ещё в студенчестве. А-а, начинал там со стажёра и так вот а-а, рос в специальности.
Speaker A
А-а, был первый проект, это у нас разработка SCADA-системы, то есть управление инженерными системами в промышленных и гражданских зданиях. Сам я занимался немного выявлением требований, описание ТЗ для разработчиков, user story там, use кейсы, какие-то end поинты при необходимости.
Speaker A
Но большая часть задач заключалась в проработке интеграции, так как каждый заказчик хотел работать со своим оборудованием. А у каждого оборудования там поставщик делает свои виды интеграции. У кого-то это REST, у кого-то SDK или SOAP, XML RPC. То есть
Speaker A
всё это нужно было прорабатывать и унифицировать под нашу систему. Вот там я проработал год, потом перешёл уже работать в банковскую сферу, MBA банк, Москва. Там в отделе кредитования в основном с юрлицами.
Speaker A
То есть также я занимался аналитикой, это выявление требований, составление use кейсов, user story, wireframes, чтобы там а-а, дизайнеру было проще описывать внешний вид клиентской части там, в основном для клиентов, для сотрудников банка.
Speaker A
А-а, прорабатывали сбор данных, то есть интеграция с различными ресурсами, чтобы можно было собрать данные о том, а-а, о заказчике, допустим, кто хочет кредит взять. И передача этих данных команде скоринга с помощью кафки.
Speaker A
Ну это как бы Касались данные юридическим А-а, сначала в открытом доступе, но была сначала анкета, которую юрлицо заполнялось, вот там были данные там с сайта ФНС, судебных приставов.
Speaker A
Собирались отзывы с определённых сайтов, чтобы проверить репутацию. И там сайт налоговой, чтобы мы собрали там баланс а-а компании, там движение денежных средств.
Speaker A
Угу. Понятно. О'кей. А-а, то есть в основном твои задачи на последнем месте работы в банке были связаны с кредитованием юридических лиц.
Speaker A
Да. А-а, о'кей. М-м, скажи, пожалуйста, вот какая самая интересная задача, над которой тебе довелось поработать, вот именно в банке?
Speaker A
Угу. Ну, самые интересные задачи это были именно проработка интеграции, то есть найти способы, проанализировать их, протестировать.
Speaker A
И он сохранит у нас. То есть вот поиск и анализ вот этих всех данных было для меня самым интересным.
Speaker A
Угу. Ну а-а у вас была какая-то а-а API? Ну, типа, условно, кредит API, да? И помимо этого, помимо этой API, она, скорее всего, взаимодействовала с множеством других систем. Вот можешь назвать смежные системы, с которыми приходилось взаимодействовать для того, чтобы
Speaker A
ну, тут скорее можно получать данные, возможно, где-то какие-то лимиты и так далее. То есть вот какие системы конкретно это были?
Speaker A
А если не считать сторонние сервисы, где мы брали интеграт с помощью интеграции данные, то мы передавали данные по кавке а-а, скоринговой системе, то есть мы просто передавали, что есть заявка и уже на своей стороне прописывали вот этот REST API, с помощью которого они могли
Speaker A
вытягивать все данные для подсчёта. А-а, ну, наш сервис в основном занимался сбором и отображением статусов кредита.
Speaker A
Угу. Ну, ещё сервис сервисом платежей, чтобы показывать там историю платежей клиента. Угу. Платежей именно для юридических лиц, не для физических?
Speaker A
Да, да, юридических. О'кей, хорошо. А что такое лимитный модуль? Вот это не знаю. У меня был просто разговор в чатике, в общем, что там [смех] всем, кто пишет, всем, кто говорит о том, что они работали с кредитами, он
Speaker A
валит этим вопросом, что такое лимитный модуль. А он у всех должен быть? [тяжело вздыхает] Ну, в общем, на самом деле, применительно к юридическим лицам, это, наверное, скорее к физическим лицам.
Speaker A
Угу. Ну, то есть, есть какой-то список там лимитов на снятие денежных средств и так далее. И по кредитам тоже, скорее всего, какие-то предельные лимиты. Вот, а при юридических лицах, честно говоря, скорее там взаимодействие тоже будет происходить с какими-то моделями, но это
Speaker A
будет какой-то модуль, который из АБС информацию тянет и, возможно, оттуда можно получать какую-то информацию, типа, по предельным, предельным суммам, которые может, они могут получить.
Speaker A
Короче, на самом деле, тут не знаю, сложно предполагать, просто я с кредитами не работаю. Кредиты - это штука такая довольно сложная.
Speaker A
Угу. Вот, платежи тоже. Ну, ты сказал, что асинхронно всё было организовано через Kafka да?
Speaker A
Да. Угу. А вот если вам нужно проверить, например, наименование юрлица, то с каким сервисом можно интеграцию запилить?
Speaker A
Ну, я так думаю. Или наименование и ИНН сопоставить, проверить, что нет ошибки. Ну, с сайтом ФНС.
Speaker A
А DaData. [смех] А DaData называется? Да, DaData. С таким не сталкивался. Мне кажется, в России все знают DaData.
Speaker A
Сейчас. Ну, ты сказал, довольно сложно, довольно легко, вернее, сделать интеграцию с ними, у них открытая API.
Speaker A
Угу. И на самом есть один вопрос про DaData в рекомендации. То есть, как с ним интегрироваться?
Speaker A
Нет, не как интегрироваться, а вот тип тип такой вот, ну, правда, там на примере физического лица, например, тебе нужно подсказку всплывать, да? Ты типа фамилию ввёл, а тебе уже какие-то там варианты.
Speaker A
Вот, и там, например, да, фамилия, а тебе там подсказки перед заполнением других полей. И вот, ну, типа, считается правильным ответом, что кандидат должен порекомендовать к использованию DaData.
Speaker A
Вот. Угу. А, [откашливается] я вот я вспомнил, я его использовал для автозаполнения э-э адрес адресов, то есть, вводишь и потом вот адрес. Вот это я в своём сервисе пока тоже использовал.
Speaker A
А что? Ну, честно говоря, я просто из Беларуси. Давай я проверю, а то вдруг я тебе какую-то фигню скажу, и это только для физических лиц.
Speaker A
А тут юрлиц тоже написано. Ну, мне кажется, что да. Угу. И вот самый первый прямо абзац, ну, второй подсказки.
Speaker A
Подсказки по организации. Да, ну, я помню, я просто это делала давно-давно. Угу. О'кей, хорошо.
Speaker A
Да. Значит, просто имеем в виду, что, может быть это А скажи пожалуйста какие э э ну, под тебя просто написано, что ты как бы помогал, участвовал в описании интеграции и так далее. Ты а, артефакты аналитика ты, а, составлял самостоятельно?
Speaker A
Угу. А, user story, use case, а, описание endpoint'а тоже в confluence'е, там sequence diagram, входных-выходных данных, роутов, ошибок алгоритма, а, и wireframe'а для дизайнера.
Speaker A
Ну, ещё отдельный артефакт по, ну, описанию интеграции со сторонними сервисами, то есть, какие там роуты, какие входные-выходные данные, примеры этих данных, там, как авторизоваться в них.
Speaker A
Угу. О'кей. Ну, примеры, э, э, request и response тоже сам составлял, JSON умеешь? Да, да, умею. Ну, вот только они в схемах писались, вот это JSON как пример.
Speaker A
А, что имеется в виду не в схемах? Ну, JSON схема имеется в виду. Ну, JSON, а, а.
Speaker A
Ну, JSON схема это же схема валидации JSON. Да. Или вообще сказать, что с ним не делал, или вообще не упоминать?
Speaker A
Ну, зачем? Ну, ты же составлял JSON, что нельзя в интернет закинуть и проверить, валидно оно или нет? Ну, или самом э-э идея используется для медловой доки, она сама проверяет.
Speaker A
Если всё правильно, она вот зелёненькая, неправильно, она там типа красно-розовая. Угу. Там выскакивают ошибки, даже ничего думать не надо, если вдруг что не так.
Speaker A
Угу. Кстати, да, вот э-э есть ли у тебя опыт в мутации скидок и с IntelliJ IDEA писать доку?
Speaker A
М-м, имеется ввиду Swagger автоматически? Ну, может про Swagger рассказать. Ну, нет, это другое. Это AsciiDoc, когда документация хранится.
Speaker A
Угу. А с IDE нет, нет опыта. Ну вот почитай про AsciiDoc, я тебе в конце дам рекомендацию, потому что мне кажется, что ты скорее всего пройдёшь и лучше тебе это заранее подучить, чем потом.
Speaker A
Угу. И IDEA там, в принципе, не то чтобы, наверное, суперсложный функционал, но нужно понимать Git Flow. Вот ты, кстати, понимаешь Git Flow?
Speaker A
Э-э Это где Какие Git add, Git commit, Git comment. Что-что? Ветки? Какие команды, какие ветки вообще бывают? Как давать?
Speaker A
Прям полностью синтаксис с ветками не знаю, знаю там Git add, а commit, push, pull, branch выбрать, main там, origin ветки.
Speaker A
Dev ветки какие-то. А fetch? Fetch. Rebase. Fetch это э-э насильное какое-то слияние? Нет, это обновление проекта и rebase.
Speaker A
Вот это вот сказал просто подробно не помню. Слияние это merge. Угу. [откашливается] Нет, я имею ввиду fetch это или там параметр, который даже при ошибках как-то заставлял их сливаться.
Speaker A
Или это флаг был отдельный. Ну, если это применимо к твоей локальной версии, которая на компьютере, то что на сливается с версией, которая в гите, в битбакете лежит, ну нет, это скорее наверное другое, это просто обновление.
Speaker A
Угу. Вот, ну там есть что-то по насильному слиянию, но я это просто не использую в своей работе. Ну, типа нет.
Speaker A
Угу. Вот, а какие вообще тогда виды веток есть? Ну, ты начал говорить, вот давай прямо подробно обсудим.
Speaker A
Ну, то что я знаю, это main ветка, origin и dev ветки. Угу. Какая какая какая есть что?
Speaker A
То есть main origin ветка, это уже то, что идёт на прод, а dev ветка, это каждый разработчик под свой таск может создать ветку, там что-то сделать и потом смержить с какой-нибудь другой основной, э, dev веткой или уже потом с мейном.
Speaker A
А если не dev, то как как ещё может называться ветка, на которой можно вносить изменения?
Speaker A
Вот это не знаю сейчас. Фича. Как? Фича. Фича? Да, фича скорее всего будет фича, чем dev.
Speaker A
Угу. Ну, ещё обычная, ну, в альфе есть тест, которая сразу в тестовую среду изменения проводит.
Speaker A
Угу. А main называется master. Ну, это на разнице, как она называется, нет. Хорошо понятно.
Speaker A
Давай продолжим тогда, вернёмся к основным артефактам аналитика. Угу. В принципе, по по структуре, э, документа, которые описывают итерацию, я поняла, да, стандартно, примерно всё как у нас.
Speaker A
А, а что касается описания логики фронта или контракта middle front, вот образ составления таких документов был?
Speaker A
М, ну вот про, если это считать как use case, то есть описание действия фронта и какие он должен, а, ну, дёргать endpoint для получения или отправки данных.
Speaker A
Угу. И из чего примерно состояла эта блочка? Ну, то есть акторы, то есть действующие лица, потом, а, предусловия или какой-то триггер, что должно произойти для выполнения этого сценария, основной сценарий, а, где описывается действие от начала до конца, как реагирует система
Speaker A
на действия пользователя и в конце он приводит к результату. Потом после основного сценария альтернативный сценарий, это такое, ну, разветвление от основного что-то.
Speaker A
Какой-то другой там, сценарий пошёл, словно, в рамках этой задачи. А, потом исключение, это когда уже происходит какая-то ошибка в основном из сценариев.
Speaker A
И в конце результат того, что мы добились. Угу. [откашливается] А что должно получиться. А бывало ли такое, что вот ты показываешь use case, разработку фронта, он посмотрел, говорит: "Ну, я вроде по шагам понимаю, а ты можешь мне на
Speaker A
макетах показать, как это всё происходит?" То есть какая страничка открывается, на каком конкретно Угу, для этого делали интерактивные, интерактивные вайрфреймы в Balsamiq. То есть там можно ссылки на страни, переход по страницам. А для описания того, а, как данные передаются между системами,
Speaker A
в файлах эндпоинтов есть sequence диаграмма. М, ну, да, но лучше, конечно, всё-таки и то и то.
Speaker A
Как вот этот экранчик, описание, ну, что видит пользователь, если там есть какая-то кнопка, по нажатию идёт пере на шаг два, то есть по шагам. Типа, вот ты находишься на точке на точке А, видишь точку нажимаешь на неё, что происходит на шаге
Speaker A
один. К ней же прикладывается скриншот из макета твоего, что вот как выглядит вот то, что на этом шаге.
Speaker A
Дальше он нажимает на кнопку, переходит на шаг два, у него открывается другая страничка и тоже скриншот из Figma номер два. И так вот, типа, ну и плюс, как ты сказал, на каждом шаге какой endpoint дёргается для того, чтобы получить эти
Speaker A
данные. Угу. Ещё А-а, ну, наверное, про виджеты из SwiftUI не буду тебя спрашивать, понятно, что, скорее всего, нет.
Speaker A
Угу. А где вы логировали операции по клиентам? Там где-то периодически. Э-э, в базе данных.
Speaker A
Угу. А какой? Как? Что за база данных была? PostgreSQL. Э-э, реляционная база данных. Угу.
Speaker A
А обязательное логирование для отчётности или в ОПС у вас вообще не было ядра какого-то?
Speaker A
Э-э. Насчёт этого не думал. Э-э ну особо не работал в банковской сфере. Угу. Так, можно Ну, я предполагал, что мы храним все данные, э-э, допустим, организации у себя и обновляем их там раз в полмесяца для актуализации.
Speaker A
Ну, тут возникает Вы так, конечно, можете делать, и в любом большом есть разные базы данных, где можно что-то прихранивать на какое-то время. Но тут возникает вопрос в том, что нужно проводки проводить.
Speaker A
Счётность формирует Центробанк, это основная проблема банка. И по сути все важные финансовые должны быть зашиты в какое-то ядро, чтобы чётко делать своевременные проводки.
Speaker A
Потому что Вот. На самом деле, это даже по нефинансовым сервисам, с которыми я работаю, так. А с финансовыми это 100% И как это лучше объяснить?
Speaker A
Ну что, а-а, хранили какое-то время, как ты говоришь, там месяц, например, Postgres, а-а, но при этом передавали через шинный сервис, а-а, данные в OBS тоже, логировали операции в OBS.
Speaker A
Угу. То есть у нас временно в OBS все вещи хранятся. Да. А потом мы с них берём данные для повторного ведения.
Speaker A
Таким же путём путём тоже через шинный сервис в любой момент можно эти данные получить.
Speaker A
Ну там вопрос, а-а, куда вы обращались, уже может быть вариантов миллион, в каждом банке по-своему. Где-то это может быть какой-то кредитный модуль, да, или там, ну, что-то специфическое, заработанная прокладка, но в конечном счёте корни всё равно у этого будут OBS.
Speaker A
Он тоже будет брать в OBS, просто вам передавать. Угу. А-а, ладно, с какими архитектурными задачами удалось поработать за период работы в банке?
Speaker A
М-м, микросервисными. А-а, немного API Gateway. Ну, а остальные как бы боюсь называть, если спросят.
Speaker A
Могу не ответить. Там больше архитектура, если сказать. Угу. Это в рамках больше описания интеграции. А вот если говорить про взаимодействие с архитектором, то как оно строилось и какие артефакты или документы, диаграммы, может быть, приходилось с ним согласовывать?
Speaker A
Угу. [откашливается] Ну, то есть вот приходит задание, это таска, требования, а сначала сам сформирую там какое-то описание, не обязательно полностью все артефакты, какое-то решение.
Speaker A
Что вот нужно взаимодействовать там с теми-то системами, возможно, какая-то sequence диаграмма. И потом согласовывать это с архитектором, чтобы он, ну, посмотрел на адекватность того, что вот это реализуемо и наша система это поддержит.
Speaker A
Угу. А если архитектор, ну, то есть он же не может знать всех компонентов и систем, которые в банке существуют, даже там в одном направлении, возможно, не говоря уже о том, что иногда данные нужно получить вообще абсолютно из какой-то новой системы, с
Speaker A
которой раньше не взаимодействовали. Вот как поступить, если это абсолютно новая фича, ты и про неё ничего не знаешь?
Speaker A
Угу. Мм, ну, допустим, там бизнес заказал у архитектора вижу. Вот. Что он должен тебе принести для того, чтобы у тебя было всё, чтобы в дальнейшем описывать интеграцию?
Speaker A
Переходить к своей части. Угу. Ну, диаграмма компонентов, чтобы можно было видеть, какие компоненты с каким, по какому интерфейсу взаимодействуют.
Speaker A
Угу. А-а какой-то файл с трассировками, там, где все эндпоинты расписаны, возможно, каждого сервиса, там, отдельно геты, отдельно посты.
Speaker A
М-м. Что ещё? Вот это вот основное, что приходит в голову. Это, в принципе, основное и есть, да. То есть, компоненты, и дальше ты уже там решаешь, как их интегрировать.
Speaker A
Угу. Ну, вот. А если нам нужно спроектировать новую таблицу в базе данных, то как тогда мы это будем Приходилось ли вообще с такими задачами сталкиваться?
Speaker A
Э-э ну, да. Составляли сначала ER-диаграмму, то есть, у нас уже есть основная ER-диаграмма всей всей базы нашей.
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
А после этого разработчики ну, разрабатывали, а тестировщики в это время собирали такой тест-лист, что им нужно протестировать по каждой фиче. Допустим, у нас в user story были критерии приёмки.
Speaker A
Тоже их все выписывали. И вот дальше после теста отправлялся на, ну, он тестировался на тест, тестовом сервере.
Speaker A
А отправлялся на Если были ошибки, обратно разработчикам, если нет, то на демо. Ну, что показывали какие те или иные фичи внедрили.
Speaker A
Ну, а может сразу на прод? Вы же команда уже проверили на тестовом сервере и чего?
Speaker A
Угу. Для заказчика всё равно надо показать, вдруг мы не поняли друг, хотя в начале, конечно там все требования выявили, подписали, но каждые там два спринта демо было.
Speaker A
Ну, демо-то, конечно, был, да, но раскатка, скорее всего, была поэтапная. Так прямо, потому что на бою ты тоже не всегда знаешь, как фича себя поведёт.
Speaker A
Угу. Может повести себя не так, как на тесте, поэтому обычно применяется как раз фичи-тоглы и поэтапная раскатка после стрелка, когда она сначала открывается на рабочую группу. То есть на вас, команду, потом на банк, потом, когда уже 2 недели
Speaker A
проверили, что всё вроде бы хорошо, уже открываем там на весь, на 100, 200, 300 и на всех по закону. То есть обычно на 20 млн сразу не открывается это.
Speaker A
Угу. Очень большая редкость, исключение. Угу. Вот, э-э, смотри, а если, например, вот у нас уже есть макеты в фирме, да?
Speaker A
И может уже вестись разработка. То, вот как бы ты установил очерёдность? Сначала фронтовый разработчик делал свой делал свою часть работы, middle или одновременно, в общем?
Speaker A
Э-э, одновременно, то есть фронт может работать с mock-up данными. Угу, на три смены на разработку.
Speaker A
Но middle просто обычно ждёт, пока аналитик напишет ТЗ, а фронту кроме макетов ничего не надо.
Speaker A
[смех] Поэтому часто бывает так, что фронт наперёд. Что ему действительно макетов ничего больше не надо.
Speaker A
Угу. Middle ещё будет, скорее всего, ждать ТЗ всё-таки. Угу. А приходилось тебе оценивать задачу другого члена команды, например разработчика?
Speaker A
Story поинтах там эстимировать. Угу, ну, прям других, кроме аналитиков, нет. А других аналитиков? А других аналитиков?
Speaker A
Ну, в конце спринта, когда вот этот спринт спринт ревью, потом спринт планинг, тогда в групповых обсуждениях обсуждаем, ну, просто так.
Speaker A
На словах, без официально там story поинтов. Просто в часах. А если ты единственный аналитик в своей команде и у тебя есть 3-5 лет?
Speaker A
Ну, тогда я сначала сам всё анализировал и уже потом давал на согласование. А если вы вдвоём, то ты будет на планинге Вася условный, который будет говорить: "Мне это займёт 5 дней", а ты скажешь: "Мне 2".
Speaker A
И что? Как ты себе это представляешь? Нет, он наберёт. На самом деле мне на это надо два.
Speaker A
Или или такой он в отпуске, а я такая: "А давайте ему дадим два дня". Он пришёл такой: "В смысле, это вообще задача на два спринта".
Speaker A
Ну нет, так лучше не говорить. Как ответить тогда? Только свои. Только свои? В случае, если уже совсем ты даже примерно не знаешь, как свою задачу оценить, ты на онбординге первые там 3 месяца, можешь посоветоваться с техлидом, но точно ни с кем не из
Speaker A
команды, даже ПО тебе не может диктовать, сколько у тебя должна занимать та или иная задача.
Speaker A
Так, в связи с этим вопрос. А как происходило ревью документации у вас на проекте?
Speaker A
И было ли вообще какое-то ревью? М-м, ну вообще была кросс-ревью, то есть друг другу показывали аналитики.
Speaker A
А-а. Вот, оценивали по definition of ready и definition of done, то есть там наличие диаграмм там где-то необходимо, критерии приёмки, чтобы были входные, выходные данные.
Speaker A
Э-э, там версионность соблюдалась, допустим, endpoint описываем. Ну вот, то был шаблон, то есть если по этому шаблону этот артефакт полностью соответствует, то уже он проходит. То есть, понятно, там проходили по нему, читали, проверяли на адекватность.
Speaker A
И вот, и дальше уже передавали разработке. Угу. Сколько аппрувов надо было собрать для нового endpoint?
Speaker A
М-м, на один. Один, да? А кто участвовал? Аналитики всей дирекции, кластера или как? Ну, то есть с каким-нибудь одним аналитиком. Если были спорные моменты, уже к тимлиду идти шли.
Speaker A
А что значит какими-нибудь одним? И вот я говорю, с каким? Который в OBS разрабатывает дорабатывает ядро?
Speaker A
Или это всё-таки был какой-то соседней команды? Угу. Ну, из из нашей же команды аналитик.
Speaker A
Угу. Тоесть, какой-то смежной системы из вашего кластера, например, мастер мастер инфомобайла или из других кластеров. Тоесть, наврядли в этом бы участвовал. Как бы нет, но если прям совсем лайков не хватает, тогда конечно можно позвать кого угодно.
Speaker A
Но всё-таки скорее это были бы люди, которые что-то понимают в твоём направлении. Угу. Или можно сказать, что техлид голосовал в крайнем случае. Только он.
Speaker A
Угу. [откашливается] Вот. Хорошо. А как происходила, вот допустим, жизненная ситуация? Угу. А-а. Дизайнер нарисовал очень красивые элементы на макетах.
Speaker A
И к тебе приходит как к аналитику фронт разработчик и говорит: "Юля, мы вот запланировались и уже взяли задачу в этот спринт а-а то, чтобы разработать данный функционал.
Speaker A
Я вот начал насильно разработку и я понимаю, что у меня в библиотеке нету вот такого элемента, который написал там с морганием и навигацией.
Speaker A
И для того, чтобы его разработать, мне нужно будет ещё отдельный спринт. Тоесть, вот этот спринт я только потрачу на разработку этого элемента и потом только смогу приступить к задаче. Что ты будешь делать в такой ситуации? Как решать этот конфликт? И вообще, может,
Speaker A
ты его отправишь дизайнеру или или вообще не будешь его решать? М-м. И всё это твоей документации не касается?
Speaker A
Угу. Так, ну, сначала у нас есть, получается, wireframe, где мы описывали общую структуру страницы, а потом уже дизайнер Да, да, не надо, у нас уже есть макет фигмы из дизайн-системы, где прописано, какой элемент какого цвета, как он называется, какого типа и так далее.
Speaker A
Угу. Ну, вот он выбрал что-то такое, ну, вот решил, что под красиво будет вот именно так.
Speaker A
Ну, тогда вопросы больше к дизайнеру, потому что его решение передвигает срок, как бы, реализации, которая уже заранее согласована.
Speaker A
Так, и идём к дизайнеру и А он Ну, потом Ты идёшь с фронтендом к дизайнеру и говоришь, типа, чувак, поменяй-ка этот элемент, а он, типа, нам все сроки срывает. А он говорит: "Нет, этот элемент по требованию стейкхолдеров, они настаивают
Speaker A
на использовании именно такого дизайна и как бы всё, ну, по-другому другого выхода у нас нет. Его можно нужно реализовать именно вот таким образом, как я нарисовал".
Speaker A
Угу. Это [откашливается] требование бизнеса. Ну всё это типа тупик. Вы идёте к ПО и согласовываете увеличение сроков, ставите в известность.
Speaker A
Угу. И второй вариант, как ты говоришь, если просто дизайнер-самодур и решил вот так просто сделать для себя, тогда, конечно, вы просто с ним договариваетесь, он говорит: "О'кей, я переделаю" и переделал.
Speaker A
Угу. Тут возможно два таких варианта. Угу. А какие вопросы вот э, рассматривались на ретроспективе спринта?
Speaker A
[фыркает] Э, что понравилось, что не понравилось, что бы улучшили. И что бы Ну, это основные три вопроса.
Speaker A
А какие чаще всего проблемы были с краем? Ну, с краем же проблема все стандартные.
Speaker A
Вот, какие у вас были в команде? М-м. Не знаю, там даже представления нет. Это был водопад?
Speaker A
[смех] [фыркает] Ну, и можно сказать. Ну, подумай. Давай, давай, я тебе дам 2 минутки, ты подумай, какие проблемы вообще в скраме может быть. Это, по сути, первая тема.
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
Нет, такого нет. Банк был не особо крупный и IT-отдел такой, ну, можно сказать, на раз- на начале развития только был.
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
Угу. А, был ли у тебя опыт SOAP и умеешь ли ты составлять XML схемы? Ой, XML, прости. Создание.
Speaker A
Из XML из XSD делать пример XML файла, да умею. Угу. А как, э, ну, в каких задачах можешь привести пример вот этих SOAP запросов?
Speaker A
М-м, в интеграциях с оборудованием, то есть был производитель оборудования, у которого там, получается, датчики, как различное оборудование, был общий сервер, и мы к этому сервису обращались по SOAP, как раз по XML формату.
Speaker A
Угу. Был SOAP. Да, был очень давно. А как вы пере, ну, потом переводили как-то, да, меняли формат на JSON или так обрабатывали?
Speaker A
Угу. Нет а сразу а получали XML файл и есть, ну, с помощью там сериализации сразу в базу данных.
Speaker A
А в базе данных хранилось в каком формате? Ну, Postgres, то есть просто табличный формат.
Speaker A
Так, ну, наверное, всё-таки Подождите, нет, наверное, вы всё-таки на Java переводили уже. У нас C# был, это я вот про тот проект рассказываю, где SOAP был.
Speaker A
Ну, то есть, вы вообще никак не обрабатывали данные из Ты говорил, что они в разном формате приходили, просто всё клали в базу данных?
Speaker A
То у вас была э монолит? Нет, микросервис. Хм. Так сказать, что всё сначала в JSON переводили, а потом уже в базу данных.
Speaker A
Ну, я же не знаю, как у вас было на самом деле. Просто странно. Странно.
Speaker A
Ну, там было такое, что мы получали XML файл, то есть, он Ну, мы его часто получали, потому что это были события.
Speaker A
Угу. Регулярно. И с помощью регулярных выражений вытаскивали именно те параметры, которые нам нужны были.
Speaker A
И их уже записывали в параметры, и они хранились в базе данных. Угу. О'кей, хорошо, да, так.
Speaker A
Как это описать? Прям там Прям так и сказать? Так и сказать, да. [смех] Угу.
Speaker A
О'кей. А в дальнейшем что вы с этими данными делали? А строили это какие-то Графики строили?
Speaker A
А? Дашборды какие-то отчёты строили? Да, тренды, графики, исторические данные. Угу, понятно. Ну, это что-то наподобие вот в таких случаях обычно применяется шаблон BFF.
Speaker A
Слышал ты про такое? Такое нет. Backend from frontend. Угу. Ну, типа, это апишка, вот вы просто ложили в базу данных, да?
Speaker A
Угу. И прописывали ещё какую-то логику и скорее фильтрации, выведения. Вот. А в случае с BFF шаблоном у вас была бы как бы вот это апи, это как промежуточный слой, который не имеет никакой бизнес-логики, а просто собирает данные из различных источников, которые
Speaker A
вот, как ты говоришь, в разном формате. Кто-то на gRPC, кто-то на Slack, кто-то на Rest.
Speaker A
Вот. И он просто все данные аккумулирует и по фильтрам выдаёт там, фильтрует по каким-то параметрам.
Speaker A
Ага. Ну, наверное, это что-то наподобие того, что у вас и было, да? Или у вас было это через API Gateway?
Speaker A
Ну, в основном было так, что по ресту обращались к микросервису, который там То есть был источник данных, у него были параметры. У каждого источника, каждый источник это отдельный микросервис, то есть у него своя апишка.
Speaker A
Вот, к нему постоянно шли запросы и он присылал значения параметров. А почему они не аккумулировались всё в одной?
Speaker A
Типа, не было одной общей апишки, которая все данные вытягивала из-за всех других апишек? Dashboard front.
Speaker A
Мм. Ну, просто их же можно фильтровать. То есть, э, как когда-то нужно, типа, данные из двух источников одновременно, да?
Speaker A
Угу. Когда-то там из одного, когда-то из всех шести. То есть, если бы они все были бы одной апишке, это было бы удобно фильтровать и аккумулировать, и плюс а-а, ну, как бы не приходилось бы не синхронно, а эти данные бы они просто с
Speaker A
с определённой периодичностью обновлялись. Угу. [откашливается] Ну, да, у нас там был, получается, ядро, главный сервис.
Speaker A
Угу. А-а, к нему по апишке, то есть апишка один адрес имела, но разные порты, это разные сервисы были.
Speaker A
По ним понималось, к какому сервису, ну, к какому источнику данных относится параметр. Угу. Это похоже на API Gateway.
Speaker A
Это похоже, да, больше на шлюз, но это не очень похоже на BFF. Угу. [откашливается] Ну, потому что там всё-таки предполагается отсутствие бизнес-логики, просто какая-то фильтрация, что вот сегодня выдать всех из Москвы.
Speaker A
Там да ну, не знаю, показания всех счётчиков из Москвы, завтра там из Волгограда, послезавтра там, я не знаю, там тоже животноводство условно.
Speaker A
[смех] То есть, такое, типа просто фильтры какие-то. Угу. А у вас как это работало? Типа, вот хочу из Москвы по животноводству, обращаемся в эту апишку, фильтруем. Ну, типа, это же получается как-то нелогично, да? То есть, типа, нам нужно сначала всё собрать,
Speaker A
потом как-то этот тип набор данных отфильтровать, и каждый раз это типа какой-то разный набор задействованных апишек и так далее. То есть, какая-то предполагается более сложная логика, мне кажется. Или у вас это так было?
Speaker A
Угу, я помню точно, был главный сервис, то есть, ядро. То есть, он сначала при запуске проверял, он пинговал все остальные сервисы, чтобы они были запущены.
Speaker A
И вот так вот, а-а, то есть, одна апишка, но разные порты. То есть, по портам он понимал, к какому сервису ему обратиться надо.
Speaker A
Угу. О'кей, но он как в себе не аккумулировал все данные. Угу. То есть у каждого А что вы тогда записывали в базу данных?
Speaker A
Почему он не мог в базу данных обратиться, вот этот централизованный атом ядро? Ну, у каждого микросервиса своя база данных была.
Speaker A
А, у каждого микросервиса своя база данных была. То есть там получается источник э, разные форматы имеет, там разные сущности, поэтому проще было под каждый микросервис, каждый источник э, и своя база данных.
Speaker A
Угу. Ну, да, тогда если бы вы сделали BFF, вам бы всё равно нужна была бы какая-то новая база данных, куда бы вам это прихранивать, скорее всего, пришлось.
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
А, по сути, этот счёт, он даже не нужен, это просто реквизиты содержит и правильную сумму, для того, чтобы бухгалтерия не заморачивалась и не проверяла 10 раз, по каким реквизитам и какую сумму платить. Вообще, счёт-фактура это не обязательный документ, ты можешь просто заплатить по
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
Ладно давай короче
Topics:системный аналитиктехсобеседованиеинтеграцияuse caseuser storyKafkaScrumкредитование юрлицсобеседование ITSCADA
