Базовый минимум для старта в системном анализе
За время наставничества начинающих специалистов и проведения обучения, я столкнулась с очень популярной ошибкой у тех, кто только заходит в профессию.
Кажется, что сначала нужно добрать всё: выучить кучу нотаций, разобраться во всех типах интеграций, прочитать десятки книг… и только потом пробовать.
Но так оно не работает!
В системном анализе нельзя подготовиться «в вакууме». БОльшая часть понимания приходит только в работе, когда вы сталкиваетесь с реальными ограничениями, конфликтующими требованиями и живыми системами.
Но есть база, без которой старт действительно будет тяжелым.
Вот тот минимум, который стоит закрыть.
1️⃣ Первое – понимание, что такое система на уровне мышления.
Система – это не «экран» и не «фича», это набор взаимосвязанных элементов: данные, процессы, пользователи, внешние сервисы.
Если вы не видите связей, вы будете решать задачи локально и постоянно ломать что-то рядом.
2️⃣ Второе – работа с требованиями.
Нужно уметь превращать размытое «хотим, чтобы было удобно» в конкретное «что делает пользователь, что происходит в системе, какой результат считается корректным»
3️⃣ Третье – базовая логика процессов.
Вы должны уметь разложить любой сценарий на шаги и задать правильные вопросы:
• что происходит сначала, что потом,
• где могут быть альтернативы,
• где возникают ошибки.
4️⃣ Четвертое – данные.
Надо хотя бы минимально понимать:
• какие данные есть в системе,
• откуда они приходят,
• куда уходят,
• что с ними происходит по дороге.
Очень много проблем в проектах про криво понятые или потерянные данные.
5️⃣ Пятое – коммуникация.
Умение задавать вопросы – это половина работы аналитика! Если вы не уточняете, вы начинаете додумывать, а это почти всегда приводит к ошибкам.
Важно не бояться выглядеть глупо, гораздо хуже молча сделать неправильно.
6️⃣ Шестое – «а что же с API то?»
На старте от вас не требуется уметь проектировать сложные API или разбираться во всех нюансах архитектурных стилей. Но базовое понимание – обязательно. Без него вы просто не будете видеть, как системы взаимодействуют.
Давайте остановимся чуть подробнее на то, что именно нужно знать.
Во-первых, саму идею.
API – это контракт между системами, одна система что-то запрашивает, другая отвечает. И важно не «как это реализовано внутри», а что именно передается и в каком виде.
Во-вторых, базовую механику:
• запрос / ответ
• методы (GET, POST, PUT, DELETE — на уровне смысла, не заучивания)
• параметры, тело запроса
• коды ответов (хотя бы понимать разницу между успешным и ошибкой)
В-третьих, структуру данных.
Чаще всего это JSON.
Вы должны спокойно читать его и понимать, что за поля приходят, какие из них обязательные, как вложены объекты.
Чего НЕ нужно на старте:
• глубоко разбираться в REST vs GraphQL
• проектировать идеальные API
• знать все возможные стандарты и best practices
Это приходит в работе, когда появляется контекст!
Итого: вам не нужно уметь «строить API», но нужно уметь «читать и понимать API».
Вот и всё. Этого достаточно, чтобы начать.
Так что, если у вас есть эта база, идите в практику, а всё остальное вы дотянете по дороге.
За время наставничества начинающих специалистов и проведения обучения, я столкнулась с очень популярной ошибкой у тех, кто только заходит в профессию.
Кажется, что сначала нужно добрать всё: выучить кучу нотаций, разобраться во всех типах интеграций, прочитать десятки книг… и только потом пробовать.
Но так оно не работает!
В системном анализе нельзя подготовиться «в вакууме». БОльшая часть понимания приходит только в работе, когда вы сталкиваетесь с реальными ограничениями, конфликтующими требованиями и живыми системами.
Но есть база, без которой старт действительно будет тяжелым.
Вот тот минимум, который стоит закрыть.
Система – это не «экран» и не «фича», это набор взаимосвязанных элементов: данные, процессы, пользователи, внешние сервисы.
Если вы не видите связей, вы будете решать задачи локально и постоянно ломать что-то рядом.
Нужно уметь превращать размытое «хотим, чтобы было удобно» в конкретное «что делает пользователь, что происходит в системе, какой результат считается корректным»
Вы должны уметь разложить любой сценарий на шаги и задать правильные вопросы:
• что происходит сначала, что потом,
• где могут быть альтернативы,
• где возникают ошибки.
Надо хотя бы минимально понимать:
• какие данные есть в системе,
• откуда они приходят,
• куда уходят,
• что с ними происходит по дороге.
Очень много проблем в проектах про криво понятые или потерянные данные.
Умение задавать вопросы – это половина работы аналитика! Если вы не уточняете, вы начинаете додумывать, а это почти всегда приводит к ошибкам.
Важно не бояться выглядеть глупо, гораздо хуже молча сделать неправильно.
На старте от вас не требуется уметь проектировать сложные API или разбираться во всех нюансах архитектурных стилей. Но базовое понимание – обязательно. Без него вы просто не будете видеть, как системы взаимодействуют.
Давайте остановимся чуть подробнее на то, что именно нужно знать.
Во-первых, саму идею.
API – это контракт между системами, одна система что-то запрашивает, другая отвечает. И важно не «как это реализовано внутри», а что именно передается и в каком виде.
Во-вторых, базовую механику:
• запрос / ответ
• методы (GET, POST, PUT, DELETE — на уровне смысла, не заучивания)
• параметры, тело запроса
• коды ответов (хотя бы понимать разницу между успешным и ошибкой)
В-третьих, структуру данных.
Чаще всего это JSON.
Вы должны спокойно читать его и понимать, что за поля приходят, какие из них обязательные, как вложены объекты.
Чего НЕ нужно на старте:
• глубоко разбираться в REST vs GraphQL
• проектировать идеальные API
• знать все возможные стандарты и best practices
Это приходит в работе, когда появляется контекст!
Итого: вам не нужно уметь «строить API», но нужно уметь «читать и понимать API».
Вот и всё. Этого достаточно, чтобы начать.
Так что, если у вас есть эта база, идите в практику, а всё остальное вы дотянете по дороге.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍4✍2
Чем event-driven архитектура отличается от request-response
Предлагаю еще немного поговорить про взаимодействие систем, т.к. эта тема всегда одна из самых популярных)
Когда аналитики только начинают работать с интеграциями, почти все мыслят одинаково: одна система отправила запрос, а другая сразу ответила.
Это классическая request-response модель.
Например:
frontend отправляет запрос
backend отвечает «заказ создан»
Здесь всё просто и понятно, согласитесь?
И на старте большинства простых систем этого действительно хватает.
Но чем сложнее становится система, тем сильнее начинают проявляться ограничения такого подхода, т.к. request-response создаёт очень жёсткую связанность между сервисами.
Здесь одна система не просто сообщает другой о событии, она можно сказать требует мгновенного ответа здесь и сейчас.
А значит:
• сервис должен быть доступен,
• должен успеть обработать запрос,
• должен вернуть корректный ответ,
• и вся цепочка должна отработать синхронно.
На маленьких системах это выглядит нормально.
Но представьте, что, например, после создания заказа нужно:
• зарезервировать товар,
• создать оплату,
• отправить уведомление,
• обновить CRM
• создать доставку,
• отправить событие в аналитику.
Если всё это делать через request-response, система превращается в очень хрупкую конструкцию, потому что теперь успешность операции зависит сразу от всех участников цепочки.
А это значит, что если один сервис лёг, встал и весь процесс. Если один отвечает медленно, начинает тормозить всё остальное.
Так что в какой-то момент команды начинают переходить к event-driven подходу, ведь здесь система «мыслит» уже по-другому – она не говорит «сделай действие», она говорит «произошло событие» и всё.
Дальше другие сервисы сами подписываются на это событие и решают, что им делать.
Например, для нашего примера «заказ создан»:
• Сервис оплаты создаёт платёж.
• Сервис уведомлений отправляет письмо.
• Сервис аналитики обновляет метрики.
• Склад резервирует товар.
И инициатору вообще не нужно знать, кто именно будет это обрабатывать.
Вот оно ключевое отличие этих двух подходов:
1. Request-response:
сервисы знают друг о друге напрямую.
2. Event-driven:
сервисы знают только про событие.
Event-driven сильно уменьшает связность системы, и на уровне архитектуры это дает огромную гибкость.
Например, можно добавить новый сервис-подписчик и вообще не менять существующую систему.
С request-response так обычно не получится – придётся добавлять новые вызовы, менять цепочки, пересматривать зависимости.
Но! Очень важно понимать, что event-driven – это не волшебная таблетка, которая решит все ваши проблемы, ведь у этого подхода есть свои нюансы… Причем не очень приятные. Разберем их в следующем посте.
Предлагаю еще немного поговорить про взаимодействие систем, т.к. эта тема всегда одна из самых популярных)
Когда аналитики только начинают работать с интеграциями, почти все мыслят одинаково: одна система отправила запрос, а другая сразу ответила.
Это классическая request-response модель.
Например:
frontend отправляет запрос
POST /ordersbackend отвечает «заказ создан»
Здесь всё просто и понятно, согласитесь?
И на старте большинства простых систем этого действительно хватает.
Но чем сложнее становится система, тем сильнее начинают проявляться ограничения такого подхода, т.к. request-response создаёт очень жёсткую связанность между сервисами.
Здесь одна система не просто сообщает другой о событии, она можно сказать требует мгновенного ответа здесь и сейчас.
А значит:
• сервис должен быть доступен,
• должен успеть обработать запрос,
• должен вернуть корректный ответ,
• и вся цепочка должна отработать синхронно.
На маленьких системах это выглядит нормально.
Но представьте, что, например, после создания заказа нужно:
• зарезервировать товар,
• создать оплату,
• отправить уведомление,
• обновить CRM
• создать доставку,
• отправить событие в аналитику.
Если всё это делать через request-response, система превращается в очень хрупкую конструкцию, потому что теперь успешность операции зависит сразу от всех участников цепочки.
А это значит, что если один сервис лёг, встал и весь процесс. Если один отвечает медленно, начинает тормозить всё остальное.
Так что в какой-то момент команды начинают переходить к event-driven подходу, ведь здесь система «мыслит» уже по-другому – она не говорит «сделай действие», она говорит «произошло событие» и всё.
Дальше другие сервисы сами подписываются на это событие и решают, что им делать.
Например, для нашего примера «заказ создан»:
• Сервис оплаты создаёт платёж.
• Сервис уведомлений отправляет письмо.
• Сервис аналитики обновляет метрики.
• Склад резервирует товар.
И инициатору вообще не нужно знать, кто именно будет это обрабатывать.
Вот оно ключевое отличие этих двух подходов:
1. Request-response:
сервисы знают друг о друге напрямую.
2. Event-driven:
сервисы знают только про событие.
Event-driven сильно уменьшает связность системы, и на уровне архитектуры это дает огромную гибкость.
Например, можно добавить новый сервис-подписчик и вообще не менять существующую систему.
С request-response так обычно не получится – придётся добавлять новые вызовы, менять цепочки, пересматривать зависимости.
Но! Очень важно понимать, что event-driven – это не волшебная таблетка, которая решит все ваши проблемы, ведь у этого подхода есть свои нюансы… Причем не очень приятные. Разберем их в следующем посте.
🔥9👍3✍1
Итак, какие есть нюансы в проектировании event-driven архитектуры?
1. Во-первых, исчезает мгновенная консистентность.
В request-response всё проще: запрос завершился – данные обновились.
В event-driven между сервисами появляется асинхронность.
Событие сначала публикуется,
потом попадает в очередь,
потом обрабатывается другими сервисами.
То есть система начинает жить с задержками, что является абсолютной нормой.
Например, заказ уже создан, но уведомление еще не ушло, аналитика ещё не обновилась, а доставка появится через несколько секунд.
Это не баг! Это распределенная система.
2. Во-вторых, появляется проблема повторной доставки событий.
Событие может прийти дважды. И если система к этому не готова, то можно получить дубли оплат, повторные уведомления и несколько созданных сущностей.
Поэтому в event-driven аналитик уже обязан думать про идемпотентность, retry и
порядке обработки событий.
3. Третья проблема – трассировка.
В request-response видно цепочку вызовов, а в event-driven найти причину ошибки намного сложнее, т.к. процесс размазан между несколькими сервисами и очередями.
И когда заказчик говорит «у нас не создалась доставка», иногда приходится восстанавливать всю цепочку событий по логам.
_________________________________
И, кстати, вот здесь и лежит один из ответов на вопрос «а чем junior/middle отличается от senior?»
Junior/middle видит, что «есть API».
А senior видит:
• способ взаимодействия систем,
• уровень связанности,
• риски отказов,
• модель консистентности,
• влияние на поддержку,
• масштабируемость системы через полгода.
И снова подчеркну, это приходит с опытом – и это совершенно нормально. Поверьте, вы почувствуете, что вы готовы к этому переходу!
1. Во-первых, исчезает мгновенная консистентность.
В request-response всё проще: запрос завершился – данные обновились.
В event-driven между сервисами появляется асинхронность.
Событие сначала публикуется,
потом попадает в очередь,
потом обрабатывается другими сервисами.
То есть система начинает жить с задержками, что является абсолютной нормой.
Например, заказ уже создан, но уведомление еще не ушло, аналитика ещё не обновилась, а доставка появится через несколько секунд.
Это не баг! Это распределенная система.
2. Во-вторых, появляется проблема повторной доставки событий.
Событие может прийти дважды. И если система к этому не готова, то можно получить дубли оплат, повторные уведомления и несколько созданных сущностей.
Поэтому в event-driven аналитик уже обязан думать про идемпотентность, retry и
порядке обработки событий.
3. Третья проблема – трассировка.
В request-response видно цепочку вызовов, а в event-driven найти причину ошибки намного сложнее, т.к. процесс размазан между несколькими сервисами и очередями.
И когда заказчик говорит «у нас не создалась доставка», иногда приходится восстанавливать всю цепочку событий по логам.
_________________________________
И, кстати, вот здесь и лежит один из ответов на вопрос «а чем junior/middle отличается от senior?»
Junior/middle видит, что «есть API».
А senior видит:
• способ взаимодействия систем,
• уровень связанности,
• риски отказов,
• модель консистентности,
• влияние на поддержку,
• масштабируемость системы через полгода.
И снова подчеркну, это приходит с опытом – и это совершенно нормально. Поверьте, вы почувствуете, что вы готовы к этому переходу!
🔥7✍3👍2
Почему данные в распределенных системах обновляются не сразу
После поста про event-driven архитектуру логично поговорить ещё об одной вещи, которая сначала часто непонятна почти всем начинающим системным аналитикам.
«Почему данные в одной части системы уже обновились, а в другой еще нет?»
Для человека, который только начинает работать с распределенными системами, обычно есть интуитивное ожидание: если действие произошло, система везде сразу должна показать новый результат.
Нажали «оплатить» – заказ сразу стал оплаченным. Изменили профиль – новые данные сразу отображаются везде.
Но большие системы так почти никогда не работают.
Потому что между сервисами есть то, что создает задержки: • очереди, • события, • асинхронная обработка, • кэш, • репликация данных, • внешние интеграции.
Например, сервис заказов уже сохранил новый статус, но событие об этом еще только едет в сервис уведомлений, CRM ещё не обновилась, а аналитика вообще обработает это через несколько минут пачкой.
То есть технически система еще «догоняет сама себя».
И вот здесь появляется очень важное понятие – конечная (итоговая) согласованность (eventual consistency).
Если переводить простым языком, это значит, что система не гарантирует мгновенную синхронность, но гарантирует, что через какое-то время данные придут к согласованному состоянию.
И это абсолютно нормальная модель для больших распределенных систем.
Почему вообще так делают? Потому что мгновенная консистентность очень дорогая.
Чтобы все сервисы обновлялись синхронно и одновременно, их пришлось бы жёстко связывать между собой. А это хуже масштабируется, сильнее зависит от отказов, создает длинные цепочки блокировок и делает систему хрупкой.
Да, и здесь есть свои нюансы. Например, пользователь уже оплатил заказ, но пару секунд всё ещё видит статус «в обработке». Или уведомление пришло раньше, чем обновился интерфейс.
На что здесь обратить внимание:
• где допустима задержка, а где нет?
• какие данные должны быть консистентны сразу?
• что пользователь увидит в промежуточном состоянии?
• как система восстанавливается после рассинхрона?
Ошибка новичков – пытаться сделать мгновенно всё и везде, а ошибка опытных команд – не объяснить заказчику и пользователям, что система работает асинхронно (прям объяснить, почему так, чтобы они не пугались и не писали в техподдержку «у нас всё упало, срочно, помогите!!»)
Так что помним, что в распределенных системах задержка – это нормальное состояние системы.
После поста про event-driven архитектуру логично поговорить ещё об одной вещи, которая сначала часто непонятна почти всем начинающим системным аналитикам.
«Почему данные в одной части системы уже обновились, а в другой еще нет?»
Для человека, который только начинает работать с распределенными системами, обычно есть интуитивное ожидание: если действие произошло, система везде сразу должна показать новый результат.
Нажали «оплатить» – заказ сразу стал оплаченным. Изменили профиль – новые данные сразу отображаются везде.
Но большие системы так почти никогда не работают.
Потому что между сервисами есть то, что создает задержки: • очереди, • события, • асинхронная обработка, • кэш, • репликация данных, • внешние интеграции.
Например, сервис заказов уже сохранил новый статус, но событие об этом еще только едет в сервис уведомлений, CRM ещё не обновилась, а аналитика вообще обработает это через несколько минут пачкой.
То есть технически система еще «догоняет сама себя».
И вот здесь появляется очень важное понятие – конечная (итоговая) согласованность (eventual consistency).
Если переводить простым языком, это значит, что система не гарантирует мгновенную синхронность, но гарантирует, что через какое-то время данные придут к согласованному состоянию.
И это абсолютно нормальная модель для больших распределенных систем.
Почему вообще так делают? Потому что мгновенная консистентность очень дорогая.
Чтобы все сервисы обновлялись синхронно и одновременно, их пришлось бы жёстко связывать между собой. А это хуже масштабируется, сильнее зависит от отказов, создает длинные цепочки блокировок и делает систему хрупкой.
Да, и здесь есть свои нюансы. Например, пользователь уже оплатил заказ, но пару секунд всё ещё видит статус «в обработке». Или уведомление пришло раньше, чем обновился интерфейс.
На что здесь обратить внимание:
• где допустима задержка, а где нет?
• какие данные должны быть консистентны сразу?
• что пользователь увидит в промежуточном состоянии?
• как система восстанавливается после рассинхрона?
Ошибка новичков – пытаться сделать мгновенно всё и везде, а ошибка опытных команд – не объяснить заказчику и пользователям, что система работает асинхронно (прям объяснить, почему так, чтобы они не пугались и не писали в техподдержку «у нас всё упало, срочно, помогите!!»)
Так что помним, что в распределенных системах задержка – это нормальное состояние системы.
🔥7✍2👍1
Когда retry делает только хуже
Давайте разберем другую сторону медали – когда не просто задерживается смена состояния, а когда система не получает ответ от другого сервиса и мы пытаемся «достучаться» до нее ретраями (повторными запросами).
И на первый взгляд это выглядит разумно – если сервис не ответил, просто повторим запрос.
Но на практике именно так и появляются многие серьёзные проблемы в распределённых системах, т.к. повторная отправка – это дополнительная нагрузка на уже нестабильную систему.
Давайте рассмотрим на примере такой ситуации: есть сервис оплаты, и он начал работать медленнее из-за высокой нагрузки. Одна система отправила запрос и не дождалась ответа вовремя, и что она делает? Да, отправляет повторно. Потом еще раз. Потом ещё десятки других сервисов начинают делать то же самое. И в этот момент система, которая уже не справлялась с нагрузкой, получает ещё больше запросов. То есть попытка спасти ситуацию начинает её добивать.
Это выглядит как снежный ком:
сервис тормозит → клиенты начинают повторять запросы → нагрузка растёт →
сервис тормозит еще сильнее → повторных запросов становится ещё больше.
И система может упасть не из-за исходной проблемы, а банально из-за лавины повторных запросов.
Хочу этим постом донести важную мысль: повторная отправка — это тоже нагрузка, причём иногда очень агрессивная!
Плюс возникает еще одна проблема: повторный запрос не всегда означает «повторить безопасно».
Например, первый запрос уже успел выполнить операцию, но ответ потерялся по дороге. И с точки зрения клиента операция как будто не выполнилась, и система отправляет запрос еще раз.
В итоге получаем:
• деньги списываются повторно,
• создаются дубли,
• дважды отправляются уведомления,
• повторно начисляются бонусы.
То есть проблема уже не только в нагрузке, а в корректности данных.
Именно поэтому повторная отправка не рассматривается как простое решение.
В идеале, надо задать вопросы:
• какие операции вообще можно повторять?
• как система поймёт, что запрос уже был обработан?
• что делать, если сервис отвечает слишком медленно?
• когда нужно остановить повторные попытки?
На практике обычно:
• ограничивают количество повторов,
• увеличивают интервал между попытками,
• разделяют типы ошибок,
• и обязательно проектируют защиту от дублей.
Поэтому, как видите, повторная отправка запроса – это отдельный сценарий, который тоже нужно проектировать.
Давайте разберем другую сторону медали – когда не просто задерживается смена состояния, а когда система не получает ответ от другого сервиса и мы пытаемся «достучаться» до нее ретраями (повторными запросами).
И на первый взгляд это выглядит разумно – если сервис не ответил, просто повторим запрос.
Но на практике именно так и появляются многие серьёзные проблемы в распределённых системах, т.к. повторная отправка – это дополнительная нагрузка на уже нестабильную систему.
Давайте рассмотрим на примере такой ситуации: есть сервис оплаты, и он начал работать медленнее из-за высокой нагрузки. Одна система отправила запрос и не дождалась ответа вовремя, и что она делает? Да, отправляет повторно. Потом еще раз. Потом ещё десятки других сервисов начинают делать то же самое. И в этот момент система, которая уже не справлялась с нагрузкой, получает ещё больше запросов. То есть попытка спасти ситуацию начинает её добивать.
Это выглядит как снежный ком:
сервис тормозит → клиенты начинают повторять запросы → нагрузка растёт →
сервис тормозит еще сильнее → повторных запросов становится ещё больше.
И система может упасть не из-за исходной проблемы, а банально из-за лавины повторных запросов.
Хочу этим постом донести важную мысль: повторная отправка — это тоже нагрузка, причём иногда очень агрессивная!
Плюс возникает еще одна проблема: повторный запрос не всегда означает «повторить безопасно».
Например, первый запрос уже успел выполнить операцию, но ответ потерялся по дороге. И с точки зрения клиента операция как будто не выполнилась, и система отправляет запрос еще раз.
В итоге получаем:
• деньги списываются повторно,
• создаются дубли,
• дважды отправляются уведомления,
• повторно начисляются бонусы.
То есть проблема уже не только в нагрузке, а в корректности данных.
Именно поэтому повторная отправка не рассматривается как простое решение.
В идеале, надо задать вопросы:
• какие операции вообще можно повторять?
• как система поймёт, что запрос уже был обработан?
• что делать, если сервис отвечает слишком медленно?
• когда нужно остановить повторные попытки?
На практике обычно:
• ограничивают количество повторов,
• увеличивают интервал между попытками,
• разделяют типы ошибок,
• и обязательно проектируют защиту от дублей.
Поэтому, как видите, повторная отправка запроса – это отдельный сценарий, который тоже нужно проектировать.
✍6🔥5👍1
Почему
В интеграциях есть одна очень коварная вещь, которая становится причиной огромного количества проблем. Сервис вернул
Хотя на самом деле это может быть вообще не так. Важно понимать, что HTTP-ответ показывает только результат обработки конкретного запроса конкретным сервисом.
Он не гарантирует, что весь бизнес-процесс дошёл до конца.
Особенно это становится заметно в распределённых системах, где одна операция почти никогда не ограничивается одним действием.
Давайте вернемся к нашему примеру оформления заказа. Когда пользователь нажимает «купить» система должна создать оплату, зарезервировать товар,
создать доставку, обновить CRM, отправить уведомление и записать событие в аналитику.
Что может произойти?
Сервис заказов может успешно сохранить заказ и вернуть
С точки зрения HTTP всё хорошо, а вот с точки зрения бизнеса операция выполнена только частично.
Именно поэтому в распределённых системах очень важно разделять успешную обработку запроса и успешное завершение бизнес-операции.
Это две совершенно разные вещи.
И кстати, здесь мы видим, почему интеграции – это не «просто API». Проблемы возникают не в момент успешного запроса. Проблемы возникают между сервисами!
И если в системе не продуманы промежуточные состояния, механизмы восстановления и обработка частичных отказов, со временем начинают появляться
дубли операций, рассинхрон статусов, «пропавшие» действия, плавающие баги,
которые невозможно воспроизвести.
Поэтому мой совет всем, кто только учиться проектировать интеграции – смотрите не только на ответ API, а на полный жизненный цикл операции от первого запроса до момента, когда система действительно пришла в корректное конечное состояние.
200 OK не гарантирует успешное завершение операции? В интеграциях есть одна очень коварная вещь, которая становится причиной огромного количества проблем. Сервис вернул
200 OK, и все решили, что операция успешно завершилась.Хотя на самом деле это может быть вообще не так. Важно понимать, что HTTP-ответ показывает только результат обработки конкретного запроса конкретным сервисом.
Он не гарантирует, что весь бизнес-процесс дошёл до конца.
Особенно это становится заметно в распределённых системах, где одна операция почти никогда не ограничивается одним действием.
Давайте вернемся к нашему примеру оформления заказа. Когда пользователь нажимает «купить» система должна создать оплату, зарезервировать товар,
создать доставку, обновить CRM, отправить уведомление и записать событие в аналитику.
Что может произойти?
Сервис заказов может успешно сохранить заказ и вернуть
200 ОК, но платёжный сервис может не ответить, событие может не дойти до очереди, а внешний сервис вообще может быть временно недоступен.С точки зрения HTTP всё хорошо, а вот с точки зрения бизнеса операция выполнена только частично.
Именно поэтому в распределённых системах очень важно разделять успешную обработку запроса и успешное завершение бизнес-операции.
Это две совершенно разные вещи.
И кстати, здесь мы видим, почему интеграции – это не «просто API». Проблемы возникают не в момент успешного запроса. Проблемы возникают между сервисами!
И если в системе не продуманы промежуточные состояния, механизмы восстановления и обработка частичных отказов, со временем начинают появляться
дубли операций, рассинхрон статусов, «пропавшие» действия, плавающие баги,
которые невозможно воспроизвести.
Поэтому мой совет всем, кто только учиться проектировать интеграции – смотрите не только на ответ API, а на полный жизненный цикл операции от первого запроса до момента, когда система действительно пришла в корректное конечное состояние.
🔥6👍4✍2
«Альбина, а можно прийти на консультацию просто с вопросами? Не по обучению, а просто разобрать конкретную ситуацию?»
Да, можно! И в последнее время таких запросов становится всё больше.
Кто-то приходит с вопросом по требованиям, кто-то с карьерным тупиком, а кто-то просто не понимает, куда двигаться дальше в профессии.
И для меня самое ценное, когда после консультации у человека появляется ощущение «теперь картина сложилась».
Делюсь одним из недавних отзывов. Очень благодарна вам за доверие ❤️
Для меня это всегда намного больше, чем просто созвон.
Записаться на консультацию можно у менеджера @ginfotech_manager
Да, можно! И в последнее время таких запросов становится всё больше.
Кто-то приходит с вопросом по требованиям, кто-то с карьерным тупиком, а кто-то просто не понимает, куда двигаться дальше в профессии.
И для меня самое ценное, когда после консультации у человека появляется ощущение «теперь картина сложилась».
Делюсь одним из недавних отзывов. Очень благодарна вам за доверие ❤️
Для меня это всегда намного больше, чем просто созвон.
Записаться на консультацию можно у менеджера @ginfotech_manager
🔥7👏4❤3
Чем заменить обычные транзакции в распределенных системах
Если продолжать нашу линию про event-driven, асинхронность и рассинхрон данных, то логично ответить еще на один вопрос «А почему мы просто не обернём всё в одну транзакцию?»
В монолите это звучит разумно: есть база данных - есть транзакция - либо всё записалось, либо ничего. Но в распределённой системе этот подход начинает разваливаться. Потому что у нас уже не одна база и не один процесс, а несколько сервисов, где у каждого своя БД, свой жизненный цикл, свои очереди и задержки.
И вот стандартный кейс: создали заказ, списали оплату, зарезервировали товар, отправили уведомление. И хочется, чтобы это всё было атомарно, но проблема в том, что между этими шагами нет общей транзакции. Нельзя сказать «если уведомление не отправилось, откати оплату».
Потому что: • сервис оплаты уже мог зафиксировать списание • склад уже мог зарезервировать товар • а уведомление вообще живёт в другой системе и упало позже
И тут появляется ключевая мысль: в распределённых системах мы не предотвращаем рассинхрон, мы учимся с ним работать
Тогда что вместо транзакций?
Рассмотрим в следующем посте.
Если продолжать нашу линию про event-driven, асинхронность и рассинхрон данных, то логично ответить еще на один вопрос «А почему мы просто не обернём всё в одну транзакцию?»
В монолите это звучит разумно: есть база данных - есть транзакция - либо всё записалось, либо ничего. Но в распределённой системе этот подход начинает разваливаться. Потому что у нас уже не одна база и не один процесс, а несколько сервисов, где у каждого своя БД, свой жизненный цикл, свои очереди и задержки.
И вот стандартный кейс: создали заказ, списали оплату, зарезервировали товар, отправили уведомление. И хочется, чтобы это всё было атомарно, но проблема в том, что между этими шагами нет общей транзакции. Нельзя сказать «если уведомление не отправилось, откати оплату».
Потому что: • сервис оплаты уже мог зафиксировать списание • склад уже мог зарезервировать товар • а уведомление вообще живёт в другой системе и упало позже
И тут появляется ключевая мысль: в распределённых системах мы не предотвращаем рассинхрон, мы учимся с ним работать
Тогда что вместо транзакций?
Рассмотрим в следующем посте.
👍5✍3🔥2
Итак, вместо транзакций используются несколько паттернов. Одни из популярных – Saga и Outbox.
Saga – цепочка компенсирующих действий
Идея простая – мы не пытаемся сделать всё атомарно, мы строим процесс как набор шагов.
Если шаг не удался, мы не откатываем всё в ноль, мы выполняем компенсирующие действия.
Например:
• Создали заказ
• Списали оплату
• Зарезервировали товар
❌ Не удалось отправить в складскую систему
Что делаем?
Не откатываем всё назад, а:
• отменяем резерв
• возвращаем деньги
• помечаем заказ как отменённый
Это и есть saga — управляемый процесс с компенсациями.
Важно! Компенсация не равно откат в классическом смысле, это отдельная бизнес-операция.
Outbox – гарантированная доставка событий
Теперь другая ситуация: система говорит «заказ создан – отправим событие»
Но между записью в базу и отправкой события в брокер есть риск расхождения.
Например, заказ в БД есть, а событие в очередь не ушло (упал сервис)
И вот тут появляется outbox-паттерн, вместо того чтобы сразу отправлять событие, мы:
1. пишем заказ в БД
2. пишем событие в таблицу outbox
3. отдельный процесс читает outbox и публикует события
То есть БД становится источником истины и для данных, и для событий.
Почему системному аналитику важно в этом разбираться?
Потому что аналитик в такой системе уже не просто описывает, что «нажал кнопку – вызвали API – получили ответ», а он начинает проектировать:
• где шаги процесса,
• где возможны сбои,
• что будет при частичном выполнении,
• как выглядит компенсация,
• какие данные являются источником истины,
• что можно переиграть, а что нельзя.
Если упростить всё до одной мысли:
• в монолите мы боремся за атомарность
• в распределённых системах за устойчивость процесса
И именно поэтому появляются event-driven, retry с ограничениями, saga,
outbox – на самом деле это просто попытка сделать нестабильный мир управляемым.
Saga – цепочка компенсирующих действий
Идея простая – мы не пытаемся сделать всё атомарно, мы строим процесс как набор шагов.
Если шаг не удался, мы не откатываем всё в ноль, мы выполняем компенсирующие действия.
Например:
• Создали заказ
• Списали оплату
• Зарезервировали товар
❌ Не удалось отправить в складскую систему
Что делаем?
Не откатываем всё назад, а:
• отменяем резерв
• возвращаем деньги
• помечаем заказ как отменённый
Это и есть saga — управляемый процесс с компенсациями.
Важно! Компенсация не равно откат в классическом смысле, это отдельная бизнес-операция.
Outbox – гарантированная доставка событий
Теперь другая ситуация: система говорит «заказ создан – отправим событие»
Но между записью в базу и отправкой события в брокер есть риск расхождения.
Например, заказ в БД есть, а событие в очередь не ушло (упал сервис)
И вот тут появляется outbox-паттерн, вместо того чтобы сразу отправлять событие, мы:
1. пишем заказ в БД
2. пишем событие в таблицу outbox
3. отдельный процесс читает outbox и публикует события
То есть БД становится источником истины и для данных, и для событий.
Почему системному аналитику важно в этом разбираться?
Потому что аналитик в такой системе уже не просто описывает, что «нажал кнопку – вызвали API – получили ответ», а он начинает проектировать:
• где шаги процесса,
• где возможны сбои,
• что будет при частичном выполнении,
• как выглядит компенсация,
• какие данные являются источником истины,
• что можно переиграть, а что нельзя.
Если упростить всё до одной мысли:
• в монолите мы боремся за атомарность
• в распределённых системах за устойчивость процесса
И именно поэтому появляются event-driven, retry с ограничениями, saga,
outbox – на самом деле это просто попытка сделать нестабильный мир управляемым.
🔥6✍2👍2
Приоритизация требований: почему приоритеты почти всегда меняются
Приоритизация требований в теории выглядит просто: есть список задач, есть методика, есть порядок выполнения. В реальности это почти никогда так не работает.
И я уверена, что вы сталкивались с тем, что у заказчика «всё срочно, горит!», у разработчиков «всё сложно», тестировщикам всё нужно протестировать, а аналитик оказывается между этими точками напряжения и должен собрать из этого что-то, что вообще можно реализовать.
И первая ошибка, которую делают многие начинающие аналитики – они пытаются зафиксировать это как статичную картину. Мол, вот приоритеты, вот список, дальше просто делаем по порядку. Но в живых продуктах приоритеты не существуют в стабильном виде. Они постоянно двигаются. И дело вовсе не в «плохом» управлении, а в том, что меняется контекст: рынок, сроки, ограничения, зависимость от других систем. По сути это нормальная ситуация.
Но здесь появляется главный конфликт, т.к. заказчик часто мыслит задачами: «нам нужно сделать эту фичу, потому что она важная для роста», на что у разработки сразу есть ответ: «если мы это сделаем сейчас, мы сломаем стабильность». И вот если аналитик просто передаёт требования дальше, он автоматически усиливает этот разрыв. В итоге команда получает не систему приоритетов, а набор конкурирующих ожиданий.
Как с этим работать на практике?
У меня есть проверенный алгоритм. Расскажу в следующем посте.
Спойлер:это вообще не про таблицы и методики.
Приоритизация требований в теории выглядит просто: есть список задач, есть методика, есть порядок выполнения. В реальности это почти никогда так не работает.
И я уверена, что вы сталкивались с тем, что у заказчика «всё срочно, горит!», у разработчиков «всё сложно», тестировщикам всё нужно протестировать, а аналитик оказывается между этими точками напряжения и должен собрать из этого что-то, что вообще можно реализовать.
И первая ошибка, которую делают многие начинающие аналитики – они пытаются зафиксировать это как статичную картину. Мол, вот приоритеты, вот список, дальше просто делаем по порядку. Но в живых продуктах приоритеты не существуют в стабильном виде. Они постоянно двигаются. И дело вовсе не в «плохом» управлении, а в том, что меняется контекст: рынок, сроки, ограничения, зависимость от других систем. По сути это нормальная ситуация.
Но здесь появляется главный конфликт, т.к. заказчик часто мыслит задачами: «нам нужно сделать эту фичу, потому что она важная для роста», на что у разработки сразу есть ответ: «если мы это сделаем сейчас, мы сломаем стабильность». И вот если аналитик просто передаёт требования дальше, он автоматически усиливает этот разрыв. В итоге команда получает не систему приоритетов, а набор конкурирующих ожиданий.
Как с этим работать на практике?
У меня есть проверенный алгоритм. Расскажу в следующем посте.
Спойлер:
🔥7✍4👍1🙏1
Приоритизация требований: пошаговый план действий
В прошлом посте мы разобрали, что обычная задача может превратиться в ситуацию из басни про лебедь, рак и щуку – все тянут в свою сторону.
И в этом хаосе задача аналитика – провести команду через понятный процесс принятия решения. Делюсь проверенным рабочим алгоритмом.
1. Сначала фиксируем контекст, а не требования!
Без контекста вообще невозможно проставить приоритеты. Надо уточнить эти вопросы:
• зачем бизнесу это нужно сейчас
• какую проблему решаем
• что будет, если не делать вообще
• есть ли дедлайн, от которого всё зависит
Что мне нравится тут – что иногда на этом этапе оказывается, что срочность не такая уж и однозначная.
2. Разделяем ценность и стоимость
Спорить, что важнее бесполезно. Лучше взять и разложить:
• бизнес-ценность (что даёт фича)
• стоимость реализации (время, сложность, риски)
• последствия откладывания
• технические ограничения
По сути тут мы просто делаем картину видимой для всех сторон.
3. Выявляем зависимости
Перед тем как ставить приоритет, всегда смотрим:
• от чего эта задача зависит
• что блокирует другие задачи
• что сломается, если сделать это сейчас
Иногда задача кажется важной, но технически она вообще не может быть сделана первой.
4. Проговариваем варианты, а не одно решение
Никогда не приходите с одним вариантом. Формулируйте так:
• делаем сейчас и берём риск X
• откладываем и теряем Y
• упрощаем и получаем компромисс Z
За всех мы не решаем, но показываем последствия решений. Очень даже логично
5. Фиксируем договорённость, а не просто список задач
И только после этого появляется приоритизация! Но! Это не просто порядок задач.
Это зафиксированное решение:
• почему именно так
• какие риски приняты
• что сознательно отложено
• кто подтвердил решение
Без этого приоритеты не сработают, т.к. распадутся при первом изменении контекста.
Итого, вы больше не человек, который расставляет приоритеты, вы управляете логикой решений в системе. Используйте в работе и ставьте реакции, если было полезно!🔥🔥
В прошлом посте мы разобрали, что обычная задача может превратиться в ситуацию из басни про лебедь, рак и щуку – все тянут в свою сторону.
И в этом хаосе задача аналитика – провести команду через понятный процесс принятия решения. Делюсь проверенным рабочим алгоритмом.
1. Сначала фиксируем контекст, а не требования!
Без контекста вообще невозможно проставить приоритеты. Надо уточнить эти вопросы:
• зачем бизнесу это нужно сейчас
• какую проблему решаем
• что будет, если не делать вообще
• есть ли дедлайн, от которого всё зависит
Что мне нравится тут – что иногда на этом этапе оказывается, что срочность не такая уж и однозначная.
2. Разделяем ценность и стоимость
Спорить, что важнее бесполезно. Лучше взять и разложить:
• бизнес-ценность (что даёт фича)
• стоимость реализации (время, сложность, риски)
• последствия откладывания
• технические ограничения
По сути тут мы просто делаем картину видимой для всех сторон.
3. Выявляем зависимости
Перед тем как ставить приоритет, всегда смотрим:
• от чего эта задача зависит
• что блокирует другие задачи
• что сломается, если сделать это сейчас
Иногда задача кажется важной, но технически она вообще не может быть сделана первой.
4. Проговариваем варианты, а не одно решение
Никогда не приходите с одним вариантом. Формулируйте так:
• делаем сейчас и берём риск X
• откладываем и теряем Y
• упрощаем и получаем компромисс Z
За всех мы не решаем, но показываем последствия решений. Очень даже логично
5. Фиксируем договорённость, а не просто список задач
И только после этого появляется приоритизация! Но! Это не просто порядок задач.
Это зафиксированное решение:
• почему именно так
• какие риски приняты
• что сознательно отложено
• кто подтвердил решение
Без этого приоритеты не сработают, т.к. распадутся при первом изменении контекста.
Итого, вы больше не человек, который расставляет приоритеты, вы управляете логикой решений в системе. Используйте в работе и ставьте реакции, если было полезно!🔥🔥
🔥7👍2✍1
Ошибки новичков, из-за которых их не берут на работу
Я довольно часто вижу одинаковую картину у новичков: человек вроде бы что-то знает, прошёл курс, даже умеет делать диаграммы и пишет SQL на базовом уровне. Но на собеседовании или при разборе резюме возникает ощущение, что он не понимает, как выглядит реальная работа аналитика.
Одна из самых частых причин отказа – это фокус на инструментах вместо смысла. В резюме перечислены UML, BPMN, Postman, но нет ощущения, что человек умеет решать задачу. А в системном анализе всегда оценивают не знание нотаций, а способность разобраться в ситуации и разложить её на понятную систему.
Ещё очень заметно, когда у кандидата нет ни одного живого кейса. Не учебного в стиле «интернет-магазин», а такого, где видно контекст: зачем система, какие ограничения, что может пойти не так. Без этого сложно понять, как человек думает, а именно это и проверяют.
На собеседованиях это проявляется ещё сильнее. Новички часто сразу начинают отвечать на вопрос, не уточнив деталей. Хотя в реальной работе аналитик почти никогда не решает задачу сразу. Он сначала пытается понять, что вообще происходит, кто пользователи, какие есть ограничения, где система будет ломаться. И именно это отсутствие привычки задавать вопросы сразу бросается в глаза.
Есть ещё один момент, который сильно влияет на решение – слишком идеальные представления о системе. Когда человек проектирует всё так, будто нет старых систем, костылей, ограничений бизнеса и срочных правок. В реальности аналитик почти всегда работает в условиях, где всё уже сложнее и менее красиво, и важно это учитывать.
И отдельно стоит упомянуть базовое понимание интеграций. И я уже говорила, что здесь имеется в виду, что система не живёт одна: данные приходят, уходят, ломаются, повторяются. Если этого понимания нет, это сразу видно по ответам.
В итоге проблема обычно не в том, что новичок не дотянул по знаниям, а в том, что он ещё не показывает мышление системного аналитика. Не умеет демонстрировать, как он думает, как разбирает ситуацию и как принимает решения в условиях неопределённости.
И именно это, а не список технологий, решает, возьмут ли тебя на работу/стажировку.
Поэтому я в канале даю не какие-то отдельные инструменты, оторванные от контекста, а информацию, которая поможет понять, что такое система в целом и какие у нее есть ограничения.
Если есть темы, которые вы бы хотели разобрать, пишите в комментариях.
Я довольно часто вижу одинаковую картину у новичков: человек вроде бы что-то знает, прошёл курс, даже умеет делать диаграммы и пишет SQL на базовом уровне. Но на собеседовании или при разборе резюме возникает ощущение, что он не понимает, как выглядит реальная работа аналитика.
Одна из самых частых причин отказа – это фокус на инструментах вместо смысла. В резюме перечислены UML, BPMN, Postman, но нет ощущения, что человек умеет решать задачу. А в системном анализе всегда оценивают не знание нотаций, а способность разобраться в ситуации и разложить её на понятную систему.
Ещё очень заметно, когда у кандидата нет ни одного живого кейса. Не учебного в стиле «интернет-магазин», а такого, где видно контекст: зачем система, какие ограничения, что может пойти не так. Без этого сложно понять, как человек думает, а именно это и проверяют.
На собеседованиях это проявляется ещё сильнее. Новички часто сразу начинают отвечать на вопрос, не уточнив деталей. Хотя в реальной работе аналитик почти никогда не решает задачу сразу. Он сначала пытается понять, что вообще происходит, кто пользователи, какие есть ограничения, где система будет ломаться. И именно это отсутствие привычки задавать вопросы сразу бросается в глаза.
Есть ещё один момент, который сильно влияет на решение – слишком идеальные представления о системе. Когда человек проектирует всё так, будто нет старых систем, костылей, ограничений бизнеса и срочных правок. В реальности аналитик почти всегда работает в условиях, где всё уже сложнее и менее красиво, и важно это учитывать.
И отдельно стоит упомянуть базовое понимание интеграций. И я уже говорила, что здесь имеется в виду, что система не живёт одна: данные приходят, уходят, ломаются, повторяются. Если этого понимания нет, это сразу видно по ответам.
В итоге проблема обычно не в том, что новичок не дотянул по знаниям, а в том, что он ещё не показывает мышление системного аналитика. Не умеет демонстрировать, как он думает, как разбирает ситуацию и как принимает решения в условиях неопределённости.
И именно это, а не список технологий, решает, возьмут ли тебя на работу/стажировку.
Поэтому я в канале даю не какие-то отдельные инструменты, оторванные от контекста, а информацию, которая поможет понять, что такое система в целом и какие у нее есть ограничения.
Если есть темы, которые вы бы хотели разобрать, пишите в комментариях.
🔥7👍3✍2
Как системный аналитик влияет на бизнес-метрики
Начнем с того, что большая часть бизнес-метрик – это следствие того, как система реализована. Ну то есть быстрота, стабильность, понятность интерфейсов, отсутствие ошибок, корректные интеграции! Всё это в итоге превращается в деньги, удержание и рост пользователей. И системный аналитик влияет на это раньше всех, а именно на уровне требований и логики системы.
1. Он влияет на то, что вообще будет сделано
И это самый недооценённый уровень влияния. До разработки любой фичи есть момент, когда кто-то решает:
• делать это или нет
• делать сейчас или позже
• делать полностью или в упрощённом виде
И здесь аналитик не просто фиксирует запрос, а помогает понять: что действительно даёт ценность, а что выглядит важным только на словах.
Иногда одно правильно уточнённое требование убирает фичу, которая бы не дала никакого эффекта на метрики.
2. Он влияет на то, как фича будет работать
Один и тот же бизнес-запрос можно реализовать по-разному. Например, с лишними шагами в процессе, неудобной логикой или доп. ограничениями.
Либо наоборот, можно упростить путь пользователя так, что конверсия растёт просто из-за уменьшения трения.
Системный аналитик здесь влияет через структуру процесса и понимание пользовательских сценариев.
3. Он снижает стоимость ошибок и переделок
Каждая ошибка в требованиях – это переработка разработки, задержка релиза и ухудшение качества продукта. И всё это напрямую влияет на бизнес: скорость вывода фич и способность компании реагировать на рынок.
Хороший аналитик уменьшает количество «мы не так поняли», и это уже влияет на экономику продукта, даже если это не видно в метриках напрямую.
4. Он делает систему предсказуемой
Когда требования хаотичные, продукт становится непредсказуемым, то есть сложно планировать релизы, сложно оценивать сроки и масштабировать изменения.
А ведь предсказуемость – это основа роста. Без неё невозможно стабильно улучшать метрики, потому что команда постоянно тушит пожары.
5. Он влияет на скорость изменений
Если аналитик качественно описывает требования, снижает неоднозначности, заранее учитывает зависимости, то разработка двигается быстрее, а значит компания быстрее тестирует гипотезы и улучшает продукт.
В итоге, мы видим, что системный аналитик не управляет метриками напрямую. Вместо этого он управляет тем, как формируются решения, из которых эти метрики потом рождаются.
Если проще: системный аналитик создает систему, в которой бизнес может быть успешным.
Сохраняйте этот пост, чтобы правильно понимать свою ценность!
Начнем с того, что большая часть бизнес-метрик – это следствие того, как система реализована. Ну то есть быстрота, стабильность, понятность интерфейсов, отсутствие ошибок, корректные интеграции! Всё это в итоге превращается в деньги, удержание и рост пользователей. И системный аналитик влияет на это раньше всех, а именно на уровне требований и логики системы.
1. Он влияет на то, что вообще будет сделано
И это самый недооценённый уровень влияния. До разработки любой фичи есть момент, когда кто-то решает:
• делать это или нет
• делать сейчас или позже
• делать полностью или в упрощённом виде
И здесь аналитик не просто фиксирует запрос, а помогает понять: что действительно даёт ценность, а что выглядит важным только на словах.
Иногда одно правильно уточнённое требование убирает фичу, которая бы не дала никакого эффекта на метрики.
2. Он влияет на то, как фича будет работать
Один и тот же бизнес-запрос можно реализовать по-разному. Например, с лишними шагами в процессе, неудобной логикой или доп. ограничениями.
Либо наоборот, можно упростить путь пользователя так, что конверсия растёт просто из-за уменьшения трения.
Системный аналитик здесь влияет через структуру процесса и понимание пользовательских сценариев.
3. Он снижает стоимость ошибок и переделок
Каждая ошибка в требованиях – это переработка разработки, задержка релиза и ухудшение качества продукта. И всё это напрямую влияет на бизнес: скорость вывода фич и способность компании реагировать на рынок.
Хороший аналитик уменьшает количество «мы не так поняли», и это уже влияет на экономику продукта, даже если это не видно в метриках напрямую.
4. Он делает систему предсказуемой
Когда требования хаотичные, продукт становится непредсказуемым, то есть сложно планировать релизы, сложно оценивать сроки и масштабировать изменения.
А ведь предсказуемость – это основа роста. Без неё невозможно стабильно улучшать метрики, потому что команда постоянно тушит пожары.
5. Он влияет на скорость изменений
Если аналитик качественно описывает требования, снижает неоднозначности, заранее учитывает зависимости, то разработка двигается быстрее, а значит компания быстрее тестирует гипотезы и улучшает продукт.
В итоге, мы видим, что системный аналитик не управляет метриками напрямую. Вместо этого он управляет тем, как формируются решения, из которых эти метрики потом рождаются.
Если проще: системный аналитик создает систему, в которой бизнес может быть успешным.
Сохраняйте этот пост, чтобы правильно понимать свою ценность!
🔥5✍2👏1
Метрики: как аналитик влияет на бизнес-показатели
Помните, я спрашивала, по каким темам вам нужны короткие и прикладные материалы? Вы голосовали за БД, метрики, процессы и интеграции.
Я вас услышала и сделала это – собрала ваши запросы в линейку мини-продуктов, которые можно пройти за вечер и сразу применить в работе.
И продолжаю серию темой, которая напрямую связывает вашу работу с деньгами бизнеса – продуктовые метрики. Хотя некоторым кажется, что метрики – это удел продактов, а аналитик остаётся лишь «передатчиком задач», но это не совсем так.
Если вы ещё не читали пост от 31.05 о том, как аналитик влияет на бизнес-метрики – обязательно загляните, это поможет лучше понять контекст урока.
И сейчас открываю возможность приобрести видеоурок, который закроет этот пробел.
Итак, что внутри:
Вместе с менеджером продукта, Эльвирой Ромашкиной, рассмотрим, зачем системному аналитику нужны продуктовые метрики и как с их помощью усиливать ценность требований.
Вы получите шаблон описания событий и научитесь выделять, отслеживать и анализировать ключевые события в продукте.
А ещё разберём на практике:
✔️Как правильно именовать события и параметры, чтобы с ними было удобно работать всей команде
✔️Как ставить задачу разработке на создание событий: какие поля указывать, типы данных, обязательность параметров
✔️Как анализировать продукт через метрики: строить воронки, считать конверсии, запускать A/B-тесты и валидировать новые фичи
➕вас ждет тест для самопроверки, а доступ к уроку останется навсегда!
При этом стоимость всех материалов всего 1 000 ₽
(Это меньше, чем стоимость одного часа работы аналитика, потраченного на правки из-за криво собранной аналитики)
➡️ Забрать урок: ссылка
Если остались вопросы, пишите @ginfotech_manager
Помните, я спрашивала, по каким темам вам нужны короткие и прикладные материалы? Вы голосовали за БД, метрики, процессы и интеграции.
Я вас услышала и сделала это – собрала ваши запросы в линейку мини-продуктов, которые можно пройти за вечер и сразу применить в работе.
И продолжаю серию темой, которая напрямую связывает вашу работу с деньгами бизнеса – продуктовые метрики. Хотя некоторым кажется, что метрики – это удел продактов, а аналитик остаётся лишь «передатчиком задач», но это не совсем так.
Если вы ещё не читали пост от 31.05 о том, как аналитик влияет на бизнес-метрики – обязательно загляните, это поможет лучше понять контекст урока.
И сейчас открываю возможность приобрести видеоурок, который закроет этот пробел.
Итак, что внутри:
Вместе с менеджером продукта, Эльвирой Ромашкиной, рассмотрим, зачем системному аналитику нужны продуктовые метрики и как с их помощью усиливать ценность требований.
Вы получите шаблон описания событий и научитесь выделять, отслеживать и анализировать ключевые события в продукте.
А ещё разберём на практике:
✔️Как правильно именовать события и параметры, чтобы с ними было удобно работать всей команде
✔️Как ставить задачу разработке на создание событий: какие поля указывать, типы данных, обязательность параметров
✔️Как анализировать продукт через метрики: строить воронки, считать конверсии, запускать A/B-тесты и валидировать новые фичи
➕вас ждет тест для самопроверки, а доступ к уроку останется навсегда!
При этом стоимость всех материалов всего 1 000 ₽
(Это меньше, чем стоимость одного часа работы аналитика, потраченного на правки из-за криво собранной аналитики)
Если остались вопросы, пишите @ginfotech_manager
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍2✍1
Интеграции: дайджест постов за 2026 год
Интеграции – это то самое место, где всё работало на тесте, но сломалось на проде, где аналитик становится переводчиком между системами, которые говорят на разных языках.
Я собрала для вас посты по интеграциям в один дайджест, чтобы вы могли быстро найти ответ, когда вопрос «а как это правильно описать?» возникает в самый неподходящий момент.
Читайте, сохраняйте и используйте в работе:
• Проектирование API с точки зрения безопасности
• Почему это задача аналитика?
• Rate limiting
• Webhooks
• Очереди, webhooks или polling?
• 3 вопроса, которые я всегда задаю перед описанием интеграции
• Стратегии тестирования API: о чём часто забывают аналитики
• Что такое API-first и зачем он нужен
• Стандартизация кодов и форматов ошибок в API
• Версионирование API
• API и бизнес-логика
• Где на практике ломаются даже правильно спроектированные API
Пишите в комментариях, какие еще темы вы бы хотели разобрать?
Интеграции – это то самое место, где всё работало на тесте, но сломалось на проде, где аналитик становится переводчиком между системами, которые говорят на разных языках.
Я собрала для вас посты по интеграциям в один дайджест, чтобы вы могли быстро найти ответ, когда вопрос «а как это правильно описать?» возникает в самый неподходящий момент.
Читайте, сохраняйте и используйте в работе:
• Проектирование API с точки зрения безопасности
• Почему это задача аналитика?
• Rate limiting
• Webhooks
• Очереди, webhooks или polling?
• 3 вопроса, которые я всегда задаю перед описанием интеграции
• Стратегии тестирования API: о чём часто забывают аналитики
• Что такое API-first и зачем он нужен
• Стандартизация кодов и форматов ошибок в API
• Версионирование API
• API и бизнес-логика
• Где на практике ломаются даже правильно спроектированные API
Пишите в комментариях, какие еще темы вы бы хотели разобрать?
🔥7❤2✍1
Тестирование взаимодействия систем
Спешу вас обрадовать – я подготовила материалы для аналитиков, которые устали от плавающих багов в интеграциях и не раз попадали в ситуации, когда 200 OK есть, а данные не ушли, когда QA говорит, что это баг, разработчик – что это фича… Знакомо да?
А проблема здесь в том, что нас не учат тестировать интеграции системно. Мы пишем требования, но часто не знаем, как проверить их на стыке систем и где заканчивается зона ответственности аналитика, а начинается работа QA.
Открываю возможность приобрести 2 урока, которые закроют этот пробел:
✔️Урок 1. Вместе с приглашенным экспертом, Олегом Маврешко, ведущим QA-инженером, узнаём всё о тестировании: роли QA, документацию, виды тестов и ключевые инструменты. А главное – чётко определим, где проходит граница между задачами QA и системного аналитика.
➕презентация и тест для самопроверки
✔️Урок 2. Postman и Swagger
На практике познакомлю вас с инструментами для тестирования API. Вы научитесь уверенно работать с запросами и читать документацию, чтобы проверять интеграции самостоятельно.
➡️ Стоимость уроков: 3 000 ₽
Забрать материалы: ссылка
Если остались вопросы, пишите @ginfotech_manager
Спешу вас обрадовать – я подготовила материалы для аналитиков, которые устали от плавающих багов в интеграциях и не раз попадали в ситуации, когда 200 OK есть, а данные не ушли, когда QA говорит, что это баг, разработчик – что это фича… Знакомо да?
А проблема здесь в том, что нас не учат тестировать интеграции системно. Мы пишем требования, но часто не знаем, как проверить их на стыке систем и где заканчивается зона ответственности аналитика, а начинается работа QA.
Открываю возможность приобрести 2 урока, которые закроют этот пробел:
✔️Урок 1. Вместе с приглашенным экспертом, Олегом Маврешко, ведущим QA-инженером, узнаём всё о тестировании: роли QA, документацию, виды тестов и ключевые инструменты. А главное – чётко определим, где проходит граница между задачами QA и системного аналитика.
➕презентация и тест для самопроверки
✔️Урок 2. Postman и Swagger
На практике познакомлю вас с инструментами для тестирования API. Вы научитесь уверенно работать с запросами и читать документацию, чтобы проверять интеграции самостоятельно.
Забрать материалы: ссылка
Если остались вопросы, пишите @ginfotech_manager
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👏2
БД для системного аналитика
Знакомо ли вам:
• Разработчик говорит про джойны и индексы, а вы киваете, но думаете «я потом погуглю»?
• Нужно описать требования к отчёту, но вы не уверены, как правильно сформулировать запрос, чтобы не получить не то?
• На обсуждении архитектуры теряетесь в терминах: репликация, шардирование, денормализация, и молчите, чтобы не выдать пробел?
• Заказчик просит выгрузку данных, а вы не можете быстро проверить, корректно ли вам прислали результат?
• На собеседовании спрашивают про нормализацию или оконные функции, а вы зависаете?
Системный аналитик без понимания БД работает вслепую: требования получаются размытыми, оценка сложности неточной, а диалог с разработкой напряжённым.
Напомню, что именно поэтому я собрала полноценное обучение по базам данных, чтобы вы перестали «угадывать» и начали говорить с командой на одном языке.
Вот что внутри:
✔️Модуль 1. Проектирование БД
• Процесс проектирования баз данных
• ER-диаграммы: как визуализировать связи
• Структура и нормализация: когда упрощать, а когда дробить
• Системы управления БД: чем отличаются и как выбрать
✔️Модуль 2. Основы SQL. Часть 1
• Язык SQL
• Типы соединений
• Функции агрегирования
• Сортировка и группировка данных
✔️Модуль 3. Основы SQL. Часть 2
• Оконные/аналитические функции для сложных отчётов и метрик
• Представления: как упростить жизнь себе и команде
• Денормализация
• Индексы, секционирование, шардирование: что влияет на скорость и как это учитывать в требованиях
• Репликация данных
🎁 Бонусы:
• Презентации к каждому занятию: скачивайте и используйте как шпаргалку
• Практическое занятие с разбором реальных кейсов
• Тесты для самопроверки после каждого модуля
• Доступ остаётся навсегда
Формат: видеоуроки с приглашённым экспертом-практиком Иваном Чувашовым, который объясняет сложное простыми словами и сразу показывает, как это работает в реальных проектах.
🔥Стоимость: 9 900 ₽
➡️ Забрать курс: ссылка
Если остались вопросы, пишите @ginfotech_manager, помогу разобраться.
Знакомо ли вам:
• Разработчик говорит про джойны и индексы, а вы киваете, но думаете «я потом погуглю»?
• Нужно описать требования к отчёту, но вы не уверены, как правильно сформулировать запрос, чтобы не получить не то?
• На обсуждении архитектуры теряетесь в терминах: репликация, шардирование, денормализация, и молчите, чтобы не выдать пробел?
• Заказчик просит выгрузку данных, а вы не можете быстро проверить, корректно ли вам прислали результат?
• На собеседовании спрашивают про нормализацию или оконные функции, а вы зависаете?
Системный аналитик без понимания БД работает вслепую: требования получаются размытыми, оценка сложности неточной, а диалог с разработкой напряжённым.
Напомню, что именно поэтому я собрала полноценное обучение по базам данных, чтобы вы перестали «угадывать» и начали говорить с командой на одном языке.
Вот что внутри:
✔️Модуль 1. Проектирование БД
• Процесс проектирования баз данных
• ER-диаграммы: как визуализировать связи
• Структура и нормализация: когда упрощать, а когда дробить
• Системы управления БД: чем отличаются и как выбрать
✔️Модуль 2. Основы SQL. Часть 1
• Язык SQL
• Типы соединений
• Функции агрегирования
• Сортировка и группировка данных
✔️Модуль 3. Основы SQL. Часть 2
• Оконные/аналитические функции для сложных отчётов и метрик
• Представления: как упростить жизнь себе и команде
• Денормализация
• Индексы, секционирование, шардирование: что влияет на скорость и как это учитывать в требованиях
• Репликация данных
🎁 Бонусы:
• Презентации к каждому занятию: скачивайте и используйте как шпаргалку
• Практическое занятие с разбором реальных кейсов
• Тесты для самопроверки после каждого модуля
• Доступ остаётся навсегда
Формат: видеоуроки с приглашённым экспертом-практиком Иваном Чувашовым, который объясняет сложное простыми словами и сразу показывает, как это работает в реальных проектах.
🔥Стоимость: 9 900 ₽
Если остались вопросы, пишите @ginfotech_manager, помогу разобраться.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👏1
Самое ценное в создании образовательных продуктов – ваши #отзывы и искренняя обратная связь.
Делюсь отзывом Регины – она работала бухгалтером и решила выучиться на системного аналитика:
«Я работаю бухгалтером, и системный аналитик – совершенно новая и неизвестная для меня профессия. На курсе мне было полезно всё. Мне очень понравилось, что курс структурированный, без воды, огромное количество информации, ненужного не было совсем: тема, выжимка по теме, тестирование, практика. Очень понравилась работа с куратором – тебе помогают, поддерживают, направляют. Это очень ценно. С практикой были сложности, но благодаря куратору все получилось, но куратор не подсказывал, а направлял тебя и твои мысли.
Самое интересное, что после обучения сейчас на работе бухгалтером я даже по-другому начала думать, особенно в работе с отчетами, фильтрации данных и т.д. Раньше я многое собирала, выверяла «ручками», а сейчас думаю, как сделать удобнее и проще. Так что мозг я прокачала на все 100%. И несмотря на то, что изначально я решила изучить профессию для общего развития, то сейчас я намерена попробовать себя в этой роли и пройти стажировку.»
Полную версию отзыва можно посмотреть по ссылке: https://vk.com/video251822710_456239170
Регина, благодарю за искренность и желаю удачи в новой профессии! 🚀
Делюсь отзывом Регины – она работала бухгалтером и решила выучиться на системного аналитика:
«Я работаю бухгалтером, и системный аналитик – совершенно новая и неизвестная для меня профессия. На курсе мне было полезно всё. Мне очень понравилось, что курс структурированный, без воды, огромное количество информации, ненужного не было совсем: тема, выжимка по теме, тестирование, практика. Очень понравилась работа с куратором – тебе помогают, поддерживают, направляют. Это очень ценно. С практикой были сложности, но благодаря куратору все получилось, но куратор не подсказывал, а направлял тебя и твои мысли.
Самое интересное, что после обучения сейчас на работе бухгалтером я даже по-другому начала думать, особенно в работе с отчетами, фильтрации данных и т.д. Раньше я многое собирала, выверяла «ручками», а сейчас думаю, как сделать удобнее и проще. Так что мозг я прокачала на все 100%. И несмотря на то, что изначально я решила изучить профессию для общего развития, то сейчас я намерена попробовать себя в этой роли и пройти стажировку.»
Полную версию отзыва можно посмотреть по ссылке: https://vk.com/video251822710_456239170
Регина, благодарю за искренность и желаю удачи в новой профессии! 🚀
🔥6👏2❤1
«ТЗ готово, но задача не двигается»: почему аналитику критично понимать процессы разработки
Знакомая картина: вы пишете подробное ТЗ, согласовываете его с бизнесом, аккуратно оформляете в Confluence… а задача тихо висит в бэклоге три недели? Или вас зовут на ретроспективу, а вы сидите и думаете: «А что я тут должен говорить?». Или на дейли разработчик спрашивает: «А это в рамках текущего спринта или кидаем в бэклог?», а вы пожимаете плечами.
Спросите себя, а вы понимаете, как вообще работает команда? Где заканчивается дискавери и начинается деливери? Почему приоритеты меняются посреди итерации? Кто на самом деле принимает решение: скрам-мастер, продакт, тимлид или заказчик? Почему в Jira всё живёт по своим законам, а в голове у разработки по другим?
Процессы разработки – это не бюрократия, хотя иногда кажется именно так!
Процессы – это кровеносная система проекта. Если вы не знаете, как по ней течёт информация, ваши требования просто не дойдут до реализации в том виде, в котором вы их задумали.
Аналитик без понимания процессов работает вслепую:
• Пишет идеальную спецификацию, но команда работает по канбану, и задача «тонет» в потоке операционки.
• Приходит на планирование с готовыми Use Case, а команда оценивает риски и story points, и ваше ТЗ превращается в «историю», которую надо дробить.
• Пытается наладить коммуникацию, но не знает, где проходит граница между аналитикой, QA и продактом, и начинает делать работу за всех, выгорая на ровном месте.
Сегодня большинство компаний живут в миксе: Waterfall на стороне бизнеса, Scrum в разработке, канбан-метрики у лида… и аналитик оказывается переводчиком, который не знает грамматики ни одного из языков.
И тут вас выручает знание процессов! Вы перестаёте «скидывать ТЗ в чат», так как:
→ Понимаете, в каком формате и на каком этапе требование должно попасть к команде, чтобы его не переписали три раза.
→ Видите, где процесс создаёт трение, и предлагаете решение, а не жалуетесь на сроки.
→ Говорите с разработкой, тестировщиками и бизнесом на одном языке, потому что знаете правила игры.
В IT реально ценят тех, кто умеет встраивать свою работу в живой процесс без лишнего трения. Умение читать процессы команды – это не софт-скилл. Это базовая компетентность, которая напрямую влияет на то, будут ли ваши требования вообще реализованы.
А вы знаете в чем различие скрама от канбана?
Знакомая картина: вы пишете подробное ТЗ, согласовываете его с бизнесом, аккуратно оформляете в Confluence… а задача тихо висит в бэклоге три недели? Или вас зовут на ретроспективу, а вы сидите и думаете: «А что я тут должен говорить?». Или на дейли разработчик спрашивает: «А это в рамках текущего спринта или кидаем в бэклог?», а вы пожимаете плечами.
Спросите себя, а вы понимаете, как вообще работает команда? Где заканчивается дискавери и начинается деливери? Почему приоритеты меняются посреди итерации? Кто на самом деле принимает решение: скрам-мастер, продакт, тимлид или заказчик? Почему в Jira всё живёт по своим законам, а в голове у разработки по другим?
Процессы разработки – это не бюрократия, хотя иногда кажется именно так!
Процессы – это кровеносная система проекта. Если вы не знаете, как по ней течёт информация, ваши требования просто не дойдут до реализации в том виде, в котором вы их задумали.
Аналитик без понимания процессов работает вслепую:
• Пишет идеальную спецификацию, но команда работает по канбану, и задача «тонет» в потоке операционки.
• Приходит на планирование с готовыми Use Case, а команда оценивает риски и story points, и ваше ТЗ превращается в «историю», которую надо дробить.
• Пытается наладить коммуникацию, но не знает, где проходит граница между аналитикой, QA и продактом, и начинает делать работу за всех, выгорая на ровном месте.
Сегодня большинство компаний живут в миксе: Waterfall на стороне бизнеса, Scrum в разработке, канбан-метрики у лида… и аналитик оказывается переводчиком, который не знает грамматики ни одного из языков.
И тут вас выручает знание процессов! Вы перестаёте «скидывать ТЗ в чат», так как:
→ Понимаете, в каком формате и на каком этапе требование должно попасть к команде, чтобы его не переписали три раза.
→ Видите, где процесс создаёт трение, и предлагаете решение, а не жалуетесь на сроки.
→ Говорите с разработкой, тестировщиками и бизнесом на одном языке, потому что знаете правила игры.
В IT реально ценят тех, кто умеет встраивать свою работу в живой процесс без лишнего трения. Умение читать процессы команды – это не софт-скилл. Это базовая компетентность, которая напрямую влияет на то, будут ли ваши требования вообще реализованы.
А вы знаете в чем различие скрама от канбана?
🔥9👍2❤1
Вчера я писала о том, как незнание процессов превращает аналитика просто в создателя ТЗ, который теряет задачи и выгорает. Но что, если можно перестать гадать и наконец понять, как на самом деле работает IT-команда?
И сегодня я открываю доступ к уроку «Процессы в команде разработки», который закрывает именно этот пробел. Вместе с приглашённым экспертом, Ольгой Окуловой, мы раскроем внутреннюю кухню IT-проектов: как устроены процессы разработки, какие роли бывают в команде и как всё это управляется на практике.
После этой лекции вы будете уверенно ориентироваться в методологиях, артефактах и инструментах управления IT-проектами.
Что внутри урока:
• Где ваше место в структуре организации? И как это влияет на вашу работу?
• Waterfall, Agile, Scrum, Kanban или микс: перестанете путаться в терминах. Разберём, как работает каждый подход, почему в реальности 90% компаний используют гибриды, и как аналитику подстраиваться под любой процесс без стресса.
• Инструменты, которые связывают команду: Jira, Confluence, Miro, Figma, Swagger, GitLab. Когда, зачем и как их использовать, чтобы задачи не терялись, а документация работала на вас.
• Практические правила работы в IT-команде: как изучать документацию (даже неполную), выстраивать отношения с коллегами, правильно задавать вопросы, проявлять инициативу и сохранять work-life balance в условиях спринтов и релизов.
+ тест для самопроверки, а доступ останется навсегда!
🔥🔥При этом стоимость урока всего 1 000 ₽!
➡️ Забрать урок: ссылка
Если остались вопросы, пишите @ginfotech_manager
И сегодня я открываю доступ к уроку «Процессы в команде разработки», который закрывает именно этот пробел. Вместе с приглашённым экспертом, Ольгой Окуловой, мы раскроем внутреннюю кухню IT-проектов: как устроены процессы разработки, какие роли бывают в команде и как всё это управляется на практике.
После этой лекции вы будете уверенно ориентироваться в методологиях, артефактах и инструментах управления IT-проектами.
Что внутри урока:
• Где ваше место в структуре организации? И как это влияет на вашу работу?
• Waterfall, Agile, Scrum, Kanban или микс: перестанете путаться в терминах. Разберём, как работает каждый подход, почему в реальности 90% компаний используют гибриды, и как аналитику подстраиваться под любой процесс без стресса.
• Инструменты, которые связывают команду: Jira, Confluence, Miro, Figma, Swagger, GitLab. Когда, зачем и как их использовать, чтобы задачи не терялись, а документация работала на вас.
• Практические правила работы в IT-команде: как изучать документацию (даже неполную), выстраивать отношения с коллегами, правильно задавать вопросы, проявлять инициативу и сохранять work-life balance в условиях спринтов и релизов.
+ тест для самопроверки, а доступ останется навсегда!
🔥🔥При этом стоимость урока всего 1 000 ₽!
Если остались вопросы, пишите @ginfotech_manager
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👏2👍1