Для многих аналитиков и разработчиков нефункциональные требования к системе — тёмный лес. Понятно, что «система должна работать быстро и надёжно», но вот какие именно цифры написать в ТЗ, какие метрики указать и как всё это потом проверять — часто остаётся загадкой.
Мониторинг — один из ключевых инструментов, связанных с архитектурой и инфраструктурой, который позволяет не на словах, а в реальности проверить, выполняются ли нефункциональные требования.
Сообщество системных аналитиков GetAnalyst: https://t.me/getanalysts
Материалы к эпизоду: https://getanalyst.ru/podcast/monitoring
В этом эпизоде мы разложим по полочкам:
+ что именно нужно мониторить на проекте,
+ какие инструменты обычно настраивают,
+ и главное — какие конкретные метрики и показатели можно и нужно писать в ТЗ.
После выпуска у вас будет структурированное понимание, какие цифры писать в НФТ и как измерять качество системы, а не просто «надеяться, что всё ок».
Тайм-коды эпизода:
01:30 | Мониторинг и диагностика IT-систем: что это такое и зачем нужен системный мониторинг.
6:25 | Что нужно мониторить в продакшене: ключевые метрики и показатели мониторинга для вашей системы.
10:00 | Логирование и трассировка запросов: что это, зачем нужны, как работают и как связаны с системным мониторингом.
11:45 | Конкретные нефункциональные требования к мониторингу: какие цифры по времени отклика писать в спецификации системы.
14:06 | Как мониторить мобильные приложения.
16:21 | Нефункциональные требования к нагрузке: какие значения % CPU и ресурсов указывать в требованиях.
20:10 | Инструменты мониторинга и observability: что выбрать, когда и зачем. Стандарт OpenTelemetry и пример схемы архитектуры.
27:35 | Реальные кейсы, где мониторинг помогает проектам. Мониторинг кэширования.
33:04 | Кто на проекте настраивает мониторинг системы и что для этого нужно.
35:41 | Источники требований к мониторингу: от кого они приходят, в каком виде и как собирать требования к метрикам.
37:53 | Кто и как следит за показателями мониторинга на проекте: процессы, роли и работа с инцидентами.
44:37 | Дашборды мониторинга: как понять, что нужен новый дашборд.
46:27 | Итоги эпизода: рекомендации командам по внедрению мониторинга на разных стадиях проекта и практика «учебных тревог» в IT-проектах.
Ведущая:
Екатерина Ананьева, Основатель сообщества системных аналитиков GetAnalyst.
Гости:
Никита Улько, Техлид VK Tech.
Повсюду «AI, AI, AI»: Generative AI, LLM, Fine-Tuning, RAG — но что это значит для системных и бизнес-аналитиков? Куда бежать, что изучать и с чего начать, если уже сейчас хочется новый виток в карьере в направлении AI?
В этом выпуске разбираем реальные проекты, задачи и роли в компании red_mad_robot: где место аналитика в Generative AI, какие навыки нужны на старте и как меняется работа команд по сравнению с «обычными» IT-проектами.
Telegram-канал сообщества: https://t.me/getanalysts
Статья к эпизоду: https://getanalyst.ru/podcast/generative-ai-for-analysts
red_mad_robot: https://www.redmadrobot.com/
AI акселератор для БА и СА: https://getanalyst.ru/education/ai-for-systems-analysts
Анастасия и Игорь «раскрывают кухню» Generative AI-проектов: RAG vs Fine-Tuning, Small LLMs, метрики качества, безопасность и свой реальный опыт работы. К концу эпизода вы поймёте, с чего начать переход, какие артефакты добавить в портфолио и чего ожидать на собеседованиях.
Слушайте, делайте заметки и задавайте вопросы в комментариях, чтобы мы могли дать вам максимум пользы от этого выпуска!
Тайм-коды:
00:00 | Введение в Generative AI и машинное обучение. Знакомство с опытом аналитиков в AI-компании.
7:19 | Что такое Generative AI: короткое погружение и ключевые термины.
12:49 | Популярные направления внедрения Generative AI: типовые бизнес-задачи и запросы.
16:24 | RAG и Fine-Tuning: как адаптируют модели под задачи.
18:37 | Оценка работы AI: качество ответов, замена человека, типичные проблемы.
25:13 | Какие AI-модели внедряют в мире и РФ, безопасность использования AI.
30:22 | Small LLMs: что это и как повышают безопасность внедрения.
35:34 | Навыки для работы с Generative AI: отличия ролей аналитика, разработчика и тестировщика от обычных IT-команд.
40:01 | Как начать карьеру в Generative AI без опыта и компетенций.
50:30 | Страхи и барьеры компаний при внедрении Generative AI.
57:53 | Реальные кейсы и экономика: где Generative AI даёт эффект, а где убытки.
1:04:09 | Пожелания и рекомендации для бизнеса и IT-специалистов.
Ведущая:
Екатерина Ананьева,
основатель сообщества системных аналитиков GetAnalyst
https://t.me/getanalysts
Гости:
Анастасия Панфëрова и Игорь Епанешников,
компания red_mad_robot
https://www.redmadrobot.com/
Надоели бесконечные созвоны и непонятные встречи? Или вы только начинаете карьеру аналитика и хотите разобраться, какие мероприятия вообще есть в Scrum и зачем они нужны?
TG-канал сообщества системных аналитиков GetAnalyst:
https://t.me/getanalysts
Сайт эпизода:
https://getanalyst.ru/podcast/scrum-meetings
Практические курсы для СА:
https://getanalyst.ru/education
В этом эпизоде мы разбираем все ключевые события Scrum — планирование, дейли, обзоры, ретроспективы и груминг. Делимся своим опытом, ошибками и лучшими практиками, чтобы вы могли увидеть, как это работает в реальных командах и применить полезное в своей работе.
Подойдёт и новичкам, которые хотят погрузиться в атмосферу IT-разработки, и опытным аналитикам, которые ищут свежий взгляд и инсайты для улучшения своих процессов.
Связанный эпизод: Всё про Agile, Scrum, Kanban и «Документация не нужна»
Тайм-коды к эпизоду:
00:00 | Введение. Зачем системному аналитику понимать мероприятия Scrum и как это помогает в работе с командой.
01:21 | Основные мероприятия Scrum.
05:07 | Планирование спринта: кто участвует, сколько длится, лучшие практики. Проблема 40 часов / неделю.
20:38 | Когда проводить планирование.
23:53 | Daily Scrum (Stand-up, Дейли): зачем нужны ежедневные митинги, кто участвует, как уложиться в 15 минут. Практики против «болтовни».
34:10 | Обзор спринта (Sprint Review): что обсуждают, кто участвует и как это помогает команде и бизнесу увидеть реальную ценность работы.
43:42 | Ретроспектива спринта: зачем нужна, кто участвует, примеры тем для обсуждения.
57:36 | Методы ретроспектив: от “Mad-Sad-Glad” до “Воздушного шара”.
1:00:02 | Груминг (Product Backlog Refinement, PBR): зачем нужен, кто участвует, cпособы проведения и подготовка.
1:17:35 | Scrum-мастер: нужен ли он?
1:22:45 | Резюме по эпизоду и подведение итогов.
Ведущая:
Екатерина Ананьева
Гости:
Кристина Виноградова
Елена Киселева
Готовитесь к миграции данных между СУБД, планируете переезд с легаси системы на новую платформу, или запускаете проект по импортозамещению? Этот выпуск для вас!
Разбираем типовые ошибки связанные с падением продакшн, и показываем, как их избежать. Теперь вы теперь точно не допустите их в своей практике. Слушайте, делайте заметки и делитесь с коллегами.
Telegram-канал сообщества: https://t.me/getanalysts
Рекомендуемый чеклист НФТ: https://getanalyst.ru/podcast/nft
Тайм-коды эпизода:
00:00 | Введение и предыстория: погружение в задачу на импортозамещение высоконагруженной системы.
04:47 | Что случилось в день X, когда продакшн лёг: когда нефункциональные требования важны.
08:51 | Разбор технического решения по миграции терабайтов данных.
13:14 | Первые признаки “падения”: какие инструменты мониторинга показали сбой в системе.
14:36 | Реакция команды и результаты анализа проблемы.
18:15 | Погружение в технические детали бага.
20:56 | Индексы в БД.
25:55 | Оперативная реакция: что делать, когда миграция БД положила систему и какова в этом роль системного аналитика.
29:47 | Кто виноват в “падении” продакшн? Проблемы игнорирования нефункциональных требований.
32:17 | Примеры нефункциональных требований, которые надо было зафиксировать.
34:42 | Рекомендации для аналитиков, кому предстоит работать с импортозамещением и миграции между СУБД.
Ведущая:
Екатерина Ананьева,
Основатель сообщества системных аналитиков GetAnalyst
Гости:
Елизавета Акманова,
Старший cистемный аналитик компании UseTech
Если вы на пороге смены работы или хотите вырасти до уровня Senior Системного Аналитика — этот выпуск для вас.
Мы собрали 10 ключевых вопросов с собеседований на позицию Senior Системный Аналитик (Старший Системный Аналитик), разбор ответов на них и полезные ссылки для самостоятельной подготовки.
Telegram-канал сообщества:
https://t.me/getanalysts
Статья к эпизоду с полезными материалами и ссылками:
https://getanalyst.ru/podcast/top-10-interview-questions-for-senior-analyst
После прослушивания вы поймёте, какие темы у вас закрыты, а какие требуют дополнительного изучения или повторения, и сможете заранее закрыть пробелы в знаниях, чтобы уверенно проходить даже самые сложные интервью.
Включайте, чтобы начать свой путь к уровню Senior!
Тайм-коды эпизода:
01:00 | Виды архитектуры: монолит, SOA, MSA, EDA.
07:42 | 8 шаблонов проектирования микросервисов.
11:44 | Подходы к интеграции сервисов в распределенных системах.
14:15 | API Gateway: что это, зачем нужен, преимущества и недостатки.
19:57 | API Gateway как точка отказа в системе.
22:54 | Оркестрация и хореография микросервисов.
32:16 | Способы управления высокой нагрузкой для систем.
34:59 | Проектирование БД: связь “многие-ко-многим”.
37:53 | Миграция данных без простоя: как реализовать?
44:44 | Виды интеграции систем.
51:03 | Брокеры и очереди сообщений. RabbitMQ и Kafka.
54:41 | Аутентификация и авторизация в API.
Ведущая:
Екатерина Ананьева
Основатель сообщества Системных Аналитиков GetAnalyst
Монолиты, микросервисы, и… чистая архитектура. Как они связаны?
Если вы разработчик или системный аналитик и планируете рост в архитектора, вам так или иначе придётся познакомиться с чистой архитектурой — подходом, который важно не просто изучить, а понять, принять и научиться применять на практике.
Статья к эпизоду: https://getanalyst.ru/podcast/clean-architecture
Telegram-канал сообщества: https://t.me/getanalysts
В этом выпуске объясняем простыми словами, как работает чистая архитектура, зачем она нужна и какие принципы лежат в её основе.
Тайм-коды эпизода:
00:00 | Знакомство со спикером. Про путь из разработчика в системного архитектора.
4:49 | Как архитекторы проверяют новые технологии: пишут код сами или делегируют?
8:15 | Что такое “Читая архитектура” и чем отличается от микросервисной архитектуры.
10:39 | Как выглядит чистая архитектура в нотации C4 / Component (L3): разбираем слои presentation, domain и data и связи между ними.
15:45 | Какие слои надо дорабатывать в чистой архитектуре, если решили переехать с REST на gRPC?
17:22 | Маппинг данных в чистой архитектуре. Разбор Use Case с описанием потока данных между слоями presentation, domain и data (для лучшего понимания смотреть на схему в статье).
23:42 | Как несколько доменов могут жить внутри одного сервиса: как меняется организация слоёв чистой архитектуры.
27:49 | Связь чистой архитектуры с монолитами, SOA и микросервисами.
29:11 | Преимущества и недостатки чистой архитектуры.
37:00 | Для каких проектов лучше подходит чистая архитектура.
41:25 | Работа аналитиков на проектах с чистой архитектурой: особенности постановки задач и ведения документации.
51:32 | Рекомендации по изучению подхода чистой архитектуры.
Ведущая:
Екатерина Ананьева,
Основатель сообщества системных аналитиков GetAnalyst
Гости:
Никита Улько,
Системный Архитектор, UseTech
Этот технический выпуск мы сделали для системных аналитиков, которые хотят развиваться в направлении архитектуры и освоить микрофронтенды.
Статья к эпизоду: https://getanalyst.ru/podcast/microfrontend
Telegram-канал сообщества: https://t.me/getanalysts
Рассказываем, когда и почему выбирают микрофронтенд‑архитектуру, как она помогает масштабировать разработку Frontend, какие типичные сложности возникают при внедрении и как их избегать.
На примере реального кейса разбираем логику работы и обмен данными в архитектуре микрофронтендов, как формулировать задачи на разработчиков, на что обращать внимание при проектировании UI‑архитектуры, и почему микрофронты — не просто тренд, а взвешенное техническое решение.
Тайм-коды эпизода:
00:00 | Введение. Знакомство со спикером и актуальность темы.
4:47 | Что такое микрофронтенды.
7:30 | Как разделить приложение на микрофронтенды.
9:45 | Архитектура приложения построенного на микрофронтендах.
12:05 | Разбор кейса: проблемы добавления нового языка для приложения на микрофорнтендах.
17:42 | На что обращать внимание при локализации приложения: язык, валидация данных, бизнес-логика.
23:32 | Как микрофронтенд взаимодействует с микросервисным бэкендом — маршрутизация запросов: разбор кейса с локализацией и соблюдением требований к хранению персональных данных иностранных граждан.
32:13 | Особенности постановки задач на микрофронтенды для системных аналитиков.
37:49 | Каким проектам лучше подойдут микрофронтенды.
44:53 | Шаблон постановки задачи от системного аналитика на разработку микрофронтенда.
49:47 | Заключение.
Ведущая:
Екатерина Ананьева,
Основатель сообщества Системных Аналитиков GetAnalyst
Гости:
Елизавета Акманова,
Старший cистемный аналитик компании UseTech
Если вы работаете системным или бизнес-аналитиком в IT, либо руководите командой разработки, и вам хочется понять, как оценивать задачи и измерять эффективность работы аналитика, то этот выпуск для вас.
Вместе с Сергеем Кругловым, Chief Product Owner в компаниях ITECH и Vetsy, рассуждаем о том, какую ценность аналитик привносит в команду разработки и как оценивать его работу. Разбираем, какие KPI и метрики помогают отследить эффективность аналитика, и предлагаем практические советы по планированию и оценке задач.
Сайт эпизода:
https://getanalyst.ru/podcast/analyst-task-estimation-and-value
Telegram-канал сообщества:
https://t.me/getanalysts
Тайм-коды эпизода:
00:00 | Знакомство со спикером и его ролью Chief Product Owner (CPO) в проектах.
04:59 | Кто входит в состав типичной IT-команды.
07:41 | Как оценивать задачи на аналитику и исследовательские задачи.
11:37 | Делить ли оценку задачи по ролям или считать её как общую для всех? Кто отвечает за оценку.
17:37 | Почему сложно точно оценить задачи аналитика и что делать при неуверенности.
27:44 | Что делать, если задача выходит за рамки изначальной оценки в процессе разработки.
34:55 | Про детализацию постановок задач от аналитиков и документацию в стартапах.
39:09 | Подходы к оценке аналитических задач.
42:46 | Может ли аналитика занимать больше времени, чем разработка?
46:34 | Как оценить окупаемость аналитики и обосновать её бюджет. В чем ценность аналитики на проекте?
52:19 | KPI и метрики для оценки эффективности системного или бизнес-аналитика.
56:09 | Сколько аналитиков нужно в команде.
59:53 | Кейсы, когда аналитики сокращают время разработки за счёт хорошей проработки требований.
1:09:30 | Заключение: рекомендации по планированию разработки, оценке задач и эффективному управлению IT-командой.
Ведущая:
Екатерина Ананьева
Гости:
Сергей Круглов,
Chief Product Owner
ITECH ( https://itech-group.ru / https://t.me/itechgr )
Vetsy ( https://vetsy.ru / https://t.me/vetsy_ru )
Agile окружён мифами. Одни думают, что это хаос без плана и документации. Другие — что это волшебная палочка, которая решает все проблемы проекта. В этом выпуске разбираемся, что такое Agile на самом деле, и как системные аналитики работают в таких командах: без розовых очков, на практике, с акцентом на документацию, здравый смысл и реальные задачи.
Если вы начинающий системный аналитик или только делаете первые шаги в IT, этот эпизод поможет разобраться, что такое Agile (Scrum, Kanban) глазами системных аналитиков. Мы обсудим, как работают Agile-команды, в чём их особенности и что происходит внутри таких проектов.
А если вас раздражает фраза “документация не нужна”, вы не понимаете, зачем столько созвонов и почему это всё в Agile — этот выпуск также для вас, опытных аналитиков и IT-специалистов.
Погружаемся в реальную разработку и объясняем на практике, почему процессы влияют на стоимость, качество и гибкость продукта.
Важные цитаты:
“Agile — это набор принципов здравого смысла”
“Agile — это про бизнес”
Слушайте и расширяйте свою профессиональную экспертизу!
Статья к эпизоду:
https://getanalyst.ru/podcast/agile-and-documentation
Telegram-канал сообщества: https://t.me/getanalysts
Тайм-коды к эпизоду:
00:00 | Введение и актуальность темы.
02:27 | Опыт спикеров: что используют в реальной разработке.
05:21 | Agile — что это, история появления, решаемые проблемы.
17:17 | Почему «люди и взаимодействие важнее процессов»: как это работает в реальности.
21:07 | Документация в Agile не нужна? Про реальные подходы к ведению документации в Agile-командах и определение её ценности.
36:17 | Как аргументировать, что документация нужна? Самые важные советы для системных и бизнес-аналитиков.
39:56 | Ценности Agile о сотрудничестве с заказчиком и готовности к внезапным изменениям: отражение в проектной и продуктовой разработке.
51:12 | 12 принципов Agile о которых надо знать: как понять, что вы вписываетесь в Agile-команду и вас не уволят.
55:36 | Scrum Framework: что это, история появления, когда применяют, особенности и связь с Agile.
1:03:22 | Kanban Framework: что это, история появления, как работает и когда применяют, отличия от Scrum.
1:11:13 | Заключение.
Ведущая:
Екатерина Ананьева, основатель сообщества Системных аналитиков GetAnalyst
Гости:
Кристина Виноградова, Системный аналитик
Елена Киселева, Системный аналитик
Если вы уже работаете в IT и слышали о хранилищах данных (DWH), но никогда не сталкивались с ними вживую, этот выпуск подкаста для вас.
Мы делимся реальным опытом работы с DWH на крупных проектах: рассказываем про механизмы обмена данными, архитектуру, как выстраивается взаимодействие между аналитиками данных и системными / бизнес- аналитиками, какие процессы и коммуникации необходимы, и что может пойти не так.
Слушайте новый эпизод, чтобы перевести свои знания о DWH и BI-системах из разряда «теории» в категорию «я готов решать задачи на реальных проектах».
Сайт эпизода: https://getanalyst.ru/podcast/dwh-for-systems-analysts
Telegram-канал сообщества: https://t.me/getanalysts
Тайм-коды эпизода:
00:00 | Знакомство со спикером. Про старт карьеры аналитика данных.
03:20 | Нужно ли уметь программировать аналитику данных?
05:00 | DWH: что это и зачем нужно.
11:03 | Связь между DWH и BI-системами.
14:35 | Обсуждаем самописные BI-системы и готовые решения на рынке.
18:02 | PostgreSQL, MySQL, SQLite и другие СУБД, и как они связаны с DWH. MPP базы данных.
22:37 | Определение и сравнение OLTP- и OLAP-систем.
23:44 | Архитектура с BI-системами. Способы синхронизации данных в DWH. Использование Kafka.
29:22 | Системный аналитик и Аналитик данных: зоны ответственности и процессы в разработке.
38:19 | Взаимодействие между командами разработки основной системы и командой аналитики данных.
41:44 | Загрузка данных в DWH: проблемы, решения и оптимизация.
48:40 | Про несоблюдение обратной совместимости при работе с данными и БД.
53:00 | Рекомендации и пожелания для аналитиков, которые хотят лучше понимать BI-системы и DWH.
Ведущая:
Екатерина Ананьева
Гости:
Екатерина Колпакова,
Руководитель направления DWH и BI, EMEX
Рано или поздно системные аналитики сталкиваются с брокерами сообщений — такими как RabbitMQ и Apache Kafka. Эти технологии становятся неотъемлемой частью современной архитектуры систем.
Недавно мы выпустили 23-й эпизод подкаста про Kafka (https://getanalyst.ru/podcast/kafka-for-system-analysts), который вызвал много откликов. В продолжение этой темы — новый выпуск, в котором мы подробно разбираем брокер RabbitMQ: как он работает, когда применяется, и чем принципиально отличается от Kafka, чтобы вы могли уверенно выбирать решение под задачи проекта.
Этот выпуск будет полезен для опытных системных аналитиков, кто планирует работать в крупных IT-продуктах и проектах с распределенной архитектурой, и для всех, кто интересуется архитектурой систем и интеграциями через брокеры.
Сайт эпизода: https://getanalyst.ru/podcast/rabbitmq-vs-kafka
Тайм-коды эпизода:
00:00 | Введение. Про актуальность изучения брокеров для системных аналитиков.
3:00 | Сравнение механизмов обмена сообщениями через брокеры RabbitMQ и Kafka.
10:15 | RabbitMQ - базовое устройство, настройка, масштабируемость и поддержка.
15:01 | Чем отличается очередь в RabbitMQ от топика в Kafka?
23:38 | Потребление, приоритеты и удаление сообщений в RabbitMQ и Kafka.
26:27 | Общая сводка по отличиям между RabbitMQ и Kafka.
31:26 | Примеры использования RabbitMQ на проектах,в том числе совместно с Kafka.
37:15 | Что важно учитывать в постановке задачи для разработчиков на RabbitMQ.
44:55 | За отвечает системный аналитик при постановке задачи на RabbitMQ, а что находится в зоне ответственности архитекторов, DevOps и разработчиков.
47:24 | Подведение итогов и рекомендации.
Ведущая:
Екатерина Ананьева,
Основатель сообщества системных аналитиков GetAnalyst
Гость:
Яна Паршина,
Менеджер Системных аналитиков в X5 Tech
В этом эпизоде вы познакомитесь с актуальными AI-инструментами для системных аналитиков и получите практическое руководство по их применению в рабочих задачах: сравнение нейросетей, связки инструментов и особенности промпт-инжиниринга.
Ключевые нейросети в обзоре:
ChatGPT: https://chatgpt.com/
DeepSeek: https://www.deepseek.com/
Gemini: https://gemini.google.com
YandexGPT: https://alice.yandex.ru/
Эпизод основан на исследовании работы AI в “чистых” и обученных аккаунтах. Он будет полезен как опытным системным аналитикам, которые хотят убедиться, что используют нейросети по максимуму, так и новичкам, только начинающим путь в мир AI и желающим понять, с чего начать и как встроить нейросети в рабочие процессы.
Реальные кейсы, примеры и личный опыт.
Подкаст, который точно стоит послушать сегодня!
Статья к эпизоду с дополнительными материалами:
https://getanalyst.ru/podcast/ai-tools-for-systems-analysts
Telegram-канал сообщества СА и БА:
https://t.me/getanalysts
Часть 1. Общий обзор нейросетей
00:00 | Введение. Про начало эры нейросетей и почему тема искусственного интеллекта актуальна для системных аналитиков.
2:37 | Обзор и история появления ChatGPT и DeepSeek. Сравнение возможностей.
12:47 | Обзор Gemini AI от Google и YandexGPT. Сравнение возможностей.
15:44 | Для каких задач лучше всего подходит каждая из нейросетей. API для разработки собственных приложений. Стоимость и доступность для пользователей разных стран.
22:38 | Особенность, которая привела меня к использованию Gemini AI: почему я выбираю его для задач, где мне нужна проверенная информация.
Часть 2. Применение нейросетей для решения задач системных аналитиков
31:55 | Введение в тему использования нейросетей системными и бизнес-аналитиками.
32:57 | Разработка требований с использованием нейросетей. Рекомендации к формированию промптов (запросов).
43:26 | Анализ голоса и преобразование в структурированный текст. Личный опыт в помощи для рабочих задач. Дополнительные инструменты для анализа, поиска и генерации информации со встроенными возможностями AI.
49:43 | Создание UML диаграмм через нейросети.
54:57 | Создание BPMN диаграмм через нейросети.
59:36 | Визуализация информации и её структурирование: mind map, user story mapping и другие. Разработка презентаций.
01:01:04 | Диаграмма C4 для проектирования схем архитектуры.
01:03:49 | ER-диаграмма для описания БД на логическом и физическом уровнях. SQL-запросы к БД на основе загруженной ER-диаграммы.
1:12:22 | Проектирование API и требования к брокерам.
1:15:35 | Другие задачи аналитиков, с которыми могут помочь нейросети.
Ведущая подкаста:
Екатерина Ананьева,
основатель сообщества системных и бизнес-аналитиков GetAnalyst
Многие компании ожидают, что системные аналитики умеют работать с Kafka. Но с чего начать изучение этой технологии?
В этом эпизоде мы подробно разбираем устройство Kafka и ключевые особенности, которые важно понимать аналитикам.
Презентация к эпизоду: https://getanalyst.ru/podcast/kafka-for-system-analysts
Вы узнаете, что важно учитывать при постановке задач разработчикам, познакомитесь с принципами работы распределенной архитектуры и асинхронным взаимодействием сервисов внутри системы на примере подсистемы технической поддержки.
Этот выпуск будет полезен как опытным аналитикам, уже работающим с Kafka, так и тем, кто только планирует развиваться в этом направлении, чтобы начать работать на проектах с распределенной архитектурой.
00:00 | Введение. Почему знание Kafka может быть актуально для Системного аналитика.
03:37 | Знакомство с Kafka - базовое устройство, принцип работы и примеры использования.
05:26 | Возможно ли прямое подключение Frontend (мобильных, веб- и других) приложений к Kafka.
09:51 | Pull- и Push- модели взаимодействия консьюмеров с брокером.
11:17 | Почему выбирают Kafka, а не другие брокеры. Для решения каких задач она подходит лучше всего.
13:21 | Внутреннее устройство Kafka. Кто принимает решения в проекте за выделение топиков (тем) внутри брокера.
22:12 | Способы организации сообщений в Kafka (FIFO). Порядок чтения сообщений консьюмерами. Оффсеты (offset).
26:24 | Как понять, когда сообщение можно удалять из брокера. И про вечное хранение сообщений в брокере.
28:49 | Current offset. Log-start offset. Log-end offset.
30:09 | Из чего состоят сообщения, передаваемые в брокер Kafka.
31:58 | Сравнение Kafka и RabbitMQ. Что выбрать?
35:36 | Что нужно знать Системному аналитику про Kafka, чтобы начать работать с постановками задач. Шаблон постановки задачи.
40:05 | Инструменты для работы с Kafka.
41:45 | Подведение итогов и рекомендации для аналитиков.
Ведущая:
Екатерина Ананьева
Гости:
Елизавета Акманова,
Старший системный аналитик в компании UseTech
В этом эпизоде подкаста мы разбираем 13 типичных ошибок при использовании нотации BPMN на примере задачи, которую может получить на собеседовании Системный или Бизнес-аналитик.
Статья к эпизоду: https://getanalyst.ru/podcast/bpmn-top-mistakes
Вы наглядно познакомитесь со списком ошибок, которые чаще всего допускают специалисты, а также получите рекомендации по их исправлению и полезные материалы, которые помогут в работе с нотацией.
Эпизод будет полезен как начинающим, так и опытным аналитикам, стремящимся улучшить свои навыки в создании BPMN-диаграмм для описания бизнес-процессов.
00:00 | Введение. Зачем нотация BPMN нужна системным аналитикам и в разработке в целом?
06:12 | Ключевые элементы нотации BPMN.
07:54 | Инструменты для создания BPMN-диаграмм.
11:34 | Знакомство с бизнес-процессом. Обзор BPMN-диаграммы процесса с ошибкой.
15:50 | Группы ошибок в BPMN, которые можно выделить.
17:24 | Элементы не из BPMN.
18:52 | Процесс сверху-вниз или “змейка”.
19:50 | Неверные события.
20:45 | Неверные шлюзы.
23:02 | Неверные потоки.
24:17 | Текст вместо элементов диаграммы.
27:02 | Неверные символы для действий / задач.
30:05 | Все события завершаются в одном.
31:53 | Отсутствие начального и/или конечного событий.
32:47 | Много стрелок из/в задачи.
36:01 | Дорожки или развернутые пулы.
39:28 | Одна задача для множественной логики.
41:10 | Задачи “передать - получить” информацию.
42:09 | Обзор итоговой диаграммы.
43:13 | Подведение итогов и рекомендации по самостоятельному изучению BPMN.
Ведущая:
Екатерина Ананьева
Гость:
Яна Паршина,
Менеджер Системных аналитиков в X5 Tech
Подкаст сообщества системных аналитиков GetAnalyst.
В этом эпизоде мы разбираемся, как работает авторизация в API: какие шаги она включает, виды авторизации и что нужно описывать в требованиях разработчикам.
Эпизод будет полезен системным аналитикам, кто работает с Backend, API и интеграциями, а также тем, кто только начинает осваивать эту область. Кроме того, он станет отличным ресурсом для подготовки к собеседованиям, помогая освежить теоретические знания и понять практические аспекты безопасности в API.
Статья к эпизоду: https://getanalyst.ru/podcast/api-authorization
Сообщество GetAnalyst: https://t.me/getanalysts
00:19 - Когда системный аналитик встречается со сценариями авторизации в системе.
2:51 - Предварительные шаги процесса авторизации: идентификация и аутентификация.
8:19 - Секретный ключ для работы с API - Token для подписания запросов.
9:23 - Понятие авторизации запросов к API.
14:25 - Постановки задач на разработчиков, связанные с авторизацией пользователей в системе.
15:53 - Задачи на авторизацию при проектировании собственного API, например - REST API.
24:12 - Задачи на авторизацию при проектировании интеграций с внешними системами. Особенности процесса авторизации для приложений и пользователей.
24:12 - Задачи на авторизацию при проектировании интеграций с внешними системами. Особенности процесса авторизации для приложений и пользователей.
34:20 - Способы авторизации в API. API-key.
40:26 - Basic Authorization
45:22 - Bearer Token
48:47 - JWT Token (JSON Web Token)
50:00 - OAuth 2.0
55:54 - Подведение итогов и рекомендации.
Ведущая:
Екатерина Ананьева,
основатель сообщества GetAnalyst
В эпизоде разбираем одну из самых популярных задач для собеседования на системного аналитика: проектирование БД, ER-диаграмма и связь “многие ко-многим”.
Эпизод будет полезен для всех начинающих и опытных системных аналитиков, у кого мало опыта в создании ER-диаграмм с нуля.
При прослушивании эпизода обязательно держите открытой статью со схемами и картинками к нему:
https://getanalyst.ru/podcast/database-er-diagram-interview
Рекомендуется перейти в любой видео-источник и смотреть подкаст с видео к нему.
Введение
00:18 - Про актуальность задачи проектирования БД и работы с ER-диаграммами системных аналитиков. Draw.io для создания ER-диаграмм.
Этап 1. Создание каркаса ER-диаграммы
05:00 - Первые шаги в создании ER-диаграммы - сущности и свойства. СУБД PostgreSQL для определения типов данных.
14:33 - Внешние ключи (FK - Foreign Key). Установка связей между таблицами по id сущностей.
15:50 - Структурирование данных при хранение в БД (Адрес + ФИО аналогично).
Этап 2. Представление ER-диаграммы в виде таблиц EXCEL
19:29 - Представление данных в EXCEL: как таблицы в ER-диаграмме связаны с реальным хранением данных.
26:02 - Как найти связь “многие-ко-многим” и избавиться от неё. Зачем убирать связь “многие-ко-многим”.
Этап 3. ER-диаграмма после добавления промежуточной таблицы, чтобы убрать связь "многие-ко-многим"
31:09 - Промежуточная таблица для связи “многие-ко-многим”: как её добавить и что происходит с кратностями и внешними ключами.
38:27 - Исторические данные в БД с классическим примером по Интернет-магазину.
Разбор дополнительных задач, чтобы “набить руку”
40:19 - Почему задача важна и как её могут непредсказуемо усложнять и развивать в процессе.
41:51 - Пример простой задачи по медицинской системе.
44:36 - Усложненная задача по агентству недвижимости.
52:59 - Подведение итогов и рекомендации.
Ведущая:
Екатерина Ананьева
В этом эпизоде мы рассказываем об архитектуре систем, а именно о двух мощных инструментах, которые могут существенно изменить подход системного аналитика к проектированию сложных систем: Domain Driven Design (DDD) и Event Storming.
Мы обсудим, почему эти подходы становятся всё более популярными, как их правильно применять и каких ошибок стоит избегать. Вы узнаете, как Event Storming помогает разложить сложные процессы на отдельные события, почему это важно для проектирования архитектуры и как использовать эти инструменты в новых проектах и при пересмотре существующих решений.
Сайт эпизода с дополнительными материалами:
https://getanalyst.ru/podcast/ddd-event-storming
00:18 - Почему темы архитектуры, Domain Driven Design (DDD) и Event Storming становятся всё более актуальными для системных аналитиков.
3:50 - Знакомство с принципами проектирования архитектуры по DDD.
8:40 - Про подход Event Storming и о его пользе для выделения независимых частей системы - потенциальных микросервисов. Правила проведения.
14:32 - Кто участвует в Event Storming и как часто его проводят.
17:53 - Когда команда встречается с Event Storming и работает над выделением микросервисов. Про новые проекты и пересмотр архитектуры существующих.
22:58 - Микрофронтенды и применение Event Storming.
24:22 - Ошибки и проблемы в применении подхода DDD и Event Storming.
33:31 - Когда аналитик впервые знакомится в своём опыте с Event Storming, какой должен быть грейд.
35:40 - Про ситуацию из жизни, когда надо было перепроектировать работающие микросервисы заново.
45:48 - Подведение итогов и рекомендации для слушателей.
Ведущая:
Екатерина Ананьева,
Основатель сообщества Системных аналитиков GetAnalyst
Гость:
Яна Паршина,
Менеджер Системных аналитиков в X5 Tech
Работаете с задачами на Backend, проектируете методы REST API или описываете интеграции? Этот эпизод актуален для вас. В нём мы разберём, что такое версионирование API, когда и почему нужно вводить новые версии, какие подходы к версионированию лучше использовать и как это влияет на его пользователей.
Эпизод будет полезен системным аналитикам, которые работают с интеграциями, разрабатывают контракты методов API и сталкиваются с задачами изменения существующих API. Особенно это актуально в задачах на проектирование REST API методов.
Сообщество системных аналитиков GetAnalyst: t.me/getanalysts
Сайт эпизода: https://getanalyst.ru/podcast/api-versioning
00:19 - Знакомство со спикером и актуальность темы версионирования API.
03:05 - Что включает понятие версионирования API. Обратная совместимость в API.
7:55 - Сколько версий API могут работать одновременно.
8:59 - Как долго занимает переход с одной версии API на другую. Как правильно выводить из эксплуатации устаревшие версии API.
11:51 - Разработка контрактов REST API системными аналитиками: OpenAPI, Swagger, GitHub, Postman, Confluence.
14:51 - Проблемы тестирования и инфраструктуры при наличии нескольких активных версий API. Информирование клиентов об изменениях в API.
20:20 - Реализация версий в API и что об этом надо знать системному аналитику. Где указывать версию и в каком формате.
30:20 - Переход клиентских приложений на новые версии API. Проблемы и решения.
41:15 - Как отслеживать количество пользователей, использующих устаревшие версии API.
44:46 - Итоги эпизода и практические рекомендации.
Ведущая:
Екатерина Ананьева
Гости:
Елизавета Акманова,
Старший системный аналитик в компании UseTech
В этом эпизоде мы разберём каждую диаграмму, которую могут использовать в своей работе системные аналитики: что она из себя представляет, когда её применять и с помощью каких инструментов создавать.
Обсудим, стоит ли строго следовать правилам нотаций моделирования, или можно отклоняться от них и создавать свои схемы.
Если вы только начинаете свой путь в системном анализе или уже работаете в этой сфере, этот выпуск будет полезен, чтобы улучшить навыки визуализации и понять, какие диаграммы действительно работают.
Статья к эпизоду с дополнительными материалами:
https://getanalyst.ru/podcast/diagrams
00:18 - Актуальность использования диаграмм в разработке и проектировании систем.
02:38 - Основные диаграммы, используемые на практике системными аналитиками.
06:07 - UML Sequence - диаграмма последовательности.
13:47 - UML Activity - диаграмма деятельности.
16:34 - UML классов и ее применение в реальной работе системным аналитиком.
21:34 - ER-диаграмма реляционной базы данных.
30:20 - SysML Requirement Diagram (Диаграмма требований): для тех, кто работает с IoT, роботами, беспилотниками и не только.
35:18 - Data Flow Diagram (DFD) - Диаграмма Потоков Данных.
38:54 - Диаграмма С4 для проектирования архитектуры, её уровни и их полезность.
49:37 - BPMN-диаграмма для системных аналитиков, и “когда есть Camunda”.
55:01 - Mind Map, CJM (Customer Journey Mapping), User Story Mapping, SysML диаграмма обзора взаимодействия.
1:04:20 - UML Диаграмма состояний.
1:06:35 - ТОП диаграмм для системного аналитика.
1:08:39 - Соблюдение нотаций моделирования в диаграммах - нужно ли?
1:12:37 - Всегда ли нужны диаграммы и какие нужно знать для подготовки к собеседованию на системного аналитика.
1:19:57 - Подведение итогов и рекомендации для коллег.
Ведущая:
Екатерина Ананьева,
Основатель сообщества Системных аналитиков GetAnalyst
Гость:
Яна Паршина,
Менеджер Системных аналитиков в X5 Tech
Если вы уже работаете с проектированием баз данных и не используете, либо забыли про нормальные формы, или только начинаете их изучать тему, то этот эпизод для вас!
Он посвящен основам проектирования реляционных баз данных, а именно — нормальным формам: что это, сколько их, и как они помогают улучшить структуру базы данных.
Этот выпуск отлично подойдет как для общего развития, так и для подготовки к собеседованиям.
Мы начнем с объяснения, что такое реляционная база данных, а затем шаг за шагом разберем процесс её нормализации. На простых примерах вы увидите, как выглядит таблица “до” и “после” применения каждой нормальной формы.
Статья к подкасту и видео эпизода:
https://getanalyst.ru/podcast/database-normal-forms
Рекомендации:
Книга Д. Осипова “Технологии проектирования баз данных”
Книга К. Дейта “Введение в системы баз данных”
Статья “Нормализация отношений. Шесть нормальных форм”
0:18 - О практическом применении нормальных форм БД в работе
02:16 - Термины и определения связанные с реляционными базами данных
07:36 - Определение нормальной формы для базы данных, когда они нужны и какой пример будем разбирать в подкасте
11:49 - 1НФ (первая нормальная форма)
15:09 - 2НФ (вторая нормальная форма)
19:49 - 3НФ (третья нормальная форма)
27:30 - НФБК (нормальная форма Бойса-Кодда)
29:56 - 4НФ (четвертая нормальная форма)
33:31 - 5НФ (пятая нормальная форма)
36:35 - ДКНФ (доменно-ключевая нормальная форма)
39:05 - 6НФ (шестая нормальная форма)
42:00 - Выводы и рекомендации
Каналы подкаста и сообщества:
https://t.me/getanalysts
https://t.me/kateit