Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Event Sourcing: что это и зачем его знать системному аналитику?
Салют! Сегодня разберём Event Sourcing (ES) — важный паттерн проектирования, который стоит понимать каждому системному аналитику, а иногда и бизнес-аналитику, если он связан с больше с ИТ частью.
#архитектура | BA|SA
🔍 Что такое Event Sourcing?
Event Sourcing — это подход, при котором состояние системы определяется последовательностью событий (events), а не просто последними исходными данными.
🔹 Простой пример
Представьте банковский счёт:
- В традиционной системе хранится только текущий баланс (например, `1000₽`).
- В Event Sourcing хранятся все события:
Если вдруг произошла ошибка, можно пересчитать баланс с нуля, просто "проиграв" все события.
🎯 Зачем это системному аналитику?
1. Точность данных – можно восстановить состояние на любой момент времени.
2. Аудит и откат изменений – все действия записаны, можно анализировать, кто и что сделал.
3. Гибкость – можно создавать новые отчёты и аналитику на основе истории событий.
4. Поддержка сложных сценариев – полезно в микросервисах, финансах, логистике, игровых системах.
📌 Ключевые аспекты Event Sourcing
✅ События (Events) – неизменяемые записи о том, что произошло.
✅ Event Store – база, где хранятся все события.
✅ Проекции (Projections) – представления данных, которые строятся из событий (например, текущий баланс).
✅ Реиграция (Replay) – возможность "переиграть" события для восстановления состояния.
Часто Event Sourcing используют вместе с CQRS (Command Query Responsibility Segregation) – это когда запись и чтение данных разделены.
📚 Полезные материалы
- Знакомимся с Event Sourcing. Часть 1 – основы ES.
- Prostore — простой Event sourcing + CQRS фреймворк – практический пример.
- Гайд по эвент-сорсингу – разбор паттерна.
- Применение CQRS и Event Sourcing в микросервисах – как это работает в распределённых системах.
- Server-Sent Events: пример использования – про push-уведомления в вебе.
- Обновление состояния через SSE без затей – как использовать события в реальном времени.
💡 Вместо вывода
Event Sourcing – мощный инструмент для систем, где важна полная история изменений. Если вы аналитик в fintech, e-commerce или сложных enterprise-системах – понимание ES поможет проектировать более надёжные и прозрачные решения.
Источник: @ba_and_sa
Салют! Сегодня разберём Event Sourcing (ES) — важный паттерн проектирования, который стоит понимать каждому системному аналитику, а иногда и бизнес-аналитику, если он связан с больше с ИТ частью.
#архитектура | BA|SA
Event Sourcing — это подход, при котором состояние системы определяется последовательностью событий (events), а не просто последними исходными данными.
🔹 Простой пример
Представьте банковский счёт:
- В традиционной системе хранится только текущий баланс (например, `1000₽`).
- В Event Sourcing хранятся все события:
-Счёт открыт (+0₽)
-Начислено +500₽→ баланс500₽
-Списано -200₽→ баланс300₽
-Начислено +700₽→ баланс1000₽
Если вдруг произошла ошибка, можно пересчитать баланс с нуля, просто "проиграв" все события.
1. Точность данных – можно восстановить состояние на любой момент времени.
2. Аудит и откат изменений – все действия записаны, можно анализировать, кто и что сделал.
3. Гибкость – можно создавать новые отчёты и аналитику на основе истории событий.
4. Поддержка сложных сценариев – полезно в микросервисах, финансах, логистике, игровых системах.
✅ События (Events) – неизменяемые записи о том, что произошло.
✅ Event Store – база, где хранятся все события.
✅ Проекции (Projections) – представления данных, которые строятся из событий (например, текущий баланс).
✅ Реиграция (Replay) – возможность "переиграть" события для восстановления состояния.
Часто Event Sourcing используют вместе с CQRS (Command Query Responsibility Segregation) – это когда запись и чтение данных разделены.
📚 Полезные материалы
- Знакомимся с Event Sourcing. Часть 1 – основы ES.
- Prostore — простой Event sourcing + CQRS фреймворк – практический пример.
- Гайд по эвент-сорсингу – разбор паттерна.
- Применение CQRS и Event Sourcing в микросервисах – как это работает в распределённых системах.
- Server-Sent Events: пример использования – про push-уведомления в вебе.
- Обновление состояния через SSE без затей – как использовать события в реальном времени.
Event Sourcing – мощный инструмент для систем, где важна полная история изменений. Если вы аналитик в fintech, e-commerce или сложных enterprise-системах – понимание ES поможет проектировать более надёжные и прозрачные решения.
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥4👌3❤2
Салют! Сегодня продолжаем мой «мини курс» для системных аналитиков!
В прошлый раз рассмотрели:
1. Введение в системный анализ
Сегодня у нас:
2️⃣ Выявление требований
#курс | @ba_and_sa
____________
Для закрепления:
Сбор требований — это основа успеха любого проекта. Ошибки на этом этапе могут привести к переделкам, срыву сроков и недовольству заказчика.
🚀 Для начала начните с подготовки:
Перед встречей с заказчиком:
- Изучите контекст. Узнайте, чем занимается компания, какие у нее бизнес-цели, кто конкуренты. Почитайте документацию, если она есть (например, ТЗ прошлых проектов)
- Определите стейкхолдеров. Кто принимает решения? Кто будет пользоваться системой? Не упустите ни одну группу: менеджеры, конечные пользователи, технические специалисты
- Сформулируйте гипотезы. Запишите свои предположения о потребностях заказчика — это поможет задавать точные вопросы.
📋 Техники сбора требований
Используйте комбинацию методов:
- Интервью.
Задавайте открытые вопросы: «Расскажите, как сейчас проходит процесс X», избегайте наводящих вопросов: «Вам же нужна автоматизация, верно?»
- Воркшопы. Совместное обсуждение с использованием доски (физической или цифровой) помогает визуализировать требования.
- Наблюдение. Посмотрите, как пользователи работают в текущей системе — это выявит неочевидные проблемы.
- Прототипы. Эскизы интерфейсов или схемы процессов помогут заказчику конкретизировать пожелания.
✅ Как готовиться к интервью
- Составьте чек-лист вопросов, но будьте готовы отклониться от него. Примеры:
▫️ «Что вас не устраивает в текущем процессе?»
▫️ «Какие ограничения (бюджет, сроки, технологии) важно учесть?»
- Используйте технику «5 почему». Если заказчик говорит: «Нам нужна кнопка здесь», спросите: «Почему это важно?», пока не докопаетесь до корневой потребности.
- Записывайте всё. Используйте диктофон (с разрешения!) или конспектируйте ключевые тезисы.
📑 Документирование требований
📎 Статья: Стандарты и шаблоны для ТЗ на разработку ПО
- Структурируйте информацию. Разделяйте требования на:
- Функциональные (что система должна делать).
- Нефункциональные (производительность, безопасность, удобство).
- Ограничения (сроки, бюджет, законодательство).
- Используйте шаблоны. Например, User Stories (*«Как [роль], я хочу [действие], чтобы [цель]»*) или Use Case-диаграммы.
- Проверяйте требования на SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.
❗️ Чего делать НЕ стоит
- Не додумывайте за заказчика. Если что-то непонятно — переспрашивайте.
- Не игнорируйте конфликтующие требования. Если мнения стейкхолдеров расходятся, зафиксируйте это и обсудите приоритеты.
- Не используйте технический жаргон. Говорите на языке заказчика.
- Не спешите. Лучше потратить время на уточнение, чем переделывать готовый функционал.
✅ Проверка и согласование
- Проведите ревью. Убедитесь, что требования:
- Полные (охватывают все сценарии).
- Непротиворечивые.
- Тестируемые (можно проверить результат).
- Утвердите документ. Подпись заказчика формализует договоренности и снижает риски.
____
Советы из личного опыта
- Всегда спрашивайте: «Что будет, если этого НЕ сделать?» — это помогает отсечь «хотелки» от критически важных требований.
- Добавляйте примеры из реальной жизни в документацию («Для заказа клиент заполняет форму, как на Рис. 1»).
- Используйте инструменты: Jira, Confluence, Miro, Draw.io — они упрощают визуализацию и совместную работу.
Финальный лайфхак: Требования меняются. Заложите в процесс регулярные встречи для актуализации документации и будьте готовы к итерациям.
Источник: @ba_and_sa
В прошлый раз рассмотрели:
1. Введение в системный анализ
Сегодня у нас:
#курс | @ba_and_sa
____________
Для закрепления:
Сбор требований — это основа успеха любого проекта. Ошибки на этом этапе могут привести к переделкам, срыву сроков и недовольству заказчика.
Перед встречей с заказчиком:
- Изучите контекст. Узнайте, чем занимается компания, какие у нее бизнес-цели, кто конкуренты. Почитайте документацию, если она есть (например, ТЗ прошлых проектов)
- Определите стейкхолдеров. Кто принимает решения? Кто будет пользоваться системой? Не упустите ни одну группу: менеджеры, конечные пользователи, технические специалисты
- Сформулируйте гипотезы. Запишите свои предположения о потребностях заказчика — это поможет задавать точные вопросы.
📋 Техники сбора требований
Используйте комбинацию методов:
- Интервью.
Задавайте открытые вопросы: «Расскажите, как сейчас проходит процесс X», избегайте наводящих вопросов: «Вам же нужна автоматизация, верно?»
- Воркшопы. Совместное обсуждение с использованием доски (физической или цифровой) помогает визуализировать требования.
- Наблюдение. Посмотрите, как пользователи работают в текущей системе — это выявит неочевидные проблемы.
- Прототипы. Эскизы интерфейсов или схемы процессов помогут заказчику конкретизировать пожелания.
- Составьте чек-лист вопросов, но будьте готовы отклониться от него. Примеры:
▫️ «Что вас не устраивает в текущем процессе?»
▫️ «Какие ограничения (бюджет, сроки, технологии) важно учесть?»
- Используйте технику «5 почему». Если заказчик говорит: «Нам нужна кнопка здесь», спросите: «Почему это важно?», пока не докопаетесь до корневой потребности.
- Записывайте всё. Используйте диктофон (с разрешения!) или конспектируйте ключевые тезисы.
📑 Документирование требований
- Структурируйте информацию. Разделяйте требования на:
- Функциональные (что система должна делать).
- Нефункциональные (производительность, безопасность, удобство).
- Ограничения (сроки, бюджет, законодательство).
- Используйте шаблоны. Например, User Stories (*«Как [роль], я хочу [действие], чтобы [цель]»*) или Use Case-диаграммы.
- Проверяйте требования на SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.
- Не додумывайте за заказчика. Если что-то непонятно — переспрашивайте.
- Не игнорируйте конфликтующие требования. Если мнения стейкхолдеров расходятся, зафиксируйте это и обсудите приоритеты.
- Не используйте технический жаргон. Говорите на языке заказчика.
- Не спешите. Лучше потратить время на уточнение, чем переделывать готовый функционал.
- Проведите ревью. Убедитесь, что требования:
- Полные (охватывают все сценарии).
- Непротиворечивые.
- Тестируемые (можно проверить результат).
- Утвердите документ. Подпись заказчика формализует договоренности и снижает риски.
____
Советы из личного опыта
- Всегда спрашивайте: «Что будет, если этого НЕ сделать?» — это помогает отсечь «хотелки» от критически важных требований.
- Добавляйте примеры из реальной жизни в документацию («Для заказа клиент заполняет форму, как на Рис. 1»).
- Используйте инструменты: Jira, Confluence, Miro, Draw.io — они упрощают визуализацию и совместную работу.
Финальный лайфхак: Требования меняются. Заложите в процесс регулярные встречи для актуализации документации и будьте готовы к итерациям.
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍33🔥14❤5👏3
Салют! Вчера выложила пост про 2 часть своего «мини курса», где описала процесс сбора требований.
Кто-то может сказать «зачем в курсе для Системных аналитиков темы про требования и составления ТЗ в части бизнес-целей, моделирования БП и тд», но исходя из своего личного опыта, системный аналитик тоже сталкивается с требованиями (сбор, анализ, моделирование, управление, и тд). Но думаю на этом мы закончим изучение бизнесовой части и в след раз уже перейдем к технологической части, и будем более детально рассматривать системные части нашей профессии))
Если есть вопросы/возражения, делитесь в комментариях и оставляйте реакции, если ждете продолжение😉
Также чуть позже поделюсь с вами своими шпаргалками и шаблонами по документации, которыми сама пользуюсь на проекте))
Кто-то может сказать «зачем в курсе для Системных аналитиков темы про требования и составления ТЗ в части бизнес-целей, моделирования БП и тд», но исходя из своего личного опыта, системный аналитик тоже сталкивается с требованиями (сбор, анализ, моделирование, управление, и тд). Но думаю на этом мы закончим изучение бизнесовой части и в след раз уже перейдем к технологической части, и будем более детально рассматривать системные части нашей профессии))
Если есть вопросы/возражения, делитесь в комментариях и оставляйте реакции, если ждете продолжение
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17👍8💯4
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥2🥰2
Please open Telegram to view this post
VIEW IN TELEGRAM
🥱5❤3🔥2
А как вы думаете, заменит ли ИИ аналитиков? Или что нам ждать от этой штуки? Может мы станем хорошими напарниками?
Давайте немного разберемся
1. Что ИИ уже умеет делать вместо аналитика?
✅ Автоматизация рутины – сбор требований, анализ данных, генерация документации.
✅ Обработка больших данных – быстрее человека находит паттерны и аномалии.
✅ Генерация отчётов и диаграмм – ChatGPT, Copilot, Power BI с ИИ уже помогают.
✅ Предсказательная аналитика – прогнозирует риски на основе исторических данных.
2. Что ИИ пока не может заменить?
❌ Глубокий контекст и переговоры – ИИ не чувствует скрытые мотивы стейкхолдеров.
❌ Креативное решение проблем – не может придумать неочевидное решение, как человек.
❌ Эмпатия и soft skills – не убедит директора выделить бюджет или уладить конфликт в команде.
❌ Ответственность за решения – ИИ не подпишет ТЗ и не понесёт последствия за ошибку.
3. Полная замена или помощник?
🔹 Скорее помощник (как калькулятор для бухгалтера).
🔹 Часть задач уйдёт – например, ручной сбор требований или анализ логов.
🔹 Но появится спрос на новые навыки – умение работать с ИИ, интерпретировать его выводы, принимать финальные решения.
4. Кого заменит, а кого нет?
✔ Рискуют аналитики, которые только "переливают воду" в документации.
❌ Не рискуют те, кто умеет:
- Вести переговоры,
- Понимать бизнес-контекст,
- Принимать нестандартные решения.
____________
Вывод по моему мнению:
ИИ не заменит системных и бизнес-аналитиков, но:
- Слабых специалистов – вытеснит,
- Сильных – сделает в разы продуктивнее.
Совет: осваивай Prompt Engineering, учись задавать ИИ правильные вопросы – и будешь востребованным специалистом. 😉
Как думаешь, какие навыки аналитика ИИ пока не сможет повторить?
Давайте немного разберемся
1. Что ИИ уже умеет делать вместо аналитика?
2. Что ИИ пока не может заменить?
3. Полная замена или помощник?
🔹 Скорее помощник (как калькулятор для бухгалтера).
🔹 Часть задач уйдёт – например, ручной сбор требований или анализ логов.
🔹 Но появится спрос на новые навыки – умение работать с ИИ, интерпретировать его выводы, принимать финальные решения.
4. Кого заменит, а кого нет?
✔ Рискуют аналитики, которые только "переливают воду" в документации.
❌ Не рискуют те, кто умеет:
- Вести переговоры,
- Понимать бизнес-контекст,
- Принимать нестандартные решения.
____________
Вывод по моему мнению:
ИИ не заменит системных и бизнес-аналитиков, но:
- Слабых специалистов – вытеснит,
- Сильных – сделает в разы продуктивнее.
Совет: осваивай Prompt Engineering, учись задавать ИИ правильные вопросы – и будешь востребованным специалистом. 😉
Как думаешь, какие навыки аналитика ИИ пока не сможет повторить?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍2
Forwarded from Analyst IT
SMART, INVEST, MoSCoW – простыми словами для новичков (с моих уст) 😏
Эти три методики помогают правильно ставить цели, разбивать задачи и расставлять приоритеты в разработке продуктов (и не только).
1️⃣ SMART – как ставить понятные цели
Используется, когда нужно сформулировать конкретную, измеримую и достижимую цель.
Расшифровка:
- S (Specific) – Конкретная:
Не "улучшить продукт", а "увеличить скорость загрузки страницы на 20%"
- M (Measurable) – Измеримая:
Должны быть цифры: "привлечь 1000 новых пользователей"
- A (Achievable) – Достижимая:
Не "сделать самый популярный сервис в мире", а "выйти в топ-3 в своём регионе"
- R (Relevant) – Релевантная:
Цель должна быть важна для бизнеса, а не просто "хотелка"
- T (Time-bound) – Ограниченная по времени:
"до конца квартала"
Пример SMART-цели:
❌ Плохо: "Сделать удобный интерфейс".
✅ Хорошо: "Увеличить конверсию оформления заказа с 5% до 8% к 1 декабря за счёт упрощения формы оплаты".
Когда использовать?
✔ Постановка KPI, планирование проектов, личные цели.
_______________
2️⃣ INVEST – как писать хорошие пользовательские истории (User Stories)
Нужен, чтобы задачи в бэклоге были независимыми, ценными и тестируемыми.
Расшифровка:
- I (Independent) – Независимая (можно реализовать без других задач)
- N (Negotiable) – Обсуждаемая (не жёсткое ТЗ, а договорённость с заказчиком)
- V (Valuable) – Ценная (должна приносить пользу пользователю или бизнесу)
- E (Estimable) – Оцениваемая (можно понять, сколько времени займёт)
- S (Small) – Небольшая (чтобы сделать за 1-2 спринта)
- T (Testable) – Тестируемая (есть чёткие критерии выполнения).
Пример INVEST-истории:
❌ Плохо: "Сделать личный кабинет".
✅ Хорошо: "Как пользователь, я хочу видеть историю заказов в личном кабинете, чтобы отслеживать статус доставки".
Когда использовать?
✔ Agile-разработка, Scrum, написание бэклога.
______________
3️⃣ MoSCoW – как расставить приоритеты
Помогает решить, без чего нельзя обойтись, а что можно отложить.
Категории:
- M (Must have) – Обязательно (без этого продукт не работает)
- S (Should have) – Важно, но не критично (можно без этого запуститься)
- C (Could have) – Было бы хорошо (если останется время)
- W (Won’t have) – Не будем делать (по крайней мере сейчас)
Пример MoSCoW-приоритизации для интернет-магазина:
- Must have: Корзина, оплата, каталог товаров.
- Should have: Поиск по сайту.
- Could have: Рекомендации товаров.
- Won’t have: Виртуальная примерочная.
Когда использовать?
✔ Планирование спринтов, MVP, управление требованиями.
_________________
Вывод:
- Хочешь чёткую цель? → SMART.
- Нужно разбить задачу на части? → INVEST.
- Не знаешь, что делать в первую очередь? → MoSCoW.
Источник: @analysis_it
Теперь ты сможешь объяснить их даже бабушке! 😉
Эти три методики помогают правильно ставить цели, разбивать задачи и расставлять приоритеты в разработке продуктов (и не только).
Используется, когда нужно сформулировать конкретную, измеримую и достижимую цель.
Расшифровка:
- S (Specific) – Конкретная:
Не "улучшить продукт", а "увеличить скорость загрузки страницы на 20%"
- M (Measurable) – Измеримая:
Должны быть цифры: "привлечь 1000 новых пользователей"
- A (Achievable) – Достижимая:
Не "сделать самый популярный сервис в мире", а "выйти в топ-3 в своём регионе"
- R (Relevant) – Релевантная:
Цель должна быть важна для бизнеса, а не просто "хотелка"
- T (Time-bound) – Ограниченная по времени:
"до конца квартала"
Пример SMART-цели:
Когда использовать?
✔ Постановка KPI, планирование проектов, личные цели.
_______________
Нужен, чтобы задачи в бэклоге были независимыми, ценными и тестируемыми.
Расшифровка:
- I (Independent) – Независимая (можно реализовать без других задач)
- N (Negotiable) – Обсуждаемая (не жёсткое ТЗ, а договорённость с заказчиком)
- V (Valuable) – Ценная (должна приносить пользу пользователю или бизнесу)
- E (Estimable) – Оцениваемая (можно понять, сколько времени займёт)
- S (Small) – Небольшая (чтобы сделать за 1-2 спринта)
- T (Testable) – Тестируемая (есть чёткие критерии выполнения).
Пример INVEST-истории:
Когда использовать?
✔ Agile-разработка, Scrum, написание бэклога.
______________
Помогает решить, без чего нельзя обойтись, а что можно отложить.
Категории:
- M (Must have) – Обязательно (без этого продукт не работает)
- S (Should have) – Важно, но не критично (можно без этого запуститься)
- C (Could have) – Было бы хорошо (если останется время)
- W (Won’t have) – Не будем делать (по крайней мере сейчас)
Пример MoSCoW-приоритизации для интернет-магазина:
- Must have: Корзина, оплата, каталог товаров.
- Should have: Поиск по сайту.
- Could have: Рекомендации товаров.
- Won’t have: Виртуальная примерочная.
Когда использовать?
✔ Планирование спринтов, MVP, управление требованиями.
_________________
Вывод:
- Хочешь чёткую цель? → SMART.
- Нужно разбить задачу на части? → INVEST.
- Не знаешь, что делать в первую очередь? → MoSCoW.
Источник: @analysis_it
Теперь ты сможешь объяснить их даже бабушке! 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
👏16👍8🔥8❤4💯2
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7