🔌 Аналитику про API: почему без этого ну совсем никак?

Это случается почти с каждым новичком ↘️
Тебе говорят:
➡️ слушай, а проверь, какие там параметры улетают
➡️ глянь, что бэк отвечает
➡️ там 400-я ошибка, посмотри, что не так
😔 И вот ты сидишь, и в голове лишь один вопрос:
а что именно мне там искать?..😐

✔️ И очень быстро становится ясно:
без понимания того, как работает API, ты просто не видишь и половины всего, что происходит.

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

📌 И в чем же тогда загвоздка, если ты совсем не врубаешься в эти процессы?
Ну, смотри:
🔸ты понятия не имеешь, какие данные на самом деле уходят
🔸 не можешь понять, где именно засела ошибка
🔸 сам себя толком проверить не в состоянии
🔸 да и постоянно висишь на крючке у разработчиков

😔 Отсюда и рождаются знакомые до боли диалоги:

- Что-то не работает
- А что именно?
- Ну... просто не работает 😳

📌 Что же тогда стоит держать в голове,
и при этом не углубляясь в дебри разработки?

Не надо тебе становиться программистом.
Но вот что по минимуму, на базовом уровне, знать очень важно:
👉 что вообще такое запрос: то есть, что именно система отсылает
👉 и что такое ответ: что она потом получает
Стоит еще разобраться, какие там бывают параметры и как они передаются,
ну и, конечно, что значат все эти статусы: успех это или все-таки ошибка.
👍 Вот этих знаний уже вполне достаточно, чтобы ты чувствовал себя гораздо увереннее и мог ориентироваться.

📌 Ну и ещё моментик

👌Аналитик, вполне может сам описывать API:
говорить про методы, про параметры, какие будут ответы и возможные ошибки – все это часть его работы.
✖Но вот в чем главная фишка: аналитик не пишет код.
Его задача – глубоко понимать, как все устроено и как оно должно выглядеть с точки зрения логики.

📌 И что тебе это даст на практике?

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

Это ли не прелесть навыков)

🔌 Поговорим про интеграции:
зачем они вообще нужны аналитику?

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

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

По факту, интеграция ➡️ это то, как разные системы общаются между собой, используя API.

➡️ Одна система говорит другой, отправляя запрос:

👉 держи данные, обработай их

➡️ А вторая ей в ответ:

👉 отлично, всё валидно, вот тебе результат обработки

или

👉 сорри, у тебя тут ошибка в данных, не могу обработать, вот тебе в ответ ошибка

💙Давайте посмотрим на что-то совсем простое:
вот, например, логин.

💙 Вы вводите свои данные, нажимаете кнопку "Войти".
Снаружи кажется, что сайт тебя или пустил, или не пустил.

Но если заглянуть под капот, то там происходит вот что:

👉 фронт отправляет POST-запрос с твоим логином и паролем
👉 бэк тут же проверяет полученные данные, есть ли такая учётка в бд
👉 может сходить и в другую систему
(например, для проверки авторизации)
👉 получает от неё ответ
👉 возвращает вам статус ответа и результат (200/401/400)
И только после всей этой беготни вы видите, что получилось на экране.

💙 Вот тут-то и кроется самое интересное для аналитика.

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

В этом и заключается вся разница.

🔠🔠🔠🔠🔠🔠🔠

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

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

🤔 Что происходит после того, как ты написал требования

💙Вот ты сел, дописал ТЗ, перечитал его и кажется, вроде всё сходится..
💙Отправляешь разработчику и с чувством выполненного долга:
👉 "ну всё, теперь можно выдохнуть"

Спойлер: рановато расслабляться 😄
🟠🟠🟠🟠🟠
Потому что, на самом деле, в этот момент требования только начинают жить.
Разработчик берётся за задачу и буквально сразу начинаются уточняющие вопросы:
👉 а что тут должно произойти, если...
👉 а если пользователь попробует вот так?
👉 это поле точно обязательное или нет?

И часть из этого у тебя в голове есть…
но в тексте - не всегда.😑
🟠🟠🟠🟠🟠
Дальше, как правило, запускается такой привычный цикл:
что-то уточнил ➡️ переписал ➡️ снова обсудили ➡️ снова поправил.

‼️И дело совсем не в том, что ты, мол, "плохо написал".
Просто пока за задачу не взялись с другой стороны,
в голове у каждого она всё равно выглядит немного по-своему.
🟠🟠🟠🟠🟠
🎉 Потом задача, наконец, уходит в разработку.

🤩 И тут важный моментик, который надо запомнить:
аналитик никуда не пропадает.
🤩 Потому что по ходу дела обязательно вылезает что-то из серии:
👉 ой, а мы это не учли
👉 это ограничение где-то описано или мы его сейчас придумываем?
👉 если сюда придёт пустое значение, то что делаем?
👉 а тут точно всё бьётся с тем, что выше?
🟠🟠🟠🟠🟠
Следом в дело вступает тестирование.👊

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

И вот порой именно на этом этапе и вылезают самые занятные моменты.
🟠🟠🟠🟠🟠
😮‍💨 Потом - релиз.

🤩 И если тебе кажется, что вот теперь-то точно всё - не торопись с выводами.😊
Пользователи обязательно начнут делать что-то непредсказуемое,
тут же всплывут новые нюансы, и, конечно, появятся доработки.
🟠🟠🟠🟠🟠
💙И вот здесь, пожалуй, самая главная мысль:
👉 Аналитик - это не тот, кто "написал требования и пошёл дальше"
👉 Это, скорее, проводник,
который ведёт задачу от самой первой идеи
до того момента, как она реально заработает в системе.
🟠🟠🟠🟠🟠
🦞 Поэтому со временем начинаешь видеть задачу не просто как некий "документ",
а скорее как большой процесс, который нужно заботливо довести до логического и рабочего завершения.

✅ Как аналитик проверяет задачу перед разработкой (чек-лист)

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

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

✅ Я могу внятно рассказать о задаче, не глядя в текст:

Просто своими словами, без шпаргалок:
что делает пользователь? что делает система? и что в итоге должно получиться?
❌ Если вдруг начинаешь:
сбиваться, путаться или прыгать с мысли на мысль,
то скорее всего, где-то в логике ещё есть пробел.

✅ Я описал, что произойдёт, если всё пойдёт не так, как задумано:

Речь не об идеальном мире, а о самом обычном пользовательском пути:
забыл ввести что-то? ввёл не то, что надо? или вообще не туда нажал?
❌ Если в этих критических точках:
всё расплывчато или никак не описано,
то будь готов, вопросы не заставят себя ждать.

✅ Данные - это тоже больная точка (и я это учёл):

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

✅ Дальше я бегло просматриваю всё на предмет противоречий.

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

✅ Ещё один, очень простой тест:

получится ли отдать эту задачу в работу вообще без созвона?
❌ Если ты про себя думаешь: "да ладно, потом объясню если что",
то это верный признак, что в тексте ты что-то упустил....

✅ И самый последний фильтр: как это тестировать?

❌ Если ты не можешь сходу объяснить:
- вот так проверяем
- и вот такой должен быть результат,
значит, задача пока ещё сырая.

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

🤔 Что на самом деле проверяют на собеседовании аналитика

Когда готовишься к собесу, очень уж хочется думать, что всё решит только теория.
Повторил REST, освежил SQL, вспомнил BPMN, зазубрил свой опыт и кажется, что вроде можно идти покорять рынок.
Так красиво, уверенно, прямо как настоящий айтишник.😋

🙁 Но потом, прямо на собесе, тебе вдруг прилетает не тот вопрос, что ты зубрил по конспекту)
➡️ А что-то совсем другое, например:
🟡как бы ты спроектировал вот такой процесс?
🟡что случится, если пользователь вдруг решит пойти совсем не по тому сценарию, что мы задумали?
🟡какие вопросы ты бы задал заказчику, прежде чем писать требования?

❗️И тут уже не выйдет просто вытащить из памяти заученное определение.
Потому что проверяют не только то, что ты знаешь.
Проверяет ещё, как ты мыслишь.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
На собесе, кстати, очень быстро видно, умеет ли человек рассуждать.
Не просто отделаться фразой "я собирал требования", а внятно рассказать:
🟡у кого уточнял детали?
🟡что предпринимал, если требования вдруг противоречили одно другому?
🟡и как вообще понимал, что информации уже хватает?
❗️вот тут-то многие начинают плыть.

Дело не в том, что они совсем ничего не знают.
Просто они привыкли давать ответы по шаблону, а не разбирать конкретную ситуацию.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
А знаете, какой прикол? идеальный ответ не всегда и нужен.🤪
Иногда куда сильнее смотрится кандидат, который просто и спокойно говорит:
🟡я бы для начала уточнил вот этот момент
🟡здесь, кажется, не хватает вводных данных
🟡тут вообще может быть несколько вариантов решения
🟡если у нас такое-то ограничение, то решение будет одно, а если другое - то уже иначе

Это звучит гораздо живее и профессиональнее, чем просто попытка угадать тот самый "правильный ответ".
Потому что в настоящей работе аналитика, по сути, почти никогда не бывает задач прямо как из учебника.

🤩 Там чаще всего такая картина:
💙бизнес хочет одно,
💙разработка заявляет "так просто не получится",
💙пользователь вообще творит что-то третье,
а ты сидишь между ними и пытаешься собрать из этого всего хоть какую-то внятную картину.

Вот на собеседовании как раз и проверяют, сможешь ли ты в такой картинке не растеряться.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Поэтому, когда готовишься к собеседованию, это не просто зазубривание определений.
Это ещё и живая практика:
🟡разбирать реальные кейсы
🟡учиться правильно задавать вопросы
🟡проговаривать вслух свой ход мыслей
🟡получать обратную связь
🟡привыкать к тому, что вопрос может оказаться совсем не по тому сценарию, что ты ожидал.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Мы, кстати, постоянно такое наблюдаем на наших мок-собесах)
Человек вроде и базу знает, но теряется, когда ему надо просто начать рассуждать вслух.
💙 А потом, после пары-тройки таких разборов,
он уже совсем иначе отвечает: намного спокойнее, чётче, увереннее.
🤩 И вот это то самое умение, которое заметно отличает "я просто почитал теорию" от "я готов общаться как настоящий аналитик".
Поэтому, если ты готовишься к собесу, не стоит ограничиваться одними конспектами.

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

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

Там не просто сухая теория,
но и много практики, свой пет-проект, поможем с резюме, проведём мок-собесы
и даже сопроводим в поиске работы. 🤓🤓🤓
⏭тык на ссылочку курса⏮

🧩 Чем фронт отличается от бэка
(и где здесь наш аналитик)

💙Когда в задачах начинают мелькать 'фронт' и 'бэк', это кажется какой-то жуткой абстракцией, правда?
💙На деле всё куда проще и понятнее:

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

🟠🟠🟠🟠🟠
Давайте посмотрим, как это обычно выглядит в любой реальной задаче:
➡️ пользователь что-то нажимает
➡️ клиентская часть (наш фронт) собирает нужные данные
➡️ и отправляет их HTTP-запросом на сервер
➡️ сервер (то есть бэк) обрабатывает всё это дело
➡️ потом возвращает какой-то ответ
и уже на основе этого ответа клиент решает, что именно показать пользователю.

❕Поймите, это всегда одна непрерывная цепочка,
а не какие-то 'две разные части', живущие сами по себе.

🟠🟠🟠🟠🟠
🤔 Если копнуть чуть глубже, в технические детали:

💻 клиентская сторона формирует запрос:
1️⃣ определяет метод, например, GET или POST
2️⃣ указывает URL
3️⃣ прикладывает параметры или тело запроса (payload)

😀 сервер же:
1️⃣ сначала проверяет все данные на валидность
2️⃣ потом выполняет свою логику
3️⃣ может обратиться к базе данных или другим сервисам
4️⃣ и в конце возвращает ответ, который включает статус и тело.

💻 а клиент:
1️⃣ интерпретирует полученный ответ
2️⃣ и затем меняет состояние пользовательского интерфейса

🟠🟠🟠🟠🟠
😎 И тут на сцену выходит наш аналитик!
Он описывает обе эти стороны,
и самое главное - как они между собой "общаются", их стык.

😀 для бэка он прописывает:

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

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

🟠🟠🟠🟠🟠
⛳️ Возьмём, к примеру, тот же процесс авторизации:

👉 фронт:
отправляет POST-запрос на /login с адресом электронной почты и паролем.
👉 бэк:
проверяет эти данные и возвращает
либо 200 (всё хорошо),
либо 401 (ошибка авторизации).
👉 фронт:
1) если пришло 200, то пользователь попадает в систему
2) если же пришло 401, то фронт показывает ему ошибку на экране.

Если все эти моменты не описаны чётко, то появляются расхождения и проблемы.

🟠🟠🟠🟠🟠
😊 Вот что важно понять:

аналитик не просто описывает 'экран'
или какой-то 'метод по отдельности'.
👉 он формулирует тот самый контракт, соглашение между клиентом и сервером:
➡️ что мы отправляем
➡️ что получаем в ответ
➡️ и как на всё это реагируем.

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

😊 Надо видеть всю цепочку целиком:
👉 от действия пользователя 👉 через запрос 👉 его обработку
👉 до ответа 👉 и окончательного поведения интерфейса)

🔐 Что же такое JWT, access token и refresh token
и почему это тебя постоянно разлогинивает ☹️

⤵️ Наверняка у тебя бывало такое:
сидишь себе спокойно на сайте, занимаешься своими делами…
и вдруг раз:
👉 сессия истекла
👉 нужно войти снова
👉 авторизуйтесь повторно
А ты такой:
😐 да я буквально десять минут назад заходил...

🟠🟠🟠🟠🟠
⤵️ На самом деле за этим стоит довольно важная техническая штука,
с которой аналитики сталкиваются буквально на каждом шагу.
⤵️ Речь идёт о🤩токенах авторизации🤩
и чаще всего в их устройстве встречаются:
🪵 JWT-токен
🪵 access token
🪵 refresh token
Звучит это куда страшнее, чем работает на самом деле))

🟠🟠🟠🟠🟠
🤔 Если попробовать объяснить совсем просто:
😔Когда ты вводишь свой логин и пароль,
то сервер их проверяет и как бы говорит:

👍 "Хорошо, этому пользователю можно доверять"

😔После такой проверки сервер выдаёт тебе access token,
это такой специальный временный ключ доступа.
😔Теперь каждый раз, когда ты обращаешься к сайту,
клиент (фронт) отправляет этот токен вместе с запросом, словно говоря:

🫶 Привет, это снова я, пропустите плиз

🟠🟠🟠🟠🟠
⤵️ И вот тут мы подходим к JWT (или JSON Web Token)
Это просто один из популярных форматов, в котором такой токен может быть сделан.
Внутри него обычно содержится вся нужная информация:
👉 кто ты как пользователь
👉 до какого момента этот токен вообще действителен
👉 какие у тебя есть права или роли в системе
и, конечно, специальная подпись, чтобы никто не смог подделать этот токен.
😔 Так что это вовсе не какая-то "магическая строка", а вполне чётко организованные данные.

🟠🟠🟠🟠🟠
💙Но есть одна загвоздка.
❌Если access token будет действовать вечно, это становится небезопасно.

Представь, если его кто-то украдёт, то получит доступ навсегда 😬
Поэтому access token обычно не живёт долго:
👉 всего пять минут, или полчаса, но максимум час

🟠🟠🟠🟠🟠
⤵️ И чтобы пользователю не приходилось постоянно заново вводить пароль,
когда access token истечёт, придумали 🤩refresh token🤩
💙Access token можно представить как одноразовый пропуск, чтобы пройти в офис.
💙А refresh token это как твой постоянный документ,
по которому можно прийти и получить новый временный пропуск 🤭

😔 Когда срок действия access token заканчивается:
👉 фронт направляет серверу refresh token
👉 сервер внимательно его проверяет
👉 и, если всё в порядке, выдаёт новый access token.

При этом обычный пользователь чаще всего вообще ничего такого не замечает)

🟠🟠🟠🟠🟠
⤵️ А вот если и refresh token уже просрочен или по каким-то причинам стал недействительным,
тогда тебя и выкидывает на страницу входа.
😔 Вот почему иногда сайт:
👉 просто спокойно обновляет твою сессию, и ты продолжаешь работать
а иногда:
👉 требует войти заново

🟠🟠🟠🟠🟠
🤩 И зачем, спрашивается, всё это полезно понимать аналитику?

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

⤵️ И в задачах то и дело всплывают вопросы, например:

💙 где хранится этот самый токен
💙 в какой момент он обновляется
💙 что мы делаем, если его срок действия закончился
💙 как фронт должен реагировать на ошибку 401
💙 и как правильно разлогинивать пользователя

🟠🟠🟠🟠🟠
🚩И вот в такие моменты очень здорово помогает
не просто знать, "что нажать в интерфейсе",
а понимать, что на самом деле происходит внутри под капотом.

🚩 Ведь чем дальше ты растёшь в аналитике,
тем чаще начинаешь видеть систему как единое целое,
а не просто набор отдельных экранов 😊

📈 Есть ощущение, которое рано или поздно накрывает многих аналитиков.

👉Вроде бы внешне ничего особо не изменилось:
ты всё так же ходишь на созвоны, пишешь требования, обсуждаешь задачи.
👉Но внутри уже начинаешь замечать:
💙задачи стали даваться легче
💙в новых системах разбираешься быстрее
💙к тебе всё чаще приходят что-то уточнить или посоветоваться
👉Ну и мысль наклёвывается:
😐 а я вообще всё ещё на том же уровне?
🟠🟠🟠🟠🟠
Самое интересное, что рост в аналитике редко ощущается резко...
👉 нет такого, вчера был джуном, а сегодня проснулся сеньором)

👉Обычно это очень такой..незаметгный процесс:
➖ тебе начинают давать более сложные задачи,
➖ потом подключают к важным обсуждениям,
➖ потом ты внезапно становишься человеком, который:
может разобраться/сходит уточнит/дожмёт задачу/поймёт, отчего вдруг всё рухнуло
👉И только спустя время доходит:
🫠 ответственности, знаний и нагрузки уже сильно больше, чем раньше.
🟠🟠🟠🟠🟠
При этом зарплата иногда будто вообще не замечает
твоего внутреннего апгрейда))
и вот это уже довольно обидно..
👉 потому что ты уже работаешь сильно иначе, мыслишь иначе, берёшь на себя больше,
а по бумагам можешь всё ещё оставаться на прежней позиции, вроде бы...
🟠🟠🟠🟠🟠
💙 Причём многие очень долго обесценивают свой рост.
Кажется, что "ну это все умеют", "я просто привык", "да я ещё не настолько сильный"
👉 Хотя если посмотреть на себя год назад - разница уже огромная.
Ты быстрее понимаешь задачи, лучше чувствуешь систему, меньше тонешь в информации
и уже совсем по-другому разговариваешь с командой.
❗️И это как раз тот рост, который не всегда видно сразу, но который очень хорошо ощущается в работе.
🟠🟠🟠🟠🟠
👉Проблема только в том, что компании редко сами приходят со словами:
"мы заметили, как ты вырос,
вот тебе новая зарплата 👍"
👉Так что приходится учиться:
💙 замечать свой уровень
💙 нормально рассказывать о своём опыте
💙 собирать достижения
💙 смотреть рынок
💙 и не бояться ходить по собеседованиям

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