Время увлекательных историй. А точнее одной, но очень показательной 🥲
Примерно год назад ко мне на курс «СА с нуля» пришёл студент.
Важно:
▫️ он не был аналитиком,
▫️ он никогда не работал в ИТ,
▫️ он просто хотел сменить профессию с совершенно нетехнической и стать системным аналитиком.
До этого он уже прошёл обучение у конкурентов. И знаете, какой курс ему продали?
🤡 Курс по интеграциям 🤡
Новичку. Без базы. Без опыта. Просто человеку, который «хочу в ИТ» 🥲
Почему?!!?!?!!
Потому что дороже / моднее / на собеседованиях спрашивают.
Лишь бы продать?!
👉 Знакомство со студентом
На программе для начинающих есть вводная встреча, где я лично 30-60 минут беседую со студентами и пытаюсь выяснить текущие знания и опыт, чтобы далее составить индивидуальный план обучения.
Я знала предысторию, поэтому ещё до встречи я запросила:
+ резюме, которое ему посоветовали сделать после того курса,
+ все его выполненные ДЗ с обучения.
Открываю.
И у меня, честно, просто отваливается челюсть 😭
Не его опыт, не его задачи, не его результаты.
Просто: «Вот, что было в программе». Copy-paste.
После этого сopy-paste - ссылки на работы:
🔥 кривая архитектура,
🔥 некорректные UML из draw io
🔥 какие-то урывки простейших REST API методов, с ошибками
И при этом:
«У меня это всё проверяли, сказали, что работы хорошие»😱
Студент ни в чём не виноват.
Он честно верил, что так и должно быть.
👉 И вот тут у меня реально вопрос:
Он пришёл к нам в надежде на понимание и возможность получить нормальное обучение, поняв, что за 1.5 месяца он получил только кашу в голове.
Я не стала очень много комментировать это вот всё, а сказала:
«Окей, давай начнём с нуля. Всё разберём. Задача понятна».
👉 Процесс
Это было непросто. На курсе ему было тяжело, как и всем изначально далёким от IT, но он:
+ задавал много вопросов
+ разбирался
+ делал много ошибок в заданиях (мне кажется он мне BPMN точно раз 5 пересдавал, остальные работы по 2-3 раза)
Он очень старался.
В общем молодец, это нормальный путь 👍
👉 Чем всё закончилось
Примерно через 7 месяцев после старта обучения он выходит на свою первую стажировку системным аналитиком.
Ещё через 3-4 месяца его переводят в штат на позицию middle системного аналитика.
И это было РЕАЛЬНО СЛОЖНО!
Стажёрскую позицию в компании закрыли, и ему пришлось доказывать, что он тянет до миддла.
И он справился сам!
Сейчас у него стабильная работа, реальные задачи, рост. Он иногда пишет мне про успехи, и я правда очень благодарю за эти тексты и очень горжусь 💚💚💚
👉 Зачем я это рассказываю
Коллеги частенько встречают подобное и попросили осветить эту историю.
Не для того, чтобы сказать «мы хорошие, конкуренты плохие».
А чтобы подчеркнуть:
Кому-то было важно продать курс, а не помочь 🤡
Проверка ДЗ у него была «на словах», а по факту - резюме и работы, с которыми его отправляли на рынок, были… ну, скажем мягко, ужасными.
👉 Если вы выбираете обучение
✔️ трезво оценивайте свой уровень
✔️ уточняйте формат проверки ДЗ
✔️ и выбирайте тех, кто реально вкладывается в ваш результат и хочет помочь, а не просто «продаёт модный курс»
Я за то, чтобы к людям относились не как к «чеку в системе оплаты», а как к тем, кто доверяет своё время, деньги и карьеру.
И очень хочу, чтобы у вас было больше историй про то, как вы реально нашли своё место в IT или выросли в карьере 💚
P.S. Сообщения от этого студента связанные с этой историей есть тут
Примерно год назад ко мне на курс «СА с нуля» пришёл студент.
Важно:
▫️ он не был аналитиком,
▫️ он никогда не работал в ИТ,
▫️ он просто хотел сменить профессию с совершенно нетехнической и стать системным аналитиком.
До этого он уже прошёл обучение у конкурентов. И знаете, какой курс ему продали?
🤡 Курс по интеграциям 🤡
Новичку. Без базы. Без опыта. Просто человеку, который «хочу в ИТ» 🥲
Почему?!!?!?!!
Потому что дороже / моднее / на собеседованиях спрашивают.
Лишь бы продать?!
👉 Знакомство со студентом
На программе для начинающих есть вводная встреча, где я лично 30-60 минут беседую со студентами и пытаюсь выяснить текущие знания и опыт, чтобы далее составить индивидуальный план обучения.
Я знала предысторию, поэтому ещё до встречи я запросила:
+ резюме, которое ему посоветовали сделать после того курса,
+ все его выполненные ДЗ с обучения.
Открываю.
И у меня, честно, просто отваливается челюсть 😭
В резюме просто тупо вставлена программа этого самого курса по интеграциям.
Не его опыт, не его задачи, не его результаты.
Просто: «Вот, что было в программе». Copy-paste.
После этого сopy-paste - ссылки на работы:
🔥 кривая архитектура,
🔥 некорректные UML из draw io
🔥 какие-то урывки простейших REST API методов, с ошибками
И при этом:
«У меня это всё проверяли, сказали, что работы хорошие»
Студент ни в чём не виноват.
Он честно верил, что так и должно быть.
👉 И вот тут у меня реально вопрос:
как так можно обращаться с людьми?
Он пришёл к нам в надежде на понимание и возможность получить нормальное обучение, поняв, что за 1.5 месяца он получил только кашу в голове.
Я не стала очень много комментировать это вот всё, а сказала:
«Окей, давай начнём с нуля. Всё разберём. Задача понятна».
👉 Процесс
Это было непросто. На курсе ему было тяжело, как и всем изначально далёким от IT, но он:
+ задавал много вопросов
+ разбирался
+ делал много ошибок в заданиях (мне кажется он мне BPMN точно раз 5 пересдавал, остальные работы по 2-3 раза)
Он очень старался.
В общем молодец, это нормальный путь 👍
👉 Чем всё закончилось
Примерно через 7 месяцев после старта обучения он выходит на свою первую стажировку системным аналитиком.
Ещё через 3-4 месяца его переводят в штат на позицию middle системного аналитика.
И это было РЕАЛЬНО СЛОЖНО!
Стажёрскую позицию в компании закрыли, и ему пришлось доказывать, что он тянет до миддла.
И он справился сам!
Сейчас у него стабильная работа, реальные задачи, рост. Он иногда пишет мне про успехи, и я правда очень благодарю за эти тексты и очень горжусь 💚💚💚
👉 Зачем я это рассказываю
Коллеги частенько встречают подобное и попросили осветить эту историю.
Не для того, чтобы сказать «мы хорошие, конкуренты плохие».
А чтобы подчеркнуть:
Он был нулевым человеком, который просто хотел войти в ИТ.
И его сразу отправили на курс по интеграциям,
вместо того чтобы дать базу по аналитике
Кому-то было важно продать курс, а не помочь 🤡
Проверка ДЗ у него была «на словах», а по факту - резюме и работы, с которыми его отправляли на рынок, были… ну, скажем мягко, ужасными.
👉 Если вы выбираете обучение
✔️ трезво оценивайте свой уровень
✔️ уточняйте формат проверки ДЗ
✔️ и выбирайте тех, кто реально вкладывается в ваш результат и хочет помочь, а не просто «продаёт модный курс»
Я за то, чтобы к людям относились не как к «чеку в системе оплаты», а как к тем, кто доверяет своё время, деньги и карьеру.
И очень хочу, чтобы у вас было больше историй про то, как вы реально нашли своё место в IT или выросли в карьере 💚
P.S. Сообщения от этого студента связанные с этой историей есть тут
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
Мы провели вместе почти год... ❤️🔥
Встречи закончились ещё месяц назад, а я уже скучаю, и с теплом вспоминаю все занятия и сообщения наших выпускников Системный аналитик с нуля.
Для меня это огромная ответственность, чтобы вести коллег в аналитике не…
Встречи закончились ещё месяц назад, а я уже скучаю, и с теплом вспоминаю все занятия и сообщения наших выпускников Системный аналитик с нуля.
Для меня это огромная ответственность, чтобы вести коллег в аналитике не…
❤34🔥16❤🔥5😱3💯1
GetAnalyst_Интеграции_Книга_для_СА_и_БА.pdf
10.7 MB
📚 Мини-книга по Интеграциям: полный справочник для Системного аналитика 📚
Интеграция — это процесс объединения различных систем и приложений в единое целое, чтобы они могли работать вместе, обмениваться данными и выполнять задачи, как одна система.
👉 Пример 1
Платформа по доставке еды хочет отправлять клиенту SMS о процессе доставки.
Надо ли этой платформе:
1. Покупать оборудование для отправки SMS?
2. Заключать договоры и делать интеграции со всеми операторами сотовой связи?
Конечно, нет.
Мы подключаем готовый SMS-сервис (например, Unisender) через API — и задача по доставке SMS решена 🙌
👉 Пример 2
Тот же сервис доставки хочет принимать оплату банковскими картами.
Надо ли ему:
1. Реализовывать проверку карты?
2. Поддерживать 3-D Secure?
3. Хранить токены и проходить банковскую сертификацию PCI DSS?
Нет. Мы просто подключаем готовое решение по API, например, от ТБанка.
Главная идея интеграций:
👉 Виды интеграций:
1) по окружениям:
▫️ Внешние - когда мы хотим подключить к нашей системе чужую, от других разработчиков.
▫️ Внутренние
- на проекте сервисная или микросервисная архитектура, сервисы обмениваются данными по API или через брокеры.
- мобильное приложение работает с данными благодаря интеграции с сервером по API.
2) по направлению:
▫️ Во внешние системы - когда мы используем API чужих систем.
▫️ К нашей системе - когда мы сами разрабатываем свой API, чтобы к нам подключались (например, по примеру выше, мы банк, и даем другим свой API для подключения)
👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа. Обработка в фоне.
👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры
▫️ Файлы
▫️ Общая БД
📚 Подробнее об интеграциях читайте в мини-книге с картинками и примерами.
Файл прикреплен к посту.
Загружаем, изучаем и используем 🚀
#ИнтеграцииGA
Интеграция — это процесс объединения различных систем и приложений в единое целое, чтобы они могли работать вместе, обмениваться данными и выполнять задачи, как одна система.
👉 Пример 1
Платформа по доставке еды хочет отправлять клиенту SMS о процессе доставки.
Надо ли этой платформе:
1. Покупать оборудование для отправки SMS?
2. Заключать договоры и делать интеграции со всеми операторами сотовой связи?
Конечно, нет.
Мы подключаем готовый SMS-сервис (например, Unisender) через API — и задача по доставке SMS решена 🙌
👉 Пример 2
Тот же сервис доставки хочет принимать оплату банковскими картами.
Надо ли ему:
1. Реализовывать проверку карты?
2. Поддерживать 3-D Secure?
3. Хранить токены и проходить банковскую сертификацию PCI DSS?
Нет. Мы просто подключаем готовое решение по API, например, от ТБанка.
Главная идея интеграций:
Если не хочешь "изобретать велосипед", просто подключи (интегрируй) уже готовое решение в свою систему.
👉 Виды интеграций:
1) по окружениям:
▫️ Внешние - когда мы хотим подключить к нашей системе чужую, от других разработчиков.
▫️ Внутренние
- на проекте сервисная или микросервисная архитектура, сервисы обмениваются данными по API или через брокеры.
- мобильное приложение работает с данными благодаря интеграции с сервером по API.
2) по направлению:
▫️ Во внешние системы - когда мы используем API чужих систем.
▫️ К нашей системе - когда мы сами разрабатываем свой API, чтобы к нам подключались (например, по примеру выше, мы банк, и даем другим свой API для подключения)
👉 Способы обмена данными:
▫️ Синхронный - отправили данные и получили ответ сразу.
▫️ Асинхронный - отправили данные и продолжили работу без ожидания ответа. Обработка в фоне.
👉 Основные способы интеграции:
▫️ API
▫️ Библиотеки и SDK
▫️ Брокеры
▫️ Файлы
▫️ Общая БД
📚 Подробнее об интеграциях читайте в мини-книге с картинками и примерами.
Файл прикреплен к посту.
Загружаем, изучаем и используем 🚀
#ИнтеграцииGA
❤28🔥15❤🔥4👍3🎉3
Когда я закончила учёбу по AI в Гарварде (Harvard University) в этом году, у меня остался главный вопрос:
Да, нам дали фундамент, кейсы внедрения AI в бизнес-процессы и инструменты.
Но Гарвард оказался больше про бизнес и стратегию, чем про технику.
👉 Мне хотелось именно залезть "под капот" 👀
Поэтому почти сразу после завершения Гарварда я начала искать что дальше. Выбирала между лучшими техническими университетами - Стэнфордом и Джонсом Хопкинсом (Johns Hopkins University).
В итоге победил Хопкинс, так как программа сильно ближе к тому, что надо системному аналитику.
Хотела заглянуть "под капот"? Получила 😄
Теперь каждую неделю я
+ пишу код
+ тестирую алгоритмы
+ обучаю модели
+ анализирую данные
Руками копаюсь во всей «внутрянке».
👉 Почему я вообще пошла учиться?
Синдром самозванца.
И желание брать проекты с AI.
К началу 2025 года я уже много знала: 2024 прошёл в конференциях и самостоятельном обучении, мы встроили AI во все наши программы. Но полноценного курса именно по AI не было.
Я написала первую версию программы по AI, но осталась ей недовольна. Не хотела делать очередной курс уровня «вставьте промпт - скопируйте ответ», поэтому заморозила его и занялась структурированием знаний.
👉 AI-Акселератор
В начале осени я заново собрала программу, которая получилась тем самым, что я сама искала!
У аналитика с AI две ключевые роли:
1️⃣ пользователь — когда AI помогает в задачах
2️⃣ интегратор — когда мы внедряем AI в продукты
Поэтому в AI-Акселераторе:
✔️ как работают LLM «изнутри»
✔️ локальные LLM
✔️ промпт-инжиниринг
✔️ работа с моделями через API
✔️ немного кодинга
✔️ практика по реальным задачам аналитиков
Смотрю и радуюсь.
Это тот курс, который я сама искала весь год 🤩
На путь к нему ушло много времени, сил и денег, но теперь я честно могу сказать:
👉 я готова передать вам лучший технический опыт работы с AI
🗓 AI-акселератор для аналитиков стартует уже в этот четверг, 11 декабря
Спасибо всем, кто уже с нами!
Искренне надеюсь отдать лучшее!🤖
А как AI работает "под капотом"?
Да, нам дали фундамент, кейсы внедрения AI в бизнес-процессы и инструменты.
Но Гарвард оказался больше про бизнес и стратегию, чем про технику.
👉 Мне хотелось именно залезть "под капот" 👀
Поэтому почти сразу после завершения Гарварда я начала искать что дальше. Выбирала между лучшими техническими университетами - Стэнфордом и Джонсом Хопкинсом (Johns Hopkins University).
В итоге победил Хопкинс, так как программа сильно ближе к тому, что надо системному аналитику.
Хотела заглянуть "под капот"? Получила 😄
Теперь каждую неделю я
+ пишу код
+ тестирую алгоритмы
+ обучаю модели
+ анализирую данные
Руками копаюсь во всей «внутрянке».
👉 Почему я вообще пошла учиться?
Синдром самозванца.
И желание брать проекты с AI.
К началу 2025 года я уже много знала: 2024 прошёл в конференциях и самостоятельном обучении, мы встроили AI во все наши программы. Но полноценного курса именно по AI не было.
Я написала первую версию программы по AI, но осталась ей недовольна. Не хотела делать очередной курс уровня «вставьте промпт - скопируйте ответ», поэтому заморозила его и занялась структурированием знаний.
👉 AI-Акселератор
В начале осени я заново собрала программу, которая получилась тем самым, что я сама искала!
У аналитика с AI две ключевые роли:
1️⃣ пользователь — когда AI помогает в задачах
2️⃣ интегратор — когда мы внедряем AI в продукты
Поэтому в AI-Акселераторе:
✔️ как работают LLM «изнутри»
✔️ локальные LLM
✔️ промпт-инжиниринг
✔️ работа с моделями через API
✔️ немного кодинга
✔️ практика по реальным задачам аналитиков
Смотрю и радуюсь.
Это тот курс, который я сама искала весь год 🤩
На путь к нему ушло много времени, сил и денег, но теперь я честно могу сказать:
👉 я готова передать вам лучший технический опыт работы с AI
Спасибо всем, кто уже с нами!
Искренне надеюсь отдать лучшее!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥45❤7❤🔥5🦄4👍1
GetAnalyst_Виды_Интеграций_полный_справочник.png
699.4 KB
1. Синхронные по API (REST, SOAP, GraphQL и другие)
2. Асинхронные по API (Webhook, Polling)
3. Режим реального времени (WebSocket, SSE и другие)
4. Брокеры и очереди сообщений
5. Общая БД
6. Обмен файлами
Полезно иметь под рукой для подготовки к собеседованиям 🤝
#ИнтеграцииGA
Please open Telegram to view this post
VIEW IN TELEGRAM
💯38🔥29❤🔥4👍1
GetAnalyst_Use_Cases_Обычные_VS_Интеграционные.pdf
1.1 MB
🧩 Интеграционные Use Cases vs Обычные — разбор с примерами 🧩
Use Case — это:
▫️ детализированные функциональные требования;
▫️ описание, как пользователь взаимодействует с системой для достижения цели;
▫️ сценарий, который показывает шаги пользователя и системы в процессе выполнения задачи;
▫️ алгоритм работы системы.
👉 Стандартный шаблон Use Case:
▪ Предусловие
▪ Роли пользователей
▪ Приложения и системы
▪ Входные данные
▪ Основной сценарий
▪ Обработка ошибок и альтернативные сценарии
▪ Ожидаемый результат
👉 Интеграционный Use Case дополняется:
▪ техническими деталями по вызовам API методов, которые аналитику важно прописать в постановке задачи,
▪ а также маппингом данных.
Важно понимать, что Интеграции — это не просто "еще одна задача".
Это серьезная работа по анализу взаимосвязей
+ БД
+ Функций
+ UI/UX
+ API нашей и внешних систем,
которая требует нашего опыта, внимания и профессионализма 🙌
Мини-книгу про отличия обычных Use Case от интеграционных прикрепила к посту 🤝
#ИнтеграцииGA
Use Case — это:
▫️ детализированные функциональные требования;
▫️ описание, как пользователь взаимодействует с системой для достижения цели;
▫️ сценарий, который показывает шаги пользователя и системы в процессе выполнения задачи;
▫️ алгоритм работы системы.
👉 Стандартный шаблон Use Case:
▪ Предусловие
▪ Роли пользователей
▪ Приложения и системы
▪ Входные данные
▪ Основной сценарий
▪ Обработка ошибок и альтернативные сценарии
▪ Ожидаемый результат
👉 Интеграционный Use Case дополняется:
▪ техническими деталями по вызовам API методов, которые аналитику важно прописать в постановке задачи,
▪ а также маппингом данных.
Важно понимать, что Интеграции — это не просто "еще одна задача".
Это серьезная работа по анализу взаимосвязей
+ БД
+ Функций
+ UI/UX
+ API нашей и внешних систем,
которая требует нашего опыта, внимания и профессионализма 🙌
Мини-книгу про отличия обычных Use Case от интеграционных прикрепила к посту 🤝
#ИнтеграцииGA
👍31❤11🔥8🍾1
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
👩🏫🚀 Как выбрать ментора системному аналитику: 5 практических советов 👨🏫🚀
Иногда аналитикам нужно индивидуально разобрать свою карьерную ситуацию: построить план развития, сменить работу и подготовиться к собеседованию, перейти от теории к практике, разобрать конкретные рабочие вопросы и ошибки.
В такие моменты появляется запрос на ментора — опытного специалиста, который помогает структурировать цели, ответить на вопросы, дать практику, выстроить шаги в развитии, снизить тревогу и двигаться вперёд заметно быстрее.
В этом эпизоде разбираем кто такой ментор, когда он действительно нужен, как проходит работа с ним и чего от неё можно (и нельзя) ожидать. Говорим о том, как выбрать «своего» человека, не слить время и деньги и в итоге получать от менторства конкретный результат, а не просто галочку «я сходил к ментору».
🔗 Сайт эпизода
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
Сообщество GetAnalyst — место, где системные аналитики растут быстрее🚀
Иногда аналитикам нужно индивидуально разобрать свою карьерную ситуацию: построить план развития, сменить работу и подготовиться к собеседованию, перейти от теории к практике, разобрать конкретные рабочие вопросы и ошибки.
В такие моменты появляется запрос на ментора — опытного специалиста, который помогает структурировать цели, ответить на вопросы, дать практику, выстроить шаги в развитии, снизить тревогу и двигаться вперёд заметно быстрее.
В этом эпизоде разбираем кто такой ментор, когда он действительно нужен, как проходит работа с ним и чего от неё можно (и нельзя) ожидать. Говорим о том, как выбрать «своего» человека, не слить время и деньги и в итоге получать от менторства конкретный результат, а не просто галочку «я сходил к ментору».
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
Сообщество GetAnalyst — место, где системные аналитики растут быстрее
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16🔥5👍3🤣2❤🔥1😍1
Уже почти два года я живу в доме за городом. И хочу сказать, что это лучшее решение в моей жизни 🙌
Из плюсов:
1. Спокойствие и тишина
2. Чистейший воздух и природа
3. Спокойные соседи с семьями
4. Никаких непредсказуемых людей за стеной, и самой можно шуметь в любое время суток
5. Чтобы выйти на улицу и пройтись 5 минут между созвонами, нужно просто надеть тапочки или кроссовки и выйти. Никаких лифтов и подъездов
6. Прогулки по тихим улицам на природе каждый день
Из минусов:
1. До ближайшего магазина — 20 минут пешком, и он не очень, поэтому почти всегда я на машине
2. Вижусь с друзьями всего пару раз в месяц, потому что до города ехать 35–40 минут. Лень берёт верх: всё самое нужное — в пределах 15 минут на машине, в том числе хорошие рестораны и океан
3. Моя одежда - уютные спортивные костюмы 90% времени
Мои родители живут за городом уже больше 15 лет. И ещё 5 лет назад я вообще не понимала, как так можно?! До города далеко, общаться почти не с кем, магазинов нет, до аэропорта — как до луны… А сейчас? Кажется, я знаю, в кого я 😄
Если бы я была тусовщицей, я бы, наверное, умерла от скуки. Но в последние годы спокойствие и тишина — это что-то очень родное и «про меня» 🙌 Это моё вдохновение.
Мне нравится работать, гулять, ходить в зал, на падел, в сауну и ледяные ванны, ужинать в одном и том же месте по выходным своим лососем с зелёным салатом.
Живу в своей маленькой рутине и искренне радуюсь))
Примерно раз в месяц разбавляю рутину командировками в другие города и безумно скучаю по дому!
И это не зона комфорта и стояния, когда не хочется расти. Для меня дом - это место, чтобы творить 🩷🏡 В этом спокойствии я сильно выросла за последние годы.
Это то, что я искала, путешествуя по миру — и нашла.
Так что делюсь с вами редким фото городской меня 😃
И мне интересно узнать о вас чуть больше...
👉 На какой стороне вы? Город и движение, или спокойствие на природе?
Делитесь в комментариях своими историями и голосуйте реакцией:
❤️ жизнь за городом, в природе
🔥 городская жизнь
Из плюсов:
1. Спокойствие и тишина
2. Чистейший воздух и природа
3. Спокойные соседи с семьями
4. Никаких непредсказуемых людей за стеной, и самой можно шуметь в любое время суток
5. Чтобы выйти на улицу и пройтись 5 минут между созвонами, нужно просто надеть тапочки или кроссовки и выйти. Никаких лифтов и подъездов
6. Прогулки по тихим улицам на природе каждый день
Из минусов:
1. До ближайшего магазина — 20 минут пешком, и он не очень, поэтому почти всегда я на машине
2. Вижусь с друзьями всего пару раз в месяц, потому что до города ехать 35–40 минут. Лень берёт верх: всё самое нужное — в пределах 15 минут на машине, в том числе хорошие рестораны и океан
3. Моя одежда - уютные спортивные костюмы 90% времени
Мои родители живут за городом уже больше 15 лет. И ещё 5 лет назад я вообще не понимала, как так можно?! До города далеко, общаться почти не с кем, магазинов нет, до аэропорта — как до луны… А сейчас? Кажется, я знаю, в кого я 😄
Если бы я была тусовщицей, я бы, наверное, умерла от скуки. Но в последние годы спокойствие и тишина — это что-то очень родное и «про меня» 🙌 Это моё вдохновение.
Мне нравится работать, гулять, ходить в зал, на падел, в сауну и ледяные ванны, ужинать в одном и том же месте по выходным своим лососем с зелёным салатом.
Живу в своей маленькой рутине и искренне радуюсь))
Примерно раз в месяц разбавляю рутину командировками в другие города и безумно скучаю по дому!
И это не зона комфорта и стояния, когда не хочется расти. Для меня дом - это место, чтобы творить 🩷🏡 В этом спокойствии я сильно выросла за последние годы.
Это то, что я искала, путешествуя по миру — и нашла.
Так что делюсь с вами редким фото городской меня 😃
И мне интересно узнать о вас чуть больше...
👉 На какой стороне вы? Город и движение, или спокойствие на природе?
Делитесь в комментариях своими историями и голосуйте реакцией:
❤️ жизнь за городом, в природе
🔥 городская жизнь
❤95🔥50👏5❤🔥2😁2😢1
Когда я только начинала работать системным аналитиком, мои постановки задач сводились к описанию экранов: что нажали → что увидели.
И это было ОК 😃
А потом пришёл “умный и важный” Backend-разработчик и сказал примерно так:
Теперь мы делаем не монолит, где UI + логика + БД в одной кодовой базе.
Теперь у нас Frontend и Backend, которые общаются по API
И вот тогда я впервые узнала интеграции на минимальном уровне:
➡️ Frontend → Backend
Но настоящий “аттракцион” начался позже, когда появилась задача получать данные из внешней системы 👀
➡️ наш Frontend → наш Backend → внешняя система
➡️ а потом интеграции микросервисов
И самое неприятное тогда было - чувство, когда ты угадываешь, что ждут разработчики. Было много "танцев на граблях".
С годами интеграций становилось больше: разные API, протоколы, асинхрон, оборудование. И этот тип задач в итоге стал моим самым любимым🙌
Сейчас я рада делиться своим опытом в интеграциях с вами!
Уже на следующей неделе мы откроем предобучение на практической программе:
👉 Интеграции систем для СА и БА
🟢 Первый онлайн: 21 января 2026
Результат:
✔️ Описываете интеграционные Use Cases
✔️ Уверенно работаете с API: REST, SOAP, GraphQL, gRPC, WebSocket
✔️ Опыт работы с Postman
✔️ Знаете нотацию C4 для архитектуры
✔️ Понимате асинхрон, в т.ч. брокеры
✔️ Можете сделать задачу на интеграционный REST API метод
✔️ У вас десятки примеров документации, которые можно переиспользовать в работе
Это то, что сейчас спрашивают Middle+ системных аналитиков на собеседованиях, и то, что реально нужно в работе.
Приглашаем вас начать новый 2026 год с навыка, который даёт уверенность в системном анализе и рост в карьере
Вопросы? Пишите @getanalyst или на info@getanalyst.ru. Поможем оценить текущие навыки и разобраться, подойдёт ли вам программа 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥7👍5❤🔥2👎1🤣1
🧩 Краткий чек-лист по работе с Интеграциями 🧩
☑️ Получить вводные от заказчика
☑️ Выделить компоненты системы: внешние, внутренние
☑️ Найти API-документацию для каждого из внешних сервисов, а если необходимо, то и для внутренних
☑️ Нарисовать схему архитектуры — первое приближение
☑️ Описать процессы, которые нужно поддержать в системе
☑️ Найти по API-документации соответствующие процессам методы, добавить их в описание
☑️ Уточнить схему архитектуры (и далее постоянно актуализировать по ходу детального проектирования и постановок задач)
☑️ Получить доступы к API
☑️ Протестировать API своими силами или с помощью разработчиков
☑️ Сопоставить наборы данных, доработать/спроектировать БД нашей системы при необходимости, описать маппинг данных
☑️ Создать задачи в Jira и выстроить порядок разработки
☑️ Сделать детализацию постановок задач в Confluence на основе исследований, проведенных ранее
Пусть он станет вашим помощником при работе с задачами на интеграции и в подготовке к собеседованиям.
👉 Полный пошаговый план работы с задачами на интеграции в статье.
#ИнтеграцииGA
☑️ Получить вводные от заказчика
☑️ Выделить компоненты системы: внешние, внутренние
☑️ Найти API-документацию для каждого из внешних сервисов, а если необходимо, то и для внутренних
☑️ Нарисовать схему архитектуры — первое приближение
☑️ Описать процессы, которые нужно поддержать в системе
☑️ Найти по API-документации соответствующие процессам методы, добавить их в описание
☑️ Уточнить схему архитектуры (и далее постоянно актуализировать по ходу детального проектирования и постановок задач)
☑️ Получить доступы к API
☑️ Протестировать API своими силами или с помощью разработчиков
☑️ Сопоставить наборы данных, доработать/спроектировать БД нашей системы при необходимости, описать маппинг данных
☑️ Создать задачи в Jira и выстроить порядок разработки
☑️ Сделать детализацию постановок задач в Confluence на основе исследований, проведенных ранее
Пусть он станет вашим помощником при работе с задачами на интеграции и в подготовке к собеседованиям.
👉 Полный пошаговый план работы с задачами на интеграции в статье.
#ИнтеграцииGA
❤24👏16❤🔥5👍3🔥1
GetAnalyst_Интеграции_Типовые_Альтернативные_сценарии_.pdf
5.1 MB
📚 Чек-лист: типовые требования к обработке ошибок в Интеграциях 📚
Написание требований к обработке ошибок является важной частью обязанностей Системного Аналитика. Я всегда начинаю описание работы системы с прямого сценария, а затем сразу же перехожу к поиску подвохов и отклонений на каждом его шаге.
Это нужно, чтобы после релиза системы не получать от пользователей обращения в тех поддержку и негативные отзывы о том, что наша система плохо работает или сломалась из-за какой-то мелочи.
Также не хочется получать разочарования на этапе тестирования, когда довольный тестировщик нашел очередной баг, что ведет к “уточнениям по аналитике”, очередным кругам доработок, задержкам релизов и отвлечению от новых задач.
😄👉 Я абсолютно уверена, что работа аналитика - победить тестировщика,
то есть первым найти все потенциальные ошибки и сбои, которые может создать пользователь. Поэтому круто, когда в Системный Анализ переходят Тестировщики.
🔖 При работе с интеграциями я использую стандартный чек-лист, по которому можно написать требования к обработке ошибок:
1. Аутентификация
2. Доступ
3. Тайм-аут
4. Ошибки по документации внешней системы
5. Неизвестные ошибки, которых не было в документации и не планировалось их обрабатывать (новые коды, неизвестные форматы тела ответа)
6. Новые статусы или значения справочников, которые не совпадают с нашими перекодировочными таблицами, описанными в маппинге данных
Подробности в мини-книге к посту 📚
#ИнтеграцииGA
Написание требований к обработке ошибок является важной частью обязанностей Системного Аналитика. Я всегда начинаю описание работы системы с прямого сценария, а затем сразу же перехожу к поиску подвохов и отклонений на каждом его шаге.
Это нужно, чтобы после релиза системы не получать от пользователей обращения в тех поддержку и негативные отзывы о том, что наша система плохо работает или сломалась из-за какой-то мелочи.
Также не хочется получать разочарования на этапе тестирования, когда довольный тестировщик нашел очередной баг, что ведет к “уточнениям по аналитике”, очередным кругам доработок, задержкам релизов и отвлечению от новых задач.
😄👉 Я абсолютно уверена, что работа аналитика - победить тестировщика,
то есть первым найти все потенциальные ошибки и сбои, которые может создать пользователь. Поэтому круто, когда в Системный Анализ переходят Тестировщики.
1. Аутентификация
2. Доступ
3. Тайм-аут
4. Ошибки по документации внешней системы
5. Неизвестные ошибки, которых не было в документации и не планировалось их обрабатывать (новые коды, неизвестные форматы тела ответа)
6. Новые статусы или значения справочников, которые не совпадают с нашими перекодировочными таблицами, описанными в маппинге данных
Подробности в мини-книге к посту 📚
#ИнтеграцииGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤21🔥12🍾1
🔐 5 способов авторизации в API - наглядное демо по настройкам в Postman 🔐
При проектировании интеграций, системному аналитику важно заранее продумать сценарий авторизации запросов во внешнюю систему.
Почему?
1. Без авторизации вызовы API просто не пройдут — интеграция «упадёт» уже на первом шаге.
2. Разные механизмы требуют разной логики работы и обработки ошибок.
3. Чёткое понимание процесса авторизации упрощает тестирование и облегчает отладку сценариев интеграции.
📌 Основные способы авторизации
API Key
Basic Auth
Bearer Token
JWT Token
OAuth 2.0
Mutual TLS (по сертификатам)
📌 Как оформлять в требованиях?
При работе с задачей на интеграцию, аналитик пишет требования к интеграционным API-методам или Backend-процессам для своей системы, в логике которых встроены вызовы внешних API.
👉 Не дублируйте требования к авторизации в одном и том же внешнем API в каждом Use Case, который его использует.
Вместо того, чтобы в каждом интеграционном Use Case описывать требования к авторизации во внешней системе и обработку её ошибок, достаточно вынести общие требования к авторизации в отдельную статью (+задачу) и затем ссылаться на неё.
При описании отдельных API-методов или Backend-процессов лучше фокусироваться только на специфике их работы.
📌 Обработка ошибок
Важно предусмотреть и описать требования к обработке ошибок аутентификации и авторизации в процессе работы интеграции:
❌ 401 Unauthorized — неверные или отсутствующие учётные данные. Возможна повторная фоновая аутентификация.
❌ 403 Forbidden — недостаточно прав для выполнения операции, хотя аутентификация (учётные данные) может быть верной.
❌ 419 Token Expired — срок действия токена истёк, требуется рефреш или повторная фоновая аутентификация.
❌ 429 Too Many Requests — превышен лимит запросов (для API Key/токена OAuth, учетной записи).
📌 Логирование
Логируйте и мониторьте случаи ошибок авторизации.
Если попытки повторной фоновой авторизации не приводят к успеху, то есть высокий риск, что интеграция "упала".
#ИнтеграцииGA
При проектировании интеграций, системному аналитику важно заранее продумать сценарий авторизации запросов во внешнюю систему.
Почему?
1. Без авторизации вызовы API просто не пройдут — интеграция «упадёт» уже на первом шаге.
2. Разные механизмы требуют разной логики работы и обработки ошибок.
3. Чёткое понимание процесса авторизации упрощает тестирование и облегчает отладку сценариев интеграции.
📌 Основные способы авторизации
API Key
Basic Auth
Bearer Token
JWT Token
OAuth 2.0
Mutual TLS (по сертификатам)
📌 Как оформлять в требованиях?
При работе с задачей на интеграцию, аналитик пишет требования к интеграционным API-методам или Backend-процессам для своей системы, в логике которых встроены вызовы внешних API.
👉 Не дублируйте требования к авторизации в одном и том же внешнем API в каждом Use Case, который его использует.
Вместо того, чтобы в каждом интеграционном Use Case описывать требования к авторизации во внешней системе и обработку её ошибок, достаточно вынести общие требования к авторизации в отдельную статью (+задачу) и затем ссылаться на неё.
При описании отдельных API-методов или Backend-процессов лучше фокусироваться только на специфике их работы.
📌 Обработка ошибок
Важно предусмотреть и описать требования к обработке ошибок аутентификации и авторизации в процессе работы интеграции:
❌ 401 Unauthorized — неверные или отсутствующие учётные данные. Возможна повторная фоновая аутентификация.
❌ 403 Forbidden — недостаточно прав для выполнения операции, хотя аутентификация (учётные данные) может быть верной.
❌ 419 Token Expired — срок действия токена истёк, требуется рефреш или повторная фоновая аутентификация.
❌ 429 Too Many Requests — превышен лимит запросов (для API Key/токена OAuth, учетной записи).
📌 Логирование
Логируйте и мониторьте случаи ошибок авторизации.
Если попытки повторной фоновой авторизации не приводят к успеху, то есть высокий риск, что интеграция "упала".
#ИнтеграцииGA
❤19👍10🔥7❤🔥4😍1👀1
🔐 Новый проект по OAuth 2.0 на реальном кейсе: подключаем вход через аккаунт Mail.ru в FoodDeliveryGA 🔐
Один из самых частых вопросов в чате GetAnalyst и от наших студентов звучит примерно так:
По аналогии с тем, как мы везде входим “через Google”, “через Apple”, "через Яндекс" и другие сервисы.
👉 Это именно та интеграция, которая сегодня встречается почти в любом IT-продукте: от интернет-магазинов до корпоративных систем.
Поэтому в этом месяце мы продолжим разбирать проект FoodDeliveryGA, чтобы на его примере показать как проектировать интеграцию с OAuth 2.0 сервисом на практике:
🔐 Пользователь сможет войти в FoodDeliveryGA через профиль Mail.ru
(полный аналог “Войти через Госуслуги”, только на другом провайдере)
👉 План:
1. Разберёмся в специфике OAuth 2.0
2. Определим влияние интеграции на архитектуру системы (какие компоненты и потоки появляются)
3. Исследуем API-документацию Mail.ru
4. Протестируем API Mail.ru в Postman, чтобы увидеть, как он реально работает (а не “как написано в доке”)
5. Опишем интеграционные Use Cases:
+ регистрация пользователя
+ авторизация
+ восстановление доступа
со всеми тех. деталями (запросы, ответы, альтернативные ветки)
6. Сделаем маппинги данных + доработки БД (что храним, что НЕ храним после входа через аккаунт Mail.ru, ключевые поля)
7. Дополним требования UML-диаграммами
8. Сформируем требования к интеграционным REST API методам на нашем Backend
🎯 Результат:
У вас на руках будет не “теория про токены и OAuth 2.0”, а полноценная постановка задачи на интеграцию, которую можно повторить с любым OAuth-провайдером в любом проекте!
✅ В том числе с Госуслугами!
Проект FoodDeliveryGA разбираем в поддержку практической программы Интеграции систем 🧩
Готовы получить новый опыт и знания?
Подписывайтесь на GetAnalyst и следите за хэштегом #FoodDeliveryGA_oauth!
Добро пожаловать в проект! 🤝
#ИнтеграцииGA
Один из самых частых вопросов в чате GetAnalyst и от наших студентов звучит примерно так:
👉 Как спроектировать авторизацию через Госуслуги в нашей системе?
По аналогии с тем, как мы везде входим “через Google”, “через Apple”, "через Яндекс" и другие сервисы.
👉 Это именно та интеграция, которая сегодня встречается почти в любом IT-продукте: от интернет-магазинов до корпоративных систем.
Поэтому в этом месяце мы продолжим разбирать проект FoodDeliveryGA, чтобы на его примере показать как проектировать интеграцию с OAuth 2.0 сервисом на практике:
🔐 Пользователь сможет войти в FoodDeliveryGA через профиль Mail.ru
(полный аналог “Войти через Госуслуги”, только на другом провайдере)
👉 План:
1. Разберёмся в специфике OAuth 2.0
2. Определим влияние интеграции на архитектуру системы (какие компоненты и потоки появляются)
3. Исследуем API-документацию Mail.ru
4. Протестируем API Mail.ru в Postman, чтобы увидеть, как он реально работает (а не “как написано в доке”)
5. Опишем интеграционные Use Cases:
+ регистрация пользователя
+ авторизация
+ восстановление доступа
со всеми тех. деталями (запросы, ответы, альтернативные ветки)
6. Сделаем маппинги данных + доработки БД (что храним, что НЕ храним после входа через аккаунт Mail.ru, ключевые поля)
7. Дополним требования UML-диаграммами
8. Сформируем требования к интеграционным REST API методам на нашем Backend
🎯 Результат:
У вас на руках будет не “теория про токены и OAuth 2.0”, а полноценная постановка задачи на интеграцию, которую можно повторить с любым OAuth-провайдером в любом проекте!
✅ В том числе с Госуслугами!
Проект FoodDeliveryGA разбираем в поддержку практической программы Интеграции систем 🧩
Готовы получить новый опыт и знания?
Подписывайтесь на GetAnalyst и следите за хэштегом #FoodDeliveryGA_oauth!
Добро пожаловать в проект! 🤝
#ИнтеграцииGA
🔥42❤14
📖🔖 Всё про OAuth 2.0 с примером за 3 минуты 📖
👉 OAuth 2.0 — это стандарт, который позволяет вашему приложению получить ограниченный доступ к данным пользователя во внешнем сервисе без передачи пароля
👉 Ключевая идея на примере FoodDeliveryGA
✅ пользователь логинится в приложении FoodDeliveryGA и подтверждает доступ к его личным данным на стороне внешнего сервиса (Mail.ru) - через его безопасную web-форму
✅ FoodDeliveryGA получает токены доступа и работает дальше через API
❌ пароль пользователя от Mail.ru приложению FoodDeliveryGA никогда не передают
👉 Роли в OAuth 2.0
на примере FoodDeliveryGA
▫️Resource Owner (Владелец ресурса) — пользователь
Человек, который хочет войти в приложение FoodDeliveryGA и даёт согласие на доступ к его данным в Mail.ru для этого приложения
▫️Client (Клиент) — приложение FoodDeliveryGA
Frontend + Backend (в зависимости от схемы), которое инициирует авторизацию
▫️Authorization Server (Сервер авторизации) — Mail.ru
На предоставляемой им web-форме пользователь вводит логин/пароль Mail.ru и подтверждает доступ к данным
▫️Resource Server (Сервер ресурсов) — API Mail.ru
Методы REST API, где лежат данные пользователя (например, профайл / user info, информация о друзьях, посты на стене в социальной сети Мой Мир и другие данные).
Эти методы мы вызываем с использованием токена, который получили после аутентификации пользователя
💡 Часто Authorization Server и Resource Server находятся “в одном провайдере” (как Mail.ru), но логически это разные роли и с точки зрения Mail.ru это разные сервисы (сервера)
👉 Алгоритм работы OAuth 2.0 по шагам на картинке
для Grant Type=authorization_code
👉 OAuth 2.0 Grant Types - алгоритмы
authorization_code
refresh_token
client_credentials
implicit
password
device_code
👉 Ключевые параметры OAuth 2.0
для API-методов (в URL и JSON)
response_type
client_id
client_secret
redirect_uri
scope
state
refresh_token
access_token
token_type
expires_in
Зависят от Grant Type
Продолжение в следующих постах #FoodDeliveryGA_oauth 🚀
#ИнтеграцииGA
👉 OAuth 2.0 — это стандарт, который позволяет вашему приложению получить ограниченный доступ к данным пользователя во внешнем сервисе без передачи пароля
👉 Ключевая идея на примере FoodDeliveryGA
✅ пользователь логинится в приложении FoodDeliveryGA и подтверждает доступ к его личным данным на стороне внешнего сервиса (Mail.ru) - через его безопасную web-форму
✅ FoodDeliveryGA получает токены доступа и работает дальше через API
❌ пароль пользователя от Mail.ru приложению FoodDeliveryGA никогда не передают
👉 Роли в OAuth 2.0
на примере FoodDeliveryGA
▫️Resource Owner (Владелец ресурса) — пользователь
Человек, который хочет войти в приложение FoodDeliveryGA и даёт согласие на доступ к его данным в Mail.ru для этого приложения
▫️Client (Клиент) — приложение FoodDeliveryGA
Frontend + Backend (в зависимости от схемы), которое инициирует авторизацию
▫️Authorization Server (Сервер авторизации) — Mail.ru
На предоставляемой им web-форме пользователь вводит логин/пароль Mail.ru и подтверждает доступ к данным
▫️Resource Server (Сервер ресурсов) — API Mail.ru
Методы REST API, где лежат данные пользователя (например, профайл / user info, информация о друзьях, посты на стене в социальной сети Мой Мир и другие данные).
Эти методы мы вызываем с использованием токена, который получили после аутентификации пользователя
💡 Часто Authorization Server и Resource Server находятся “в одном провайдере” (как Mail.ru), но логически это разные роли и с точки зрения Mail.ru это разные сервисы (сервера)
👉 Алгоритм работы OAuth 2.0 по шагам на картинке
для Grant Type=authorization_code
👉 OAuth 2.0 Grant Types - алгоритмы
authorization_code
refresh_token
client_credentials
implicit
password
device_code
👉 Ключевые параметры OAuth 2.0
для API-методов (в URL и JSON)
response_type
client_id
client_secret
redirect_uri
scope
state
refresh_token
access_token
token_type
expires_in
Зависят от Grant Type
Продолжение в следующих постах #FoodDeliveryGA_oauth 🚀
#ИнтеграцииGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16🔥9❤🔥2👍1