Сегодня собираемся на мок-собес в 20:00
Ссылкочка на стрим придет в 🔺@analytics_team_bot

Чат будет тут👇

Самый странный кейс на сбор требований, который я слышала

Задача с собеседования Х5 на миддл БА:

«К вам прибегает продакт и говорит: у меня на столе каждое утро должен лежать бутерброд. Твои действия как бизнес-аналитика?»

Подсказка (читаем, только если мыслей нет)
1. Нужно постараться понять истинную проблему клиента, прежде чем предлагать решение. Примените подход "5 почему".
2. Пройдите по пути использования продукта клиентом (CJM) и соберите требования к каждому его шагу.

👇 Делимся, как бы вы отвечали на этот вопрос? Свой вариант опубликую на следующей неделе

Кто я | Отзывы | Менторство

Системные аналитики, бизнес аналитики, продуктовые, функциональные, дата аналитики, финансовые аналитики... так так, стоп, это зоопарк какой-то, так кем ты там работаешь? 👀👀

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

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

Аналитик в целом имеет компетенцию мыслить здраво и логично, спрашивает 5 почему.

А дальше уже специализации в разных сферах.
Системный - это тот, кто в системах ведает.

Приведу пример - нужно в приложении сделать новую функцию заказа карты на дом.

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


В идеале, если все идет последовательно, так бывает в государственных, финансовых организациях (банки) и больших корпорациях , где есть четкое разделение на специалистов. Но в большинстве случаев, компании рассчитывают, что ты будешь разбираться и в БА и в СА.

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

Ссылка на стрим как обычно будет в ➡️➡️ @analytics_team_bot

Спроектируйте Т-банк: разбор кейса в прямом эфире

«Как бы вы спроектировали приложение Т-банк?» — один из вопросов, который можно услышать на собеседовании.

Завтра, 23 июля в 19:00 разберём его в прямом эфире. На ваших глазах разработчик, бизнес-аналитик и системный аналитик попробуют спроектировать приложение с нуля — каждый со своей профессиональной точки зрения.

Обсудим:

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

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

Ведущая: СА, Таня Павлюченкова. Приходите знакомиться 🤩
Участники: Тихон Галактионов из @frontend_punks и Таня Коган

📅 23 июля, 19:00. Ссылка придет в ➡️ @analytics_team_bot
Подпишитесь сейчас, чтобы не пропустить эфир

чат будет тут 👇

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

Рассказываю!

Спойлер: это не только диаграммы и требования в Confluence.

50–70% моего времени — коммуникация. Встречи, созвоны, обсуждения, согласования. Потому что без разговора с бизнесом и командой невозможно понять, что на самом деле нужно сделать.

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

Конкретные задачи зависят от стадии каждой фичи:

➖ Если фича на старте — встречаюсь с бизнесом, согласовываю требования, задаю уточняющие вопросы, веду переписку.

➖ Если требования понятны — описываю их в Confluence, ставлю задачи на команду.

➖ Если разработка уже идёт — обсуждаю детали с командой, отвечаю на уточнения, проверяю, что всё правильно поняли.

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

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

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

Надеюсь, теперь понятнее. Если хотите разобрать какой-то из этапов подробнее — пишите в комментариях 👇

А еще скоро ждем пост от моей коллеги - системного аналитика, Таня поделится, как выглядит ее день)

Кто я | Отзывы | Менторство

Что мы видим в 90% резюме бизнес-/системных аналитиков?

Привет! На связи Таня Коган 👋
Недавно у нас в канале проходил стрим с разбором резюме с участием опытного HR в ИТ и вот, какие тренды в резюме мы выделили:

1. В резюме нет понятного позиционирования
Частая формулировка:

«Бизнес-аналитик / системный аналитик / product analyst / project manager».

Для рекрутера это выглядит не как универсальность, а как отсутствие фокуса.
Рабочая концепция:
1 резюме = 1 целевая роль.
Для бизнес-аналитика акцент — на процессах, требованиях, стейкхолдерах и бизнес-эффекте.
Для системного — на интеграциях, API, моделях данных, спецификациях и архитектурном контексте.

2. Есть список обязанностей, но непонятен масштаб задач

«Собирал требования», «писал документацию», «участвовал во встречах».

Такие формулировки почти ничего не говорят о специалисте.
Гораздо лучше показать:
— для какой системы собирались требования
— сколько было стейкхолдеров и команд
— какие интеграции проектировались
— какие артефакты создавались
— что изменилось после внедрения
👉 Не «описывал бизнес-процессы», а: «Описал AS IS / TO BE для процесса согласования договоров, устранил 4 дублирующих этапа и сократил среднее время согласования договора на 20%».

3. Навыки перечислены отдельно и не подтверждены опытом
В блоке скиллов часто написано:
BPMN, UML, SQL, REST API, Kafka, Swagger, Postman, Jira, Confluence.
Но в проектах не видно, где и зачем всё это использовалось.
Для ATS ключевые слова важны, но для нанимающего менеджера важнее контекст.
Хорошие примеры:
— «Спроектировал REST API для обмена данными между CRM и биллингом»
— «Описал sequence diagram для сценариев авторизации»
— «Сформировал контракт интеграции в Swagger / OpenAPI»

4. Нет результатов и бизнес-эффекта
Аналитики часто думают, что результаты — только для product-менеджеров. А еще, они считают, что раз они только написали требования, результаты работы всего проекта не могут быть указаны в резюме
Какие эффекты могут быть у аналитиков?
— ускорили согласование требований
— уменьшили количество ошибок после релиза
— автоматизировали ручной процесс
— запустили новую интеграцию
— перевели пользователей с legacy-системы

5. Проект описан без контекста
Название компании само по себе ничего не объясняет.
Рекрутеру и нанимающему менеджеру важно быстро понять:
— что это за продукт
— B2B или B2C
— внутренняя или внешняя система
— legacy, разработка с нуля или внедрение коробки
— размер команды
— зона ответственности аналитика
Хороший блок опыта начинается не с обязанностей, а с контекста проекта.

6. Резюме перегружено «украшательством»
Для аналитика особенно хочется показать любовь к схемам 😅 Но CV — не тех. документация.
Сложная верстка, таблицы в несколько колонок и декоративные блоки могут плохо считываться ATS.
Оптимально:
— PDF
— 1–2 страницы
— простой шрифт
— понятные заголовки
— короткие буллеты
— ключевые слова внутри опыта

Итого, резюме аналитика должно отвечать на 4 вопроса:
Какую проблему решал?
Что именно анализировал и проектировал?
Какие инструменты использовал?
Какой результат получил бизнес и команда?

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

Если тебе тоже нужно упаковать опыт бизнес-/системного аналитика и пройти воронку до достойного оффера — знаешь, кому писать ➡️ @analytics_team_help

Прикрепила к посту визуальный пример резюме бизнес аналитика с легендой
Есть, что к нему добавить? Пиши в комменты 👇