Вернуться в видеотекуИнтервью на IT Бизнес Аналитика /Business Analyst (часть 1)
Мок-интервью на Middle Business Analyst с практическими кейсами по элиситации требований, приоритизации и разрешению командных конфликтов. Завершается упражнением по моделированию процесса оплаты в ресторане и детальным фидбэком по диаграмме.
- Направление
- Business Analysis
- Формат
- Мок-собеседование
- Грейд
- Middle
- Длительность
- 35 мин
Коротко о видео
Первая часть мок-интервью на роль Middle Business Analyst: кандидатка с опытом PM отвечает на практические кейсы, характерные, по её словам, для собеседований на рынке UK. На примерах мобильного банкинга обсуждаются работа с новыми стейкхолдерами, приоритизация конфликтующих потребностей и разбор разногласий между QA и разработчиком. В финале кандидатка строит диаграмму оплаты счёта в ресторане, а интервьюер разбирает выбор нотации, логику процесса и ошибки моделирования.
Затронутые темы
Что взять на заметку
- При появлении новых стейкхолдеров сначала уточнить их роль: влияют ли они на продукт или только получают отчётность; затем обновить план коммуникаций и RACI-матрицу.
- Для сбора требований у нового отдела маркетинга кандидатка предлагает сочетать интервью и воркшопы с прототипами, вайрфреймами и моделированием процессов, а не ограничиваться письменными опросами.
- Конфликт между запросами разных отделов можно снижать заранее согласованными квотами спринта на новые фичи, баги, техдолг и другие виды работ.
- Если квоты не решают спор об одних и тех же задачах, обсуждаются MoSCoW и ICE как способы перевести разговор от позиций участников к приоритетам, данным и допущениям.
- При споре QA и разработчика сначала нужно быстро прояснить реализацию, чтобы не блокировать команду, затем найти причину: неоднозначные требования, отсутствие доступа к ним или недопонимание.
- Задачи в Jira стоит связывать с требованиями в Confluence; уточнения, найденные в ходе обсуждения, нужно зафиксировать в документации.
- Перед построением процессной диаграммы нужно определить её цель, границы, вход и выход, участников и нужную степень детализации; для ролей клиента и официанта нужны отдельные дорожки.