🏳️‍🌈Интервью с выпускницей курса по системному анализу

📎Каждый студент курса мечтает об одном - устроиться на работу.
Сегодня у нас история Леры: ещё недавно она работала в образовании с низкой зп, а теперь она системный аналитик с зарплатой 160 тысяч.
Мы поговорили с ней о пути, трудностях и победах.

➡️ Чем занималась до курса и почему решила пойти в системный анализ?

Лера:
Ох...Занималась много чем, последнее место работы - в образовании. Давно хотела сменить курс.
В айти порекомендовал пойти брат. Купила курс скилбокс BI аналитик, после окончания начала искать работу, но как оказалось, что ты без опыта не нужен никому. А в Скилбокс не особо могли помочь...зп на старте максимум 30 тр.
И в процессе поиска случайно наткнулась на сайт ProSySTalent.
Написала, прошла обучение, собесы, устроилась на работу. Сейчас работаю по аутсорсу, зп 160 тр.

➡️ Что стало главным толчком?

Лера:
Тяжёлый труд и маленькая зарплата)).

➡️ Были сомнения "вдруг не получится" Как с ними справлялась?

Лера:
До сих пор есть!)) Постоянно нужно учиться и развиваться. Уверенность появилась только на работе, когда пошли первые положительные результаты.

➡️ Что было самым увлекательным на курсе?

Лера:
Для меня увлекательно было всё) Нравилось рисовать макеты, чертить схемы.

➡️ Сколько собеседований прошла?

Лера:
До десяти. Но именно второй собес "стрельнул".
Оффер был один, но меня в нём все устраивало, так что долго я не думала и никого с ответом не ждала.

➡️ Что почувствовала, когда получила оффер?

Лера:
Ура! Для меня собесы - это треш))

➡️ С какими трудностями столкнулась в начале и как их решала?

Лера:
Меня сразу кинули на задачи))
Причем API надо было сделать в Свагерре, просидела все выходные и ночи, чтобы изучить. На задачу было 4 дня.
Сдала в итоге вовремя, но чуть не сошла с ума) Ручка вышла на 2000 строк...
Ну и последующие задачи все были малознакомы, пришлось коммуницировать, уточнять.
По итогу всё не так и страшно. Косяки есть у всех, даже у людей с огромным опытом.

➡️ Можешь ли выделить, что больше всего нравится в профессии системного аналитика?

Лера:
На моём проекте мы не только СА, мы - фуллстек, нужно уметь делать все.
Последнее время были задачи по БА, там у меня вообще огонь!)
А из СА точно могу сказать, что рисовать схемы, стори и кейсы мне зашли больше.
Нравится, когда у тебя получается и положительный фидбек.

➡️ Сколько часов в день работаешь?

Лера:
Обычно не больше 8 часов, не нужно убиваться) Последние недели просто сидим, задачи все закрыли.

➡️ Что изменилось в жизни после выхода в профессию?

Лера:
Мне нравится то, чем я занимаюсь. И конечно с ростом бюджета появляется много возможностей)

➡️ Твой главный совет тем, кто сейчас учится и тем, кто задумывается начать обучение?

Лера:
Не бойтесь пробовать новое, у вас все получится, нужно немного сил и терпения.

➡️ Какие ближайшие планы?

Лера: Хотим купить дом) И отдыхать начали 2 раза в год, при условии, что у меня двое детей)

🖐В заключении 🖖

🔓История Леры - пример, что системный анализ открывает новую жизнь:
из образования ➡️ в IT с высоким доходом, удалёнкой и планами о собственном доме🔓

👉 А на курсе ProSySTalent мы учим системному анализу так, чтобы после выпуска реально можно было пройти собеседования и устроиться на работу.😎

Аналитик и дизайнер: любовь, логика и пиксели

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

🎨 Когда логика встречает ✨эстетику✨

У начинающего аналитика часто появляется соблазн отойти в сторону:

Дизайн - не моя зона ответственности. Пусть дизайнер сам решает, где какие кнопки. 😄

А потом наступает демо...ты смотришь на макет....и видишь: красиво, модно, всё ровненько,
только вот бизнес-логика плачет в сторонке.

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

👍 Почему аналитик должен участвовать в дизайне?
Потому что именно ты знаешь контекст задачи: кто пользователь, зачем он сюда пришёл, и чего мы вообще хотим добиться.
Без этого понимания дизайнеру тяжеловато: он рисует интерфейс 🖐по ощущениям 🖖, а не по логике.

📎Вот пример

Кнопка "Отправить" стоит до поля для ввода.
Нет обозначения обязательных полей.
Подсказка спрятана, потому что 🖐так красивее 🖖.

И всё, сценарий пошёл вообще не так, как надо....

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

📎Ещё пример:

👨‍🎨 Дизайнер: "Я уберу подсказку, она мешает".
💻 Аналитик: "Если её убрать, пользователь не поймёт, что поле обязательное. Система вернёт ошибку".

Но есть выход - вместе находим вариант, где и красиво, и работает.

🧠 Фразы, которые спасут ваши нервы

✔️"Супер выглядит! Можно я уточню сценарий?"

✔️"А давай посмотрим глазами пользователя?"

✔️"Мне нравится, но тут может сломаться бизнес-логика".

✔️"А если сделать вот так, что думаешь?"

И самая проверенная 😎

✔️"Заказчик сказал сделать так, значит придётся так"


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

📁📂 Интеграция: с чего начать разбираться

Этот месяц посвятим интеграции - тому, как системы обмениваются данными и зачем всё это нужно бизнесу.

🟰 Что такое интеграция?

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

⏭ Пример ⏮

Представь, есть сайт, где пользователь оформляет заказ, и есть отдельная система склада.
Когда заказ создан, сайт должен передать данные о нём на склад, чтобы там зарезервировали товар.
Это и есть🟡интеграция🟡: сайт отправляет запрос, склад отвечает, что заказ принят.

📌 Передача может идти по-разному:

➡️ через API - когда один сервис обращается к другому по
HTTP-запросу
(например, POST /createOrder)
➡️ через обмен файлами - CSV, XML или JSON, которые передаются по расписанию.
➡️ через брокер сообщений - очередь, куда система кладёт события, а другая их читает.

📌 Зачем это нужно?

➡️ Чтобы не вводить одни и те же данные вручную и не терять информацию между системами.
Если интеграция выстроена правильно, то данные попадают туда, куда нужно, а пользователи даже не задумываются, что внутри происходят десятки обменов.

📌 Роль аналитика в интеграции

➡️ Аналитик описывает правила этого обмена.
Он отвечает за то, чтобы обе стороны одинаково понимали:

🔸какие поля передаются (и их типы)
🔸какие методы вызываются
🔸что возвращается в ответе
🔸как обрабатываются ошибки
(например, 400 Bad Request или 500 Internal Server Error).

✅ Также аналитик фиксирует три вещи:

🔸Триггер - что запускает интеграцию
(например, создание документа).
🔸Формат - как выглядит запрос и ответ
(JSON, XML, CSV).
🔸Условия синхронизации - когда и как часто данные передаются.

👀 Что будет дальше?
В следующих постах мы поговорим о подробнее о том,
🔸как читать API-спецификации и понимать структуру методов;
🔸чем REST отличается от SOAP
(и почему их часто сравнивают)
🔸зачем нужны брокеры сообщений и сервисные шины

⏭и как аналитик оформляет всё это в требованиях, чтобы разработчики понимали друг друга⏮

⚙️ API и спецификации: как в них не запутаться (часть 1)

⭐️Привет!⭐️
Продолжаем цикл про интеграции.
Сегодня разберёмся, что такое API и зачем аналитику вообще туда смотреть.

📎 Что такое API простыми словами

API - это способ, с помощью которого одна система обращается к другой.
Можно представить, что это меню в кафе:
Ты выбираешь блюдо (метод), добавляешь параметры (например, “без лука”), отправляешь заказ и ждёшь ответ.

Запрос выглядит примерно так:

POST /login
{
  "login": "user@mail.ru",
  "password": "1234"
}

А в ответ приходит:

{
  "status": "ok",
  "userId": 42
}

Вот и всё. Система сказала: "Принято, вот твой ID".

📎 Что хранится в спецификации

Чтобы все понимали, как вызывать методы и какие данные ждать, создают ⏭спецификацию⏮
В ней описано:
🔵адреса методов
(например, /login, /user),
🔵типы запросов
(GET, POST, PUT, DELETE),
🔵параметры
(обязательные и необязательные)
🔵структура тела запроса и ответа,
🔵коды ошибок и их расшифровка

➡️ Для REST-сервисов часто используют Swagger (он же OpenAPI) - можно открыть в браузере и прямо кликнуть по методу, чтобы увидеть пример.

➡️ Если же API работает через JSON-RPC, структура немного другая:

{
  "jsonrpc": "2.0",
  "method": "user.getInfo",
  "params": { "userId": 42 },
  "id": 1
}

А ответ приходит с тем же id и результатом внутри result.

📎Что важно аналитику

1️⃣Понимать источник данных.
Откуда метод берёт информацию и что возвращает: база, внешний сервис, кэш.

2️⃣Фиксировать форматы.
Например, дата может быть 2025-10-13 или 13.10.2025. Если не уточнить - потом будет весело...

3️⃣ Уточнять ошибки.
Что значит 400, 401, 500, и что делает система в каждом случае.

4️⃣ Следить за связями.
Методы редко работают поодиночке. Часто один вызывает другой, и важно понять цепочку.

📎 Что дальше?
В следующем посте разберём тело запроса и ответа детальнее:
где headers, где body, зачем нужны query-параметры и как по спецификации понять, что и откуда приходит.

📩 Если у тебя API вызывал страх или скуку - самое время разобраться!
Поставь напоминание на следующую часть, чтобы не потерять нить)

⚙️ API и спецификации: часть 2 - что внутри запросов и ответов

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

Посмотрим, из чего состоит запрос и как читать структуру ответа.📖

🔖Запрос: из чего он состоит

Когда система просит что-то у другой системы, она отправляет запрос.
У запроса три основные части:

1️⃣ Endpoint - это адрес, куда идёт обращение, например:

POST https://api.site.ru/user/create

2️⃣ Headers - это техническая шапка запроса.
В ней хранятся метаданные: тип контента, авторизация, ключи.
Например:

Content-Type: application/json  
Authorization: Bearer token123

3️⃣Body - тело запроса, где лежат сами данные.
Иногда вместо body данные передают через query-параметры (после вопросительного знака):

GET /user/get?userId=42

🔖 Ответ: что приходит обратно

Сервер всегда что-то возвращает. Даже если это ошибка.
Обычно структура такая:

{
  "status": "ok",
  "result": {
    "userId": 42,
    "name": "Алексей"
  }
}

Если что-то пошло не так, приходит ошибка:

{
  "status": "error",
  "code": 401,
  "message": "Unauthorized"
}

©️Для REST-сервисов ошибки часто сопровождаются HTTP-кодом: 200 (успешно), 400 (ошибка клиента), 500 (ошибка сервера).
©️А в JSON-RPC обычно приходит поле error с описанием.

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Invalid params",
    "data": {
      "field": "userId"
    }
  }
}

Поле error всегда содержит код, сообщение и, при необходимости, дополнительные данные.
Это помогает понять, где именно ошибка: в запросе, авторизации или логике метода.

🔖Что смотреть аналитику

✅ Проверяй, какие поля обязательные.
✅ Сверяй типы данных (int, string, boolean).
✅ Уточняй, что делает система при ошибке: пишет в лог, показывает сообщение пользователю, шлёт уведомление.
✅ И всегда проверяй примеры - они часто точнее, чем текстовое описание.

В следующем посте пойдём дальше - сравним REST и SOAP, разберёмся, чем они отличаются и почему от одного из них уже все устали...😳

💬 Если стало чуть понятнее, как устроены запросы, то ты уже на полпути к пониманию интеграций!
Сохрани пост, чтобы не потерять продолжение)

☑️ Чек-лист идеального сотрудника для компании

Считаете, что застряли на месте в компании и не понимаете как расти дальше? Хотите, но боитесь попросить повышение? Боитесь стать ненужным сотрудником, которого вот-вот могут уволить?

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

1️⃣Иметь гибкое мышление и быть готовым учиться новому
Должно быть так:

Не знаю сейчас, но это нужно для работы - значит изучу

Мир технологий очень гибок, даже банальная смена инструмента с Postgres на Clickhouse или миграция с Power BI на Datalens проверяет сотрудников кто может быстро приспособиться к новым реалиям внутри компании. Не хочешь меняться, а работать только с одной привычной технологией - рано или поздно ты станешь не нужен.

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

3️⃣Уметь ошибаться
Накосячил - принял этот факт - порефлексировал и сделал разбор ошибок - сделал выводы. Плохой сотрудник не тот кто ошибается, а тот кто делает одну и ту же ошибку повторно, не сделав из этого никаких выводов.

4️⃣ Иметь хорошие soft-навыки и эмоциональный интеллект
Компания не будет терпеть токсичных, не умеющих работать в обществе сотрудников, это разрушает и демотивирует коллег вокруг. У нас был такой кейс на стажировке - парень был технически сильный, но были неоднократные кейсы токсичности с коллегами. Пришлось попрощаться со стажером в первые недели стажировки.
У всех бывает плохое настроение или можно попросту вспылить в моменте. Это норм, но стоит извиниться после таких ярких ситуаций и стараться все же не повторять их в будущем.

5️⃣ Быть проактивным
Менеджеры очень любят это качество. Кричать громче всех о своих достижениях, рассказывать на широкий круг о результатах своей работы. Также ценится, когда сотрудник не только решает поставленные задачи, но и предлагает свои идеи и мысли по улучшению проекта/продукта и решений, участвовать в постановке целей ил планировании. Ну здесь понятно - чем больше делаешь за те же деньги, тем ты ценней. Надо понять что повышения в компаниях работают по принципу:
1) расширил свою зону ответственности, стал выполнять боле сложные проекты
2) если справляешься, то через время (полгода или год, в зависимости от компании) получил повышение

Многие ожидают что:
1) сначала получил повышение
2) после этого ты готов брать на себя больше, ведь за это уже платят
Увы, но работает не так

6️⃣Иметь сильную техническую компетенцию
Имея все пункты выше, но при этом быть слабым специалистом технически - увы, но ценность как исполнителя твоя будет не велика. В оценку сотрудников всегда закладываются технические компетенции его роли. Поэтому нужно иметь твердые компетенции в любом случае, чтобы справляться со своими прямыми обязанностями в работе.

❤️ если пост был полезен тебе

⚙️ REST, SOAP и всё, что между

👉 Когда начинаешь разбираться в интеграциях, эти три слова всплывают постоянно.
REST, SOAP, RPC: вроде все про одно, но работают по-разному.

Разложим по порядку ⬇️

©️REST - это стиль, по которому строятся HTTP-интерфейсы©️
Не стандарт и не протокол, а просто набор принципов взаимодействия.
Каждый метод делает своё:

▫️GET 👉 получить данные
▫️POST 👉 создать
▫️PUT 👉 обновить
▫️DELETE 👉 удалить

🔻Запрос выглядит просто:

GET /user/42  
POST /order/create

🔻Ответ приходит в JSON формате - коротко и читаемо.
🔻REST-сервисы легко тестировать: можно дернуть запрос из Postman или curl и сразу увидеть результат.

🔻Запоминаем: REST популярен, потому что гибкий и лёгкий в поддержке.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️

©️SOAP - старший брат, строгий и формальный©️
Он использует XML и жёсткую структуру.
К каждому сервису прилагается файл WSDL - в нём расписаны методы, параметры и типы данных.

🔹Пример SOAP-запроса:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUserInfo>
      <UserId>42</UserId>
    </GetUserInfo>
  </soap:Body>
</soap:Envelope>

🔻Запоминаем: SOAP работает надёжно, но тяжеловато.
Он чаще встречается в гос- и банковских системах: там, где важна стабильность и проверка форматов, а не скорость.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️

©️Есть и промежуточный формат JSON-RPC - формат обмена, где всё чётко и предсказуемо©️
Без URL-структуры, только метод и параметры:

{
  "jsonrpc": "2.0",
  "method": "user.getInfo",
  "params": { "userId": 42 },
  "id": 1
}

🔻Запоминаем: он проще, чем SOAP, но строже, чем REST: структура фиксирована, логика централизована.
Используется там, где сервисов много и REST уже не так удобен.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️

👉 Что выбрать?

✅REST ➡️ для быстрых и простых интеграций.
✅SOAP ➡️ когда важна стабильность и проверка схем.
✅JSON-RPC ➡️ для сервисов, где нужно множество вызовов и своя бизнес-логика.

✅А ещё есть GraphQL ➡️ подход, где клиент сам выбирает, какие поля получить.
(но об этом в другой раз)
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️

👉 Что важно аналитику?

✅Проверить, какой тип API используется на проекте и где лежит описание - Swagger или документация вручную.
✅Уточнить, как происходит авторизация (токен, логин-пароль, сертификат).
✅Зафиксировать структуру запроса и формат данных.
✅Не путать: REST - это стиль, SOAP - протокол.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
В следующем посте разберём REST подробнее:
какие методы идемпотентные, когда можно использовать POST вместо GET и чем отличаются PUT и PATCH.

⚙️ REST: тонкие моменты, о которых спрашивают на собеседованиях

REST кажется простым, пока не начинается собес...
Там уже не спрашивают, что делает GET, а копают глубже.
Про ➡️ идемпотентность, ➡️ коды, ➡️ можно ли использовать POST вместо GET и ➡️ чем вообще PATCH отличается от PUT.
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

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

➰ GET /user/42 - вернёт того же пользователя.

➰ DELETE /user/42 - удалит один раз, второй вызов ничего не изменит.

➰ PUT /user/42 - тоже идемпотентен, если передать те же данные.

➕ POST /user/create - нет: при повторе создаст новую запись.

❓Можно ли сделать POST идемпотентным

Да, если система умеет узнавать дубли, например, по requestId. (id самого запроса)
Второй такой же запрос просто проигнорируется.
Но это уже логика приложения, а не свойство метода.

❓А можно ли использовать POST вместо GET

➕ По RESTful принципам - нельзя.

➖ В реальной жизни - можно, если есть веская причина.

Например, когда нужно передать тело запроса (сложный фильтр или большой список параметров), то выбирают POST, даже если данные просто читаются.
GET не поддерживает тело, а длина адресной строки ограничена.

🔸На собесе можно сказать так:

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

🔸И закрепи коды, которые стоит помнить

➡️ 200 - всё хорошо.

➡️ 201 - создан новый ресурс.

➡️ 204 - успех, но без тела

➡️ 400 - ошибка в запросе.

➡️ 401 - не авторизован.

➡️ 403 - доступ запрещён.

➡️ 404 - не найдено.

➡️ 500 - ошибка на сервере.

❓ Любимый вопрос интервьюеров: чем отличаются 401 и 403?

Простой ответ:

➡️ 401 - пользователь не авторизован.
➡️ 403 - авторизован, но прав нет.

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩
📎PUT и PATCH - не одно и то же

➰ PUT заменяет ресурс целиком.
Если передать в PUT половину данных, то сервер может “стереть” остальное.

➰ PATCH обновляет только указанные поля.
А вот PATCH аккуратнее, он просто дополняет.
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

📎Про безопасность

Не стоит использовать GET для передачи конфиденциальных данных.
Все параметры в этом случае видны в URL, могут попасть в логи или историю браузера.
Для таких случаев лучше подходит POST, потому что его тело не отображается в адресной строке.

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩
📎А ещё ➰ про версии API

REST-сервисы живут годами.
Методы меняются, поля добавляются, что-то устаревает.
И если просто взять и “обновить под новую логику” ➕ старые интеграции сломаются.
Чтобы этого не случилось, вводят версии API.

🟢Обычно это выглядит так:

➡️ /api/v1/user/get
➡️ /api/v2/user/get

Версия v1 продолжает работать как раньше,
а v2 добавляет новые поля или правила.
Если ты описываешь API в документации, всегда указывай, какая версия актуальна и что изменилось.
И добавляй мини-блок “История изменений” - он экономит часы на переписке.

📎 И напоследок, ещё каверзный вопрос:

Почему PUT идемпотентен, если он меняет данные?

➖ Отвечай так:

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

В целом REST несложная штука.
Главное понимать, как она устроена и какие последствия у каждого запроса)

💬 Если тебя хоть раз спрашивали про идемпотентность и ты начал тянуть время, вспоминая примеры, этот пост можно считать репетицией.
Сохрани, пригодится!

🧾 Как аналитикам описывать API в Confluence

Хорошее описание API экономит часы работы!
Если спека написана понятно, разработчик реализует метод без уточнений, а тестировщик проверит всё без лишних вопросов👍
❌С чего начать 👇

1️⃣Начни с короткого контекста:

⚪️зачем вообще нужна интеграция?
⚪️кто кого вызывает?
⚪️в каком случае срабатывает обмен?
Пара предложений и человек уже понимает, что делает этот API, даже не глядя в JSON.👍

2️⃣Добавь базовые параметры:
Эта информация всегда нужна первой👇

⚪️протокол: HTTP или HTTPS
⚪️формат данных: JSON или XML
⚪️тип API: REST или JSON-RPC
⚪️способ авторизации: токен, сертификат, логин/пароль
⚪️кодировка.
Без этого даже лучший пример не спасёт...😞

3️⃣Распиши методы
После небольшого описания концепта начинается структура.
Пиши одинаково для всех методов, чтобы глаза не спотыкались, вот пример 👇

Метод: POST /user/create
Назначение: создаёт пользователя
Входные данные: email, password
Ответ: статус и id пользователя
Пример запроса:

{
  "email": "user@mail.ru",
  "password": "1234"
}

Пример ответа:

{
  "status": "ok",
  "userId": 42
}

4️⃣ Укажи ошибки
Не обязательно составлять целый справочник, достаточно короткого списка👇

400 👉 неверный формат запроса
403 👉 доступ запрещён
404 👉 не найдено
500 👉 ошибка на сервере

5️⃣Покажи последовательность
Если методы связаны между собой, то добавь один абзац об этом👇

Сначала /auth/login, потом /user/getInfo.
Если первый вызов неуспешен 👉 возвращаем 401, дальше не идём.

Так тестировщикам проще понимать, что и за чем идёт.

6️⃣Подпиши версию и изменения (это опционально)
Если API развивается, всегда указывай версию: /api/v2/user/get.
А под методами добавь блок “Что изменилось”:
⚪️новые поля
⚪️форматы
⚪️статусы
Через месяц это сэкономит тебе больше времени, чем кажется)

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

📬 Брокеры сообщений: зачем они нужны

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

🤔 Что делает брокер❓

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

⁉️ Как всё устроено❓

➡️Продюсер (отправитель) публикует сообщение.
➡️Брокер сохраняет его в очередь.
➡️Консьюмер (получатель) забирает, когда готов обработать.
❕Если получателей несколько - брокер может отправить сообщение всем сразу.

😐 Зачем это нужно❓

☑️Чтобы данные не терялись, даже если один сервис “лежит”
☑️Чтобы разгрузить системы и не заставлять их ждать друг друга
☑️Чтобы можно было обрабатывать события асинхронно, в фоне.

🙂 Пример из жизни

☑️ Интернет-магазин получил заказ.
➡️ Система заказов отправляет сообщение в очередь: “новый заказ создан”.
➡️ Дальше его подхватывают другие сервисы: склад резервирует товар, бухгалтерия создаёт документ, доставка строит маршрут.

💾Если один из них временно недоступен - ничего страшного.
Брокер дождётся и передаст сообщение, как только тот вернётся.

💾Популярные брокеры

RabbitMQ ➡️ простой и надёжный, с очередями и подтверждениями доставки.
Kafka ➡️ для больших потоков событий и быстрой обработки.
ActiveMQ, Redis Streams ➡️ встречаются реже, но делают то же самое.

🤨Что важно знать аналитику❓

✔️Кто отправитель, а кто получатель
✔️Какой формат сообщения (JSON, XML, просто текст)
✔️Что делает система, если брокер недоступен
✔️Как обрабатываются ошибки и повторы.

☝️Брокер - это связующее звено между системами.

💬 Если на проекте всё ломается, когда один сервис падает, то возможно, что там как раз не хватает брокера)
Сохрани этот пост, пригодится, когда дойдёшь до Kafka или RabbitMQ.

📡 Kafka: когда сообщений слишком много.

В прошлом посте мы разобрались, зачем вообще нужны брокеры сообщений.
Теперь пойдём глубже 👉 поговорим про одну из самых известных систем: ⏭Kafka⏮
Она не просто передаёт данные, а умеет держать огромные потоки событий, не теряя ни байта информации.

📎 Что такое Kafka?

Это распределённая система для обмена потоками сообщений.
Её задача не просто доставлять данные, а удерживать поток.
Можно перечитывать историю, возвращаться назад или подключаться к нужному моменту, как к записи эфира.

📎 Как она устроена?

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

💡 Пример:

👉 сервис заказов пишет событие “создан заказ” в топик "orders"
👉сервис аналитики слушает топик "order" и считает статистику.
👉сервис уведомлений тоже подписан на топик "orders", чтобы отправить письмо клиенту.
В итоге каждый "читатель" работает независимо, не мешая другим.

📎 Чем Kafka отличается от обычной очереди?

В RabbitMQ сообщение исчезает после обработки.
В Kafka оно остаётся.

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

📎 Когда она нужна?

✅Когда поток событий идёт постоянно: логи, клики, заказы, метрики.
✅Когда важно не потерять ни одного сообщения.
✅Когда системы обрабатывают данные параллельно, а не по очереди.

Kafka особенно полезна там, где всё крутится вокруг данных: маркетплейсы, платёжные сервисы, аналитика, телеметрия.

📎 Что важно знать аналитику или "от меня что требуется?"😐

‼️какие топики существуют и какие события туда пишутся
‼️кто продюсер (отправляет), а кто консьюмер (читает)
‼️какие гарантии нужны: “хотя бы один раз” или “ровно один раз”
‼️как долго хранятся сообщения (retention).

Kafka выдерживает огромные нагрузки и хранит историю, как хронику системы.

💬 Если RabbitMQ - это надёжная почта, то Kafka - это радиоэфир: все слушают, но каждый выбирает, с какого момента включиться.

📬🐰RabbitMQ: просто, надёжно и понятно

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

Вот тут вступает ⏭RabbitMQ⏮👉 брокер, который делает всё просто и надёжно.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
❣️Когда одна система отправляет данные другой, обычно всё происходит напрямую: запрос 👉 ответ.
Но если получатель временно недоступен, сообщение теряется...😢
RabbitMQ решает эту проблему, он: 1️⃣берёт сообщение,2️⃣складывает в очередь,3️⃣ждёт, пока кто-то его заберёт.

❌Представь бережливого курьера:
Он не бросает посылку у двери, а хранит её у себя, пока получатель не получит и не откроет.
Если не получилось доставить 👉 попробует снова.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
❣️В RabbitMQ всё крутится вокруг очередей:
👉 Отправитель - это producer
👉 Получатель - это consumer
👉 Между ними есть посредник - exchange
Он решает, в какую очередь положить сообщение и кто его получит.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Иногда сообщение нужно передать конкретному сервису 👉 тогда используется direct exchange.
А иногда 👉 всем сразу, например, при создании нового заказа, 👉 тогда fanout.
А если сообщений много и они разного типа, подключается topic exchange, который умеет фильтровать их по шаблонам вроде order.created или order.cancelled.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Самое приятное 👉 надёжность.
Когда получатель забрал сообщение и обработал его, он отправляет брокеру подтверждение 👉 ack.
Если подтверждения нет, сообщение возвращается обратно.
Ничего не пропадает, просто откладывается “на потом”.

Можно даже настроить, чтобы несколько сервисов забирали сообщения параллельно 👉 очередь распределяет их сама.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🐰RabbitMQ не пытается быть универсальным решением.
Он просто делает своё дело: хранит, доставляет и повторяет, если нужно.
Поэтому его особенно любят там, где важна стабильность и предсказуемость.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
📌 Для аналитика важно знать не только, что “где-то там брокер”, а:
⚪️какие очереди есть
⚪️какие сервисы их слушают, и что происходит, если доставка не удалась.
👉 Эти детали решают половину проблем при интеграции.
〰️〰️〰️〰️〰️〰️〰️〰️
🐰RabbitMQ 👉 это та самая система, которая не суетится)
Она не ломается от нагрузки и не теряет данные, просто доставляет точно и вовремя.

💬 Если Kafka 👉 это радио, где всё звучит одновременно,
то RabbitMQ 👉 это почтовое отделение: письма лежат в ящике и ждут, пока их аккуратно разберут.

🔗 Сервисная шина против брокеров 🔗

Мы уже поговорили про брокеры: Kafka держит потоки, RabbitMQ передаёт сообщения надёжно.
Но представь, что систем становится десятки.
Каждая связана с каждой и теперь у тебя паутина, где одно изменение может задеть половину проекта.

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

Брокер - это просто транспорт: отправил ➡️ доставил.
Но он не думает кому это нужно, в каком порядке и что делать дальше.
Если систем много, без координации начинается путаница:
каждая пишет другим напрямую, логику обмена никто не контролирует.

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

❓Что делает шина?

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

Сервис отправляет сообщение “новый заказ создан” ➡️ шина решает, кому это важно: складу, бухгалтерии, CRM.
Если нужно, меняет формат данных и отправляет каждому в его виде.

Можно сказать, что шина - это брокер с мозгами)

↖️ Пример из жизни

Допустим, у тебя десяток систем: заказы, платежи, уведомления, аналитика.

🫡Без шины между ними десятки точек связи, и любое изменение превращается в квест.
🙏С шиной у каждой системы одно соединение 👉 к шине.

Они не знают друг о друге, но всё работает.

❓Чем отличается от брокера?

1️⃣ Брокер просто хранит и доставляет сообщения.

2️⃣ Шина управляет маршрутизацией, преобразованием данных и контролем потоков.
У шины есть правила, мониторинг, логирование и даже возможность “приостановить” интеграцию.

❓Когда стоит использовать шину?

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

Для аналитика шина ➡️ это как панель управления интеграциями.
Ты видишь, что с чем связано, какие форматы проходят, где упало и почему.
И это уже не просто обмен данными, а полноценная архитектура!

⚪️Но помни
Шина не всегда обязательна, если у тебя пара систем, то хватит и RabbitMQ.
Но когда связей становится слишком много, без шины проект превращается в клубок...

💬 Поэтому запоминаем:
✅ брокер отвечает за доставку, ✅шина отвечает за порядок.
И когда данных становится слишком много, порядок - это тоже интеграция)

⚙️ Хореография и оркестрация микросервисов

🙂Когда систем становится много, то их взаимодействие уже не похоже на прямой диалог “запрос ⤵️ ответ”.
Каждая система что-то делает, реагирует на события других, запускает свои процессы.
И тут важно не просто знать “кто с кем общается”, а кто управляет этим взаимодействием.🙂

💡 Есть два подхода: хореография и оркестрация.

Хореография ➡️ когда всё само работает.

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

💬 Одна система отправляет сообщение “заказ создан”, и дальше никто ни с кем не согласовывает, остальные просто реагируют.
💬 Склад резервирует товар, бухгалтерия создаёт счёт, CRM обновляет статус клиента.

Никакого центрального координатора нет.
Такой подход прост и гибок: добавляешь новый сервис и он просто подписывается на нужные события.

🙂Но и минусы очевидны: если в цепочке что-то пошло не так, найти причину сложнее, потому что событий много, логики централизованной нет.

Оркестрация ➡️ когда есть управляющий центр.

Здесь появляется отдельный компонент - оркестратор.
Он знает последовательность шагов и управляет ею👇

✅Создать заказ
✅Проверить оплату
✅Подтвердить склад
✅Отправить уведомление

Если что-то падает 👉 оркестратор понимает, где именно, и решает, откатить ли процесс или повторить попытку.
Это похоже на режиссёра, который координирует актёров: каждый играет свою роль, но по единому сценарию)

🤨 Как выбрать подход?

➡️Хореография: когда важно, чтобы сервисы были максимально независимыми и легко подключались к общей экосистеме.

➡️Оркестрация: когда нужен контроль, чёткий порядок действий и прозрачная логика.

На практике часто комбинируют: часть процессов живёт “по событиям”, а ключевые шаги управляются оркестратором.

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

🔄 Обратная связь в интеграциях:
WebSocket, Webhook, Callback и Fallback
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

🆖 Мы уже разобрались, как системы обмениваются сообщениями.
Теперь пора поговорить о том, как они дают ответ.

🆖 Потому что иногда интеграция похожа на общение:
один пишет, второй читает, третий “я занят, перезвоню позже”, а четвёртый вообще молчит до последнего.
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

🔵 WebSocket - это когда обе стороны на связи

Другими словами, WebSocket ➡️ это постоянное соединение.👍
Не “отправил запрос ➡️ получил ответ”, а более честно:
"Я здесь, ты здесь, давай держать линию открытой"

🤔 Как это выглядит:

➡️ клиент подключился
➡️ сервер держит соединение открытым;
➡️ как только что-то изменилось - клиент узнаёт мгновенно.

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

🔵 Webhook ➡️ когда тебя честно предупреждают

То есть Webhook ➡️ это когда система говорит:
"Я позвоню сама, не жди меня у порога" 👍

🆖 Ты даёшь URL, а внешняя система сама отправляет туда запрос, когда у неё произошло событие.

✔️ Типичный случай:

Платёж прошёл ➡️ платёжка прислала тебе уведомление ➡️ ты обновил статус заказа.

Никаких постоянных опросов, никакого “а что там у них?”. Webhook сам всё расскажет.
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

🔵 Callback ➡️ внутренний “готово!”

🆖 Callback ➡️ это как локальный webhook для своих.
Один сервис выполняет долгий процесс, а потом вызывает твой обратный метод:
"Всё, закончил, можешь продолжать работу".

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

❗️Если webhook ➡️ это уведомление от платёжки,
то callback ➡️ уведомление от другого вашего микросервиса.
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

🔵 Fallback ➡️ способ не сорваться в тишину.

И вот самый жизненный механизм. Fallback ➡️ это запасной план.
Когда основной сервис внезапно “ушёл покурить”, а пользователю нужно показать хоть что-то.😖

🆖 Что делают:

➡️ возвращают данные из кэша
➡️ подставляют упрощённый ответ
➡️ повторяют попытку через время
➡️ идут по запасному маршруту

🆖 Типичная ситуация:

Сервис профиля лежит ➡️ возвращаем последний сохранённый профиль ➡️ обновляем позже.
Пользователю хорошо, системе тоже не больно)

🤏Как легко отличать всё это?

➡️ WebSocket - постоянное соединение.
Почти как телеграм чат: написал ➡️ сразу прилетело.

➡️ Webhook - уведомление от внешней системы.
Как доставка: "Ваша посылка прибыла в пункт выдачи".

➡️ Callback - уведомление от своей же системы.
Как коллега: "Я всё сделал, смотри".

➡️ Fallback - запасной сценарий.
Как когда интернет пропал, а видео всё равно доигрывает из буфера - примерно та же логика.

💬Если раньше эти четыре слова казались чем-то туманным, то теперь ты точно можешь объяснить их человеку без диаграмм и UML.
А значит ➡️ пост справился со своей миссией 😎.💬

🧩 Интеграция глазами аналитика

😏 За этот месяц мы разобрали многое:
REST и SOAP, брокеры, Kafka, RabbitMQ, шину, оркестрацию.
Снаружи всё это кажется сложным, но внутри - лишь логика и здравый смысл)

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

👉Спрашивать себя:

❓кто инициирует процесс
❓куда идут данные и зачем
❓что будет, если один из участников “молчит”
❓как понять, что всё сработало правильно

Интеграция - это всегда история о надёжности и она не должна зависеть от удачи.

‼️Поэтому хороший аналитик видит не только, что передаётся, но и почему именно так.‼️
Он умеет объяснить, зачем нужен брокер, почему REST подходит здесь, а SOAP - там.

👉Иногда интеграция выглядит просто: “отправили - получили”.
🔻Но на деле за этим стоит десяток решений, проверок и точек синхронизации.
И именно аналитик держит этот контур в порядке.

💬 Сохрани эти посты, перечитай через пару месяцев и посмотри, как изменится твой взгляд на интеграции)

👉Что такое система и зачем аналитику видеть её целиком

Так, с интеграцией вроде разобрались.
Теперь перейдём к тому, о чём почти не пишут, но что отличает аналитика, который “делает задачи”, от аналитика, который рулит проектом - это умение видеть систему целиком.

Когда ты только начинаешь работать аналитиком, кажется, что главное - это разобраться в задаче и описать её так, чтобы разработчики всё поняли.🙂
Но со временем ловишь себя на мысли:
можно идеально расписать маленький кусочек, но если не понимаешь, где он живёт, то результат будет не всегда удачным...😔

Тогда и приходит 🖐системное мышление 🖖

🤨 Что вообще такое система?

Система - это просто набор вещей, которые связаны между собой: сервисы, роли, данные, процессы, события.
Каждый элемент что-то делает не просто так, а потому что на него что-то влияет и он влияет на других.

Иногда система огромная (торговая площадка), а иногда маленькая (процесс восстановления пароля)
✔️ Суть одна: понимать, как всё связано, а не только саму кнопку, метод или поле.

🤨 Зачем это аналитику?

Если ты работаешь только в рамках своей задачи, легко сделать что-то логичное локально, но странное глобально...

🟦Представь ситуацию.

Ты добавляешь поле в профиль. Локально - всё супер.
А потом выясняется, что это поле участвует в регистрации, выгружается в отчёт, влияет на фильтр в админке и вообще зачем-то подтягивается в интеграцию...😒

Системное мышление как раз помогает этого избежать.

✅ Оно отвечает на вопросы:

➡️какие процессы затронет моя задача
➡️что сломается, если изменить это поле
➡️кто потребляет эти данные
➡️какой сервис будет страдать первым

🤨 Как выглядит системное мышление в жизни аналитика?

Это когда перед тем, как писать задачу, ты автоматически думаешь:
➡️где эти данные живут ещё
➡️кто ими пользуется
➡️что будет, если здесь появится новое поведение
➡️стоит ли трогать это место вообще...

🟣Это привычка, которая появляется с опытом и, кстати, она реально экономит время)
Меньше уточнений, меньше переделок, меньше “мы это не учли”.

👍 Маленькое наблюдение

✅ Чем дольше работаешь аналитиком, тем лучше понимаешь, что задача ➡️ это не кнопка, не метод и даже не сценарий.
Это часть одной большой конструкции.
И чем раньше ты увидишь конструкцию, тем спокойнее у тебя будет жизнь (и у команды тоже).

❗️И помни, системное мышление ➡️ это не врождённый навык, он формируется постепенно, со своими маленькими открытиями на каждом проекте.


📣 Если хочешь прокачать этот навык на реальных задачах — на курсе мы как раз работаем с настоящими проектами.
Системное мышление там появляется не из теории, а из практики, приходи!

💬 Как задавать вопросы, чтобы получать нормальные ответы, а не раздражение

Мало кто думает о том, что хорошие вопросы в работе аналитика экономят времени больше, чем любое шикарное ТЗ.
🏳️‍🌈И чем дольше страдаешь работаешь, тем лучше понимаешь: люди охотнее отвечают не на те вопросы, что “правильные”, а на те, что заданы по человечески.

➡️Вот несколько вещей, которые реально работают в жизни, а не в методичках.

🙁 Не мучай человека фразой "есть минутка?"

Если честно, этот вопрос выбивает из контекста хуже любого звонка.
Человек не знает, на что он соглашается, поэтому лучше сразу написать, что тебе нужно:

"Мне нужно уточнить один момент по задаче с интеграцией. Написала ниже, посмотри, пожалуйста"

✅ Это сокращает коммуникацию раза в два и никто не чувствует себя загнанным в угол)


🙂 Дай человеку опору: покажи, что уже посмотрел.

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

"Я проверила метод getUser он отдаёт статус 'false'. Хочу понять, это всегда так или есть исключения?"

✅ Ты задаёшь не “сырой вопрос”, а продолжаешь мысль, это совсем другое ощущение.


🙁 Не смешивай несколько разных тем в одну

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

➡️ Лучше так:

"Уточню три момента, они связаны между собой:
- кто формирует дату?
- обновляется ли она?
- зависит ли от неё другой процесс?"

это делает переписку чище и добавляет структуры.


🙁 Абстрактные вопросы - враги продуктивности

Вот это⤵️

"Почему метод не работает?"

⬆️ всегда тупик.

А вот это⤵️

"Метод возвращает ошибку на таких данных, вот пример. Я подозреваю, что проблема может быть в поле userId. Правильно думаю?"

⬆️ уже похоже на рабочий диалог.

🟣Видишь разницу?
Во втором варианте человек понимает, куда смотреть и как помочь.

🙂 И да, уважение к чужому времени чувствуется всегда

Не нужно комплиментов, смайликов и "сорри, что отвлекаю".
Достаточно просто быть аккуратным в формулировках, задавать контекст и люди начинают отвечать охотнее, даже те, кто обычно пишет “давай завтра”))

💡 Небольшое заключение
Уметь правильно задавать вопросы - это не врождённый талант, а привычка думать на шаг вперёд: что человек увидит, глядя на мой текст, и сможет ли он быстро помочь?
И если иногда кажется, что ты "слишком подробно" пишешь - поверь, это лучше, чем полдня тянуть из человека ответ по слову.

А если кто-то отвечает быстро и по делу - значит, ты задал хороший вопрос!

🤝 Как искать границы системы и не тащить на себя лишнее

Если честно, умение находить границы системы - один из недооценённых навыков аналитика.
Пока его нет, кажется, что ты отвечаешь за всё: и за то, что происходит внутри сервиса, и за то, что происходит в трёх соседних командах, и иногда даже за погоду за окном...😐
А потом в какой-то момент задаёшь себе вопрос: “секунду… это вообще не наша ответственность”.🤨
И работа становится спокойнее в разы.

💘 Что такое границы на самом деле?

Это ответ на простой вопрос: "Где заканчивается наша зона влияния?"
И это не абстракция, а очень практичная штука: она помогает не писать лишние требования, не чинить чужие проблемы и не обещать то, что твой сервис вообще не делает.

💘 Как понять, что ты вышел за границы?
Есть маленький признак:
если ты начинаешь придумывать логику, которую твоя система не может выполнить физически, значит, ты уже в чужом огороде.
👉 Например:

Если сервис умеет только “создать заказ”, он не обязан “проверять склад”, “выставлять счет”, “отправлять уведомления” и ещё полдня решать судьбу пользователя. Он просто создаёт заказ и точка.
Дальше подключаются другие сервисы.

💘 Границы видно по входам и выходам

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

💘 И да, границы не всегда очевидны

На реальных проектах тебе никто не даст листочек “вот наша зона ответственности”.
Иногда сервисы перепутаны, процессы зависят друг от друга, а документация покрыта пылью.

👉 И вот здесь помогает привычка задавать вопросы:

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

😔 Грустная жиза:

❌ Когда аналитик не видит границ, он начинает тащить на себя всё: от UX до интеграций, от бизнес-правил до архитектуры.
Звучит героично, но работает плохо и малоэффективно.
✅Когда видит, то процесс становится проще, задачи - короче, а решения - логичнее.


⏭💜💜💜💜⏮

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

🧷Как понимать входы, выходы, состояние системы и почему это упрощает любую задачу

⬇️Иногда задача кажется какой-то странной: много шагов, много условий, кто-то что-то куда-то отправляет, что-то меняется…и вообще непонятно, с чего начинать.

⬇️В такие моменты полезно отбросить всё лишнее и посмотреть на систему через три вещи: входы, выходы и состояние.
💛 Это простая схема, но она разложила мне полжизни в анализе по полочкам.

🔖 Входы - это всё, что система получает

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

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

Если входы не ясны, дальше никак...😢
Система не может сделать то, для чего у неё нет данных.

✅ Хорошие вопросы в этот момент:

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

Иногда один ответ “а вот это к нам не приходит” меняет половину решения.

🔖 Выходы - это результат, который система должна показать наружу

То есть это не только успешный ответ. Это:
🔵 ошибки,
🔵 статусы,
🔵 события,
🔵 побочные эффекты,
🔵 или даже просто тишина (да, такое тоже бывает).

Когда ты понимаешь выход, ты понимаешь зачем существует весь процесс.
Потому что система делает не “действия”, а производит результат.

✅ Полезные вопросы:

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

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

🔖 Состояние - это то, что остаётся внутри системы после операции

Это самый тихий, но самый важный элемент. Это то, что система запоминает.

Например:
🔵 создали заказ → статус “новый”
🔵 пользователь сменил пароль → поле обновилось
🔵 запущен процесс модерации → выставлен признак, что проверка началась

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

✅ Хорошие вопросы:

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

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

🔖 Почему это так сильно упрощает работу

Потому что ты перестаёшь метаться между деталями.
Процесс превращается из длинного “что-то где-то происходит” в три чёткие точки:

➡️Что пришло ➡️ что изменилось внутри → что вышло наружу.
Если эти три вещи понятны, всё остальное становится только техникой)

💭💛💛💛💛💛💛💛💛💛💛💭

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

💭 Как понять, что одно действие в системе тянет за собой другое
(и почему это важно аналитику)

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

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

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

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

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

💡 Как вообще понять, что за чем следует?

Проще всего смотреть на задачу как на короткую цепочку. Не UML, не диаграмму, просто цепочку:

что произошло ➡️ что система сделала из-за этого ➡️ что стало доступно дальше

✳️Например (максимально простой):

1️⃣пользователь нажал кнопку
2️⃣система сохранила действие
3️⃣после этого появилась возможность сделать следующий шаг

⏭И вот мы уже видим причинно-следственную связь⏮


💡 Почему такие связи важно замечать?

Потому что, когда их не видишь, задачи кажутся нелогичными.
Ты думаешь: "Что за баги появились? Я же описал всё нормально.."😖
А оказывается, что система ведёт себя правильно, это просто ты не учёл шаг, который для неё обязателен, а для тебя просто неочевиден. 😒

💡 Как тренировать это мышление?

✨Ничего сложного✨, просто каждый раз, когда разбираешь задачу, спроси себя:

🔵а что запускает этот шаг?
🔵а что должно произойти сразу после него?
🔵а что станет доступно только когда он выполнится?
И всё, особо сильно погружаться не надо. Этого достаточно, чтобы увидеть цепочку 😎

▫️🔠 🔠🔠🔠🔠🔠▫️
Когда начинаешь видеть связи между шагами, задачи становятся структурно логичными.
Ты не пытаешься держать в голове всю систему и каждую мелочь, просто понимаешь, что одно действие приводит к другому.
И это помогает писать требования так, чтобы система вела себя предсказуемо. (и ты мог бы чаще отдыхать)