Системный аналитик с нуля | Альбина Гараева

5 продуктов, которые закроют ваши главные пробелы

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

🔹 БД для системного аналитика

Разбираем проектирование баз данных, ER-диаграммы, нормализацию и SQL от основ до оконных функций. Видеоуроки с экспертом, практические задания и тесты помогут уверенно формулировать требования к данным, индексам и репликации.  

9 900 ₽ | Купить

🔹 Процессы в команде разработки

Раскрываем внутреннюю кухню IT-команд: как устроены Waterfall, Scrum, Kanban и их гибриды, где заканчивается discovery и начинается delivery, и какие инструменты действительно работают на результат. После урока вы будете точно знать свою роль, правила игры и как избегать хаоса на стыке бизнес-задач и разработки.  

1 000 ₽ | Купить

🔹 Тестирование взаимодействия систем (API) 

Закрываем пробел в понимании интеграций: роли QA и аналитика, виды тестов, документация и практика работы с Postman и Swagger. Разбираем, почему «200 OK» не гарантирует передачу данных, и учимся системно проверять API до попадания в прод, чтобы избежать плавающих багов и бесконечных разборов инцидентов.  

3 000 ₽ | Купить

🔹 Проектирование интерфейсов (UX/UI)

Вместе с UX/UI-дизайнером разбираем гештальт-принципы, когнитивные искажения, гайдлайны платформ и карту пути пользователя. Учимся работать с Figma, создавать осмысленные макеты и прописывать требования к состояниям экранов так, чтобы дизайнеры не додумывали, а разработчики не переделывали.  

 3 000 ₽ | Купить

🔹 Продуктовые метрики для аналитика 

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

1 000 ₽ | Купить

➡️ Доступ ко всем материалам остаётся навсегда. Если нужна помощь с выбором или остались вопросы, пишите @ginfotech_manager, разберу вашу ситуацию и подскажу, с чего лучше начать

Дорогие студенты, благодарю вас за ваши прекрасные #отзывы

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

«Курс понравился, отдельно отмечу работу куратора: со мной работала Лена, по-моему это самый лучший куратор, она и поддерживала, и объясняла. Лена, спасибо тебе за работу со мной! А еще круто, что есть демособеседование с Альбиной, т.к. не всегда есть возможность побеседовать с создателем курса, тем более с системным аналитиком. 
В процессе обучения мне понравилось, что было и легко, и сложно, и было много практики. Большие темы были разделены на подтемы. Понравилось, что нет жестких дедлайнов по сдаче работ.

Как результат, я могу составлять ТЗ, базово разбираюсь в фигме, есть понимание API и его проектирования. Планирую применять знания на практике, и думаю буду еще приходить к Альбине на консультацию. Спасибо Альбине и всей команде!»

Подробный отзыв можно посмотреть по ссылке  https://vk.com/video251822710_456239171  

Алия, благодарю за теплую обратную связь! И спасибо, что доверилась и выбрала меня в качестве учителя!

Желаю тебе успехов в работе! Пусть все сложные задачи решаются, а карьерный путь складывается так, как ты этого хочешь!

Чтобы вы перестали гадать и начали проектировать логику взаимодействия осознанно, я открываю доступ к материалам по проектированию интерфейсов!

Вместе с UX/UI-дизайнером Олегом Удаловым разберём не «как рисовать красиво», а как формулировать требования к интерфейсам, которые поймут дизайнер, разработчик и конечный пользователь.

Вас ждет:   
🎨 Урок 1. Знакомство с UX/UI
• Гештальт-принципы и когнитивные искажения: почему пользователи «не видят» ваши кнопки и как учесть это на этапе ТЗ  
• Гайдлайны iOS/Android: как учитывать платформенные ограничения до передачи в дизайн  
• Карта пути пользователя (User Journey): как связать бизнес-сценарий с экранами и состояниями  
• Работа с макетами в Figma: научитесь читать wireframes, проверять полноту состояний и создадите свой первый прототип  

🛠 Урок 2. А теперь порисуем
• Практическое занятие: создаём интерфейсы с нуля в Figma  
• Разбираем реальные кейсы!
• Учимся передавать требования так, чтобы дизайнер не додумывал, а разработчик не переделывал  

В комплекте: видеоуроки, презентация, тесты для самопроверки, а доступ остаётся навсегда!

🔥При этом стоимость всех материалов: 3 000 ₽

➡️Забрать курс: ссылка

Если остались вопросы, пишите @ginfotech_manager 

Надо ли системному аналитику разбираться в проектировании интерфейсов?

Не раз слышала от системных аналитиков: «Моя зона ответственности – данные, API, бизнес-логика. А как это будет выглядеть на экране, пусть дизайнер нарисует». По факту это одна из самых дорогих иллюзий в IT.

Когда требования отдаются без понимания UX/UI, запускается цепная реакция:
🔹 Дизайнер получает ТЗ в духе «пользователь вводит данные, система сохраняет». Без сценариев, без состояний, без обработки ошибок. Приходится додумывать.
🔹 Разработчик верстает форму по макету, но не понимает, как обрабатывать валидацию, блокировку кнопок или переходы между состояниями. Пишет, как видит.
🔹 Заказчик получает работающую фичу, которой никто не пользуется, потому что путь пользователя сломан на третьем шаге.
🔹 Итог: бесконечные правки, споры «кто виноват», срывы сроков и ощущение, что продукт кривой, хотя архитектура безупречна.

UX/UI – это на самом деле про предсказуемость поведения системы с точки зрения человека. Аналитик, который понимает основы интерфейсного взаимодействия, работает иначе:
→ Описывает не только что система делает, но и как пользователь это воспринимает.
→ Заранее прописывает состояния экранов: загрузка, успех, ошибка, пустое состояние, недоступность функции.
→ Ставит требования к валидации, навигации, мобильной адаптации и доступности до того, как дизайнер откроет Figma.
→ Говорит с командой на одном языке, потому что знает, что такое user flow, wireframe и почему лишняя галочка может убить конверсию.

Системный анализ без понимания UX/UI – это проектирование моста, по которому невозможно ходить. Логика может быть идеальной, но если пользователь не понимает, как ею воспользоваться, вся работа идёт в минус.

А как у вас: требования к интерфейсам фиксируются до дизайна или как получится? Делитесь в комментариях 👇

Вчера я писала о том, как незнание процессов превращает аналитика просто в создателя ТЗ, который теряет задачи и выгорает. Но что, если можно перестать гадать и наконец понять, как на самом деле работает IT-команда?

И сегодня я открываю доступ к уроку «Процессы в команде разработки», который закрывает именно этот пробел. Вместе с приглашённым экспертом, Ольгой Окуловой, мы раскроем внутреннюю кухню IT-проектов: как устроены процессы разработки, какие роли бывают в команде и как всё это управляется на практике.

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

Что внутри урока:  
• Где ваше место в структуре организации? И как это влияет на вашу работу?
• Waterfall, Agile, Scrum, Kanban или микс: перестанете путаться в терминах. Разберём, как работает каждый подход, почему в реальности 90% компаний используют гибриды, и как аналитику подстраиваться под любой процесс без стресса.  
• Инструменты, которые связывают команду: Jira, Confluence, Miro, Figma, Swagger, GitLab. Когда, зачем и как их использовать, чтобы задачи не терялись, а документация работала на вас.
• Практические правила работы в IT-команде: как изучать документацию (даже неполную), выстраивать отношения с коллегами, правильно задавать вопросы, проявлять инициативу и сохранять work-life balance в условиях спринтов и релизов.  
+ тест для самопроверки, а доступ останется навсегда!

🔥🔥При этом стоимость урока всего 1 000 ₽! 

➡️Забрать урок: ссылка

Если остались вопросы, пишите @ginfotech_manager 

«ТЗ готово, но задача не двигается»: почему аналитику критично понимать процессы разработки

Знакомая картина: вы пишете подробное ТЗ, согласовываете его с бизнесом, аккуратно оформляете в Confluence… а задача тихо висит в бэклоге три недели? Или вас зовут на ретроспективу, а вы сидите и думаете: «А что я тут должен говорить?». Или на дейли разработчик спрашивает: «А это в рамках текущего спринта или кидаем в бэклог?», а вы пожимаете плечами.

Спросите себя, а вы понимаете, как вообще работает команда? Где заканчивается дискавери и начинается деливери? Почему приоритеты меняются посреди итерации? Кто на самом деле принимает решение: скрам-мастер, продакт, тимлид или заказчик? Почему в Jira всё живёт по своим законам, а в голове у разработки по другим?

Процессы разработки – это не бюрократия, хотя иногда кажется именно так!
Процессы – это кровеносная система проекта. Если вы не знаете, как по ней течёт информация, ваши требования просто не дойдут до реализации в том виде, в котором вы их задумали. 

Аналитик без понимания процессов работает вслепую:

• Пишет идеальную спецификацию, но команда работает по канбану, и задача «тонет» в потоке операционки.  
• Приходит на планирование с готовыми Use Case, а команда оценивает риски и story points, и ваше ТЗ превращается в «историю», которую надо дробить.  
• Пытается наладить коммуникацию, но не знает, где проходит граница между аналитикой, QA и продактом, и начинает делать работу за всех, выгорая на ровном месте.  

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

И тут вас выручает знание процессов! Вы перестаёте «скидывать ТЗ в чат», так как: 
→ Понимаете, в каком формате и на каком этапе требование должно попасть к команде, чтобы его не переписали три раза.  
→ Видите, где процесс создаёт трение, и предлагаете решение, а не жалуетесь на сроки.  
→ Говорите с разработкой, тестировщиками и бизнесом на одном языке, потому что знаете правила игры.  

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

А вы знаете в чем различие скрама от канбана?

Самое ценное в создании образовательных продуктов – ваши #отзывы и искренняя обратная связь. 

Делюсь отзывом Регины – она работала бухгалтером и решила выучиться на системного аналитика:

«Я работаю бухгалтером, и системный аналитик – совершенно новая и неизвестная для меня профессия. На курсе мне было полезно всё. Мне очень понравилось, что курс структурированный, без воды, огромное количество информации, ненужного не было совсем: тема, выжимка по теме, тестирование, практика. Очень понравилась работа с куратором – тебе помогают, поддерживают, направляют. Это очень ценно. С практикой были сложности, но благодаря куратору все получилось, но куратор не подсказывал, а направлял тебя и твои мысли. 

Самое интересное, что после обучения сейчас на работе бухгалтером я даже по-другому начала думать, особенно в работе с отчетами, фильтрации данных и т.д. Раньше я многое собирала, выверяла «ручками», а сейчас думаю, как сделать удобнее и проще. Так что мозг я прокачала на все 100%. И несмотря на то, что изначально я решила изучить профессию для общего развития, то сейчас я намерена попробовать себя в этой роли и пройти стажировку.»

Полную версию отзыва можно посмотреть по ссылке: https://vk.com/video251822710_456239170 

Регина, благодарю за искренность и желаю удачи в новой профессии! 🚀

БД для системного аналитика

Знакомо ли вам:  
• Разработчик говорит про джойны и индексы, а вы киваете, но думаете «я потом погуглю»?  
• Нужно описать требования к отчёту, но вы не уверены, как правильно сформулировать запрос, чтобы не получить не то?  
• На обсуждении архитектуры теряетесь в терминах: репликация, шардирование, денормализация, и молчите, чтобы не выдать пробел?  
• Заказчик просит выгрузку данных, а вы не можете быстро проверить, корректно ли вам прислали результат?  
• На собеседовании спрашивают про нормализацию или оконные функции, а вы зависаете?

Системный аналитик без понимания БД работает вслепую: требования получаются размытыми, оценка сложности неточной, а диалог с разработкой напряжённым.

Напомню, что именно поэтому я собрала полноценное обучение по базам данных, чтобы вы перестали «угадывать» и начали говорить с командой на одном языке.

Вот что внутри:

✔️Модуль 1. Проектирование БД
• Процесс проектирования баз данных  
• ER-диаграммы: как визуализировать связи  
• Структура и нормализация: когда упрощать, а когда дробить  
• Системы управления БД: чем отличаются и как выбрать  

✔️Модуль 2. Основы SQL. Часть 1
• Язык SQL
• Типы соединений
• Функции агрегирования
• Сортировка и группировка данных

✔️Модуль 3. Основы SQL. Часть 2
• Оконные/аналитические функции для сложных отчётов и метрик  
• Представления: как упростить жизнь себе и команде  
• Денормализация
• Индексы, секционирование, шардирование: что влияет на скорость и как это учитывать в требованиях  
• Репликация данных

🎁 Бонусы:
• Презентации к каждому занятию: скачивайте и используйте как шпаргалку  
• Практическое занятие с разбором реальных кейсов 
• Тесты для самопроверки после каждого модуля  
• Доступ остаётся навсегда

Формат: видеоуроки с приглашённым экспертом-практиком Иваном Чувашовым, который объясняет сложное простыми словами и сразу показывает, как это работает в реальных проектах.

🔥Стоимость: 9 900 ₽  

➡️ Забрать курс: ссылка 

Если остались вопросы, пишите @ginfotech_manager, помогу разобраться.

😂😂😂

Тык, чтобы научиться считать правильно

Тестирование взаимодействия систем

Спешу вас обрадовать – я подготовила материалы для аналитиков, которые устали от плавающих багов в интеграциях и не раз попадали в ситуации, когда 200 OK есть, а данные не ушли, когда QA говорит, что это баг, разработчик – что это фича… Знакомо да? 

А проблема здесь в том, что нас не учат тестировать интеграции системно. Мы пишем требования, но часто не знаем, как проверить их на стыке систем и где заканчивается зона ответственности аналитика, а начинается работа QA. 

Открываю возможность приобрести 2 урока, которые закроют этот пробел:

✔️Урок 1. Вместе с приглашенным экспертом, Олегом Маврешко, ведущим QA-инженером, узнаём всё о тестировании: роли QA, документацию, виды тестов и ключевые инструменты. А главное – чётко определим, где проходит граница между задачами QA и системного аналитика.  
➕презентация и тест для самопроверки

✔️Урок 2. Postman и Swagger  
На практике познакомлю вас с инструментами для тестирования API. Вы научитесь уверенно работать с запросами и читать документацию, чтобы проверять интеграции самостоятельно.  

➡️ Стоимость уроков: 3 000 ₽ 

Забрать материалы: ссылка  

Если остались вопросы, пишите @ginfotech_manager 

Интеграции: дайджест постов за 2026 год

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

Я собрала для вас посты по интеграциям в один дайджест, чтобы вы могли быстро найти ответ, когда вопрос «а как это правильно описать?» возникает в самый неподходящий момент.

Читайте, сохраняйте и используйте в работе:

• Проектирование API с точки зрения безопасности
• Почему это задача аналитика?
• Rate limiting 
• Webhooks 
• Очереди, webhooks или polling? 
• 3 вопроса, которые я всегда задаю перед описанием интеграции
• Стратегии тестирования API: о чём часто забывают аналитики
• Что такое API-first и зачем он нужен
• Стандартизация кодов и форматов ошибок в API
• Версионирование API 
• API и бизнес-логика 
• Где на практике ломаются даже правильно спроектированные API

Пишите в комментариях, какие еще темы вы бы хотели разобрать?

Метрики: как аналитик влияет на бизнес-показатели

Помните, я спрашивала, по каким темам вам нужны короткие и прикладные материалы? Вы голосовали за БД, метрики, процессы и интеграции. 

Я вас услышала и сделала это – собрала ваши запросы в линейку мини-продуктов, которые можно пройти за вечер и сразу применить в работе. 

И продолжаю серию темой, которая напрямую связывает вашу работу с деньгами бизнеса – продуктовые метрики. Хотя некоторым кажется, что метрики – это удел продактов, а аналитик остаётся лишь «передатчиком задач», но это не совсем так. 

Если вы ещё не читали пост от 31.05 о том, как аналитик влияет на бизнес-метрики – обязательно загляните, это поможет лучше понять контекст урока.

И сейчас открываю возможность приобрести видеоурок, который закроет этот пробел.

Итак, что внутри:  

Вместе с менеджером продукта, Эльвирой Ромашкиной, рассмотрим, зачем системному аналитику нужны продуктовые метрики и как с их помощью усиливать ценность требований.

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

А ещё разберём на практике:

✔️Как правильно именовать события и параметры, чтобы с ними было удобно работать всей команде
✔️Как ставить задачу разработке на создание событий: какие поля указывать, типы данных, обязательность параметров
✔️Как анализировать продукт через метрики: строить воронки, считать конверсии, запускать A/B-тесты и валидировать новые фичи

➕вас ждет тест для самопроверки, а доступ к уроку останется навсегда!

При этом стоимость всех материалов всего 1 000 ₽
(Это меньше, чем стоимость одного часа работы аналитика, потраченного на правки из-за криво собранной аналитики)

➡️ Забрать урок: ссылка 

Если остались вопросы, пишите @ginfotech_manager 

Как системный аналитик влияет на бизнес-метрики

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

1. Он влияет на то, что вообще будет сделано

И это самый недооценённый уровень влияния. До разработки любой фичи есть момент, когда кто-то решает:
• делать это или нет
• делать сейчас или позже
• делать полностью или в упрощённом виде

И здесь аналитик не просто фиксирует запрос, а помогает понять: что действительно даёт ценность, а что выглядит важным только на словах.

Иногда одно правильно уточнённое требование убирает фичу, которая бы не дала никакого эффекта на метрики. 

2. Он влияет на то, как фича будет работать

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

Системный аналитик здесь влияет через структуру процесса и понимание пользовательских сценариев.

3. Он снижает стоимость ошибок и переделок

Каждая ошибка в требованиях – это переработка разработки, задержка релиза и ухудшение качества продукта. И всё это напрямую влияет на бизнес: скорость вывода фич и способность компании реагировать на рынок.

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

4. Он делает систему предсказуемой

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

А ведь предсказуемость – это основа роста. Без неё невозможно стабильно улучшать метрики, потому что команда постоянно тушит пожары.

5. Он влияет на скорость изменений

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

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

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

Сохраняйте этот пост, чтобы правильно понимать свою ценность!

Ошибки новичков, из-за которых их не берут на работу 

Я довольно часто вижу одинаковую картину у новичков: человек вроде бы что-то знает, прошёл курс, даже умеет делать диаграммы и пишет SQL на базовом уровне. Но на собеседовании или при разборе резюме возникает ощущение, что он не понимает, как выглядит реальная работа аналитика.

Одна из самых частых причин отказа – это фокус на инструментах вместо смысла. В резюме перечислены UML, BPMN, Postman, но нет ощущения, что человек умеет решать задачу. А в системном анализе всегда оценивают не знание нотаций, а способность разобраться в ситуации и разложить её на понятную систему.

Ещё очень заметно, когда у кандидата нет ни одного живого кейса. Не учебного в стиле «интернет-магазин», а такого, где видно контекст: зачем система, какие ограничения, что может пойти не так. Без этого сложно понять, как человек думает, а именно это и проверяют.
На собеседованиях это проявляется ещё сильнее. Новички часто сразу начинают отвечать на вопрос, не уточнив деталей. Хотя в реальной работе аналитик почти никогда не решает задачу сразу. Он сначала пытается понять, что вообще происходит, кто пользователи, какие есть ограничения, где система будет ломаться. И именно это отсутствие привычки задавать вопросы сразу бросается в глаза.

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

И отдельно стоит упомянуть базовое понимание интеграций. И я уже говорила, что здесь имеется в виду, что система не живёт одна: данные приходят, уходят, ломаются, повторяются. Если этого понимания нет, это сразу видно по ответам.
В итоге проблема обычно не в том, что новичок не дотянул по знаниям, а в том, что он ещё не показывает мышление системного аналитика. Не умеет демонстрировать, как он думает, как разбирает ситуацию и как принимает решения в условиях неопределённости.
И именно это, а не список технологий, решает, возьмут ли тебя на работу/стажировку. 

Поэтому я в канале даю не какие-то отдельные инструменты, оторванные от контекста, а информацию, которая поможет понять, что такое система в целом и какие у нее есть ограничения.

Если есть темы, которые вы бы хотели разобрать, пишите в комментариях.

Приоритизация требований: пошаговый план действий

В прошлом посте мы разобрали, что обычная задача может превратиться в ситуацию из басни про лебедь, рак и щуку – все тянут в свою сторону.

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

1. Сначала фиксируем контекст, а не требования!

Без контекста вообще невозможно проставить приоритеты. Надо уточнить эти вопросы: 
• зачем бизнесу это нужно сейчас
• какую проблему решаем
• что будет, если не делать вообще
• есть ли дедлайн, от которого всё зависит

Что мне нравится тут – что иногда на этом этапе оказывается, что срочность не такая уж и однозначная.

2. Разделяем ценность и стоимость

Спорить, что важнее бесполезно. Лучше взять и разложить:
• бизнес-ценность (что даёт фича)
• стоимость реализации (время, сложность, риски)
• последствия откладывания
• технические ограничения

По сути тут мы просто делаем картину видимой для всех сторон.

3. Выявляем зависимости

Перед тем как ставить приоритет, всегда смотрим:
• от чего эта задача зависит
• что блокирует другие задачи
• что сломается, если сделать это сейчас

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

4. Проговариваем варианты, а не одно решение

Никогда не приходите с одним вариантом. Формулируйте так:
• делаем сейчас и берём риск X
• откладываем и теряем Y
• упрощаем и получаем компромисс Z

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

5. Фиксируем договорённость, а не просто список задач

И только после этого появляется приоритизация! Но! Это не просто порядок задач.

Это зафиксированное решение:
• почему именно так
• какие риски приняты
• что сознательно отложено
• кто подтвердил решение

Без этого приоритеты не сработают, т.к. распадутся при первом изменении контекста.

Итого, вы больше не человек, который расставляет приоритеты, вы управляете логикой решений в системе. Используйте в работе и ставьте реакции, если было полезно!🔥🔥

Приоритизация требований: почему приоритеты почти всегда меняются

Приоритизация требований в теории выглядит просто: есть список задач, есть методика, есть порядок выполнения. В реальности это почти никогда так не работает.

И я уверена, что вы сталкивались с тем, что у заказчика «всё срочно, горит!», у разработчиков «всё сложно», тестировщикам всё нужно протестировать, а аналитик оказывается между этими точками напряжения и должен собрать из этого что-то, что вообще можно реализовать.

И первая ошибка, которую делают многие начинающие аналитики – они пытаются зафиксировать это как статичную картину. Мол, вот приоритеты, вот список, дальше просто делаем по порядку. Но в живых продуктах приоритеты не существуют в стабильном виде. Они постоянно двигаются. И дело вовсе не в «плохом» управлении, а в том, что меняется контекст: рынок, сроки, ограничения, зависимость от других систем. По сути это нормальная ситуация.

Но здесь появляется главный конфликт, т.к. заказчик часто мыслит задачами: «нам нужно сделать эту фичу, потому что она важная для роста», на что у разработки сразу есть ответ: «если мы это сделаем сейчас, мы сломаем стабильность». И вот если аналитик просто передаёт требования дальше, он автоматически усиливает этот разрыв. В итоге команда получает не систему приоритетов, а набор конкурирующих ожиданий.

Как с этим работать на практике? 

У меня есть проверенный алгоритм. Расскажу в следующем посте. 

Спойлер: это вообще не про таблицы и методики.

Итак, вместо транзакций используются несколько паттернов. Одни из популярных – Saga и Outbox.

Saga – цепочка компенсирующих действий

Идея простая – мы не пытаемся сделать всё атомарно, мы строим процесс как набор шагов.
Если шаг не удался, мы не откатываем всё в ноль, мы выполняем компенсирующие действия.

Например:
• Создали заказ
• Списали оплату
• Зарезервировали товар
❌ Не удалось отправить в складскую систему

Что делаем?

Не откатываем всё назад, а:
• отменяем резерв
• возвращаем деньги
• помечаем заказ как отменённый

Это и есть saga — управляемый процесс с компенсациями.

Важно! Компенсация не равно откат в классическом смысле, это отдельная бизнес-операция.

Outbox – гарантированная доставка событий

Теперь другая ситуация: система говорит «заказ создан – отправим событие»

Но между записью в базу и отправкой события в брокер есть риск расхождения.

Например, заказ в БД есть, а событие в очередь не ушло (упал сервис)

И вот тут появляется outbox-паттерн, вместо того чтобы сразу отправлять событие, мы:
1. пишем заказ в БД
2. пишем событие в таблицу outbox
3. отдельный процесс читает outbox и публикует события

То есть БД становится источником истины и для данных, и для событий.

Почему системному аналитику важно в этом разбираться?

Потому что аналитик в такой системе уже не просто описывает, что «нажал кнопку – вызвали API – получили ответ», а он начинает проектировать:
• где шаги процесса,
• где возможны сбои,
• что будет при частичном выполнении,
• как выглядит компенсация,
• какие данные являются источником истины,
• что можно переиграть, а что нельзя.

Если упростить всё до одной мысли:
• в монолите мы боремся за атомарность
• в распределённых системах за устойчивость процесса

И именно поэтому появляются event-driven, retry с ограничениями, saga,
outbox – на самом деле это просто попытка сделать нестабильный мир управляемым.

Чем заменить обычные транзакции в распределенных системах 

Если продолжать нашу линию про event-driven, асинхронность и рассинхрон данных, то логично ответить еще на один вопрос «А почему мы просто не обернём всё в одну транзакцию?»

В монолите это звучит разумно: есть база данных - есть транзакция - либо всё записалось, либо ничего. Но в распределённой системе этот подход начинает разваливаться. Потому что у нас уже не одна база и не один процесс, а несколько сервисов, где у каждого своя БД, свой жизненный цикл, свои очереди и задержки.

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

Потому что: • сервис оплаты уже мог зафиксировать списание • склад уже мог зарезервировать товар • а уведомление вообще живёт в другой системе и упало позже

И тут появляется ключевая мысль: в распределённых системах мы не предотвращаем рассинхрон, мы учимся с ним работать

Тогда что вместо транзакций? 

Рассмотрим в следующем посте. 

 «Альбина, а можно прийти на консультацию просто с вопросами? Не по обучению, а просто разобрать конкретную ситуацию?»

Да, можно! И в последнее время таких запросов становится всё больше.

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

И для меня самое ценное, когда после консультации у человека появляется ощущение «теперь картина сложилась».

Делюсь одним из недавних отзывов. Очень благодарна вам за доверие ❤️

Для меня это всегда намного больше, чем просто созвон.

Записаться на консультацию можно у менеджера @ginfotech_manager 

Почему 200 OK не гарантирует успешное завершение операции?

В интеграциях есть одна очень коварная вещь, которая становится причиной огромного количества проблем. Сервис вернул 200 OK, и все решили, что операция успешно завершилась.

Хотя на самом деле это может быть вообще не так. Важно понимать, что HTTP-ответ показывает только результат обработки конкретного запроса конкретным сервисом.
Он не гарантирует, что весь бизнес-процесс дошёл до конца.

Особенно это становится заметно в распределённых системах, где одна операция почти никогда не ограничивается одним действием.

Давайте вернемся к нашему примеру оформления заказа. Когда пользователь нажимает «купить» система должна создать оплату, зарезервировать товар,
создать доставку, обновить CRM, отправить уведомление и записать событие в аналитику.

Что может произойти?

Сервис заказов может успешно сохранить заказ и вернуть 200 ОК, но платёжный сервис может не ответить, событие может не дойти до очереди, а внешний сервис вообще может быть временно недоступен.

С точки зрения HTTP всё хорошо, а вот с точки зрения бизнеса операция выполнена только частично.

Именно поэтому в распределённых системах очень важно разделять успешную обработку запроса и успешное завершение бизнес-операции.

Это две совершенно разные вещи. 

И кстати, здесь мы видим, почему интеграции – это не «просто API». Проблемы возникают не в момент успешного запроса. Проблемы возникают между сервисами!

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

Поэтому мой совет всем, кто только учиться проектировать интеграции – смотрите не только на ответ API, а на полный жизненный цикл операции от первого запроса до момента, когда система действительно пришла в корректное конечное состояние.