Работаете 1–2 года, а ощущение, что за пределами вашей команды — другая вселенная?

Вы уже системный аналитик. Работаете 1–2 года. Но всё равно время от времени появляется ощущение:

👉 «А если я чего-то не знаю, а в другой компании это обязательно?»
👉 «А как вообще у других — так же, как у нас? Или по-другому?..»
👉 «А если у меня шаблон Use Case странный?..»
👉 «А почему я до сих пор путаюсь в том, как оформлять требования для фронта и бэка?..»
👉 «А что вообще делает аналитик на PBR, кроме как слушает?..»

Знаете что? Задавать эти вопросы — это абсолютно нормально.
В каждой компании свои процессы, документы, подходы. Где-то Use Case, где-то User Story. Где-то строго по Scrum, где-то «у нас свой Agile». Где-то один аналитик делает всё, а где-то 3 человека делят одну фичу.

💡 И именно поэтому важно подтянуть базу.
Если вы знаете фундамент — вас возьмут в любую команду. Потому что вы быстро подстроитесь под их стиль, но не потеряетесь.

Курс «Системный аналитик. С нуля до старта» — не только для новичков.
Сюда приходят и те, кто уже работает, но хочет:
🔹 Систематизировать знания
🔹 Навести порядок в голове
🔹 Наконец-то понять, как может быть выстроен процесс разработки в разных командах
🔹 Прокачаться в сборе и оформлении требований, работе с макетами, моделировании процессов, нотациях, проектировании БД, подготовке документации, постановке задач на фронт и бэк.

🧠 Всё это — с обратной связью, реальными задачами и поддержкой.

Старт потока — 17 апреля.
⚡ Успейте записаться до повышения цен.

Как выстроена работа системного аналитика в разных командах?

Привет!
С вами Вера, основатель AnalystCore.

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

1️⃣ Системный аналитик один на проекте
Это предполагает много свободы, но и больше ответственности.

📌Особенности работы:
— Вы сами выбираете, как вести документацию.
— Все задачи проходят через вас.
— Вы тесно работаете с командой разработки.
— Вы досконально знаете свою систему и чувствуете, что продукт — ваше детище.
— Вас считают экспертом, к которому все идут с вопросами.
При такой схеме работы сложно новичкам, но опытным аналитикам очень даже хорошо :)

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

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

3️⃣ Много системных аналитиков на проекте. У вас есть тимлид аналитиков. Каждый аналитик в отдельной команде
🏗 Большие проекты часто делят на команды. В одну такую команду обычно приглашают одного-двух системных аналитиков. Схема работы похожа на варианты 1 и 2. Но тут ещё есть общеаналитические встречи.

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

4️⃣ Много системных аналитиков на проекте. У вас есть тимлид аналитиков. Вы работаете в отделе аналитиков и как бы «изолированы» от команды разработки.

📌Особенности работы:
— Вы работаете по Канбану: проанализировали одну задачу, закончили, берёте следующую и так далее. Но процесс разработки похож на waterfall: после анализа передаёте задачу в разработку и забываете о ней. Узнаёте, только если к вам придут с вопросами.
— Вы не ходите на командные встречи (дейли и ретро). Взаимодействуете только с внешними командами (согласовываете контракты), дизайнером, тимлидом аналитиков, с техлидом разработки (согласовываете результат анализа, проектируете вместе).
— Именно тимлид аналитиков ходит на все командные встречи, в курсе, что нравится/не нравится команде разработки и передаёт вам эту информацию.
— У вас много общеаналитических встреч, где вы обмениваетесь опытом. Вы знаете свою систему и можете подхватить друг друга.
Такой вариант удобен, когда аналитиков в компании много, но снижает погружённость в процесс разработки.

Без этого навыка не позовут в сильную команду

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

Сильные аналитики не просто «записывают хотелки». Они:
✅ Вычленяют реальную проблему из потока информации
✅ Формулируют требования так, чтобы их понял и заказчик, и разработчик
✅ Думают наперёд — что можно улучшить, где узкие места
✅ Разбираются в моделях данных, процессах и интерфейсах

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

Нужно расширять кругозор, чтобы оставаться востребованным на рынке:
🎤 Ходить на митапы и конференции
📖 Читать статьи и смотреть, как делают другие
🛠 Пробовать новые подходы

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

Есть много путей, как прокачаться. Мы предлагаем свою помощь.
👇👇👇👇👇

Приходите на курс и прокачайте БАЗУ — разберём сбор и оформление требований, моделирование процессов, проектирование БД, работу с макетами, основы интеграций и документацию. Будет много примеров и практики.

⚡️Успейте записаться по текущей цене.

✍️ Письмо самому себе на старте карьеры
Что бы я сказала себе джуну 9 лет назад?

1️⃣ Не бойтесь просить помощь
Разбираетесь в задаче пару дней — отлично. Но если дальше тупик, обращайтесь за помощью к коллегам. Долгое копание, которое тормозит работу, вредно и вам, и бизнесу.

2️⃣ Вы новичок и можете многого не знать
Вы не можете знать всего. Вы только учитесь! Для вас каждый кейс — новый, и это окей))
Не будьте строги к себе. Все ваши коллеги понимают, что вы новичок.

3️⃣ Трудные задачи — это опыт в копилку
Сейчас тяжело? Отлично, значит, вы растёте. Через год эту задачу решите за 10 минут.

4️⃣ У вас есть сильные стороны
Да, сейчас у вас есть слабые места. Но и сильные тоже есть! Выделите их. Есть то, что на работе поручают именно вам. Вам кажется, что это что-то лёгкое и неважное? На самом деле нет. Вам доверяют! Это и есть ваша сильная сторона на текущий момент, помните об этом.

5️⃣ Учитесь, даже если задач нет
Не ждите, пока вам дадут новые задачи, чтобы прокачаться. В первой компании можно отработать два года, но так и не столкнуться с моделированием данных, реальной БД, АПИ, постманом, сваггером и пр. Поэтому после работы учитесь на учебных проектах. Почувствовали силы? Идите сами к руководителю и просите такие задачи! Вам нужен опыт.

💬 Как бы вы дополнили этот список? Что бы посоветовали новичкам?
👇👇👇👇👇

💡 Хотите понять, чем занимается системный аналитик в разных компаниях? У нас есть бесплатный урок!

В нём:
🔹 Что делает системный аналитик в разработке ПО.
🔹 Разбор реальной рабочей задачи: «что и в каком виде приходит от заказчика» и «как системный аналитик с этим работает».
🔹 Возможность оценить нашу подачу материала и формат обучения.

Попробуйте бесплатно!
Успейте записаться, места ограничены.

Мы готовим курс по документации и хотим, чтобы он был по-настоящему полезным 🙌

В нём будет про то, как оформлять пространство в Confluence, как связывать задачи в Jira с документацией и как писать ТЗ так, чтобы оно сразу становилось документацией по продукту.
Будем делиться шаблонами, примерами, лайфхаками — всё как вы любите 😉

Но чтобы курс точно решал актуальные задачи, нам НУЖНА ВАША ПОМОЩЬ!
Расскажите, какие вопросы про документацию вас волнуют — и мы постараемся включить их в программу.

👉 Заполните короткий опрос (2–3 минуты) https://forms.gle/viFWmF5VVmdtApix9
А мы пришлём вам скидку на курс, когда он запустится!

Будем рады вашим идеям 🙌

В ближайшие недели мы будем говорить об API — в особенности про REST API 🔥

Сегодня API встречается в каждом проекте — и понимание, как он устроен, критически важно для работы системного аналитика.

📌 Нужно продумать взаимодействие между фронтом и бэком в вашей системе? Используете API.
📌 Нужно интегрироваться с другой системой в вашей компании? Снова API.
📌 Нужно подключиться к внешнему сервису, чтобы подтянуть адреса, курсы валют? Без API никуда.

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

💡 Будем разбирать всё по полочкам:
и для тех, кто впервые слышит про API,
и для тех, кто уже работал, но хочет глубже.

Оставайтесь с нами и следите за постами — будет полезно и практично! 💪

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

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

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

💡 Вот здесь на помощь приходит API — интерфейс, который помогает системам обмениваться информацией по заранее определённым правилам.

Можно представить API как официанта в ресторане:

🍽️ Клиент (первая система) не ходит на кухню (вторая система) за своим заказом, а просит официанта (API).
🍽️ Официант знает меню (набор запросов и данных), принимает заказы и приносит именно то, что клиент попросил.
🍽️ Кухня не видит клиента, она просто готовит блюда по заказам, которые передал официант.

Таким образом, API позволяет двум системам общаться, не «видя» внутреннего устройства друг друга.

Ещё несколько примеров API:
📍 Карты — приложение такси через API получает координаты и маршруты из Яндекс.Карт или Google Maps.
💱 Курсы валют — сайт туристического агентства получает через API актуальные курсы валют от ЦБ.
🌦️ Прогноз погоды — приложение погоды через API запрашивает данные у крупных метеосервисов.

#api

API — это какой вид интеграций?

Всех системных аналитиков рано или поздно спрашивают на собеседованиях:
«Какие виды интеграций знаешь?» 🤔

Обычно хотят услышать эти 4 вида:

1️⃣ Общая база данных

Несколько систем напрямую взаимодействуют с одной и той же базой данных.
Обычно одна из систем владеет схемой и данными, а другие — получают доступ только для чтения.
📌 Пример: система хранит данные заказов в своей БД, и предоставляет «представление» (view) с нужными полями. Сервис аналитики (например, Power BI) подключается к этой базе, читает данные из view и строит отчёты.
Это простой и быстрый способ интеграции, но с высокой связностью и рисками.

2️⃣ Обмен файлами

Системы обмениваются данными в виде файлов — CSV, XML, Excel, изображения и т. д.
Это классический способ интеграции, когда одна система пишет файл, а другая — читает.
📌 Пример: банк выгружает транзакции в CSV и передаёт их в налоговую через защищённый канал.
📌 Пример: изображения, загруженные пользователями на сайт, сохраняются в хранилище (например, S3), а другой сервис или сайт читает оттуда файлы и отображает их на страницах.
Это тоже интеграция — через общий доступ к файлам, без прямых запросов между системами.

3️⃣ Удалённый вызов процедур (RPC)
Это когда одна система напрямую вызывает метод или процедуру другой системы, как будто это её собственная процедура.
Примеры:
SOAP
gRPC
*REST API
*GraphQL

4️⃣ Обмен сообщениями (Message queue)
Одна система отправляет сообщения в очередь, а другая забирает их оттуда и обрабатывает по очереди. Примеры: Kafka, RabbitMQ, ActiveMQ, IBM MQ.

❗Такие API, как SOAP, gRPC реализуют подход удалённого вызова процедур (RPC) — когда одна система вызывает функцию другой, как будто она локальная.
REST и GraphQL не относятся к RPC в строгом смысле, но тоже позволяют обращаться к удалённой логике — просто делают это по другим архитектурным принципам.

💡 В следующих постах поговорим о паттерне «запрос — ответ»: чем он хорош, где его пределы и почему он лежит в основе большинства API-интеграций.
Разберём, как его реализуют REST, gRPC и другие подходы.

Не пропустите...

#api #interview

📢 Напоминаем: совсем скоро старт потока!

Курс «Системный аналитик. С нуля до старта» становится только сильнее💪.
В этот поток мы добавили новый модуль про интеграции — разбираем виды интеграций и в особенности REST API.
Также в курс вошёл карьерный модуль. В нём делимся частыми вопросами с собеседований (в том числе по API и интеграциям) и даём рекомендации по оформлению резюме.

В AnalystCore мы подстраиваем программу под вас:
выясняем, с каким уровнем вы пришли, и помогаем дойти до вашей цели.
Отвечаем на все вопросы, разбираем ДЗ лично, поддерживаем и помогаем.

🎯 Через 4 месяца вы:
— разложите знания по полочкам,
— будете уверенно говорить про REST API,
— и сможете повысить грейд и зарплату.

⚡️ Успейте записаться.
Начните сейчас — и к осени вы уже будете совсем на другом уровне.

👉 Подробности и запись на курс: https://analystcore.com/system-analyst-base

📬 Что такое модель «запрос–ответ» и как с ней работают системы?

Когда две системы обмениваются данными, чаще всего это происходит по принципу «запрос–ответ».
Это базовый паттерн, который лежит в основе REST API, GraphQL, gRPC и других форматов взаимодействия.

🧩 Как это работает?

Одна система (клиент) отправляет запрос. Например:
«Дай список заказов пользователя с ID 123».

Вторая система (сервер) обрабатывает запрос и отправляет ответ. Например:
«Вот список заказов. Их три: заказ от 1 апреля, заказ от 3 апреля, заказ от 7 апреля».

📌 Что обычно содержит запрос?
— Метод запроса (например, GET, POST, PUT, DELETE — о них расскажем в одном из следующих постов)
— Адрес запроса (например, /users/123/orders)
— Заголовки (например, информация об авторизации, формате данных и др.)
— Тело запроса (body) — не всегда, но если нужно передать данные (например, при создании нового заказа)

📦 Что возвращается в ответе?
— Код ответа (например, 200 — всё ок, 404 — не найдено, 500 — ошибка сервера)
— Заголовки ответа (доп. информация, например, о типе возвращаемого контента)
— Тело ответа — сами данные, которые система вернула. Они могут быть отправлены в формате JSON, XML и т. д.

Это основа, с которой стоит начинать разбираться в API.
А дальше мы постепенно пойдём к REST — одному из самых популярных способов взаимодействия между системами.

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

#api

📬 Что такое HTTP — и при чём тут REST?

Прежде чем разбираться с REST API, давайте поймём, на чём он работает.

💡 HTTP (HyperText Transfer Protocol) — это протокол передачи данных, на котором работает весь интернет.
Когда вы открываете сайт, отправляете форму или оформляете заказ — вы используете HTTP.

👉 REST работает поверх HTTP. Он просто использует его возможности — грамотно и системно.

📦 А теперь представьте, что вы отправляете обычное письмо:
— У вас есть конверт — это как тело запроса: в нём содержится информация, которую вы хотите передать.
— Вы указываете адрес получателя — это как URL, по которому нужно доставить сообщение.
— Клеите марку, где указано, что именно вы хотите сделать: получить, отправить, удалить, обновить. Это как метод запроса: GET, POST, PUT, DELETE.

📮 А дальше — всё как на почте: письмо отправляется, доходит до адресата, и если всё прошло хорошо — вы получаете ответ.

💡 HTTP — это та самая «почтовая служба».
А REST — это стиль, в котором мы этой службой пользуемся: аккуратно, понятно и по правилам.

Теперь вы готовы начать разбираться с REST. Ждите продолжение!

#api #http #rest

📦 REST — это не технология, это архитектурный стиль

Когда речь заходит об API, чаще всего упоминают именно REST. Он стал стандартом, и его часто требуют в вакансиях. Но почему?

💡 REST (Representational State Transfer) — это архитектурный стиль, основанный на использовании стандартных возможностей HTTP.
REST — это набор принципов, который говорит:
«Если вы делаете API — делайте его по-человечески, чтобы все его поняли».

Например, в HTTP есть стандартные методы:
GET, POST, PUT, DELETE.

REST предлагает:
🔹 GET — использовать, чтобы получить данные,
🔹 POST — создать новую сущность,
🔹 PUT — обновить существующую,
🔹 DELETE — удалить.

✨ Сами по себе эти методы может использовать и gRPC, и SOAP, и что угодно.
Но REST говорит: давайте договоримся, что POST — это не для удаления, а GET — не для обновления. Используем каждый метод по назначению.
То есть REST — это не просто способ общения между системами, а понятный стиль взаимодействия, в котором:
— поведение методов предсказуемо,
— код читается легко,
— API интуитивно понятно всем.

📌 REST использует коды ответа и другие элементы HTTP по назначению. Это не обязательно (с технической точки зрения), но именно договорённость и делает REST таким удобным и универсальным.

👉 В следующем посте разберём, как читается путь запроса в REST: что такое endpoint, ресурс, параметры — и как в этом всём не запутаться.

Следите за серией, дальше — практика!

#api #rest

📌 Что такое endpoint и ресурс в REST API?

Когда вы видите такой путь:
/users
это не просто адрес. Это — ресурс.

🔹 Ресурс — это сущность, с которой работает ваша система: пользователи, заказы, товары, документы.
🔹 Endpoint — это конкретный URL, по которому можно получить доступ к ресурсу через API.
В REST API мы не придумываем названия ручек вроде /getAllUsers или /createOrder.
Мы описываем что, а действие определяем через метод HTTP-запроса:

GET /users — получить список пользователей
POST /users — создать нового пользователя
GET /users/123 — получить пользователя с id 123
PUT /users/123 — полностью обновить пользователя
PATCH /users/123 — частично обновить данные пользователя
DELETE /users/123 — удалить пользователя

✨ Это и есть суть REST — использовать HTTP как язык общения, а URL — как «адрес объекта».
Такой подход делает API понятным, предсказуемым и удобным — и вам, и разработчикам, и тестировщикам.
В следующем посте расскажем, зачем в пути появляются цифры и как работают path-параметры.
Следите за серией!

#rest #api

🔢 Зачем в пути цифры? Как работают path-параметры в REST API

В прошлом посте мы говорили, что путь в REST API — это адрес ресурса.
Но что делать, если нужно обратиться не ко всем, а к конкретному ресурсу?
📌 Для этого используются path-параметры (или параметры пути).

Пример:
GET /users/123 — получить пользователя с ID 123
DELETE /orders/555 — удалить заказ с ID 555
PATCH /products/8 — частично обновить товар с ID 8

Цифра в пути — это path-параметр.
Он указывает, с каким именно экземпляром ресурса вы хотите работать.

🔗 А если нужно обратиться к вложенному ресурсу?
Всё по той же логике:
GET /users/123/orders — все заказы пользователя с ID 123
GET /users/123/orders/456 — конкретный заказ 456 этого пользователя

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

#rest #api

🔎 Что такое query-параметры и зачем они нужны в API?

Если path-параметры помогают указать, какой именно объект нас интересует,
то query-параметры (параметры запроса) нужны для того, чтобы управлять выборкой данных.

📍 Пример запроса с query-параметрами:
GET /orders?from=2024-01-01&to=2024-04-17&status=paid
Это означает:
— показать заказы с 1 января по 17 апреля
— только со статусом «оплачен»
Такие параметры идут после знака ? и перечисляются через &.

Что обычно передаётся в query-параметрах:
🔹 Фильтры
/products?category=books&price_lte=1000 — только книги до 1000 ₽
🔹 Сортировка
/orders?sort=date_desc — отсортировать заказы по дате, от новых к старым
🔹 Пагинация (разбиение на страницы)
/users?page=2&limit=10 — вторая страница, по 10 пользователей на страницу
🔹 Поиск
/articles?search=REST%20API — найти статьи по ключевым словам

💡 Почему query-параметры не указывают прямо в пути?
Потому что они не обязательны. Это опции, которые уточняют, что именно нам нужно.
А путь (/orders) остаётся неизменным — мы всё ещё обращаемся к коллекции заказов.

⚠️ Главное правило:
— Если мы обращаемся к объекту — используем path-параметр
— Если хотим повлиять на выборку — используем query-параметры

#rest #api

🚧 Что в путь, а что в параметры?

Когда вы проектируете REST API, один из частых вопросов:
какую информацию указывать в path, а что — в query? 🤔

Чтобы API был логичным и удобным, важно соблюдать этот принцип:
📌 Path-параметры (/users/123)
— Обязательные
— Указывают на конкретный ресурс или путь к нему
— Влияют на маршрут
— Без них запрос не имеет смысла

📌 Query-параметры (?sort=date&limit=10)
— Необязательные
— Управляют выборкой или поведением запроса
— Не меняют маршрут
— Можно убрать, и запрос всё равно сработает

#rest #api