🏗 Архитектура для аналитика:
что понимать обязательно, а что нет

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

➖И правда, и нет.

🤩 Начнём с главного.
Системному аналитику не нужно уметь проектировать архитектуру на уровне архитектора или разработчика.
От тебя не ждут, что ты придумаешь, как именно всё реализовать внутри сервисов.

✖Но и совсем не вникать - плохая идея:
аналитику важно понимать архитектуру на уровне логики, а не реализации.

📌Что сюда входит ⤵

🤩Во-первых: из каких крупных частей состоит система.
какие сервисы есть, за что они отвечают и кто с кем взаимодействует.
не детали, а просто общая карта.

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

🤩В-третьих: где потенциальные риски.
что будет, если один из компонентов недоступен.
какие части системы самые чувствительные к изменениям.
где "просто поправить" на самом деле может аукнуться.

И этого уже достаточно, чтобы:

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

📌 А вот что аналитику не обязательно ⤵

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

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

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

😔 Хорошая архитектурная насмотренность у аналитика появляется со временем:
через проекты, вопросы, ошибки и обсуждения. А не через заучивание схем из интернета)

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

Этого для аналитика более чем достаточно.

🤯 "Я недостаточно технический аналитик"
или когда требования уже понятны, а уверенности всё равно нет

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

❕И в моменте начинаешь думать не о задаче, а о себе:
достаточно ли я понимаю? а если спросят глубже? а если я что-то упускаю?

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

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

😔 Техническая глубина у аналитика почти никогда не появляется "заранее".
Она нарастает по ходу работы, вместе с проектом, ошибками и вопросами.
Сегодня ты уверенно разбираешься в одном куске системы, а завтра в другом.
И это нормальный, живой процесс, а не признак некомпетентности.

🤩 Поэтому ощущение "я недостаточно технический" чаще всего не соответствует фактам.
Это ощущение говорит о росте, новых зонах ответственности и выходе за привычные рамки.

А вот полная уверенность, что "мне уже нечего учить", обычно говорит о другом,
но это уже совсем отдельная тема)

😬 Почему разработчики злятся,
даже когда тебе кажется, что с требованиями всё норм

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

😳 И конечно легко подумать: "да что не так, я же всё описал".
Но если посмотреть на ситуацию глазами разработчика, картина часто выглядит иначе:

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

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

💙 Третья: изменения по ходу без фиксации.
Фраза "давайте тут чуть поправим" для аналитика может выглядеть безобидно.
Для разработчика это часто означает переработку уже продуманного решения и сдвиг сроков.

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

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

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

когда это есть, то у обоих сторон поводов для злости становится заметно меньше)

🧩 В чем же разница между системным аналитиком
и "переводчиком" между бизнесом и IT?

Эту фразу:

аналитик - это переводчик между бизнесом и IT

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

💙Переводчик ↗️ это тот, кто просто переправляет слова с одного языка на другой.
Ему не обязательно глубоко понимать смысл, важен лишь перевод.

💙А вот системный аналитик ↗️ это уже совсем другое дело)
Он не просто пересказывает запросы бизнеса команде разработчиков.
Он пытается разобраться, что именно хотят получить, зачем, какие есть ограничения и какие последствия будут, если сделать иначе.

Бизнес часто приходит не с четкими задачами,
а с примерными формулировками вроде "хочу вот так".
Разработчики в ответ задают вопросы,
типа "а это вообще реализуемо?" и "а как это повлияет на остальное?".

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

😔Поэтому аналитик ➡️ это не просто передатчик требований, а тот, кто:
💙принимает решения вместе с командой
💙закрепляет договорённости (а мы с вами помним, как они важны)
💙и несёт ответственность за целостность решения
Если аналитик застревает в роли простого переводчика, он довольно быстро встречается с потолком:
ограничениями в влиянии, уровне задач и, конечно, в оплате.

☝️Настоящий рост начинается, когда аналитик перестает только передавать слова и начинает видеть решение как систему, а не как сухой набор требований.

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

😮‍💨 Как аналитики усложняют себе работу
и постепенно теряют силы

Выгорание редко начинается с откровенного "я устал и не могу дальше".
Чаще это ощущение "всё кажется сложным, но как-то справляюсь"...

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

🟤Первая ошибка - стремление быть максимально полезным:

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

🟤 Вторая - перфекционизм там, где он не нужен:

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

🟤 Третья - пытаться держать всё в голове:

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

🟤 Четвёртая - постоянное сравнение себя с другими:

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

И засада в том, что всё это часто воспринимается как старание,
но на деле ведёт к постепенному выгоранию.

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

💙💙💙💙💙
💙 Иногда лучший способ развиваться в профессии - не учить ещё один инструмент,
а научиться не брать на себя то, что не входит в твою зону ответственности💙

😔 Как отличить выгорание от обычной усталости

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

Ведь порой кажется, что дело просто в усталости:
то дела накопились, то недели идут плотным графиком, и ты наивно думаешь, что после отдыха всё наладится.🤡
Однако и после выходных, и после отпуска остаётся чувство, что что-то не так.

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

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

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

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

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

🤩 Важно понять одну вещь, которую многие упускают:

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

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

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

🤩 Помни, что иногда самый разумный шаг - не продолжать терпеть дальше, а задуматься о переменах.

💭 ТЕСТ: сможешь ли ты выдержать первые месяцы в аналитике?

В комментариях к одному из постов спросили:
"как вообще можно не пройти испытательный срок?"

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

🤩 Давай проверим.
Если найдёшь у себя 2 и больше пунктов - стоит немного притормозить и взглянуть на себя со стороны)

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️

1️⃣Ты боишься задавать вопросы

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

2️⃣Ты берёшься за задачу, как понял

Без уточнений и согласований.
Это чревато на финише услышать "мы совсем другое имели в виду".

3️⃣Ты делаешь вид, что всё знаешь

Даже если не уверен.
Вместо честного "не знаю" - лишь "уверенные" догадки.

4️⃣Ты не смотришь дальше своей части работы

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

5️⃣Тебе тяжело воспринимать критику

Слышишь конструктивное " вот здесь не так, надо поправить",
а внутри думаешь: "всё же нормально было, во докопались"

6️⃣Ты сразу хочешь переломать систему

Ещё не понял, как всё устроено, но уже строишь грандиозные планы.

7️⃣Ты пропадаешь

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

8️⃣Ты молчишь, когда что-то идёт не по плану

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

9️⃣Ты берёшь на себя больше, чем можешь

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

1️⃣0️⃣Ты думаешь, что проблема всегда в других

"Мне плохо объяснили", "процессы странные", "команда не такая".
Иногда так и есть. Но не всегда :)

1️⃣1️⃣ Ты недооцениваешь, сколько деталей надо обсуждать

Кажется, что вроде и так всё понятно.
На самом деле - далеко не всегда и не всем.

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Нашлось что-то знакомое?

Это не значит, что ты плохой аналитик.
Это просто этап обучения и это нормально)

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

И обычно такие вещи довольно быстро исправляются, если обратить на них внимание.
А дальше начинается совсем другая история)

✨ ну что, подпищики… весна пришла 🌱 ✨

😔и вместе с ней вот это приятное состояние:
вроде ничего не произошло, а внутри свербит
"надо что-то менять"

😔 энергии чуть больше, прокрастинации чуть меньше
и где-то в глубине: "а может попробовать?.."

ну и тут, конечно, начинается база 🤡
➡️ "ну дааа, но не сейчас"
➡️ "после майских нормально начну"
➡️ "надо сначала подготовиться"

но ведь ты уже знаешь, чем это заканчивается 🙂
после майских 🪵 лето, летом 🪵 не до этого, потом осень, зима… и по кругу

конечно, ничего критичного, просто… ничего не меняется 😞

хотя правда в том, что старт вообще никогда не будет выглядить как "ну всё, я готов на 100%" 👍
обычно это ближе к: "блин, я пока не до конца понимаю, но хоть попробую"

❌ и этого достаточно! всё остальное догоняется по ходу)

🟤🟤🟤🟤🟤🟤🟤🟤🟤
если ты давно смотришь в сторону системного анализа -
вот он! тот самый момент, когда можно не просто думать, а зайти и попробовать

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

если откликается - залетай!
потому что "потом" обычно не наступает)
ссылочку дублируем,⏭ тык ⏮

Чем на самом деле занимается системный аналитик
(часть 1 - ожидание vs реальность)

Когда люди думают о системном анализе, представляют примерно так:
👉 я буду продумывать систему
👉 писать требования
👉 разбираться в логике

Звучит привлекательно и вроде бы интеллектуально, правда? 😐
Но давай посмотрим на то,
что происходит💬на самом деле💬
📏📏📏📏

📍 Ожидание №1: "Я буду писать требования"
📍 Реальность:

🍑 придётся вытаскивать их из людей, которые сами толком не знают, что им нужно:

"сделайте удобно"/"как сейчас, только лучше"/"ну вы же аналитик, помозгуйте там"
➡️ эти фразы будут тебе очень знакомы)

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

📏📏📏📏

📍 Ожидание №2: "Я буду много думать"
📍 Реальность:

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

Причина не в твоей некомпетентности (🤪🤪🤪), а просто система - это сложный сплав разных зависимостей, и сразу всё не расскажут.

📏📏📏📏

📍 Ожидание №3: «Я буду работать с документацией»
📍 Реальность:

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

Иногда писать ➡️ не главное (но взаимосвязанное), важнее договориться и понять друг друга.

📏📏📏📏

📍 Ожидание №4: "Я просто связующее звено"
📍 Реальность:

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

Если где-то что-то пойдёт не так, упрёки сразу на тебе:
➡️ аналитик не так описал/забыл учесть/аналитик не донёс

Даже если проблема абсолютно не в твоей зоне ответственности.

📏📏📏📏

✅ И вот что интересно:
Редко дают чёткое задание "делай вот это".
Обычно есть идея, ограничения, а ты разберись, что с этим делать.
Вот где начинается настоящая работа аналитика! Не просто ТЗ писать, а понять, что происходит, собрать картину, договориться, и только потом оформлять.
📏📏📏📏

‼️ И хотим сказать прямо, чтобы не сложилось ощущение, что это ад)

Да, иногда сложно и утомительно.
Да, бывает жутко много разговоров, а бывает и нет.

Но это одна из самых живых ролей в айти.
Ты не сидишь над одной задачей неделями, постоянно переключаешься,
видишь, как идея превращается в продукт, и реально влияешь на то, как система будет работать!
не код пишешь, а решаешь, что и зачем вообще должно быть.
📏📏📏📏

Если любишь разбираться, связывать разные куски, общаться и наводить порядок в неразберихе ➡️ эта работа быстро затягивает!
Проверено 👍
📏📏📏📏

⭐️ В следующий раз расскажем про реальные проблемы аналитика
и нужные навыки, которые действительно помогают)
(а не просто красиво выглядят в резюме)

⏪Если узнал себя или подумал "а я не так это себе представлял",
или наоборот, стало ещё интереснее - жми любую реакцию ниже⏩

Чем на самом деле занимается системный аналитик
(часть 2 - с чем ты столкнёшься и что действительно важно)

В прошлом посте мы немного снизили градус ожиданий. 🤷‍♀️
🔜 Если вкратце: аналитик - это не только писать ТЗ, но и уметь разобраться в огромной системе. (поэтапно)
➡️ А теперь честно: что на самом деле ждёт тебя на работе?

📌 Почти никогда ты не получишь идеально сформулированную задачу

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

📌 Люди говорят одно, думают другое и делают третье
Классика жанра:
👉 бизнес требует: нам нужна вот такая фича, только так и никак иначе
👉 разработчики отвечают: это нереализуемо
👉 пользователь в ответ: да я вообще этим не пользуюсь))
И вот ты в центре этого кружения. 👀
👉 Твоя задача - не просто записывать слова, а понять, что на самом деле нужно системе.

📌 Ты будешь ошибаться (и это нормально 🧘)
Обязательно что-то упустишь, не спросишь или плохо поймёшь.
И это вскрывается: во время разработки/на тестах, а иногда и в проде
❗️Это не значит, что ты плохой аналитик, это правда часть процесса, через которую проходят все, вообще все.

📌 70% работы - это общение 📞
И речь не о схемах, не о UML и не о крутых терминах, заученных наизусть
👉 Речь о том, чтобы:
❌ задать правильный вопрос/уметь переформулировать/договариваться/объяснять одну и ту же мысль разным людям по-разному
Поэтому на работе жёстко прокачиваются навыки общения против твоей воли)

⏭И ну вот почему возникает разрыв⏮
👉 Бывает так:
человек знает теорию, рассказывает на интервью весь свой прекрасный опыт.
👉 А потом выходит в реальную работу и думает о том, с чего вообще начать?
Потому что на практике не всё крутится вокруг терминов, там и мышление, и постоянная практика.

📌 Но есть и хорошая новость!
Всё это кажется сложным, пока не возьмёшься за дело. )
Навыки аналитика - не дар, а то, что можно и нужно тренировать.
Со временем ты начинаешь формироваться как специалист и ты сможешь:
😔 лучше формулировать вопросы
😔 быстрее видеть слабые места
😔 понимать, когда тебя пытаются ввести в заблуждение
😔 увереннее общаться с командой
И однажды себя осенит: да я вообще уже шарю за многое тут! и как вы без меня жили...😐
И это, наверное, один из самых кайфовых моментов в профессии)
🧷🧷🧷🧷🧷
Если после этого поста стало чуть меньше тумана в голове,
то значит мы всё делаем правильно)
можешь дать знать реакцией 👇

🔧 DevTools - суперспособность аналитика

Есть такая штука, с которой почти все сталкиваются одинаково:
👉 Тебе дают задачу и говорят: "посмотри, что у нас уходит на бэк"
Ты открываешь сайт, кликаешь…а дальше полный ступор, непонятно, куда смотреть 😊

И дальше два сценария:
1️⃣ написать разработчику с вопросами
2️⃣ открыть DevTools

Честно говоря, работать аналитику без DevTools - это всё равно, что идти вслепую.
Ты не видишь, какие именно данные отправляются, что приходит в ответ, где зарыта ошибка.
😔Отсюда и типичные диалоги:

- не работает
- что именно?
- ну… всё 😬

DevTools - это не что-то сложное.
Это просто инструмент, который показывает, как система реально работает.
Не по документации, не как задумывалось, а как есть

Самое полезная штука - вкладка Network.
Открываешь её и - бац! многое становится на свои места:
➡ что отправилось, куда, с какими параметрами и что приходит обратно.
😔 И типичный диалог превращается в более конструктивный:

- ааа, фронт не тот параметр шлёт
- а бэк вообще другое отдаёт

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

🤩 Есть ещё один важный переломный момент.
Когда ты начинаешь открывать DevTools раньше, чем писать кому-то с вопросом.
Отсюда начинается настоящий прогресс)

Поначалу, конечно, может казаться, что там всё сложное и непонятное.
Без паники!
DevTools не нужно выучить наперёд, его просто надо начать использовать)

Если хотите, можем показать на реальном примере: что именно смотреть в Network и как быстро находить проблему.
Жми любую реакцию, разберём 👇

🔌 Аналитику про 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, то фронт показывает ему ошибку на экране.

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

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

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

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

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