Speaker A
А то, добрый день. А, добрый день, Леонид. Так, сейчас включу камеру. По пару минут коллеги подключатся, и начнём.
Техническое собеседование на позицию аналитика в проекте «Единый профиль клиента» Альфа-Банка с обсуждением ролей, инструментов и архитектуры.
Key Takeaways
- Проект направлен на создание единой платформы для актуальных и стандартизированных клиентских данных.
- Аналитик в проекте выполняет полный цикл от бизнес-требований до постановок на разработку.
- Используются современные инструменты для интеграционного тестирования и мониторинга.
- Проект находится на стадии активного переключения систем с legacy на новую платформу.
- Команда разделена по функциональным направлениям: ядро, источники, качество, потребители.
What the video covers
- Вступительное общение и обсуждение роли аналитика в технической команде проекта.
- Описание проекта «Единый профиль клиента» как новой платформы для хранения и обработки клиентских данных Альфа-Банка.
- Задачи по замещению устаревшей системы Equation и созданию единой «золотой записи» клиента.
- Обзор структуры команд: ядровые сервисы, источники данных, качество, потребители и новые малые команды.
- Роль аналитика как фулстек специалиста, работающего с бизнес-процессами и системами-потребителями.
- Используемые инструменты для интеграционного тестирования: SOAP UI, Postman, Kafka, Open Search.
- Обсуждение процессов интеграции с внешними системами и госсервисами для нормализации данных.
- Текущий этап проекта — переключение источников и потребителей с legacy-систем на новую платформу.
- Подробности о жизненном цикле разработки, взаимодействии с архитекторами и тестировщиками.
- Обсуждение технических деталей, включая микросервисы, SQL-запросы и безопасность передачи данных.
Full Transcript — Download SRT & Markdown
Speaker A
Хорошо. А если не секрет, у вас получается какая роль? Я тех команды. Понял. Приятно. Отвечаю за айтишную составляющую по проекту.
Speaker A
Вы ищете, получается, аналитика? Да, всё верно. То есть это совмещение функций. Ну даже так скажу, что мы человек, который будет подключисти задачи, то есть от проработки бизнес-требований до системы требований, подготовки постановок на разработку.
Speaker A
Угу. Понял. Это включая, то есть, ну, если мы говорим чисто процесс, вот, э, встреча с заинтересованными сторонами, да, обычно это внешняя команда относительно проекта, находится в контуре Альфа, взаимодействие там с нашей разработкой, с архитекторами, с тестировщиками, автотестировщиками и так далее по
Speaker A
полному жизненному циклу в целом. Угу. Ну да, да, понял. Из описания вакансий. В принципе, я так предполагал, просто на всякие уточнения. Бывает такое, что, ну, описание там бывает какой-то шаблонное, например, под несколько вакансий сразу делается. Вот когда в несколько команд
Speaker A
ищут. Ну, у нас в основном конкретно под нашу, да, то есть это прямо фстек, фстек, ну и поботся на 50 на 50. То есть это вот [фыркает] прямо [откашливается] классический такой подход.
Speaker A
Нет, нет такого, что там уклон будет бизнес или в системы [откашливается], и тем, и тем придётся заниматься.
Speaker A
Угу. Не знаю, у коллег, будут ли они. А, ну да, в любом случае ждём. Если могу ещё кое-что спросить, я спрошу, пока не началось. Ну, в любом случае, что... А вот, ээ, условно у вас из описания вакансий следует то, что,
Speaker A
ну, я как аналитик не просто проектирую сервисы, да, но и условно анализирую их работу через Postman, там, Swagger. Вот как бы мне эта практика знакома. Просто любопытно, у вас вообще может какое-то, ну, подразумевается более глубокое тестирование, может, вы другими
Speaker A
инструментами пользуетесь. Смот на на ты же не против, если мы будем... А, да, да, конечно, да. Смотри, то есть здесь какая история?
Speaker A
У нас проводится интеграционное тестирование с внешними системами. Соответственно, оно проводится в формате, когда либо они направляют нам запросы через свои какие-то утилиты, либо мы направляем, мы используем, собственно, SOAP UI, да, для проверки сообщений SOAPа. Используем Postman для проверки
Speaker A
каких-нибудь API. Плюс смотрим по Графане, ой, не Графане, этим Open Search, чём сообщение по Кафке, ну или Kafka Brow, то есть именно такой полный полный scope тестирования именно как таковое тестирование, да, то есть там проверка кейсов, да, подготовка тестов и
Speaker A
прочее. Этим у нас занимаются тестировщики. Она может проверить работоспособность инструмента, который был разработан. Ну такое приёмочное испытание, да, можно сказать. Ну и то не всегда это требуется, не всегда это необходимо.
Speaker A
Вот. Ну, есть, да, нюансы по интеграционному тестированию, когда с внешними товарищами, да, общаешься там, да, там придётся покидать запросики, посмотреть ответ запрос, что всё соответствует тем требованиям, которые указаны либо у тебя, либо у... Угу. внешних товарищей. А вот у нас
Speaker A
Анастасия подключилась. Настя чуть-чуть сейчас поподробнее расскажешь по проекту, ну, и по тому, как мы проведём это собеседование дальше.
Speaker A
Так, а, а на чём мы остановились? Просто про команду рассказал, да? Лю я рассказал в целом, чем он занимается аналитик. Ну я тупо поспрашиваю, какие у нас инструменты используются и в каких областях. [откашливается] Ну давайте тогда расскажу про команду. Ой, ну в
Speaker A
целом про проект. Угу. Так. У нас ээ проект называется Единый профиль клиента. А канци написано. А это у нас платформа, которая реагирует [откашливается] в себе, то есть как хранилище является клиентских данных по Альфабанку, скажем так. То есть мы
Speaker A
сейчас только разрабатываемся. Ну, как только разрабатывается, мы на первых этапах внедрения, скажем так, потому что мы все уже в проме, но полноценно все ээ системы банка на нас ещё пока не перешли, то есть мы готовы, и мы сейчас
Speaker A
в стадии того, что на нас переключаются источники и потребители. А вот, э, ещё немножечко про платформу.
Speaker A
То есть это, э, ну, [откашливается] ещё раз проговорю, что новая система взамен существующей legacy системы. То есть в Альфабанке есть, э, тоже как бы хранилище по клиентским данным считается сейчас. И есть, ээ, устаревшая система Equation.
Speaker A
Она, ну, главное считается в банке, то есть там и по продуктам, и по самим профилям клиентов ведутся справочники, скажем так. [откашливается] Вот. А мы стараемся заместить с собой заменить с собой там DM equation и, скажем, представить клиентские данные и
Speaker A
персональные данные, вообще суть ведения информации о клиенте в совершенно новом формате. Это будет ээ некая золотая запись о клиенте, о каждом клиенте. То есть это и юрике, и физики, и так далее.
Speaker A
Вот мы работаем над тем, чтобы клиентские данные всегда были актуальны на текущий момент, стандартизированы, уникализированы, дедублицированы.
Speaker A
Аа максимально содержали бы весь профиль, весь сразу один профиль, все данные о клиенте. То есть, что не нужно будет там залезть за одними данными в одно место, за другими в другое место и так далее.
Speaker A
Вот, ээ, туда же входят у нас, ну, не только сами персональные данные, это всякие ещё и связи, то есть связанные профили, аналитические признаки, финансовые показатели, в общем, максимально всё при всём. То есть, ээ, очень глубокий подход по сбору данных.
Speaker A
Вот, а над данной платформой у нас аа работают несколько команд. То есть это команда ядровых сервисов. Ну, понятно, да, что она занимается чисто разработкой инфраструктурных сервисов и так далее.
Speaker A
А команда, ну, источников, которые занимаются тем, что подключаются системы источники, то есть это системы банка, которые работают непосредственно там с клиентами или с в процессах, э, в которых приходят, скажем так, клиентские данные, и они в итоге тоже у себя их не хранят,
Speaker A
а передают нам, да, то есть, чтобы это было опять же в едином хранилище. Вот, то есть команды, которые работают с источниками, они сейчас переключают также эти системы с legacy систем на нас.
Speaker A
Вот. Мм, потом у нас, ну, команды качества, я уже проговорила, наверное, что это как раз они разрабатывают сервисы стандартизации, дубликации, а также разрабатывают интеграции с различными госсервисами, где можно, ну, например, там по EN зайти в ФНС или там
Speaker A
в сервисы ЕГРЮЛ и, например, актуализировать действительно ЕНН по организации или и по игре, негрюлп. Вот.
Speaker A
[вздыхает][тяжело вздыхает] Ну, в общем, все возможные, все существующие, скажем так, доступные сервисы, гостсервисы тоже планируются к интеграциям и к использованию данных от них в рамках стандартизации, нормализации данных.
Speaker A
Вот. Ну, есть ээ также третья линия поддержки, отчётность NC. А новые [откашливается] командочки маленькие возникают, которые там работают со стоп-листами, блокировками, [вздыхает][тяжело вздыхает] а согласией, по-моему, тоже там будет, ээ, ну, в нашем видении трек. Вот. И так далее. А наша команда занимается
Speaker A
потребителями, то есть системы, бизнес-системы, которые используют клиентские данные в своих бизнес-процессах. Вот. И они во множественных количествах должны будут к нам подключаться. Сейчас они подключены к старым legacy системам. Мы их на себя переключаем.
Speaker A
Вот переключаем мы их пока в, ну, чтобы не давать им [вздыхает] не заставлять их перерабатываться, да? Переключаем в, скажем, в бесшовном режиме, чтобы они использовали свои существующие там сервисы SOAP, и через шину, куда они ходят, там в
Speaker A
старых сервисах и под капотом они мы их просто переключаем на свои адаптеры, которые тоже уже разработали.
Speaker A
Вот. Так что по своей готовности, ну, наверное, процентов 80-90, да, уже всё готово. Просто мы уже сейчас как раз активно занимаемся тем, что переключаем на себя источники и потребителей. Вот как раз в нашу команду требуется аналитик, который будет работать
Speaker A
с системами потребителями, то есть ээ в роли именно фулстек аналитика, когда потребуется именно прорабатывать бизнес-процесс на стороне заказчика, да.
Speaker A
Ну, это не заказчики, это именно потребители, то есть это именно системы, которые, н...
Speaker A
немножко такой подход, что они будут к нам сами приходить. мы должны будем просто их валидировать, скажем так, валидировать их процесс, смотреть, на каком этапе они, какие данные будут забирать у нас, э, как, ну, на каком этапе бизнес-процесса, имею в виду, какие клиентские данные, то
Speaker A
есть какие профили, потому что у нас есть ээ ну различного качества данные, их нужно будет проверять, фильтровать и и так далее. Это всё, а, фиксируется в бизнес-трелебованиях прорабатывается согласовывается и дальше даётся на разработку. А разработка может быть как
Speaker A
подключение к существующим сервисам, так и разработка отдельных сервисов. Ну, если там, допустим, какая-то большая нагрузка будет или там какая-то сложная логика, и потребуется это сделать персонально конкретно для одного потребителя, вот это будет вполне возможно, что это будет какие-то
Speaker A
отдельные сервисы. И при разработке отдельных сервисов тоже у нас занимается аналитик этим, ведёт эту [вздыхает][тяжело вздыхает] активность, скажем так, и разрабатывает BRD, FSD, а обсуждает, согласовывает это с архитектором, всё фиксирует и также ведёт весь производственный процесс по задаче по
Speaker A
разработке. То есть через разработку, тестирование также следить, чтобы всё это вышло в прот. Вот подключ по тому, что дальше с потребителем происходит, [откашливается] а системные требования тоже фиксируются, разрабатываются, тестируется и дальше аналитик у нас ещё участвует в интеграционном тестировании.
Speaker A
Ну это что-то вроде аа что-то вроде ПС, да, приёмнастаточных испытаний, когда в онлайне там просто прокидываются запросы и коллеги проверяют, что всё соответствует ожиданиям, всё хорошо.
Speaker A
Вот результаты это фиксируются и дальше тогда уже интеграция передаётся в прот. [откашливается] Всё подключается и всё начинает работать. И аналитик зарабатывает лишнюю звёздочку, скажем так. [вздыхает][тяжело вздыхает] А таким образом. Ну, в целом, наверное, по задаче я рассказала. Если что-то
Speaker A
нужно подробнее до рассказать, могу ответить на вопрос. Да, спасибо большое за подробный рассказ. На самом деле, ну, было понятно. И я немножко отвлекался только, чтобы, да, записать вопрос.
Speaker A
А в целом получается, данная система решает какой вопрос? Она агрегирует данные из разных источников. Я так понимаю, это уже внутрибанковские существующие источники, плюс это внешние какие-то госсточники и, возможно, не только госсервисы, а в целом, которые могут официально предоставлять данные.
Speaker A
Ну, я по вашему взгляду так понял, всё-таки. Ну, я думаю, что и такое тоже, потому что я не совсем в курсе всего, но я думаю, что всё, что возможно использовать для стандартизации и проверки данных, э, [откашливается] и это открытые доступные источники, они у
Speaker A
нас будут использоваться, да? Это получается м агрегируется, во-первых, ну, в каком-то универсальном виде, м, плюс это предоставляется нужному потребителю. Получается, до этого система существует. А, и ещё это делается, как я понял, возможно, ошибаюсь, но акцент был на том, что это как бы актуально, но
Speaker A
значит, и быстро обновляется. Вот получается так, что существующие до этого банковские системы альфы, да, вот вы несколько назвали, они, ну, этот вопрос не решали либо решали разрозненно как-то, если правильно понимаю.
Speaker A
Ну, у нас получается существующие банковские системы, они, да, не все данные хранят в себе, то есть потребителям приходилось ходить разные сервисы, и это м ну вопрос качества данных там был большой.
Speaker A
Угу. Вот. Понял. А получается, самому, ну, самому банку Альфем-то другим продуктом данная платформа нужна и для своих целей, и также как готовый продукт для потребителя.
Speaker A
Нет, для внешних целей, для внешних потребителей мы это ни в коем случае не предоставляем. Это исключительно для внутрибанковских процессов.
Speaker A
А, то есть система потребителей, да, это внутрибанковские сервисы. Да, да, да, понял. Понял. Аа, угу. А вот вы ещё про разные этапы у потребителей говорили. Получается, эта система, она будет отображать, какие данные, какой сервис подтягивает и для чего.
Speaker A
Мм, я не [откашливается] думаю, что будет отображать, потому что, смотрите, мы работаем в микросервисной архитектуре и, ну, у нас, по сути, просто это хранилище, э, данных, да, то есть это просто БД, большая большая БД. Вот. И мы разрабатываем именно
Speaker A
э микросервисы. Угу. Которые подключаются и, соответственно, либо кладут, либо получают данные от нас. То есть нет, наверное, такого.
Speaker A
Понял понял. Стандартного какого-то функционала, чтобы смотреть, кто к нам подключён, не будет. Угу. Ну, значит, я немножко ошибочно услышал.
Speaker A
Ну, я, наверное, просто, да, [откашливается] выразилась как-то неправильно. И получается ещё также, ну, под какие-то, если у потребителя специфические, так скажем, нужны под него какой-то, как скажем, ну, специальный модуль будет собираться.
Speaker A
То есть не какой-то стандартный, вполне может быть такой. Дада. Да. Угу. Понял. Ну пока ну звучит интересно, на самом деле. Врать не буду. И, а, сложно, не в плохом смысле этого слова. М пока что по вопросам. Ну, база вот так
Speaker A
всё. Потом они точно появятся ещё дополнительно, поэтому сейчас готов э как бы на все ваши вопросы отвечать.
Speaker A
Ну хорошо, тогда, э, продолжим. Тогда послушаем рассказ о тебе. Угу. А первый проект, на котором я работал как системный аналитик, даже там я начинал как бизнес-аналитик, и было, так скажем, несколько задач, связанных системно. Это был госсектор, это было Министерство строительства,
Speaker A
внедрение федеральной структуры ГИСГД есть такая на региональном уровне. Там по большей части мои задачи, там я проработал год, и в большинстве своём мои задачи заключались в том, чтобы проанализировать, как процесс выполняется сейчас. То есть как там сотрудник муниципалитета или
Speaker A
госведомства, если это, ну, госведомство именно Минстрой, если это продукт, разрешение на линейный объект, потому что полномочия были переданы по линейным объектам, такие там как газопровод, трубопровод, любой, любые сети, которые между несколькими там регионами либо между несколькими районами.
Speaker A
А, ну, условно нужно было наблюдать, как специалист выполняет этот функционал сейчас. и как э получается адаптировать системе. То есть там нету каких-то унифициаль унифицированных, так скажем, решений, которые на всю Россию прямо распространяются. По сути, ГИСГД на федеральном уровне предоставляет собой
Speaker A
какой-то, ну, как базу данных с общим функционалом э оттуда как будут данные отображаться, там, например, если это картография, вот, и как туда добавлять функционал. А вот именно с точки зрения каких-то законных законов, как это организовано на региональном уровне, в каждом регионе
Speaker A
по-разному. Вот нужно было смотреть, как у нас, какие лица отвечают за что, кто выдаёт, кто подписывает, кто что дополнительно согласовывает, у кого какие полномочия, например, направить а заявку на рассмотрение, на разрешение навод объекта в эксплуатацию назад. Аа то есть ролевая модель присутствовала.
Speaker A
Вот всё это нужно было описать в BPMAN нотации. Вот также, а, какие-то, ну, начальном этапе это было выяснение требований просто напрямую у госзаказчика получается ну у Минстроя. Просто начальном этапе я просто в блокнот записывал, потом всё это переписывал в аналог confluенс,
Speaker A
только там гасушный специальный. Вот. А, и далее сочинял от этого user стари, согласовывал их также заказчиком. чтобы видение более-менее совпадало. Скажу честно, оно чаще всего вначале совпадало, потом не совпадало.
Speaker A
Вот очень очень, наверное, вот я слышал такой вопрос, как бы что вам не нравится больше всего там как бы в работе аналитика, да? Это вот больше всего мне не нравится, когда на ходу требования меняются, но я думаю, это
Speaker A
вообще общая боль. А что ещё там было? Также, э, кроме, ну, вот как кроме user старей, юзкейсы также были. Вот всё это по сути в основном бизнес-спецификация. Там системной аналитики у меня было немного, именно был протокол САП, ээ, потому что,
Speaker A
ну, вся эта ГИСГД, она на этом протоколе завязана. И нужно было две ручки описать. Это, ну, точнее, в рамках проекта намного больше нужно было сделать, но то, что я успел до перехода в другую компанию, это две ручки я
Speaker A
прописал на, по-моему, получение информации о текущем статусе заявки. И, честно, вторую даже немножко не припомню, но там мне только довелось вот вообще увидеть, что такое XML, что что такое ВСDT, в SDL, точнее. Вот. А-э, ну и, собственно, всё про первое место.
Speaker A
Вот, если будут уточнения, как бы дополню. По второму месту это были, в частности, мобильные приложения, это РН э коллектор самокатов и личный кабинет оператора.
Speaker A
Получается, тут уже были э проектирование IP запросов, и проектирование - диаграмм. Вот тут уже намного меньше приходилось общаться с бизнесом напрямую. тут практически держателем, так скажем, ну нет, не держателем, а все доп пояснения по бизнесу po предоставлял. Вот. То есть
Speaker A
он как такой фильтр от бизнеса выступал. Он на всех совещаниях таких участвовал, ну, за с завязанных с менеджерами там, э, ещё связанными с бизнес-функциональностью. На какие-то я тоже привлекался, но по большей части уже был такой более системный функционал.
Speaker A
Вот. А-а, и вот сейчас текущее место работы, это проект система аренды и бронирования помещений, находящихся в собственности Райфы, вот, э, ну, Райфайзенбанка. Это, в частности, офисные какие-то пространства, это и производственные помещения, внутренняя платформа Райфы. Аа тут уже в начале
Speaker A
опять также проект создавался с нуля. В начале я также занимался и выяснением бизнес-требований. Тут побольше приходилось ходить к заказчику. Также описывал условно сначала в блокноте, потом это всё доводилось, ну, через, а, usеer story, через, э, юзкейсы в функциональные,
Speaker A
нефункциональные требования. И дальше уже по мере необходимости описыва, ну, создавались какие-то ручки, создавались сущности в базе данных. Тут и тесная работа была именно ну, с бэкэндером ответственно за бдшку. Тут требования поступали, так скажем, сначала, ну, в backклок заводит ПО, я беру задачку, он,
Speaker A
начиная у него что-то уточнять, он может сразу сказать: "Иди к заказчику". Потому что, ну, у него тут нету такого уровня владения, так скажем, э, в части бизнес каких-то моментов, как вот, например, на втором месте работы.
Speaker A
Вот. А тут и асинхронные запросы пощупал. То есть Кавку в первый раз вообще, ну, прописывал по шаблону.
Speaker A
Шаблоны, кстати, завёл. Вот. Ну, так как проект с нуля был, тоже, опять же, честно скажу, не не столько много времени убил на шаблоны, потому что на предыдущем проекте я, в принципе, уже дорабатывал действующий шаблон. У меня уже была картинка, так скажем, в голове,
Speaker A
как это хорошо сделать. Ну, не гиперсложно, но какая-то унифицированная форма должна, по моему мнению, быть, чтобы любой там коллега, например, коллега ушёл, другой пришёл, кого-то в команду внесли, они м по, ну, когда есть унификация, можно сразу сориентироваться, куда смотреть,
Speaker A
условно. Вот. Ну, в части ресзапросов я это точно могу отметить, а в части описания диаграмм тоже. В части каких-то обязательных артефактов тоже самое. Вот.
Speaker A
А что тут ещё было? Были моментики, например, где, ну вот тоже это по моей инициативе не очень мне нравилось, как коммуникация в команде настроена. Не в плане как бы там про какие-то ментальные там моменты говорим, да, а [откашливается] у нас общий чат.
Speaker A
Вот. И раньше это всё вот, ну, задачи и в обще в общем чате обсуждалось. Я завёл просто топики по каждой задаче. там айдишники жира брал, чтобы можно было потом по айдишнику найти эту задачку и все обсуждения посмотреть. Вот. Ну такой
Speaker A
как бы, наверное, не гиперзначимый кейс, но в части поиска информации он точно упростил аэ вопрос к команде, ну в том числе и мне.
Speaker A
Вот были, если ещё рассказывать и, так скажем конфликт между бизнесом и командой разработки. Это на втором месте работы, связанный, короче там э это, да, это был шаринг электросамокатов. Там как сначала задачка пришла от вообще бизнес-аналитика, точнее, не так, от
Speaker A
продуктового аналитика. А понадобилось им хранить информацию о том, где самокат оставили, когда арендовали, кто арендовал. Никак до этого, точнее, кто арендовал, мы и так хранили конечно честно не помню по по времени, но, по-моему, не меньше года. А вот какие-то
Speaker A
допдетали об аренде, которые им понадобились, как бы тоже не очень посвятили в детали, почему именно им это нужно.
Speaker A
А тут как бы бизнес проблему я увидел только в том, что они хотят, ну, какую-то, так скажем, по районам понимать, где выгоднее размещать больше всего самокатов. В общем, им понадобились допдетали.
Speaker A
Условно бэкндер, который у нас ответственный был за базу данных, сказал, что, ну, если это настолько важные данные, давайте, короче, шардить, ну, шардируем на несколько кластеров.
Speaker A
Я понимал, что в целом, ну, и в целом, наверное, из экономики, и у нас просто так было на втором месте работы, не очень относились к увеличению бюджета. А в любом случае, ну, кластер новый - это деньги. Вот когда пошёл сразу в голове,
Speaker A
ну, согласовывать этот вариант, сразу в голове держал момент, что можно просто, если уж откажутся, предложить вариант, что, да, это увеличит, например, по времени разработки, но не по деньгам. Аа решение такое, что просто мы разобьём базу данных. Ну, то есть нам надо
Speaker A
хранить за месяц. Мы, получается, сделаем отдельные, а, ну, участки, получается, как партиционирование по месяцам и просто репликацию. Всё это на одном кластере. Ну, то есть не тот вариант, который хотел изначально бкндер, но в то же время хоть какой-то
Speaker A
вариант по безопасности, так скажем, хранения. имею в виду не с точки зрения именно шифрования, а с точки зрения того, что данные не пропадут.
Speaker A
Вот вкратце, наверное, так. Готов ответить на допвопросы и так далее. Естественно, вышел на рынок перед текущей компании. Я работаю не напрямую в Райфе, а в компании, у которой основной заказчик, вот как раз эта система Райфа. Вот. И сколько ещё проживёт это, ну, точнее,
Speaker A
сколько ещё м Райфа будет доверять разработку этой системы нам, ани заберёт под крыло себе. И я думаю, оно просто в довесок текущим разработчикам её отдаст.
Speaker A
Я не знаю. Ну, то есть заранее хочу найти место, куда я готов перейти. Я правильно поняла, что это вот сейчас в основном работа была над одним проектом, и задачи были такие околопродуктовые, да, какие-то основное. А и под околопродуктовым имеете в виду,
Speaker A
ну, конечная ценность вот для просто, ну, тот, кто ей пользуется этой платформой. Ну да, вокруг как бы одного продукта улучшения всякие там и так далее. Угу.
Speaker A
О'кей. Так а по-попу ну пароли тоже правильно поняла, что тоже какая бы как бы фк была работа?
Speaker A
Мм, в начале больше как фулстк, сейчас больше как системный. Угу. Так а работа именно с микросервисами присутствует?
Speaker A
Да, на текущем проекте у нас микросервисная архитектура. Да, хорошо. Так, а команда большая? М на текущем проекте? Нет. Ну, относительно. Два бэкэндера, два фронта.
Speaker A
Teamle, po, я и тестировщик ещё. Угу. Объём задач большой. Мм, ну, примерно в бэклоге у нас вот сейчас всего, если вот актуально смотреть, 10 задач.
Speaker A
Вот ещё есть в тех долгие примерно 10 задач на на какой период? На спринт.
Speaker A
А нет, на спринт мы в текущий момент где-то в спринте у нас сейчас четыре задачи, но они такие по доработке уже тоже существующего функционала такие, так скажем, они не то что сложные, но придётся перелопатить некоторые моменты.
Speaker A
Вот. И с разпросами, скорее всего, придётся перезаписать и что-то добавить. Вот. А так вообще, ну, на старте там бэклок у нас разрастался и где-то до 100 задач.
Speaker A
Лёнь, задашь вопросы какие-нибудь по опыту? Всё проговорил, наверное. Хотел бы, знаешь что, услышать? Вот ты сейчас откуда получаешь задачи и как с ними работаешь? Какие у тебя артефакты получаются по итогу?
Speaker A
Угу. Ну, получается, могу получить задачу мм если это техдолг, то по сути как источником задачи Тимлит выступает для меня. Вот.
Speaker A
Если это, ну, бизнесовое, это ПИО, но как я вот уже озвучивал Анастасии, ПИОМ может поместить задачу бэклок, но как только я у него начну уточнять, он может меня напрямую к заказчику направить. И тут можно сказать, что как бы источником всё равно будет для меня
Speaker A
вот в моменте являться заказчик. По артефактам, если в начале говорить, то это были и какие-то просто записи, какие-то моменты уточнений у тех, кто будет пользоваться функционалом напрямую. То есть банально там записывал блокнот, дальше это в более-менее приличную форму записывал в confфлюнс,
Speaker A
то есть в прямом смысле текстом, чтобы были какие-то, а, так скажем, источники, откуда вообще что всё родилось. вот видеть. А, естественно, в более унифицированном формате это usерстари юзкейсы в начале были. Вот это формирование нефункциональных требований чаще всего, честно скажу. То есть я там
Speaker A
накидывал что-то, потом уже э согласовывал с разработчиками, чтобы понимать, что сам не ошибусь, что в рамках нашей инфраструктуры, планируемой ещё на тот момент, это будет как бы, ну, релевантно. Вот функциональные требования, также ограничения какие-то в начале особенно фиксировали. Сейчас больше всего, если
Speaker A
говорить из артефактов, да, это присутствует описание IP запросов и диаграммы, когда, ну, то есть это описание сущностей в БДшке, там ердиаграмма присутствует, карта с данными и так далее. Если нужно, по каждому шаблону как бы могу конкретно предсказать, что там есть, что вносим.
Speaker A
Угу. Ну, наверное, интересно было узнать, что именно с точки зрения описания IP, описание баз данных, да, входит в документ, как составляешь бизнес-требования, да, то есть тоже какому-то.
Speaker A
Угу. Ну, давайте тогда с описания базы данных, да? То есть изначально, ну, такой самый в голове то, что возникло пример. А на этапе, получается, первого описания там что было. М ну вот эта система бронирования помещений. Вот есть карточка помещений. То есть изначально я
Speaker A
просто для себя, ну, заказчикам поговорил, понял, какие примерно какая информация в его понимании должна храниться о помещении. То есть я выдел для себя сущность, условно помещение, и туда все атрибуты вписал. Дальше я смотрел условно, если у, ну, есть ли
Speaker A
какая-то, так скажем, даже, ну, можно назвать это денормализацию уже ещё на этапе, как бы просто, почему говорю, можно назвать, ещё же не существует база данных, да, это там относительно прототип черновик. Вот я смотрел, что есть очень много данных, которые он
Speaker A
хочет, чтобы были в карточке, а данных о здании, в котором расположено помещение. То есть я выделял уже в отдельную сущность здания, ну, и там рисовал связи в надиаграмме. Всё это в DFU, если что по инструменту. Вот. Э, то есть таким
Speaker A
образом у меня появлялась эдиаграмма, допустим, дальше я составлял таблицу, ну, как mapл данные, то есть каждый атрибут прописывал, ну, его название, естественно, тип данных, какие есть ограничения и в целом всё. Да, если говорить про то, как вот выглядит шаблон по бдшке, ну, по
Speaker A
какой-либо того. А сами ДДL для создания таблицы ты не писал? М, DDL нет, не писал.
Speaker A
О'кей. Вот. А ну если ещё тут, конечно, получается всё равно по касательно как-то задеваем по SQL запросам, да? Это у меня был опыт, например, написания на второй работе, в частности, чтобы увидеть ээ данные, которые, точнее, даже так вот спроектировали, например,
Speaker A
сущность какую-то, всё в базу данных это добавили. Дальше я хочу просто с помощью запроса ну удостовериться самостоятельно, точно ли эти данные приходят, даже если это на ещё протстади, то есть это, ну, данные похожи на настоящие, чтобы увидеть, нормально ли
Speaker A
они вообще выглядят. Вот. То есть это какие-то селекты, это простые джойны каких-то прям был был опыт, так скажем, просмотр просто разбора портянок каких-то, да, это тоже на втором месте работа. Кто ещё до меня там запросы писал? Ну это именно
Speaker A
просмотр на готовых как бы таких огромных запросов не писал. Дальше получается порест. Вы ещё спрашивали по рестзапросу у меня, ну, получается сама ручка, её версионность, также тело запроса, да? То есть возьмём это постзапрос там на создание карточки. А
Speaker A
что в Jсоне присутствует, какой тип данных? а-э, что логика самого запроса получается, что мы, э, ну, вот мы отправили это тело, что мы получим, какие коды ответа могут быть и если мы, например, на это тоже какое-то тело получаем, что в этом ответе будет также
Speaker A
таблица, а, с описанием вот э получается этого тела, там же всё описано тоже как название, параметра, типа данных и так далее. Потом не для каждого запроса, то есть у нас не было это прям не введено как обязательный формат, но я старался
Speaker A
это всё же прописывать. А это sequнс диаграмма вот в plно скажу, там как бы, ну, то есть я сейчас там откроем в реалтайме, я там вспомню, напишу, но последнее время пристрастился немножко конечно с нейросеткой это делать. Ну вот тут как
Speaker A
бы честно скажу, а, ну то есть неросятка там скелет накидала, а я что-то доправляю, до делаю прямо. Я чувствую, как это ускоряет, кладом пользуюсь. М.
Speaker A
Угу. Ну он он план, да, получается, м по sequнс диаграмме, имеется в виду. Да.
Speaker A
Да. Угу. По plant. А-а, дальше что ещё у нас? Ну, по запросу, кстати, вроде, да, всё описал по разпросу.
Speaker A
А по бизнес-требования вы имеете в виду? Ну, то есть там, в частности, какая-то именно бизнес-спецификация, то есть там, ну, как usеer story охранялась или case.
Speaker A
Ну да, да, да. То, то есть вот тебе пришла задача, да, там проанализировать там такой-то функционал, да, то есть у тебя какая-то документация, да, переличная в любом случае должна быть члениние бизнеса. А что, для чего, как, почему? Вот хотелось понимать, как оно
Speaker A
выглядело. Угу. Ну вот, как я уже говорил, если брать совсем, да, от начала я мог прям изначально в confluлюнс вставить прямо текст того, что я перезаписал блокнот.
Speaker A
То есть вот прямо как сыро это выглядело. Ну это не в формате там диалог, да, Василий сказал, а я ответил, а в формате, что вот заказчик видит это так-то, так-то хочет то-то, то-то. А ещё, кстати, про, если говорить про то,
Speaker A
что с заказчиком там вот на текущем проекте накидывали, это в Бальзамике мог опять же в реалтайме накидать какую-нибудь, ну, примерный прототип, что он хочет. Он, кстати, на предыдущем месяце работы был дизайнер. С ним было, ну, не скажу, что глубокая
Speaker A
работа, но было взаимодействие, потому что на текущем месте работы у нас дизайнера в команде нет. Вот, э, есть только дизайнер на стороне Райфы, которые смотрят уже практически, как сказать, остаётся в UI интерфейс очень похожий на тот же, что я отрисовал
Speaker A
в бальзамике, потому что тут никаких придирок, как внутренней системы, там по, а, красоте нету. Вот тут главное, чтобы, ну, их дизайнер в целом согласовал и ээ у нас фронт понимал, что происходит при нажатии на ту или иную кнопку.
Speaker A
Вот. То есть это UIформы, э, с описанием опять же. То есть если это, например, возьмём там реестр помещений, да, ээ, там в этом фильтрация есть в этом реестре, то есть я описывал каждую кнопку, какой запрос, э, ну, получается,
Speaker A
по нажатию этой кнопки происходит. То есть это тоже всё в confluенс приложен макет, а, ну, прототип получается из бальзамика и подробное описание этого макета.
Speaker A
Вот. Ну, это если про визуалку взять. Дальше получается, если вернёмся немножко назад, вот я переписал то, что мне рассказал заказчик. А я это оформил в какие-то usерстари, то есть вот понятно, там по по ролям там есть менеджер есть
Speaker A
в получается как повышенный доступ, как мы назвали эту роль, как владелец, кто хочет отчётность качнуть сразу. А у бухгалтера также должен быть доступ. И, э-э, ещё, ну, по сути, всё только, ну, ещё дополнительную роль прописывали. Она как тестовая была, но, короче, её
Speaker A
впоследствии убрали. А, получается, вот от этих ролей танцевал, как юзер старая выглядит, какие критерии, приёмки у неё будут. А опять же созванивали заказчикам, уточняли вот, ну, так ли? Ну вот я ему озвучивал в стандартном шаблоне, то есть юзер старает роль,
Speaker A
что ты делаешь и какая ценность. Ну, то есть по базовому шаблону описывал, если в целом он, ну, старался донести суть, а в целом его устраивал, всё фиксировали.
Speaker A
Дальше юзер старю бил на юзкейсы, то есть подробное описание. Ну вот, кстати, да, про описание, если говорить, [вздыхает][тяжело вздыхает] а в confluence старя по сути так и прописывалось. То есть роль отп критерия и критерии и всё по ужекейсам
Speaker A
поподробней. То есть я добавил таблицу, в которой есть, ну, это тоже как бы не какая-то там я добавил, как бы говорю громко, наверное, звучит. Опять же то, что я уже где-то насмотренность получил, видел, я как бы сочинил такую же новую
Speaker A
ээ такой же шаблон, короче, для описания. Там присутствует номер, получается, юзкейса, акторы, э кто завязан в этом юзкейсе. Получается основной сценарий, альтернативные исключение, вот и привязка нефункциональных требований шла тоже кюзкейсу. То есть, ну, как US подробно алгоритм действий предоставлял. Всё это
Speaker A
тоже в confluence фиксируется. Вот. А в целом плюс-минус. Так, если ещё доппросы какие-то есть, как бы что-то я в моменте Давайте уже, наверное, перейдём к задачке.
Speaker A
Лёнь, ты не против? Да, давай там я только где-нибудь вас буду останавливать и буду вопросики задавать.
Speaker A
Да, хорошо. Так, Артур, а у нас задачка м большая, ну, как бы которая по которой сразу посмотрим несколько твои файл. Меня или нет?
Speaker A
[смех] Может быть, да. Да. Ну, не, значит, Угу. Начнём. Начнём с того, что, э, представим, что я заказчик. Ты аналитика от команды разработки. Вот. И я как заказчик, э, очень хочу, чтобы мне команда разработки, соответственно, разработала интернетмагазин.
Speaker A
Вот. Очень хочу продавать э на сайте свои товары, получить за это деньги. Вот. Угу.
Speaker A
Зарабатывать даже. Вот. И, э- на первом этапе хотелось бы понять, вот как будет выглядеть наш сайт. И хотелось бы к этому прийти через описание юзкейса, э, юзкейса, заказы товара на сайте.
Speaker A
Угу. Ну, подробный, детальный, пошаговый ээзкейс там или как можно сказать, бизнес-процесс. Угу. Заказа товара на сайте. Вот хорошо было бы это всё визуализировать. То есть можно открыть какой-нибудь там draw io или если мы хотим, допустим, этот ззкейс быстренько пошагово описать текстом, то
Speaker A
можно просто в текстовом варианте. Мёте в виду как, а как CASE диаграмму как бы описать? Ну то есть у нас есть акция, ну я думаю, что на данном этапе я бы хотела, чтобы мы просто сейчас описали детальный пошаговый процесс заказа
Speaker A
товара на сайте. Вот. Так как я заказчик и хочу, как обычно, непонятно что, можно у меня ещё по ходу дела или там перед этим аэ для описания этого юзкейса, да, то есть сразу скажу, в рамках этого именно этого
Speaker A
процесса собрать у меня какие-то бизнес-требования функциональные требования, задать мне вопросы, вот, и, соответственно, потом а его описать.
Speaker A
Вот. Ну да, я как бы без вопросов и не хотел приступать, получается. В основном, как бы, я вот услышал от вас как от заказчика главную вашу, ну, не то что даже боль, да, понятно, все хотят. Это вы хотите продавать свои, вы, кстати,
Speaker A
сказали свои товары. Имеется в виду это какая-то, ну, своя система производства или это просто как бы выражение, там можно перекупать, всё, что хотите, будете продавать. Правильно понял?
Speaker A
Ну нет, это будет ээ да, просто работа с поставщиками. То есть я хочу продавать, ээ, что я хочу продавать? Я хочу продавать мебель.
Speaker A
Угу. Кухонную мебель. Вот так вот. Угу. Именно акцент, да, прямо на Ну, то есть это практически одна категория товара.
Speaker A
Ну, относительно, то есть, да, да, дада. Кухонная мебель. То есть это у вас будет сайт кухонной мебели.
Speaker A
А, ну это такой базовый для меня вопрос, да. как вы сейчас видите вот свой сайт, да?
Speaker A
В целом, что вы на никак не вижу, но просто вижу, что вот просто хочу, чтобы на него заходил клиент мой и выбирал товары, покупал.
Speaker A
Вот всё, что я вижу. У. Угу. Ну, то есть чтобы чтобы было по красоте, так скажем, и чтобы по красоте, конечно, клиент не смог мимо пройти.
Speaker A
Понял, конечно, конечно. [фыркает] Тогда давайте сначала определим с функционалом да этого интернет-магазина. Вот я услышал, чтобы клиент заходил и покупал товар.
Speaker A
Аа, ну, основная цель, то есть, мм, ну, сразу из этого, да, вытекает, э, сейчас пока, то есть, у него должны быть, ладно, такой уточняющий вопрос. Он должен, у него должна быть возможность купить товар, например, в рассрочку, э, либо же
Speaker A
оформить, может быть, постоплату. Вот ещё, кстати, как у него будет организовано м ну вот он покупает какую-то мебель для кухни, у него там процесс доставки, вот самовывоз, это то есть какие услуги вы ещё предлагаете, кроме того, что вот он
Speaker A
может купить ну вот товар, то есть есть какие-то сопутствующие услуги, которые также через сайт будут транслироваться клиенту?
Speaker A
Вот. Ну, в целом, если мы хотим это оговорить, то, ну, оплата давайте, пусть будет у нас на сайте просто по карте.
Speaker A
Угу. Вот. В рассрочку. Ну да, сейчас есть прекрасные сервисы по рассрочке. Можем это тоже добавить.
Speaker A
По сопутствующим услугам у нас, ну, пусть будет вызов мастера, замерщика и установщика, скажем так.
Speaker A
монтажник. Угу. Ну, получается, это в целом самовывоз будет, да? То есть доставка это кухни клиенту не будет.
Speaker A
[откашливается] А, ну доставка почему вылет? Угу. Доставка тоже есть. То есть у нас такой, ну, всё равно получается очень хороший вариант под ключ. Клиент зашёл на этот сайт, он выбрал кухню, он оплатил либо сразу, либо в рассрочку.
Speaker A
После этого ему также предлагается услуга а-а доставки дополнительной либо самовывоза. Вот. Ну, точнее, неправильно я озвучил, не оплатил, а, то есть на этапе формирования заказа ему предлагаются дополнительные услуги, доставка, замерщик и установщик. Вот всё это он может как
Speaker A
бы включить в заказ. А у нас, я извиняюсь, немножко ушёл от изначально вопрос, у нас задача получается понять как важно, как выглядит вообще сайт или это второстепенно, неважно. Вот в первую очередь я хочу, чтобы, да, просто мне писал вот caseй
Speaker A
детальный пошаговый бизнес-процесс. Всё пользователя на сайте. Хорошо, тогда, ну, возьмём там US CASE 1, например, аэ, USCAS 1 это будет, мм, ну, возьмём сначала просмотр. Просмотр, аэ товаров.
Speaker A
Просмотр, да, товаров, потому что у нас в любом случае, ну, сейчас мало кто сразу покупает, да, это и нормально. То есть ему нужно будет посмотреть сначала, выбрать из чего-то, да, каталог этих, э, товаров увидеть. А, ну я на всякий как
Speaker A
бы всё равно заказчика уточняю, как бы вы не против, что это будет как бы, ну, вот страница, да, с каталогом товаров и какими-то фильтрами? Вот, может быть, у вас уже идея есть, так как вы как бы в этой сфере, ну, если я так подразумеваю,
Speaker A
если вы решили продавать кухонную мебель, вы, наверное, в этой сфере разбираетесь, и вы подскажете, возможно, да, даже как бы, ну, отвечая на вопрос: "А по каким фильтрам, возможно, покупатель чаще всего ищет?" И вот, исходя из этого, мы можем какие-то вот
Speaker A
фильтры в каталоге сразу внедрить. М, не знаю. А что бы вот вы предложили? Ну, это точно цена, то есть самое актуальное.
Speaker A
Вот это, я думаю, мм, обязательно дизайн, то есть, э, ну, там разные стили есть, честно там не разбираюсь, но какие, например, а, ну, наверное, есть как какой-нибудь, как я могу параллельно как бы зайти посмотреть, какие вообще дизайны.
Speaker A
Не надо, не надо. У нас просто очень мало времени. Я хотела бы, чтобы мы уже на самом деле перешли к описанию на самом деле бизнес-процесса. Можно не конкретного куска, а вот хорошо поня бизнес-процесс всего.
Speaker A
Вот от начала и до покупки товара. Ладно, хорошо. Тогда ээ пользователь заходит на сайт. пользователь, э, ну, вот первое, пользователь зашёл на сайт, а второе пользователь а-а м пере мх пользователь выбирает по фильтрам м категорию това. Я хотела бы, чтобы мы
Speaker A
это всё записали, потому что от этого пойдёт у нас второе задание. А, всё ладно. То есть я в чат это проще писать.
Speaker A
Нет, можно пошарить экраны и, например, поставить какой-нибудь редактор любой текстовый или что угодно. Можно другоё, чтобы всё было там.
Speaker A
А, хорошо, без проблем, потому что потом мы порисуем. Я понял. Так, так, видно ли?
Speaker A
Да, всё видно. Сейчас там условно это старые записи. [тяжело вздыхает] Так. [вздыхает] Так. Ну, возьмём пока будем просто как заметку использовать. Это то есть первое так.
Speaker A
Зашёл на страницу каталога товаров. Так вот сделал второе. Аа пользователь применил мм нужные ему фильтры. Ну, я немножко упрощённо пишу, чтобы как бы по времени, [вздыхает] а особо не этот не расширяться. Система, ну, сайт, ладно, сайт напишем. Сайт аэ отобразил
Speaker A
отобразил, э, товары в соответствии с выбранной фильтрацией. фильтрации. А пользователь нажал на аа на интересующсующую карточку товара.
Speaker A
А дальше а сайт сайт отобразил мм карточку товара. Пользователь нажал а добавить в корзину в корзину и пере и перейти в корзину.
Speaker A
А сайт м отобразил. Так, аа опять же для скорости м уточняю, нужно ли, ну, как бы нормально будет, если я ещё также добавлю, что пользователь вначале должен авторизоваться. Вот мы можем, ну, как бы нужно прописать или будем думать, что
Speaker A
пользователь уже заранее зарегистрировался? Ну, хорошо, что мы этот вопрос подняли. Я думаю, что на лучше, чтобы пользователь уже, наверное, в процессе оформления всё-таки мы его заставляли бы авторизовываться или регистрироваться.
Speaker A
Вот. Понял. Хорошо. Мм, пользователь отобразил страницу авторизации на этом этапе. А м пользователь ввёл, а авторизации по а номеру, нет, страницу авторизации или регистрации. Страницу авторизации и м ну вот так. Регистрация по номеру телефона.
Speaker A
А так сейчас нет. Так пользователь ввёл мм номер телефона и нажал, а зарегистрироваться. Возможно, он просто он, возможно, у нас просто первый раз зашёл к нам на сайт.
Speaker A
Аа система м отправила система Да, система отправила код подтверждениядения для регистрации и отобразила, а мм и отобразила окно ввода.
Speaker A
А ввод кода пользователь ввёл код и нажал подтвер подтвердить. А дальше м система э проверила авторизацию.
Speaker A
и отобразила страницу страницу корзины с ранее выбранным товаром. Так дальше. А товаром и допуслуги.
Speaker A
услуги. Получается, доставка сборка замер. Доставка, сборка, замер. Аа, да, получается, так как у нас есть как бы в любом случае замер ещё кухне, да, у нас э мы должны это предусмотреть, то есть мы должны какие-то поля ему выделить, в
Speaker A
которые он будет вводить размеры кухни, которая ему нужна. Угуз. Давай не будем это писать. Я услышала кайф, да, что всё это всё поняли. Угу.
Speaker A
Угу. М. Ну ладно, хорошо. Значит, это, допустим, есть аа ну можем, то есть сократить пользователь, а выбирает выбирает допуслуги, да, и опять же для сокращения. Тут можно немножко пофантазировать, но просто аа и нажимает добавить опять же. То есть
Speaker A
подтверждение какое-то от юзера должно быть, а система аа формирует даже я бы, знаете, я аэ сайт на систему перевёл. У меня так привычно. Не знаю, почему я вначале начал сайт. А система формирует окончательную стоимость и отображает, а кнопку оплатить.
Speaker A
А оплатить или мм ну или взять в рассрочку. А так пользователь пользователь, а нажимает оплатить.
Speaker A
Система получается у нас не внешний какой, ну, то есть платёжный шлюз у нас интегрированный. Понятно. Но я так услышал, он без перехода на какую-то внешнюю страницу, как это часто бывает, он, то есть, прямо в форме самого сайта будет отображаться.
Speaker A
Угу. Угу. Система отображает окно оплаты, а точнее окно мм Так, сейчас тут варианты оплаты. Ну, по сути, у нас из ранее озвученных вами требований мы оплачиваем только а по карте.
Speaker A
Нажимает оплатить по карте. Система отображает окно ввода данных карты. Аа, получается э ну, давай напишем уже просто, что пользует или оплачивает, и надо чуть-чуть заканчивать. Угу. То есть там бы ещё точная система внешним шлюзом воспользовалась для проверки, да,
Speaker A
релевантности вообще введённых данных, точнее, не релевантности, а валидности. И подтверждение этого получила, только потом бы транзакцию совершила.
Speaker A
Хорошо, давай вот мы сейчас процесс весь поняли, отобразим, как у нас будет ээ а выглядеть архитектура всего вот этого нашего комплекса, скажем так, чтобы всё это работало. Ну, то есть, ну, давай нарисуем какую-нибудь типа диаграмму компонентов.
Speaker A
Угу. Диаграмму компонентов. Честно, ну, то есть какие, да, какие системы будут участвовать и какие сервисы на БКЕК будут. У нас будет микросервисная архитектура на БКЕК.
Speaker A
Угу. То есть, ээ, это мы сейчас не про Sequence диаграмму говорим, это просто свободный квадратиками, как бы квадратики.
Speaker A
кружочки, да, прямоугольники, что что угодно. Понял. Ну сейчас, мм, мы систему внутреннюю рисуем или вот, ну, полностью как взаимодействие происходит от уровня, когда полностью пользую, да? Угу.
Speaker A
То есть есть у нас, допустим, пользователь, да? А-а, вам видно, конечно. Да. Всё ладно.
Speaker A
Так. Аа пользователем взаимодействует аа. Ну, это у нас, а, фронт будет, то есть, а, мы, получается, я просто сразу на автомате начал начал, мм, мы же сейчас взаимодействие между сервисами, показываем, и я хочу как бы сразу показать, ну, с операции, например,
Speaker A
пользователь нажал А, ну у нас тут оплатить слишком будет быстро. Давай пока на более высоком уровне абстракции сделаем. То есть просто определим, какие у нас микросервисы есть, и общий принципы их взаимодействия. То есть там как UI будет с другими сервисами
Speaker A
взаимодействовать и будут ли там сервисы между собой как-то коммуницировать. Угу. Хорошо. Ну пока, да, просто раскидаю сервисы. То есть у нас точно Ну вот что сразу в голову мне пришло, пока не забыл. Сервис э оплаты будет точно.
Speaker A
оплаты. Аа также у нас будет сервис. Аа м ну это получается как Marреestр каталогом его не хочется называть. Что-то слишком продуктово будет для сервиса звучать. Сервис, э реестра м на автомате. Сервис реестра м ну товаров. Сервис реестр товаров.
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
Мм сейчас подумаю. Но в целом у нас сервис реестр товаров, да, он будет отвечать и за создание какого-то, ну, отображение там нового товара, полностью фильтрацию товаров. Сервис оплаты чисто за оплату отображений. Ну, UI тут просто крупно, так скажем. Это то, что то, с
Speaker A
чем будет взаимодействовать пользователь. Сервис корзины, в частности функционал перечислили. Авторизация сервис профиля клиента. Аа, ну, конечно, тут ещё есть такой функционал, да, как вот по тому, что будет доставка, сборка, замер. Вот. А давай её пропустим пока. Давай нарисуем
Speaker A
вот как сейчас у нас всё-таки будет взаимодействовать всё это между собой. Сейчас, Настя, извини, давай два вопроса прож.
Speaker A
У нас есть бизнес-функция по отправке уведомлений по SMS получения кода. Это у нас будет в сервисе авторизации или нужно в отдельный сервис вносить?
Speaker A
Мм, ну мы бы воспользовались каким-то готовым решением точно. Я имею в виду по вот решению инфраструктура. Это всё-таки отдельный сервис или?
Speaker A
Ну, это как отдельный будет именно вот отправка уведомления, да, это отдельный внешний сервис какой-то.
Speaker A
Ну пусть он тоже будет на схемке. Угу. И давай, наверное, вот с точки зрения взаимодействия мы опишем взаимодействие между фронтом и, ну, короче, авторизацию опишем с точки зрения взаимодействия сервисов.
Speaker A
Мм, авторизация с точки зрения взаимодействия сервисов. А, ну то есть пользователь в любом случае у нас нажимает на какой-то элемент, ну, не на какой-то, а, то есть, если исходить из сценария, который мы уже обговорили, пользователь там сначала добавил товары, потом нажал,
Speaker A
точнее, сначала выбрал товар, нажал добавить в корзину. На этом этапе мы предлагаем ему авторизацию.
Speaker A
Аа он нажимает там либо авторизоваться, либо зарегистрироваться. Он нажимает авторизоваться. Если, ну, более получается глубже идти на этом этапе, а, идёт запрос от фронта к сервису авторизации, как раз. То есть, ну, давай счёт пока покажем просто хочу пока некоторые моментики.
Speaker A
Ну, пользователя убери, он тут лишний. Ладно, мы мы здесь именно архитектурно указываем. Здесь акта нам не нужны.
Speaker A
То есть нажал, да, укажем паттерны взаимодействие. То есть это как что будет там XML будем отправлять Сапконверты, может быть, это JPшка будет.
Speaker A
Ну я, наверное, больше на свой опыт опираюсь, чем привычнее работать. То есть это может А, ну вот про Саапу упомянули, да? Я сразу, точнее, мы же на ты договорились.
Speaker A
Мм, я вспомнил, что у Сааппа все данные идут по зашифрованном в зашифрованном виде. Там, по-моему, мм, VS Security, по-моему, называется протокол. Точнее, не протокол, а этот А можете и протокол, по которому они шифруются уже внутри. Наверное, запрос, который связан, ну, точнее, не,
Speaker A
наверное, любой чувствительный запрос, он должен идти с учётом того, что данные должны быть зашифрованы. Вот в росте это тоже в целом а можно сделать, но я сейчас честно не скажу, как м то есть это, ну, ну у нас вот здесь вот UI сервис
Speaker A
авторизация всё-таки по какому принципу будет взаимодействовать с протокол? Имеете в виду? Ну, получается, что какой какого типа запрос отправляется, когда пользователь нажимает кнопку авторизоваться?
Speaker A
Да. Дадада. Аа, ну, допустим, если даже это не авторизоваться, а зарегистрироваться, он вёл данные. Ну, например, это постзапрос передачи и тело запроса.
Speaker A
Угу. О'кей. Ну, давай отобразим как раз с точки зрения взаимодействия. Угу. Пост запрос. М.
Speaker A
Ну, просто так прописать или что-то нужно? Да, достаточно. Только здесь у меня сразу вопрос. У нас HTTP будет или HTTPS?
Speaker A
HTPS, конечно же. Ну, то есть secкюрити, потому что в зашифрованном виде будут передаваться данные.
Speaker A
Угу. О'кей. А дальше у нас от сервиса авторизации идёт, точнее, ну, тут постзапрос ушёл на сервис авторизации а он, получается, в постзапросе, понятно, отправил в том числе телефон, на который уже Так, у нас сервис отправки кодов подтверждение. Мм, сервис авторизации
Speaker A
идёт, а-э, отправляет запрос, в свою очередь, а, в сервис отправки кодов подтверждений. А тут получается, ну, тут в зависимости, конечно, как этот внешний шлюз, ну, как с ним вообще организовано взаимодействие. Может быть, он предусматривает только работу по SAUP,
Speaker A
но, допустим, у нас тут тоже постзапрос уходит с данными. Хм, получается аэ ну, давай ведём небольшое ограничение, что этот сервис может давать ответ там до 5 минут.
Speaker A
Угу. Аа, ну тогда, то есть, то, то есть мы можем инициировать запрос, да, но когда он вернёт его, мы не знаем.
Speaker A
Ответ. Понял. Ну тогда, естественно, тут мы говорим про асинхронное взаимодействие, да? Ээ, чтобы у нас пользователь, ну, система вообще сама не зависла на момент ожидания этого кода подтверждения. То есть вы хотите, чтобы я как-то отобразил это или Ну, смотри, да, то есть здесь идея то,
Speaker A
что я хочу понять, как мы на фронт вернём пользователю этот код. Угу, я понял.
Speaker A
То есть даже даже по даже по-другому, да? То есть понятно, код он пойдёт в эсэмэске, да, и он должен его ввести. То есть мы должны получить валидный код у себя в базе где-то, да, и фронту сказать, что вот этот код
Speaker A
будет валидным. Угу. Вот эти вот бесшовные, да, которые переход знаешь наверное да? А у себя в базе вы говорите: "А мы же вроде бы, ну, насколько я знаю, вот устройство при передаче там каких-то секретных кодов там не предусматривает
Speaker A
сохранение на, ну, в каких-то своих базах". То есть там по зашифрованному, извиняюсь за звонок, на на по зашифрованному каналу назад он клиенту передаётся. То есть сам сервис он А нет, нет, нет, это я неправильно говорю. Немножко с другим спутал.
Speaker A
Угу. Аа, ну, то есть вы хотите, чтобы я отобразил условно БДку, в которую мы сохраняем этот, э, м, код, да, чтобы потом сравнить с тем, м, что ведёт пользователь. Ему же на номер телефона вот этот внешний сервис как раз
Speaker A
должен прислать этот код. Да, да, да, всё. Так, аа и у вас как бы вопрос, как мы это как бы, ну, визуально клиент же может уйти, условно с этой страницы авторизации раз до 5 минут, да? То есть мы ему, понятно,
Speaker A
визуально отобразим, что, ээ, м, ожидайте кода, там код может прийти в течение 5 минут, чтобы клиент понимал, как бы, что возможно там и минуты, и две придётся подождать. Тут, конечно, если он закроет страницу, а, честно, не продумывал я, как. Я
Speaker A
просто видел уже из наглядности в реальных кейсах. Бывает так, что это редкий случай, когда можно вернуться на страницу, да, там авторизация перезагрузить и ввести ранее отправленный код. Но чаще всего происходит так, что просто заново приходится запрашивать код.
Speaker A
Поэтому, ну, тут в рамках проектировано, чтобы не не подзакопаться, я бы просто тогда сказал, что клиенту мы отобразим информацию о том, что код запрошен, ожидайте доставка в течение 5 минут, ну, условно.
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
Угу. Ну, может тогда вы ты что-то про более простое имел в виду, там webхуook, например?
Speaker A
Как это для сервисов, для взаимодействия беговских сервисов применимо? А, ну мы, получается, ему же, получается, при запросе отдадим.
Speaker A
А, а, ну нет, нет, это, да, это не сюда, не в эту кассу. А, ну смотри, давай подскажу. Вот ты отправил постзапрос.
Speaker A
Так. То есть, по сути, сказал сервис отправь кодов: "Создай мне новый код". Угу. Да. Пока он там не прошлстит, пока он там не дёрнет какие-нибудь там мобильные сервисы, там оператора не дёрнет там, пока он там трелька у него непонятная
Speaker A
какая, да, он шрудит. Кто тебе мешает отправить ответ 200? Ну, типа я принял в обработку запрос, да, и дальшерудить. Ну как сообщить сервис авторизации о том, что я закончил всё это делать?
Speaker A
Как сообщить э фронту? Имеешь в виду о том что пока пока сервису авторизации для фронта нам ещё вплыть доплыть.
Speaker A
Как сервису отправки кодов сообщить сервису авторизации о том, что ну код прислать ему назад в этом вопросе?
Speaker A
Да. А ты, получается, когда про синхронно, как и синхронное, асинхронное взаимодействие выставить, а вот выстроить, точнее, а сейчас сказал, что код назад на отправить. Это ты просинхронное взаимодействие имел в виду?
Speaker A
Почему это асинхронно? А я думал, имеешь в виду то, что когда мы от фронта направили постзапрос, ну, если постзапрост ушёл дальше, мы сразу же 200 присылаем о том, что условно запрос обработан, всё о'кей.
Speaker A
Не, подожди, сейчас я рассматриваю только игру прокейс, где мы взаимодействие двух бековских сервисов, да, обсуждаем. То есть мы пока front не трогаем. Фронт отправил свой постзапрос, да, как-то сказал на сервис авторизации.
Speaker A
Всё. То есть там он не, ну, может получить 200, может не получить 200. Здесь как, как скажешь. Дальше серс авторизации отправляет пост запрос или там, ну, пост, да, получается сер отправки коров подтверждения, да, понятно. Сервис ковжей может очень долго
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
То есть, как как мы свяжем запрос и ответ, если они по времени разделены? Да. То есть нам нужно какой-то, ну, идентификатор, то есть нам нужно дополнительно хранить где-то идентификаторы запроса и потом сопоставлять их. И что? Так, ну S ID.
Speaker A
Ну да, О'кей. Давай тогда ещё вопросики чуть-чуть по базам. Вот смотри, у нас сейчас много сервисов, да? Какие базы мы под них выберем?
Speaker A
Так аамеешь в виду вот, например, да, у нас есть сервис реестр товаров. И какой именно вот прямо, ну, название базы ты имеешь в виду? Например, есть реляционка там пазгря, есть нереляционные, которые там для объектных всяких подходят. Вот, честно скажу, с реляционными у меня
Speaker A
опыта прямо вот руками нет. А я знаю из опыта, например, есть S3, в которой объекты могут храниться.
Speaker A
Вот у Ну да, вот конкретно вот у нас есть скопсервисов, да, и под них просто базейки см прям голосом, можно сказать, какие, да, вот под Ну у фронта будет баз, а, ну, на фронте мы кэшировать что-то должны. точнее, ну нет, не на самом
Speaker A
фронте. [откашливается] М, ну у фронта я не вижу необходимости в базе данных здесь, поскольку он всё равно будет всегда на БК ходить, только если мы что-то хотим кэшировать на клиенте. И, но я тоже под это как бы не
Speaker A
не скажу, что шарю, какую базу данных под это подбирать. Ну, на нти нет баз данных. Сейчас бековские ходят. Давай дальше. О'кей.
Speaker A
Серс авторизации. Мы что выберем? Так ну подхонение мм, как бы стандартных каких данных, да, там условно номер телефона. И мы не обговаривали, есть ли там пароли, вообще вся эта штука, но, допустим, что есть, да, последствии можно там в кабинете
Speaker A
придумать. Аа, ну я бы, ну, ту же пасгрю выбрал, потому что у нас они, в принципе-то, да, наунифицированные будут, но мы это как-то должны шифровать, понятное дело.
Speaker A
Ну, у нас же есть отдельный сервис этих самих клиентов. Профиль, вот сервис профиля клиента, да.
Speaker A
А, ну информация авторизации. Ну да, да. Тогда в сервис авторизации, ну, у нас он только будет связан в моменте, когда ему нужно хранить для сравнения код, а, SMS-код.
Speaker A
И под это Угу. А, а только ли для этого он нужен будет? Мм, хранить ещё текущее состояние. а-а, как бы вот так, ну, пользователь начал там сессию авторизации вот хранить об этом информацию ещё по сути.
Speaker A
А-а для этого, что нам лучше использовать? Ну это ну, мне кажется, это точно не реляционка тогда. Ну, то есть не позгря не подойдёт. Но какую, э, мне, к сожалению, сложно м сказать.
Speaker A
То есть пальцем небо буду тыкать, если там называть какую-нибудь документированную. Ну, ну нет, это точно не про это. То есть база данных нужна не только для, ну, самое известное решение для сервисов авторизации и придуманное, собственно, под них.
Speaker A
Давай минутку на подумать. М. Нет, на самом деле, у меня так как я не знаю, мне прямо сложно это думать не думать. И у меня там единственное, что всплыл в голове, там как Firebase, но это вообще, по-моему, сервис просто от Гугла. Он никак не
Speaker A
связан с хранением там паролей. Ну, честно не не не знаю, что что за штука, поэтому ничего не скажу.
Speaker A
Ну, значит, точно не оно. А, а так дис то любай. А, а я я извиняюсь хотел, я думал дис он для кэширования же чаще всего применяется.
Speaker A
Это это KДB база, то есть которая по идентификатору позволяет вытягивать определённую информацию. Вот. То есть они как раз для авторизации это 70, ну, 97% они входят ко для авто, потому что они быстро получают данные, быстро и недолго их хранят.
Speaker A
Про скорость, да, знаю, но в любом случае я бы на на абум сказал, поэтому тут я хотя бы честный остался.
Speaker A
А давай ещё по Давай базейку для сервиса реестра товаров выбери. Аа я сначала, конечно, сказал про объектные, но но как объектные, нам же нужно хранить по мм товарам также изображения различные этих товаров. Мы можем, конечно, в реляционной там в пасгре хранить все
Speaker A
атрибуты карточки товара, да, и хранить какой-нибудь, не знаю, айдишники или, ну, айдишники там изображений, которые уже будут храниться в отдельной какой-то БДшке. Но лучше, я думаю, всё же всё делать, э, ну, в одной БД по карточке товара. То есть мы можем, да, в пагре
Speaker A
хранить через JON и файлы изображений, но не принято так. И в целом, ну, зачем, типа, когда есть как бы, ну, другие решения для хранения объектов. S3 опять же, вот говорю мне, мм, ну-ка давай вот давай просто как будет
Speaker A
выглядеть базейка для там одного товара. Мм, сущность имеешь в виду? Да, да, да, да. Ну ты говоришь, что у тебя есть фотография, да, есть там какой-то атрибуты, которые описывают этот товар, да?
Speaker A
Да. Ну он он у нас по сути, да, не просто ведь ну нет, если это как цельный товар, то есть у нас есть эйдишник, у нас есть наименование этого товара, у нас есть характеристики количественные какие-то, то есть это размеры, да, там это же
Speaker A
целая кухня, то есть шкафчики, всё это, вот вся эта информация. У. Ну это по сути вот сейчас я размышляю, я понимаю, что данные очень могут отличаться у какой-то там кухни, например, полей, может, ну не полей, а шкафчиков может быть там 10, у другой
Speaker A
два. Вот такие, то есть непостоянные данные тогда, ну и плюс фотография, тогда хочется какую-то, короче, бдшку объектную затащить.
Speaker A
Вот. Но, как я уже говорю, у меня вот ограничено объектная. Это вот Oracle, я знаю, тоже объектная есть S3 есть объектная.
Speaker A
S3 - это не БДшка. ST - это объектное хранилище, не база данных чуть-чуть. Это как если бы мы мм вот как раз для фотографий и для файлов.
Speaker A
Отлично. А если мы хотим хранить документы, объекты, это другие базы, типа ранга, монго, ну либо погрес, да, с Jonби.
Speaker A
Угу. А так в целом, ну, фотографии, да? То есть ты можешь в базе хранить ссылку на стре, например. [откашливается] Угу.
Speaker A
То же самое погре, то есть у тебя будет просто колонка, где ссылка на треть.
Speaker A
Это нормальный кейс или так? Ну тогда я бы так сделал. Мне в целом это представляется. Ну то есть можно с ссылку хранить прямо в базе, можно этот, как его зовут?
Speaker A
Можно даже бинарник там хранить. Угу. То мне там на прошлой работе мы там тоже хранили бинарниками. Вполне нормально.
Speaker A
Через Jon B получается. Нене там есть этот тип данных байт Ай, по-моему. А и вот мы там фотографии хранили прямо в такому в таком виде.
Speaker A
Угу. Ладно, наверное, надо закругляться, пото что просто следующая встреча уже. Угу. Если есть вопросики, давай задавай, готов ответить. Если нет, но появятся, можно будет задать через чаров. Мы, в принципе, вернёмся с ответами по возможности по обратной связи на от нас. Она уйдёт в течение
Speaker A
дня. Вот когда HR её передадут, не знаю. Угу. Понял. Ну да, у меня вопросы есть по проекту общие, как бы. Ну сам остановишь, когда уже всё в притык будет. А задавай.
Speaker A
Да, вот ещё в описании я видел, что есть SAUP и XSD, да. И вот виноват, если прослушал, получается, в том числе новые контракты на сабпротоколе проектируются или же это вот какие-то legси.
Speaker A
В основном Leg, то есть новая. Вот за последнее время я не помню, что появлялись новые насапи.
Speaker A
То есть сейчас основной подход - это Угу. Пи и ацинхронная кавка. Угу. Ну, у вас всёф, да? То есть вы прямо по росту стараетесь идти. Понял.
Speaker A
Аа вот по проектированию моделей, да, и также упомянуто в описании базовое владение SQL. А базовая что включает?
Speaker A
По базам данных опять же у нас аналитики достаточно редко этим пользуются. То есть там какой-нибудь простой селектик из какой-нибудь таблички из какой-нибудь базы. То есть у нас большинство данных хранится как объекты.
Speaker A
Угу. Но в просгресе. Вот поэтому какой-нибудь селект там по такому-то идентификатору вытащить что-то. То есть у нас там прямо каких-то сложных скот запросов, да, их и не будет.
Speaker A
Ну и каких-то запросов на создание обновления данных тоже. То есть это в основном выборки.
Speaker A
Угу. Угу. Понял. Э-э, ну, у меня ещё был вопрос про жизненный цикл, как бы владения требованием, но я услышал, вот ты в самом начале как раз озвучил, что там прямо от этапа выяснения бизнес-боли до этапа доведения и фиксирования вообще
Speaker A
системных спецификаций. Аа, понял. Так, а тако такие более базовые тогда ещё вопросики получается. Вот у вас подуси под усиление, э, ну, условно, вакансия открылась под усиление команды.
Speaker A
Да, да, да. То есть мы расширяем сейчас состав. Сколько клеток открыто, не знаю, но знаю, что больше одной.
Speaker A
Угу. Угу. Хорошо. Аа, ну так тогда условно, ну, допустим, я хорошо про, ну, то есть я прошёл собеседование, вы вы, ну, я вам понравился, условно, вы взяли меня на работу, а-а, я вышел первый день, и вот какие задачи я
Speaker A
получу, если не касаемо, да, там, ну, стандартно каких-то моментов анбординга, какие-то там опросы заполнить, доки ещё дополнительно, вот доступы я получил, то есть я всё вот боевая единица. Первую задачу, которую мне дадут, в рамках приоритетов, с, скажем так. То
Speaker A
есть у нас сейчас достаточно много разных задач. Вот. И какие будут в момент выхода, я просто даже представить не могу. То есть есть какой-то ээ как называется?
Speaker A
Сейчас правильно скажу. Есть постоянно текущая задача - это работать с потребителями. То есть это пойти к какой-то системе, выяснить у них контракты взаимодействия, выяснить их э-э бизнес-процесс, выяснить какие данные их нужны, описать с ними, договориться, какие контракты будут у
Speaker A
нас, на нас для нас, когда мы проведём с ними и тнт, ну и так далее. То есть пойти к потребителю и проработать в целом его переключению. Вот это из таких базовых задач, которые в целом у нас практически все аналитики там хоть
Speaker A
чуть-чуть берут на себя. Угу. Э-э, может быть какая-нибудь задачка по внутренним функционалу для юая, например, да? То есть у нас тоже есть ээ юаная составляющая, но ей там занимается у нас человек, ну, 90% занимается он этой задачей. Ну,
Speaker A
а то есть это выделенный системный аналитик, который чисто, так скажем, по UI идёт. Ну, он как приоретизирован на задачу UI, вот так скажем. Ну, не сказать, что она отдельно выделен прямо, но по возможности задача пою ей уходит.
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
Понял. То есть задачки в Клок заводит продукт owner. А, и обычно сами аналитики, то есть ээ то есть в формате к тебе приходит, говорят, надо вот это вот сделать. Понял.
Speaker A
Вот тут. Ээ, а дальше иди копай. Ну, это знакомо, понимаю. Вот. Угу. А вот получается, если доп уточнения вообще у продуктов, ну, продукт owner, так скажем, он владеет всеми заморочками по поводу там бизнеса, как это должно выглядеть ээ
Speaker A
или же это а-а к тому сервису. Ну, мы же, получается, этот сервис, точнее, вы делаете для пользователей внутрибанковской системы.
Speaker A
И в рамках задачи, которую я там от продуктовра услышал, я сразу пойду уточнять какие-то допдетали именно у того, кто для кого м ну под кого эта задачка сделана, правильно понимаю? Или же Ну, смотри, то есть здесь какая история,
Speaker A
то есть у нас, да, у нас большая платформа, которая хранит в себе огромное количество данных по клиенту.
Speaker A
Вот у нас есть много потребителей, которые эти данные хотят к себе получать. Угу. То есть их там больше там 200, по-моему.
Speaker A
Собственно, для ка с каждым потребителем нужно пообщаться, договориться, что как, когда и почему. Это, собственно, та типовая задача, да, про которую я говорил ранее.
Speaker A
Вот. [откашливается] То есть по ним, да, у нас есть там отдельное рукнаправление. Это там Лёша, он не не собесит. Вот, э, там он полностью за вот этот блок работы отвечает.
Speaker A
Угу. соответственно, и он полностью в контексте полностью понимает, да, что там происходит, может там где-то помочь, где-то там эскалировать, если, ну, при необходимости.
Speaker A
Вот продуктовно у нас отвечает в целом за вс за все направления, которые есть внутри команды.
Speaker A
Угу. Поэтому она на чуть-чуть более высоком уровне абстракции. Понял, понял. Вот. Но всегда вопрос, как бы мы там на уровне руководитель направлений можем тебе помочь решить, подсказать, да, там.
Speaker A
Угу. Понял. А, ну у меня пока по вопросам всё. Спасибо большое за подробные ответы.
Speaker A
Ату. Спасибо тебе за уделённое время. Надеюсь, вернёмся с обратной, точ быстренько вернёмся к тебе с обратной связью. Вот. Ну и хорошего дня, хороших выходных.
Speaker A
Взаимно спасибо. Сразу как бы поделюсь. было, ну вот приятно сейчас, особенно последний момент там с проектированием было, хоть я понятно там, а, понимаю, что где-то там подтормаживаю ещё что-то, мне было недушно и в целом я не нервничал, как это бывает, честно скажу.
Speaker A
Взаимно с тобой было очень приятно пообщаться. Спасибо большое. Всё, хороших выходных, на связи. Давай. Пока-пока.
Speaker A
Пока. Это
Topics:техническое собеседованиеаналитикЕдиный профиль клиентаАльфа-Банкмикросервисыинтеграционное тестированиеSOAP UIPostmanKafkalegacy системы
