Салют! Сегодня разберем еще один из любимых вопросов от моих подписчиков: «Как пройти техническое собеседование на ИТ-аналитика (системный/бизнес-аналитик): поделитесь опытом или советами»

Я — системный аналитик с многолетним опытом (уже больше 10 лет я в этой сфере, начинала с Бизнес-аналитика), прошла десятки собеседований (и как кандидат, и как интервьюер). Расскажу, на что действительно обращают внимание и как пройти техническую часть без стресса.

1️⃣ Что проверяют на техническом собеседовании? Для чего вообще его проводят:

Вас будут оценивать по нескольким ключевым направлениям и тут уже не важно какой у вас стаж:

1.1. Понимание процессов разработки

- SDLC (Software Development Life Cycle) – какие этапы, кто за что отвечает. Если уже с опытом, попросят поделиться им и рассказать как было на ваших проектах.

- Методологии (Agile, Scrum, Kanban, Waterfall) – не просто названия, а как они применяются в реальных проектах. Спросят что и для чего выберете вы сами, с чем работали, с чем сталкивались.

- Роль аналитика в команде – взаимодействие с PM, разработчиками, тестировщиками. С чем были трудности, как решали конфликты.

❌ Ошибка новичка: Путать обязанности аналитика и проджект-менеджера.

1.2. Работа с требованиями

- Виды требований (BRS, SRS, User Stories, Use Cases).
- Как писать четкие, нефтогенерящие требования.
- Техники сбора требований (интервью, workshops, прототипирование).

✅ Совет: Будьте готовы разобрать кейс – например, как вы будете собирать требования для нового функционала в мобильном приложении.

1.3. Документирование и моделирование

- Диаграммы (BPMN, UML, ER, DFD) – хотя бы базовое понимание.
- Инструменты (Confluence, Jira, Figma, Miro, draw.io) – если не знаете, скажите, что быстро освоите.

❌ Ошибка новичка: Говорить, что вы "отлично знаете BPMN", но не суметь нарисовать простой процесс. А это точно проверят)))

1.4. SQL и данные (часто спрашивают!)

- Базовый SQL (SELECT, JOIN, GROUP BY, подзапросы).
- Нормализация БД, ключи, индексы – хотя бы основы.
- NoSQL vs SQL – когда что применяется.

✅ Совет: Если не уверены в SQL, потренируйтесь на leetcode.com или sql-ex.ru.

1.5. API и интеграции

- REST vs SOAP.
- Что такое Swagger/OpenAPI.
- Форматы данных (JSON, XML).

❌ Ошибка новичка: Путать PUT и POST в REST API.

2️⃣ Как готовиться к собеседованию?

📌 2.1. Разберите типовые вопросы

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

Пробегитесь по часто-задоваемым вопросам, которые я описывала: Часть 1 и Часть 2

📌 2.2. Практика на кейсах

Вас могут попросить:
- Описать процесс "Оформления заказа" в интернет-магазине.
- Написать User Story для функции "Поиск по фильтрам".
- Нарисовать схему взаимодействия систем.

📌 2.3. Повторите основы
- SQL (хотя бы SELECT + JOIN).
- Протоколы HTTP, методы API.
- Основы тестирования (что такое smoke-тесты, регресс?).

3️⃣ Как вести себя на собеседовании?

🎯 3.1. Говорите структурированно
Используйте метод STAR (Situation, Task, Action, Result) для ответов:
- "Был проект Х, задача Y, я сделал Z, результат – W".

🎯 3.2. Не бойтесь говорить "не знаю"
Лучше честно сказать *"Я с этим не сталкивался, но могу разобраться"*, чем врать.

🎯 3.3. Задавайте вопросы
- "Как в вашей компании строится процесс работы с требованиями?"
- "Какие инструменты вы используете?"
- "Какие сложности бывают в проектах?"

4️⃣ Что делать после собеседования?

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

Вместо вывода:

Главное – практика и уверенность. Даже если не знаете ответ, покажите ход мыслей. IT-аналитика – это не про зазубренные ответы, а про умение разбираться в процессах и доносить идеи.

Источник: @ba_and_sa

Удачи на собеседовании! 🚀 Если есть вопросы – пишите в комментарии👇

Требования vs Реальность: Почему в ТЗ находят «дыры» и как это исправить

⏳ 11 мин | 🟤🟤⚪️

Перейти | BA|SA

Новые процессы без боли: как сделать так, чтобы команда не сопротивлялась

⏳ 4 мин | 🟤⚪️⚪️

Перейти | BA|SA

Если говорить про требования к кандидатам, тогда (2012-2013) и сегодня (2024-2025), то отличия тоже есть:

✅ 2012-2013 г.

- Раньше было проще попасть даже с минимальными знаниями бизнес-анализа (я прошла 3 собеседования и мне прислали оффер). За плечами было только образование прикладной информатики, знаний было мало, опыта практически не было, только прохождение практики на одном проекте, ну и диплом с описанием процессов.

- Технические требования: моделирование БП в любой из нотаций, знание Excel, умение общаться с заказчиками, написание документации.

✅ 2024-2025 г.:

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

- Технические требования: моделирование БП, основы интеграции, api, понимание архитектуры, знание БД (написание простых запросов), и многое другое . Напомню, что я делала анализ рынка по требованиям к кандидатам в 2024г., там как раз есть описание требований по опыту работы кандидатов.

⁉️ Что ждет аналитиков в будущем?

1. Полное исчезновение «чистых» BA в IT-продуктах (но сохранение в госсекторе в банках, крупных компаниях (нефтяных например)

2. Рост спроса на аналитиков-«переводчиков» между бизнесом и Data Science-командами

3. Упрощение entry-level: Junior-аналитикам будут доверять меньше задач, но требовать базового понимания DevOps (CI/CD, логирование) Ну и технические навыки будут серьезней.

Вывод

Аналитика движется к гибридным ролям с акцентом на:

✅ Техническую грамотность (код + инфраструктура).

✅ Гибкость (быстрое переключение между бизнесом и tech).

✅ Работу с ИИ (использование, но не зависимость от него).

Совет: Прокачивайте системное мышление и навыки презентации — это то, что не автоматизируется в ближайшие 10 лет.

Источник: @ba_and_sa

Docs as Code — это подход к созданию документации, при котором:

- Документация пишется как код (в текстовых форматах: Markdown, reStructuredText, AsciiDoc).
- Хранится в системе контроля версий (Git).
- Сборка и публикация автоматизируются через CI/CD (например, GitHub Actions, GitLab CI).
- Изменения проходят ревью, как код.

📎И небольшая подборка статей на эту тему:

- Docs as Code: введение в предмет
- Инструменты подхода Docs-as-code
- Как перейти на Docs-as-a-Code и какие инструменты для этого использовать
- Docs As Code: Документация как Код

@ba_and_sa

Салют! Сегодня делюсь с вами своими советами по составлению резюме для новичка😊

1️⃣ Структура резюме

Резюме должно быть четким, читаемым и релевантным.

Оптимальная структура:
- Контактные данные (имя, телефон, email, LinkedIn/GitHub если есть)
- Цель / Краткое описание (2-3 предложения о твоих навыках и ожиданиях от работы):

- Навыки (Hard & Soft Skills)
- Опыт работы (если есть) / Стажировки / Проекты
- Образование
- Дополнительная информация (сертификаты, курсы, языки, хобби, если это релевантно)

2️⃣ На что обратить внимание?

✅ Что выделить:

1. Технические навыки (даже если опыта мало):
- Работа с требованиями (User Stories, Use Cases)
- Основы SQL (простые запросы)
- UML / BPMN (даже базовые диаграммы)
- Знание методологий (Agile, Waterfall)
- Инструменты (Jira, Confluence, Trello, Figma, Postman)

2. Soft Skills (очень важны для аналитика):
- Коммуникация, работа с stakeholders
- Аналитическое мышление
- Умение структурировать информацию

3. Проекты / Кейсы (если нет коммерческого опыта):
- Учебные проекты (например, разбор бизнес-процессов магазина)
- Курсовые работы (если связаны с анализом)
- Фриланс / Волонтерство (если помогал с документацией)

4. Образование и курсы:
- Диплом по смежной специальности (IT, экономика, менеджмент)? Укажи.
- Курсы по аналитике (Coursera, Stepik, Skillbox)? Обязательно впиши.

❌ Чего избегать:

- Общих фраз в стиле "быстро учусь, стрессоустойчивый" (лучше показать на примере).
- Списка всех подряд технологий (если не уверен — не пиши).
- Длинных описаний нерелевантного опыта (например, если работал официантом — можно кратко, без деталей).

3️⃣ Как повысить шансы на собеседование?

- Подстрой резюме под вакансию (используй ключевые слова из описания).
- Добавь цифры (если есть проекты — укажи результаты: "автоматизировал процесс, что сократило время обработки данных на 20%").
- Сделай одностраничное резюме (новичку хватит).
- Проверь на ошибки (HR отсеивают резюме с опечатками).

‼️ Вместо вывода:

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

Источник: @ba_and_sa

UX/UI для системного аналитика: кратко и понятно

1️⃣ Чем отличаются UX и UI?

- UI (User Interface) – это визуальная часть: кнопки, цвета, шрифты, расположение элементов.
- UX (User Experience) – это удобство и логика взаимодействия. Даже красивый интерфейс может быть неудобным, если UX плохой.

2️⃣ Зачем системному аналитику разбираться в UX/UI?

- Чтобы понимать, как пользователи работают с системой и какие у них боли.
- Чтобы правильно формулировать требования к интерфейсу (не просто "сделать кнопку", а "упростить процесс оформления заказа").
- Чтобы общаться с дизайнерами и разработчиками на одном языке.

3️⃣ Основные принципы UX, которые важно знать

- Простота – чем меньше шагов для действия, тем лучше.
- Консистентность – одинаковые элементы ведут себя одинаково (например, синие подчеркнутые слова = ссылки).
- Обратная связь – пользователь должен понимать, что происходит (например, сообщение "Заказ сохранен" после нажатия кнопки).
- User Flow – логика перемещения пользователя по системе (например, "регистрация → подтверждение почты → вход в ЛК").

4️⃣ Основные принципы UI, которые важно знать

- Иерархия элементов – важные элементы (кнопки, заголовки) должны выделяться.
- Читаемость – шрифты должны быть разборчивыми, контраст текста и фона – достаточным.
- Единый стиль – цвета, шрифты, отступы должны быть согласованы по всей системе.
- Доступность – интерфейс должен быть удобен для всех, включая людей с ограниченными возможностями (например, контраст для слабовидящих).
- Предсказуемость – элементы интерфейса должны вести себя интуитивно (например, иконка лупы = поиск).

5️⃣ Что может сделать аналитик для улучшения UX?

- Изучать сценарии пользователей (как они реально работают с системой).
- Анализировать боли (например, если пользователи часто ошибаются при заполнении формы – возможно, её надо упростить).
- Проверять гипотезы (например, A/B-тестирование: сравнить два варианта интерфейса).

6️⃣ Что может сделать аналитик для улучшения UI?

- Собирать требования к визуалу (например, "кнопка должна быть заметной, но не раздражающей").
- Проверять соответствие гайдлайнам (если у компании есть дизайн-система, следить, чтобы интерфейс ей соответствовал).
- Тестировать адаптивность – убеждаться, что интерфейс хорошо выглядит на разных устройствах (ПК, мобильные).
- Фиксировать несогласованности (например, если в одном месте кнопки зеленые, а в другом – синие).

⁉️ Где взять информацию по UX/UI?

- Книги: *"Не заставляйте меня думать. Веб-юзабилити и здравый смысл"* (Стив Круг), *"Интерфейс"* (Алан Купер).
- Гайдлайны (Google Material Design, Apple Human Interface Guidelines).
- Инструменты: Figma, Miro (для анализа экранов и user flow).

Вывод: UX/UI – это не только про дизайн, но и про логику и удобство системы. Хороший системный аналитик должен понимать основы, чтобы создавать удобные и эстетичные решения.

Источник: @ba_and_sa

Используйте Camunda как удобный REST-движок для оркестрации и workflow — без необходимости работать с Java

⏳ 6 мин | 🟤⚪️⚪️

Перейти | BA|SA

Салют! Когда я проходила собесы у меня часто спрашивали «Чем полезен системный аналитик в команде разработки?» или я должна была пояснить, кто он такой и чем занимается. Поэтому сегодня немного погрузимся в эту тему😉

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

Но чем именно он полезен для каждого участника команды?

1. Для тестировщиков (QA)

✅ Четкие требования = меньше багов на выходе

- Аналитик прорабатывает сценарии использования, edge-кейсы и нефункциональные требования (производительность, безопасность), что снижает количество "недопониманий" на этапе тестирования.
- Формализует требования так, чтобы их можно было проверить (критерии приемки).

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

2. Для разработчиков

✅ Минимум "мусорных" задач и переделок

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

❌ Без аналитика: разработчики либо делают "как поняли", либо получают бесконечные правки от заказчика.

3. Для проектировщиков (архитекторов, Tech Lead'ов)

✅ Технические ограничения учтены на раннем этапе

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

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

4. Для дизайнеров (UX/UI)

✅ Понимание пользовательских сценариев = осознанный дизайн

- Аналитик объясняет, кто и как будет пользоваться системой, какие у пользователей боли и цели.
- Формализует требования к интерфейсу (например, "должна быть одна кнопка для подтверждения, а не три").

❌ Без аналитика: дизайнер рисует красиво, но непрактично, и потом приходится переделывать.

5. Для менеджеров (PM, PO, продактов)

✅ Контроль над scope'ом и приоритетами

- Аналитик помогает разбивать фичи на MVP и "допилы", чтобы не распыляться.
- Снижает риски, выявляя противоречия в требованиях до начала разработки.

❌ Без аналитика: менеджер берет на себя роль аналитика, но тратит время на рутину вместо стратегии.

—————————
Где без системного аналитика не обойтись?

🔹 Сложные предметные области (финансы, медицина, гос.системы) — без аналитика легко наломать дров.
🔹 Большие распределенные команды — нужен человек, который держит в голове всю систему.
🔹 Проекты с жесткими регуляторными требованиями (например, GDPR, 152-ФЗ) — без аналитика можно пропустить критичные ограничения.

Когда системный аналитик не так критичен?

🔸 Маленькие проекты или стартапы — можно обойтись проджектом или техлидом.
🔸 Прототипирование и эксперименты — если требования меняются каждый день, аналитик может замедлять процесс.


Поэтому можно сказать, что Системный аналитик — это не просто "тот, кто пишет ТЗ", а профессионал, который экономит время и нервы команды, снижая риски и повышая качество продукта. Если в вашем проекте есть сложность, неопределенность или много заинтересованных сторон — без него будет тяжело.

Источник: @ba_and_sa

Развертывание микросервисов: проблемы, решения, стратегии, антипаттерны, практические рекомендации

⏳ 25 мин | 🟤🟤⚪️

Перейти | BA|SA