GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

🗓 Зачем нужны встречи в Scrum? Полный разбор для аналитиков 🗓

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

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

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

🔗 Сайт эпизода


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video

Переходите в GetAnalyst и получайте опыт в системном анализе и архитектуре каждый день! 🙌

🤖 5 AI-инструментов, которые рекомендуем знать аналитикам к 2026 году, чтобы ускорять свою работу и быть востребованными на рынке 🤖

👉 ChatGPT
Работа с требованиями, ТЗ, ФТ, БТ, НФТ, Use Cases и тд. Ответы на сообщения и email.
В общем любые тексты, которые делает аналитик. Нейросеть идеальна для их создания и улучшения.
Рекомендуется использовать режим GPT-5 Thinking.

👉 Gemini
+ написание SQL-запросов,
+ код для plantUML, чтобы делать UML-диаграммы,
+ проектирование БД через код, например код для dbdiagram.io или SQL-скрипты,
+ проектирование API методов (json/xml/и тд).
Всё, что касается "кода" от аналитиков - сюда.

👉 Claude
Работа с большими контекстами, обработка длинных документов и получение сути из них, анализ логов.
Пример: сжать 30-страничный документ до 1 страницы.

👉 Cursor AI
Разработка собственного кода для приложений, создание прототипов.
Рекомендуемый язык программирования: Python.
Инструмент для продвинутых аналитиков, кто хочет больше, чем просто писать требования.
Полезно для личных проектов за пределами работы.

👉 DeepSeek
Инструмент для всего.
Умеет всё, что и интрументы выше, но на среднем уровне.


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

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


❗️ Важно:
+ Проверяйте результаты за AI, он не всегда прав.
+ AI не может вас заменить, но может сделать вас эффективнее.


Хотите закрывать свои задачи быстрее?
Делайте шаги в сторону AI сегодня и уже в 2026 вместе с GetAnalyst сможете выполнять свою работу быстрее 🙌

📚 Заполненные шаблоны требований из Confluence к интеграции с участием крона, воркера, брокера Kafka 📚

В сентябре мы проектировали интеграцию для сценария авторассылок для пользователей о мероприятиях в #CityGA:
▫️ мероприятия - из KudaGo
▫️ email-рассылки - через DahaMail


Что получилось:

👉 Вводный пост о проекте

1. Описали архитектуру в C4 — зафиксировали компоненты и точки интеграции для сценария

2. Исследовали API KudaGo

3. Исследовали API DashaMail

4. Провели исследовательское тестирование API KudaGo и DashaMail - оформили пошаговый гайд с примерами

5. Сделали верхнеуровневый интеграционный Use Case

6. Разработали UML-Sequence диаграмму для описанного Use Case
🎁 Тут бесплатный AI-бот + руководство по UML

7. Сделали постановку задачи в Confluence: запуск по cron (scheduler) → выгрузка из KudaGo API → формирование сообщения в Kafka.

8. Сделали маппинг данных (API ↔︎ БД ↔︎ сообщения)

9. Уточнили термины: крон, шедулер, воркер

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


👉 В этом посте делимся финальными постановками задач из Confluence:
✅📑 Срабатывание крона и авто-выгрузка мероприятий из KudaGo API
✅📑 Рассылка уведомлений через DashaMail API


❗️ Сохраняйте этот сводный пост по проекту #CityGA с готовыми аналитикой и шаблонами требований на интеграции.
Пригодится, когда встретите похожую задачу.


Проект #CityGA на текущей стадии завершён 🥳


Материалы разработаны в поддержку практической программы Интеграции систем для СА и БА 🧩


#ИнтеграцииGA

👩‍💻 Интеграционный API-метод: что это и когда нужен? 👩‍💻

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

▫️Frontend – пользовательский интерфейс. Он не всегда есть в интеграционных задачах, но если присутствует, то выполняет роль инициатора запросов.

▫️Backend – серверное приложение, которое отвечает за логику обработки данных, их проверку и взаимодействие с внешними системами.

▫️Внешняя система – источник или получатель данных, с которым взаимодействует наш Backend.

❗️ Для обеспечения безопасности, большинство интеграций реализуется через Backend.
Для этого создают интеграционные API-методы.


👉 Интеграционный API-метод – это метод на стороне нашего Backend, который:
+ принимает запросы от Frontend-приложения;
+ взаимодействует с внешней системой для получения или записи данных;
+ реализует логику сопоставления (маппинга) и обработку данных.


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

✅ Централизованное хранение данных:
Backend является центром хранения актуальных данных. Все изменения, включая удаление задач, должны проходить через него, чтобы данные оставались актуальными.

✅ Безопасность:
Хранить секретные ключи на стороне Frontend небезопасно – они могут быть скомпрометированы (например, перехвачены через консоль браузера). Размещение ключей на Backend исключает этот риск.


Пример алгоритма работы интеграционного API-метода разобрала в мини-книге к посту 🤝

#ИнтеграцииGA

👷‍♂️ Воркер (worker) - что это, зачем, примеры, требования 👷‍♀️

Когда вы слышите от разработчиков слово "воркер", они имеют в виду фонового исполнителя задач, работающего отдельно от “основной” логики приложения.


👉 Воркер (worker) — это автономный процесс или механизм, который:
✔️ слушает очередь или получает задачи от планировщика / API / БД
✔️выполняет логику (обработка данных, интеграции и т.д.)
✔️может записывать статус в БД, отправлять обратный callback / сообщение, логировать ошибки, или перемещать задачу в DLQ


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

👉 Воркер может быть масштабируемым, запущенным в нескольких копиях, и работать независимо от основного приложения.


🧩 Как “воркер” вписывается в контекст отложенных задач:

▫️ В сценариях таймера / delay часто используется очередь + воркер: задача помещается с задержкой, воркер забирает её, когда пора, и исполняет.

▫️ В сценариях cron / шедулер — шедулер может генерировать задания (например, “надо что-то выполнить сейчас”) и отправлять их в очередь, воркер их обрабатывает.

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


👉 Что важно учесть аналитику в требованиях:
1. Сколько воркеров может работать параллельно, можно ли масштабировать
2. Источник задач: из очереди, из таблицы БД, от планировщика
3. Идемпотентность, чтобы избежать дублирования выполнения задач
4. Обработка ошибок / retry / DLQ если задача "упала" — как её повторить или куда положить, чтобы выполнить попозже
5. Тайм-аут - сколько времени воркер может “висеть” на задаче
6. Изоляция - воркеры не должны мешать API (CPU, память, I/O)
7. Мониторинг и метрики
8. Как воркер запускается, перезапускается, обновляется. Важно, чтобы падения или деплой не остались без внимания


#ИнтеграцииGA #АрхитектураGA

🔔 Последний день доступа: Интеграции по REST, GraphQL и WebSocket 🔔


Сегодня — последний день, когда вы можете пройти открытый урок:

⚙️ Интеграции по REST, GraphQL и WebSocket
⏳ Доступ до 23:59 (Мск)
🔗 Получить доступ

Если узнали о нём только сейчас — подключайтесь!
Уже регистрировались? Дублировали ссылку с доступом на почту вчера 🙂


👉 Отзывы аналитиков, кто уже прошёл обучение по этому бесплатному уроку:

Ирина:
Мне кажется, что я скоро стану с вашими вебинарами senior еще не начав работать джуном. Огромное спасибо за ценнейшую информацию ❤️

Анастасия:
Столкнулась с API-интеграцией на работе, очень много встало на свои места в голове, стало гораздо понятнее пользоваться Postman и тестировать в нем методы. Огромная благодарность за интенсив!

Кристина:
Я новичок и только погружаюсь в тему интеграции и %80 пробелов закрыл ваш вебинар. Спасибо за подробное занятие

Алексей:
Очень приятное повествование, позволяет увидеть весь путь работы с интеграциями

Татьяна:
Очень понравилось занятие. Жаль, что не удалось присутствовать онлайн. Екатерина все подробно и понятно объясняет. Сравнивая с курсами, которые я проходила ранее, очень высокое качество подачи материала. Я в восторге! Большое спасибо за возможность смотреть подобные занятия в записи.


----------

👩‍🎓👨‍🎓 Этот урок - вводное занятие к практической программе Интеграции систем, которая начинается 8 октября.

А уже 15 октября мы встретимся на первой онлайн-встрече, где вы сможете:
+ познакомиться с проектом,
+ разобрать задание по интеграционным User Stories и Use Cases,
+ получить обратную связь и сразу применить знания.

----------


Смотрите открытый урок сейчас, чтобы уже сегодня получить новый опыт и структурировать имеющиеся знания! 🙌🎓

⌛️📝 Чек-лист требований при работе с отложенными задачами: cron, scheduler, timer/delay, очереди 📝⌛️

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

❗️ Если их не прописать в требованиях — разработчики могут реализовать «как получится», и система будет работать нестабильно.


Ключевые нюансы 👇

🔁 Анти-дубликаты
🛡️ Идемпотентность
🌍 Часовые пояса
⏳ Переходы времени (DST)
📊 Мониторинг и логирование
🗂 Очереди ошибок (DLQ)
📈 Масштабируемость
🗃 Где хранится расписание
💾 Таймеры через БД


👉 Подробности в картинках к посту 🖼


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

Тогда разработчики смогут реализовать систему так, чтобы она работала надёжно и предсказуемо 🙌


#ИнтеграцииGA #АрхитектураGA

⏰ Кроны, шедулеры и таймеры: что это и когда применять | Отложенные задачи ⏰

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



📌 Крон (cron)
Это механизм для запуска задач по расписанию в операционных системах.

Примеры:
+ Каждый понедельник очищать временные данные из БД
+ Каждую среду в 03:00 Мск собирать информацию о предстоящих мероприятиях из внешней системы и формировать рассылку для пользователей
+ В банках: формирование ежедневных отчётов по транзакциям в 10:00 и рассылка ответственным
+ В системах аналитики: пересчёт метрик каждые 5 минут.

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

Cron как служба ОС запускает внешние скрипты/программы, а не внутренние методы приложения в отличие от встроенных шедулеров.



📌 Шедулер (scheduler)
Это любой механизм, который умеет запускать задачи по расписанию. Более общий термин в отличие от крона.

Шедулер может быть встроенным в приложение или инфраструктурным.

▫️ Cron — это конкретная реализация шедулера на уровне ОС.
▫️ В приложениях шедулеры встроены как часть фреймворков и позволяют описывать расписания внутри системы.

Примеры:

+ в корпоративных системах: Quartz Scheduler (Java) или Hangfire (.NET) запускают задачи внутри приложений

+ в микросервисах: инфраструктурный шедулер Kubernetes CronJob — запускает контейнеры по расписанию

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



📌 Таймер (относительный запуск - delay, timer)
Иногда нужно выполнить задачу не по календарю, а через определённое время после события. Это и есть delay (отложенный запуск) или таймер.

Примеры:
+ Через 15 минут после регистрации отправить напоминание, если пользователь не подтвердил email
+ Повторить запрос через 30 секунд, если система недоступна
+ Отправить уведомление через час после бронирования

Как реализуется:

▫️ Через оперативную память приложения - проще, но ненадёжно, т.к. задача пропадёт при перезапуске.

▫️ Через очередь сообщений - RabbitMQ с плагином для отложенных сообщений, Redis-очереди или др

▫️ Через базу данных - таблица заданий с колонкой execute_at, воркер регулярно проверяет и выполняет



➕ Очереди (queue)
Для задач с большими объёмами «одноразовых» запусков лучше использовать очереди.

Когда выбирать очереди:
▫️ очень много динамических одноразовых задач «через N» (email-напоминания, повторные попытки запросов),
▫️ нужны горизонтальное масштабирование и устойчивость к сбоям,
▫️ гарантии обработки задач важнее точности расписания.

Пример:
Пользователь регистрируется на сайт. Нужно через 30 минут, если он не подтвердил email, отправить ему напоминание.

➡️ При этом регистрируются тысячи пользователей в час.

Решение через очередь с delay:

1. При регистрации создаётся сообщение с инструкцией «отправить напоминание» и параметром задержки delay = 30 минут.

2. Сообщение кладётся в очередь (например, RabbitMQ с плагином Delayed Message Exchange или TTL + DLX).
Важно: RabbitMQ не идеален для очень долгих задержек (дни, недели) — его основная область — секунды/минуты/часы.

3. Через 30 минут брокер отпустит сообщение в потребительскую очередь - т.е. в оперативную обработку.



👉 Правила выбора:

✅ Регулярные задачи по календарю (например, ежедневно в 10:00)
= cron / scheduler

✅ Отложенные одноразовые задачи (выполнить один раз через N времени от текущего момента)
= таймер / delay

✅ Массовые задачи - с большим объемом однотипных действий
= очереди

✅ Подходы могут комбинироваться


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

#ИнтеграцииGA #АрхитектураGA

🚘 Беспилотные авто в Сан-Франциско vs в Остине 🚘

На прошлой неделе я была в Сан-Франциско - в городе, где началась история беспилотных такси Waymo.

А несколькими неделями ранее я была в Остине, Техас, где впервые попробовала прокатиться на беспилотнике.

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


Делюсь наблюдениями 👇


👉 Приложение

🔹 Остин
Там Waymo работает внутри приложения Uber - такси с обычными водителями.
Когда вызываешь Uber, можно только отметить «я бы хотела Waymo».
Перед этим надо поставить кучу электронных подписей, что я согласна.
И это скорее лотерея. Шанс получить именно беспилотник был небольшой.
Но у меня получилось в последний вечер!

🔹 Сан-Франциско
Есть отдельное приложение Waymo.
Если заказываешь машину, то действительно приезжает беспилотник. Без «а вдруг повезёт».


👉 Цены: дешевле или дороже?

🔹 В Остине - одинаково.
Там мы заказываем беспилотное такси в формате лотореи.

🔹 В Сан-Франциско - вечером, в час-пик, я пробовала заказать Waymo.

Ожидание: 15 минут
Цена: $42 за 20 минут пути

Для сравнения, в Uber та же поездка стоила $28 с ожиданием 3 минуты 🧐

❗️Беспилотник оказался дороже.
Это было неожиданно, учитывая, что часто мы ждём, что «роботы дешевле людей».

Но потом, когда я заказала Waymo днём, без часа пик, то

Ожидание: 2 минуты
Цена: $13 за 14 минут пути

При этом обычный Uber в это время был по цене 14$.


👉 Ощущения от поездки
Поначалу кажется, что это страшно.
Но когда смотришь на количество камер и то, насколько умно машина реагирует на события вокруг, становится ясно: это не просто «как человек», а во многих ситуациях даже лучше.
Waymo реально кажется очень безопасным.
И как в спокойном Остине, так и в сумасшедшем Сан-Франциско, машины вели себя очень аккуратно.

❗️ Посмотрите видео и задумайтесь о количестве датчиков и сенсоров, которые сканируют обстановку вокруг.


Будущее наступило!
И классно быть не только пользователем таких технологий, но и понимать, что стоит «под капотом» 🤩