Введение
Независимо от того, приступаете ли вы к новой для себя сферы деятельности или хотите поднятся на ступеньку выше в своей карьере бизнес-аналитика, важно подготовиться к различным вопросам, которые вы можете услышать на собеседовании в новой компании. Потому что собеседование — это искусство преподнести компании себя наиболее подходящим кандидатом с нужным набором навыков и знаний, а также личностных качеств.
Как правило на собеседовании времени на раздумия крайне мало, поэтому важно заранее подготовиться по всем возможным направления деятельности бизнес-аналитика, чтобы не упасть лицом в грязь!
Уровень и сложность вопросов на собеседовании с бизнес-аналитиком варьируется в зависимости от должности, на которую вы претендуете, а также от должности в конкретной компании. Прочитайте вопросы и ответы из разных уровней сложности. Если у вас возникнут вопросы по материалам — оставьте комментарий к статье.
В этом блоге мы собрали «50 лучших вопросов из интервью для бизнес-аналитиков» — это наиболее популярные вопросы и ответы для прохождения собеседования на позицию бизнес-аналитика.
Вопросы и ответы на собеседовании с ведущими бизнес-аналитиками
Вопросы на собеседовании с ведущими бизнес-аналитиками подпадают под общую категорию и могут быть заданы, как часть вопросов на собеседовании с бизнес-аналитиками для любого уровня карьеры.
Вопрос 1 — Кто такой бизнес-аналитик? v
Ответ: Бизнес-аналитик работает как мост между различными заинтересованными сторонами в организации. Он общается с различными заинтересованными сторонами в организации, чтобы прояснить и окончательно сформулировать требования, помогает команде проекта в планировании проекта, проектировании и окончательной проверке Решения или отдельных разработанных компонентов Решения. Бизнес-аналитик — это человек, который обладает достаточными знаниями в предметной области и может сортировать бизнес-потребности от разных stakeholders, которые относятся к разным доменам.
Бизнес-аналитик — это сотрудник компании или внешний эксперт, который помогает компании проанализировать свои процессы, продукты, услуги и системы для того, чтобы улучшить текущие процессы, а также для того, чтобы разработать выгодные решения на основе анализа данных и анализа процессов.
Основная задача бизнес-аналитика в широком смысле: изучить текущий контекст бизнеса (внешняя бизнес-среда, внутренние бизнес-процессы), собрать потребности от заинтересованных сторон, описать на основе потребностей требования и обосновать возможные решения/изменения, которые необходимы бизнесу.
Вопрос 2 — Назовите типы документов, которые бизнес-аналитик использует в своей работе? v
Ответ: Ниже приведены некоторые из распространенных документов, с которыми работает бизнес-аналитик:
- Project vision document (Документ «Видение и границы проекта»)
- Use cases (Сценарии использования, Варианты использования или в народе Юзкейсы)
- Requirement Management Plan (План управления требованиями)
- User stories (Пользовательские истории)
- Requirement Traceability Matrix (RTM) — Матрица отслеживания требований
- Business Requirement Document (Бизнес-требования)
- System Requirement Specification (SRS) — Спецификация требований программного обеспечения / System Requirement Document (SRD) — Системные требования
- Test case (Тестирование или Тест-кейс)
- Functional Requirement Specification (FRS) — Спецификация функциональных требований / Functional Specification Document (FSD) — Документ с функциональными требованиями
Вопрос 3 — Что такое SRS и какие ключевые элементы SRS вы знаете? v
Ответ: Спецификация системных требований (SRS) или Спецификация требований к программному обеспечению — это документ или набор документов, которые описывают функции системы или программного приложения. Документ включает в себя множество элементов, которые определяют предполагаемую функциональность, необходимую для заинтересованных сторон и заказчика для удовлетворения конечных пользователей.
В дополнение к этому, SRS предоставляет общее представление о Системе/Решении и ее поведении, основных поддерживаемых бизнес-процессах, предположениях и ключевых параметрах производительности системы.
Ключевые элементы SRS:
- Объем работ
- Функциональные требования
- Нефункциональные требования
- Зависимости
- Модель данных
- Предположения
- Ограничения
- Критерии приемки
Вопрос 4 — Что такое требование? v
Ответ. Требование — описывает, что нужно сделать для достижения определенных бизнес-целей. Это входные данные для различных этапов SDLC (жизненного цикла программного обеспечения). Требования — это основа проекта, которые перед реализацией должны быть утверждены заинтересованными сторонами и бизнес-пользователями. Кроме того, каждое требование должно быть должным образом задокументировано для использования в будущем.
Требование — это пригодное для использования описание потребности бизнес-пользователя/заинтересованной стороны. В центре внимания находится вопрос: какую пользу получит бизнес-пользователь в результате выполнения/реализации требования. По сути, требованием может выступать как одно предложение, так и целый документ (или набор документов) — все сильно зависит от обстоятельств и масштабности проекта.
Также требования делятся на разные типы, о них хорошо написано в книге Анализ требований по Вигерсу (2004).
- Бизнес-требование: Представление целей, задач и результатов, объясняющих зачем было инициировано изменение и как будет оцениваться успех. Бизнес-требование — это не то, что должна выполнять система. Это то, что бизнесу нужно делать или иметь, чтобы продолжать расти или сохранить компанию.
- Функциональные требования — это особенности продукта или функции, которые разработчики должны реализовать, чтобы пользователи могли выполнять свои задачи. Поэтому важно прояснить их как для команды разработчиков, так и для заинтересованных сторон. Как правило, функциональные требования описывают поведение системы в определенных условиях.
- Система отправляет запрос на одобрение после того, как пользователь вводит личную информацию.
- Система отправляет электронное письмо с подтверждением при создании новой учетной записи.
- Нефункциональные требования — это требования, которые не связаны с функциональностью системы, они определяют, как система должна работать. Вот несколько примеров:
- Страницы сайта должны загружаться за 3 секунды при общем количестве одновременных пользователей < 5 тысяч.
- Система должна поддерживать 20 миллионов пользователей без снижения производительности.
Вопрос 5 — Что такое Use Case (вариант использования)? v
Ответ: Вариант использования — это схематическое представление системы, которое описывает, как пользователь использует систему для достижения цели (т.е. описан сценарий взаимодействия с системой). Это неотъемлемая часть методики разработки программного обеспечения и моделирования программного обеспечения, которая помогает определить целевые функции и предусмотреть обработку возможных ошибок, с которыми может столкнуться пользователь.
Варианты использования описывают взаимодействие между главным действующим лицом и решением, которые необходимы для достижения цели. Use case описывает возможные результаты попыток достижения определенной цели. Варианты использования пишутся с точки зрения действующего лица и избегают описания внутренней работы решения.
Вопрос 6 — Какие шаги нужно выполнить, чтобы разработать Use Case (вариант использования)? v
Ответ: Этапы разработки сценариев использования:
- Определите пользователей системы
- Создайте на каждую категорию пользователя отдельный профиль пользователя. Это включает в себя все роли, которые могут играть пользователи и которые имеют отношение к системе.
- Определите основные цели, связанные с каждой ролью. Также опишите роли.
- Далее нужно создать вариант использования для каждой цели, связанной с шаблоном варианта использования. Это также включает поддержание одного и того же уровня абстракции для всего варианта использования. Шаги варианта использования более высокого уровня считаются целями для более низкого уровня.
- Структурирование вариантов использования
- Просмотр и проверка пользователей
Вопрос 7 — Что такое Scope creep (разрастание или «расползание» границ проекта) и как его избежать? v
Ответ. В простейшей форме Scope creep — это когда требования, цели или видение проекта меняются сверх того, что было первоначально согласовано. Когда это происходит, проект перестает быть четко определенным, а границы ответственности — и, в конечном итоге, даты завершения проекта — становятся нечеткими.
Разрастание границ проекта или разрастание требований — это термин, который относится к неконтролируемым изменениям или отклонениям в объеме проекта в пределах одного и того же диапазона ресурсов, например, в рамках одного и того же графика работ и бюджета проекта. Это показатель плохого управления проектом и серьезного риска для проекта. Некоторые из возможных причин scope creep:
- Плохая коммуникация между заинтересованными сторонами проекта
- Неправильная документация требований проекта
Scope creep можно избежать за счет:
- Изучите цели своего проекта с самого начала
- Четкая и «прозрачная» документация о границах проекта
- Правильно выстроенный процесс управления изменениями, которому следуют все участники проекта и заинтересованные стороны
- Используйте программное обеспечение для управления проектами, чтобы держать всех в курсе
- Предварительное уведомление о последствиях изменений для связанных сторон
- Надлежащая документация по новым требованиям в project log
- Защитите свою команду от «позолоты»: воздержитесь от добавления extra features к существующим функциям
- Настройте правильный канал коммуникации между заинтересованными сторонами и вашей командой
Вопрос 8 — Что такое BRD? Чем он отличается от SRS? v
Ответ: Документ бизнес-требований (BRD) подробно описывает бизнес-решение, которое будет реализовываться в рамках проекта, в соответствии с потребностями и требованиями бизнеса/клиента. Он включает в себя цель запуска проекта, какое бизнес-решение оно предоставляет, цель выполнения проекта, функциональность решения, а также план-график его реализации. В общем, он описывает общую концепцию того, над чем команда собирается работать, и каков будет и как должен выглядеть конечный результат в соответствии с потребностями и требованиями бизнеса. Перед началом проекта проводится множество исследований для определения его общей структуры, требований, функций, ограничений и многого другого.
Согласно BABOK 3: Business requirements (Бизнес-требования) — Описания целей, задач и результатов, которые раскрывают информацию о том, зачем было инициировано изменение и как будут оцениваться резуальтаты проекта.
Разница между BRD и SRS заключается в следующем:
| BRD | SRS |
| BRD — это сокращение от Business Requirement Document. | SRS — это сокращение, используемое для обозначения требований к программному обеспечению. |
| BRD широко известен как документ спецификации бизнес-требований. | SRS также называется Спецификацией требований к продукту и Спецификацией системных требований. |
| Он поддерживается Business Analyst. | Он поддерживается бизнес-аналитиком или системным аналитиком. |
| Сосредоточен на бизнес-требованиях и требованиях заинтересованных сторон. | Сосредоточьтесь на функциональных и нефункциональных требованиях. |
| Используется на этапе инициации. | Используется на этапе планирования. |
| BRD используется управленческими командами высшего и среднего звена. | SRS используется менеджерами проектов, техническими руководителями и экспертами в предметной области. |
Вопрос 9 — Что такое Gap Analysis (анализ разрывов)? v
Ответ: Gap Analysis может применяться для различных целей.
Рассмотрим два наиболее релевантных определения для бизнес-аналитика. Один относится к разработке ПО, другой к разработке стратегии/плана развития компании.
Gap Analysis (анализ разрывов) — это метод анализа пробелов между функциями существующей системой и целевой системой. Разрыв (или пробел) означает объем задачи или изменение, которое может потребоваться для получения желаемого результата. Это сравнение уровня производительности между существующими и предлагаемыми функциями.
Gap Analysis (анализ разрывов) позволяет организациям определить, как лучше всего достичь своих бизнес-целей. Он сравнивает текущее состояние с идеальным состоянием или целями, что указывает на недостатки и возможности для улучшения. Определяя и анализируя эти пробелы, команда менеджеров может создать план действий, чтобы продвинуть организацию вперед и восполнить пробелы в производительности.
Вопрос 10 — Что такое приоритизация требований? Какие методы используются для растановки приоритетов у требований? v
Ответ: Приоритизация требований — это процесс распределения требований на основе срочности для бизнеса в зависимости от разных параметров: фазы проекта, график работ, стоимость и т.д.
Существуют различные методы, которые используются для определения приоритетов требований:
- MoSCoW Technique — метод приоритезации, помогающий понять и управлять приоритетами. Буквы означают:
- Must Have
- Should Have
- Could Have
- Won’t Have this time
- 100-dollar method — Один из способов сделать расстановку приоритетов более осязаемой — представить ее в терминах реального ресурса: денег. Дайте команде по расстановке приоритетов 100 воображаемых долларов для работы. Члены команды выделяют эти доллары на «покупку» элементов, которые они хотели бы реализовать, из набора требований кандидатов. Выделение большего количества долларов приводит к большему значению более приоритетных требований.
- Kano Analysis — это подход к приоритизации функций в списке требований на основе степени, в которой они могут удовлетворить клиентов.
- Матрица решений Эйзенхауэра — Чем меньше число, тем выше приоритет раздела.
- Timeboxing / Budgeting — используется, когда есть фиксированные сроки / бюджеты для достижения вех проекта. Timeboxing используется в проектах, которые ограничены крайними сроками, где реализация проекта так же важна, как и проект, который выполняется вовремя или разрабатывается в рамках бюджета. Этот метод основан на предпосылке, что важнее иметь хотя бы основные функции продукта и выпускать продукт вовремя, чем иметь все функции и запускать продукт позже. Есть две точки оценки — нормальные усилия по завершению и усилия по безопасному завершению. Нормальные усилия по завершению — это счастливый сценарий разработки требований, в то время как усилия по безопасному завершению — это оценка, основанная на наихудшем сценарии.
BABOK 3.0 предлагает 8 факторов, влияющих на приоритизацию требований:
- Выгода — это преимущество, которое бизнес получает в результате выполнения требований. Полученная выгода может относиться к функциональности, качеству или стратегическим/бизнес-целям.
- Штраф — это следствие невыполнения требования. Это может относиться к получению штрафа, потере доли рынка, неполучению дополнительной прибыли, неудовлетворенности потребителя или снижение удобства использования продукта.
- Стоимость — это усилия и ресурсы, необходимые для реализации требования. Ресурс может относиться к финансам, людским ресурсам или даже технологиям.
- Риск — это вероятность того, что требование может не принести ожидаемой ценности. Это может быть связано с различными причинами, начиная от сложности понимания требования и заканчивая его реализацией.
- Зависимости — это отношения между требованиями. Таким образом, требование потребует выполнения другого требования для его реализации.
- Чувствительность ко времени — все идет со сроком годности. Необходимо указать, когда истекает срок действия требования, или также, если требование носит сезонный характер.
- Стабильность — это относится к вероятности того, что требование останется статичным.
- Соответствие нормативным требованиям / политикам — те требования, которые необходимо выполнить, чтобы соответствовать нормативным требованиям.
Лучшие вопросы для интервью с бизнес-аналитиком начального уровня
Вопрос 11 — Что такое метод выявления требований (requirement elicitation)? v
Ответ. Выявление требований — это процесс сбора требований от заинтересованных сторон, пользователей и клиентов путем проведения встреч, анкетирования, интервью, создания прототипов, мозгового штурма, сессий и т.д.
Согласно BABOK 3: elicitation — это итеративный путь получения информации от заинтересованных сторон и из других источников, путем извлечения информации и/или порождения производной информации.
Работа по выявлению требований происходит в начале проекта. На этом этапе вы не тратите время на размышления о том, как вы собираетесь реализовывать требования. Выявление требований не должно ограничиваться разговорами «Маловероятно, что мы сможем заставить это работать». Сначала определите, что вам нужно, а затем, позже, в процессе работы с требованиями, вы сможете расставить приоритеты по функциональности и определить, как вы можете выполнить требования таким образом, чтобы это соответствовало общим целям проекта. В идеале сбор требований по проектам должен проходить под руководством и при поддержке бизнес-аналитика. Однако многие проектные группы не имеют в команде отдельного специалиста, у которого есть специальные навыки по бизнес-анализу. Поэтому руководителю проекта и членам команды приходится самостоятельно выяснять и документировать требования.
Вопрос 12 — В чем принципиальная разница между требованием и потребностью с точки зрения бизнес-анализа? v
Ответ:
Требования — это то, что нам нужно сделать, чтобы удовлетворить полностью или частично высказанную потребность. Другими словами, требование — это пригодное для практической реализации представление потребности.
Потребность или business need — это стратегически или тактически важная проблема или возможность, которая подлежит рассмотрению. В бизнесе потребности — это цели и задачи, которые бизнес должен достичь, чтобы работать, получать прибыль, эффективно служить и успешно выполнять свою миссию.
Потребности — это цели и задачи, которые бизнес должен достичь, в то время как требования — то, что нам нужно сделать для того, чтобы достичь потребности.
Вопрос 13 — Что такое нефункциональные требования и как вы их фиксируете? v
Ответ. Нефункциональные требования представляют такие характеристики уровня производительности, как скорость реакции, плавность пользовательского интерфейса, безопасность и т.д. разрабатываемого приложения.
Согласно BABOK 3: Нефункциональные требования описывают атрибуты производительности или качества, которым должно соответствовать решение. Нефункциональные требования обычно измеримы и играют роль ограничений дизайна решения в целом.
Вопрос 14 — Какими навыками должен обладать бизнес-аналитик? v
Ответ: Мы можем в общих чертах разделить навыки бизнес-аналитика на три типа:
- Фундаментальные навыки
- Технические навыки
- Навыки бизнес-анализа
Для каждой из вышеперечисленных категорий бизнес-аналитик должен обладать некоторыми навыками, как указано ниже:
| Категория навыков | Навыки |
| Фундаментальные навыки |
|
| Технические навыки |
|
| Навыки бизнес-анализа |
|
Вопрос 15 — Как вы можете описать «требование хорошего качества» как бизнес-аналитик? Какие критерии вы бы использовали для оценки требования. v
Ответ: Мы можем измерить качество требования с помощью правила SMART. Согласно этому правилу, требование хорошего качества должно быть:
- Specific (Конкретным): Требование должно быть конкретным и могло быть должным образом задокументировано
- Measurable (Измеримым): Различные параметры могут измерять критерии успеха требования
- Attainable (Достижимое): Требование должно быть выполнимым в пределах объема данных ресурсов
- Relevant (Актуально): требование должно соответствовать бизнес-модели проекта.
- Timely (Своевременность): требование должно быть сообщено на ранней стадии жизненного цикла проекта.
Вопрос 16 — Какие документы используются для сбора нефункциональных требований? v
Ответ: Есть два документа, которые используются для фиксации нефункциональных требований, а именно:
- SDD (системный проектный документ)
- FRD (документ с функциональными требованиями)
Вопрос 17 — Что такое альтернативный поток (alternate flow) в диаграмме Use Case (вариантов использования)? v
Ответ: Это альтернативное решение или действие в варианте использования, которому следует следовать в случае любого сбоя в системе.
Вопрос 18 — Что такое персонажи (personas) в бизнес-анализе? v
Ответ: Personas (Персонажи) представляют собой методологии проектирования, ориентированного на пользователя. Чтобы приложение могло работать на демографической основе, вымышленные персонажи концептуализируются бизнес-аналитиками и на основе их возможных демографических сценариев поведения создаются во время проектирования.
Вопрос 19 — Что такое диаграмма действий (activity diagram) и какие важные элементы она содержит? v
Ответ. Activity diagram (Диаграмма действий) — диаграмма поведения UML, описывающая динамические аспекты системы. Диаграмма действий — это, по сути, расширенная версия блок-схемы, которая моделирует переход от одного действия к другому. Действие можно описать как работу системы. Поток управления переходит от одной операции к другой. Этот поток может быть последовательным, разветвленным или параллельным. Диаграммы действий имеют дело со всеми типами управления потоком с использованием различных элементов, таких как fork, join и т.д.
Основная цель диаграммы деятельности — зафиксировать динамическое поведение системы.
Вопрос 20 — Что такое UML-моделирование? v
Ответ: UML расшифровывается как Unified Modeling Language. Это стандарт, который отрасль использует для документирования, построения и визуализации различных компонентов системы. Этот стандарт моделирования в основном используется для разработки программного обеспечения. Однако он также используется для описания рабочих ролей, организационных функций и бизнес-процессов. Некоторые из важных диаграмм, которые BA используют как часть UML, — это диаграмма классов, диаграммы состояний и варианты использования.
Самые популярные вопросы на собеседовании с младшим бизнес-аналитиком
Вопрос 21 — Каким лучшим практикам нужно следовать при написании варианта использования? v
Ответ. Некоторые из лучших практик для написания сценария использования заключаются в следующем:
- Чтобы стать допустимым вариантом использования, он должен вернуть некоторую ценность субъекту или заинтересованному лицу.
- Функциональные и нефункциональные требования должны быть соответствующим образом отражены в сценарии использования.
- Вариант использования должен иметь один или несколько альтернативных потоков наряду с основным потоком.
- Вариант использования должен описывать только то, что делает система, а не то, как это делается, что означает, что он не будет описывать дизайн. С точки зрения актера, это будет черный ящик.
Вопрос 22 — В чем разница между exception flow (потоком исключений) и alternate flow (альтернативным потоком)? v
Ответ: Альтернативный поток — это альтернативные действия, которые могут выполняться отдельно для основного потока и могут рассматриваться как дополнительный поток.
Поток исключений — это путь, пройденный в случае какого-либо исключения или ошибки.
Вопрос 23 — Как вы думаете, бизнес-аналитик должен участвовать в тестировании Решения? v
Ответ: Да. Потому что бизнес-аналитик очень хорошо понимает общие системные требования и проблемы, связанные с ними. Следовательно, он может сыграть важную роль на этапе тестирования, чтобы запустить его надлежащим образом и разрешить любой системный запрос.
Вопрос 24 — Что означает INVEST? v
Ответ: INVEST — это аббревиатура, с помощью которой менеджер по продукту или разработчик может создавать качественные пользовательские истории. INVEST расшифровывается как «Независимый, Договорной, Ценный, Подлежащий оценке, Соответствующий размер, Поддающийся проверке».
- Independent (Независимый)
- Negotiable (договорный)
- Valuable (Ценный)
- Estimable (Примерный)
- Sized Appropriately (Соответствующий размер)
- Testable (Проверяемый)
I — Независимость: пользовательская история должна быть автономной, если это вообще возможно, чтобы избежать зависимости от других пользовательских историй. Поскольку одной из характеристик гибких методологий является способность проявлять гибкость и менять приоритеты в том, что важно, независимые пользовательские истории обеспечивают гибкость при планировании итераций. Если вы обнаружите, что ваши пользовательские истории зависят друг от друга, вы можете объединить вместе небольшие пользовательские истории, которые зависят друг от друга. Точно так же вы можете разделить более крупные зависимые пользовательские истории на более мелкие истории, так что одна из новых более мелких историй будет содержать и изолировать перекрывающуюся часть более крупных историй.
N — договорная: истории пользователей всегда можно изменить или переписать до момента кодирования. Это дополнительно поддерживает гибкость, связанную с гибкими методологиями. Поскольку требования часто развиваются или повышаются и теряют приоритет, пользовательские истории должны иметь возможность адаптироваться к меняющимся требованиям.
V — Ценный: история пользователя представляет собой цель конечного пользователя или покупателя и должна предоставлять функциональные возможности, которые считаются ценными. Это означает, что особенности технического дизайна — это не то, что вы документировали бы в виде пользовательских историй. Однако в некоторых технических требованиях есть компонент, который представляет ценность для пользователя. Пользователь может ожидать, что страницы загрузятся в течение 2 секунд. В пользовательской истории будет указано, что время загрузки страницы составляет 2 секунды, в то время как специфика физической реализации этого будет опущена.
E- Оценка: вы всегда должны иметь возможность оценить размер пользовательской истории. Иногда у разработчиков нет опыта, необходимого для определения конкретной ситуации или необходимого для пользовательской истории. В этом случае пользовательскую историю можно разделить на две отдельные пользовательские истории. Первый — это «всплеск», при котором разработчики проводят быстрое исследование, чтобы определить осуществимость чего-либо или получить лучшее представление о том, сколько времени может потребоваться для реализации конкретной функции. Спайк всегда ограничен временными рамками, то есть ограничен заранее определенным промежутком времени. Пользовательская история «всплеска» может быть названа «Исследование (что-то) для определения…», в то время как вторая пользовательская история — это то, где фактически будет реализована функциональность. Эти две пользовательские истории следует запланировать на две отдельные итерации, чтобы можно было завершить всплеск и оценить осуществимость второй пользовательской истории до начала кодирования. Это дает команде время отреагировать, если в результате всплеска возникнут проблемы.
S- Соответствующий размер: истории пользователей не должны быть слишком большими или слишком маленькими. Так как же решить, какой размер правильный. Во-первых, любая пользовательская история, которую разработчик не может завершить за одну итерацию (или пару разработчиков, если используется парное программирование), слишком велика. Пользовательская история должна быть разделена на две или несколько более мелких историй. Точно так же нет необходимости делать пользовательские истории слишком детализированными только ради декомпозиции функций. Если функции хорошо группируются и дополняют друг друга, тогда имеет смысл создать единую пользовательскую историю. Например: «Как соискатель работы я хочу иметь возможность добавлять, удалять и редактировать профессиональные навыки в моем электронном резюме, чтобы я мог вести точный список моих навыков». Нет причин разделять «добавить, удалить, редактировать».
T — Тестируемый: пользовательские истории должны быть тестируемыми, чтобы гарантировать, что разработка завершена и была сделана правильно. Итак, когда пользовательские истории нельзя тестировать? Часто, если аналитик невнимателен, нефункциональные требования написаны в непроверенной манере. Рассмотрим пример «страницы всегда должны загружаться быстро». В этом утверждении есть два непроверяемых компонента: «Всегда» и «быстро». Можно проверить утверждение, что «страницы должны загружаться в течение 1,5 секунд в 97% случаев».
Вопрос 25 — Что такое анализ Парето? v
Ответ: Анализ Парето использует принцип Парето, также известный как «Правило 80/20», который был введен итальянским экономистом Вильфредо Парето в его книге 1896 года «Политическая экономика».
Принцип Парето гласит, что 80 процентов выгоды проекта приходится на 20 процентов работы. Или, наоборот, 80 процентов проблем можно отнести к 20 процентам причин. Анализ Парето определяет проблемные области или задачи, которые принесут наибольшую отдачу. Инструмент имеет несколько преимуществ, в том числе:
- Выявление и приоритезация проблем и задач.
- Помогаем людям более эффективно организовать свои рабочие нагрузки.
- Повышение продуктивности.
- Повышение рентабельности.
Вопрос 26 — Что такое BPMN? Назовите основные элементы BPMN? v
Ответ: BPMN — это модель и нотация бизнес-процесса. Это графическое представление бизнес-процессов.
Business Process Modeling Notation (BPMN) — Нотация моделирования бизнес-процессов — это метод, используемый для иллюстрации бизнес-процессов. Информация помещается в диаграмму, которая напоминает блок-схему, поэтому ее легче понять и использовать.
BPMN — это метод блок-схемы, который моделирует шаги запланированного бизнес-процесса от начала до конца. Метод наглядно отображает подробную последовательность бизнес-операций и информационных потоков, необходимых для завершения процесса.
BPMN содержит четыре типа элементов для диаграмм бизнес-процессов:
- Flow objects: events, activities, gateways
- Connecting objects: sequence flow, message flow, association
- Swimlanes: pool or lane
- Artifacts: data object, group, annotation
BPMN — один из наиболее распространенных методов моделирования бизнес-процессов, в котором используются стандартизованные символы, чтобы сделать карты процессов более понятными для всех заинтересованных сторон: руководства, сотрудников и консультантов. Он предлагает стандартные обозначения, понятные каждому.
В чем разница между управлением бизнес-процессами (BPM) и нотацией моделирования бизнес-процессов (BPMN).
BPM (Управление бизнес-процессами) — это дисциплина, в которой используются различные подходы для обнаружения, анализа, измерения и улучшения бизнес-процессов, а также для получения эффективных результатов, поддерживающих бизнес-стратегию. Бизнес-процессы могут быть структурированными или неструктурированными. Технологии часто используются с BPM для согласования инвестиций в ИТ / OT с бизнес-стратегией.
Проще говоря, BPM — это эффективная методология управления и контроля процессов в организации, а также обеспечение их оптимизации, чтобы сделать организацию более рентабельной. BPM позволяет организациям согласовывать бизнес-функции с потребностями клиентов, а также помогает руководителям бизнеса определять, как развертывать, отслеживать и измерять ресурсы компании. При правильном внедрении BPM может повысить эффективность и продуктивность, минимизировать затраты и уменьшить количество ошибок и рисков, оптимизируя результаты.
Нотация моделирования бизнес-процессов (BPMN), с другой стороны, представляет собой язык пиктограмм, используемый для решения задач BPM. Карта процесса может описывать сложную бизнес-процедуру или простой бизнес-процесс. Следовательно, BPMN должна быть достаточно гибкой, чтобы регистрировать все бизнес-процессы. В результате получается язык, который легко понять и относительно ограничен по объему.
Вопрос 27 — Что такое Kano analysis (Кано-анализ)? v
Ответ: Kano Analysis — это подход к приоритизации функций в дорожной карте продукта на основе степени, в которой они могут удовлетворить клиентов. Продуктовые группы могут взвесить функциональность, приносящую высокий уровень удовлетворенности, с затратами на ее реализацию, чтобы определить, является ли добавление ее в дорожную карту стратегически правильным решением. Модель Кано — одна из многих систем приоритизации, разработанных, чтобы помочь продуктовым командам определять приоритеты инициатив.
Как работает модель Кано?
С помощью модели функции и атрибуты продукта или услуги подразделяются на пять категорий:
- Пороговые атрибуты (основные сведения) (обязательные функции) — это функции, которые клиенты ожидают от услуги или продукта, это не функции, которые обязательно впечатлят клиентов, но могут вызвать недовольство, если они отсутствуют.
- Атрибуты производительности (удовлетворяющие) (одномерные функции) — эти функции не входят в сделку, но при этом повышают уровень удовлетворения.
- Атрибуты возбуждения (восхищение) (привлекательные черты) — это важнейшие характеристики, которые увеличивают преимущество продукта / услуги перед конкурентами. Это атрибут, на котором стоит сосредоточиться, поскольку он поставит вас на пьедестал среди ваших конкурентов.
- Безразличные атрибуты — это особенности, которые клиенты не могут решить, хорошие они или плохие.
- Обратные атрибуты — эти функции могут быть высокого качества или производительности, но не повышать уровень удовлетворенности.
Чтобы оценить функцию, потребителям задают два вопроса:
- Как вы себя чувствуете, если у вас есть эта функция? (Функциональный вопрос)
- Как вы себя чувствуете, если у вас нет этой функции? (Дисфункциональный вопрос)
На оба вопроса даны ответы по пятибалльной шкале с единым кодом, а на приведенной ниже диаграмме показано, как каждая функция классифицируется на основе ответов на функциональные и дисфункциональные вопросы.
Вопрос 28 — Какие типы actors вы знаете для диаграммы use case?
Ответ: в сценарии использования могут быть изображены в основном актеры двух типов:
- Главные действующие лица — начинается процесс
- Вторичные актеры — это помогает первому актеру
Более того, мы можем разделить актеров на четыре типа:
- Человек
- система
- аппаратные средства
- таймер
Вопрос 29 — С какими типами разрывов может столкнуться бизнес-аналитик во время GAP-Анализа?
Ответ: в основном есть четыре типа пробелов —
- Разрыв в производительности — разница между ожидаемой и фактической производительностью
- Продукт / Рынок Gap — разрыв между бюджетом продажами и фактическими продажами называют как продукт / ниша на рынке
- Profit Gap — Разница между целевой и фактической прибылью компании.
- Разрыв в рабочей силе — разрыв между необходимым количеством и качеством рабочей силы и фактической силой в организации
Вопрос 30 — Что такое Benchmarking (Бенчмаркинг)?
Ответ: Бенчмаркинг — это измерение эффективности организации, которая конкурирует в отрасли. В этом процессе компания может измерять свою политику, результаты деятельности, правила и другие меры.
Самые популярные вопросы на интервью на позицию старшего бизнес-аналитика (Senior Business Analyst)
Вопрос 31 — Как вы решаете, что вы, как бизнес-аналитик, собрали все требования?
Ответ: Мы можем сделать вывод, что все требования собраны только тогда, когда —
- Это подтверждено и одобрено бизнес-пользователями.
- Требования соответствующим образом соответствуют бизнес-требованиям проекта.
- Требования могут быть реализованы с использованием доступных ресурсов.
- Все ключевые деловые заинтересованные стороны приведены в соответствие с выявленными требованиями.
Вопрос 32 — Как вы производите сбор требований?
Ответ: Процесс сбора требований обычно делится на несколько этапов, которые не зависят от цикла SDLC. Каждый шаг включает в себя:
- конкретные задачи для выполнения
- принципы, которым нужно следовать
- документы для производства
Шаги следующие:
Шаг 1: Сбор исходной информации — это может включать сбор исходной информации о проекте, анализ любого потенциального риска, связанного с проектом. Для этой цели могут быть использованы такие методы, как анализ PESTLE, схема пяти сил Портера.
Шаг 2: Определите заинтересованные стороны — они принимают решения по проекту и утверждают требования и приоритеты. Заинтересованные стороны могут варьироваться от владельцев проектов до старших менеджеров, конечных пользователей и даже конкурентов.
Шаг 3: Откройте для себя бизнес-цели — это понять бизнес-потребности проекта, прежде чем углубляться в проект. SWOT-анализ, сравнительный анализ, анализ бизнес-целей SMART и перечисление бизнес-целей — вот некоторые из методов, используемых для этой цели.
Шаг 4: Оценить варианты — это определить варианты для достижения бизнес-целей. Анализ воздействия, анализ риска, анализ затрат и выгод являются одними из методов, которые используются для этой цели.
Шаг 5: Определение области действия — область действия — это цель развития проекта, которая устанавливается на основе бизнес-целей. Документ определения области используется для детализации целей для каждого этапа проекта.
Шаг 6: План доставки бизнес-аналитика — на основе объема проекта, доступности заинтересованных сторон и методологии проекта на этом этапе создается документ, называемый бизнес-аналитиком. Документ предоставляет информацию о результатах с их графиком.
Шаг 7. Определение требований проекта. На этом этапе используются два типа документов: документ функционального требования и документ нефункционального требования. Основываясь на методологии разработки, которая будет использоваться в проекте, бизнес-аналитик должен прояснить требования с заинтересованными сторонами, опросив их о требованиях и подписав их.
Шаг 8: Поддержка внедрения через SDLC. Это технический шаг внедрения требований, когда бизнес-аналитик взаимодействует с различными командами. Это включает в себя координацию с командой разработчиков и группой тестирования, чтобы гарантировать, что требования реализованы, как и ожидалось, и соответствующим образом протестированы для всех возможных бизнес-сценариев. Они также должны обработать запрос на изменение, который может возникнуть у заинтересованных сторон на более позднем этапе.
Шаг 9: Оценить добавленную стоимость проекта — это постоянная оценка проекта, чтобы оценить, правильно ли реализация бизнес-целей соответствует результатам и срокам бизнес-потребностей.
Вопрос 33 — Почему бизнес-аналитику необходимо участвовать в процессе реализации требований?
Ответ. Получение знаний в области и предоставление аналитического решения являются двумя основными критериями бизнес-аналитика. Следовательно, во время фактической реализации требования или варианта использования бизнес-аналитик может помочь решить многие проблемы, связанные с бизнес-стратегиями, которые могут возникнуть на этапе реализации. Напротив, они могут извлечь уроки из проблем, которые могут помочь им найти решение в подобных сценариях, а также помочь получить знания в своей области.
Вопрос 34 — С какими проблемами может столкнуться бизнес-аналитик?
Ответ: От инициации до пост-реализации проекта бизнес-аналитик может столкнуться со следующими проблемами:
- Вопросы, связанные с сотрудниками
- Проблемы, связанные с технологией
- Доступ связан
- Вопросы, связанные с деловой политикой
- Ошибки бизнес-модели
Вопрос 35 — Объясните стратегию выявления требований (requirement elicitation strategy)?
Ответ. Выявление требований — это процесс сбора всех требований, связанных с системой, от конечных пользователей, клиентов и заинтересованных сторон. Согласно руководству BABOK, есть девять методов, которые могут использоваться как часть процесса выявления требований, а именно:
- мозговая атака
- Интервью
- наблюдение
- Фокус-группы анализа документов
- Требования Семинары
- Анализ интерфейса
- Опрос или вопросник
- макетирования
Вопрос 36 — Что такое Business Model Analysis (анализ бизнес-модели)?
Ответ: Анализ бизнес-модели — это метод анализа жизнеспособности и ценности бизнеса с точки зрения социальных, экономических и других аспектов. Анализ бизнес-модели обеспечивает основу для любых необходимых изменений бизнес-модели и инноваций для организации.
Вопрос 37 — Считаете ли вы, что роль бизнес-аналитика необходима для проекта?
Ответ: Да, потому что роль бизнес-аналитика чрезвычайно выгодна с момента начала реализации проекта. Вот 5 главных причин:
- Во время стартовой сессии проекта есть большие возможности, что некоторые технические вопросы поступают от заинтересованных сторон и клиентов. Поскольку мы не привлекаем техническую команду проекта на этом этапе, и немедленный ответ крайне важен, бизнес-аналитик может сыграть ключевую роль в ответе на эти запросы.
- Следующий этап после начального сеанса включает в себя анализ пробелов, анализ бизнес-процессов, документирование, анализ SOW, планирование проекта и, конечно же, подготовку документации спецификации требований.
- На этапе разработки и тестирования бизнес-аналитик может сыграть важную роль в решении любых связанных с требованиями запросов проектных групп. Кроме того, он может проверить, правильно ли выполнены и протестированы требования с учетом различных функциональных и нефункциональных сценариев.
- В модели с водопадом у заинтересованного лица может быть запрошено новое требование или изменение требований с учетом меняющихся потребностей бизнеса. В этом случае бизнес-аналитик — это лицо, которое может обработать этот запрос на изменение с надлежащей проверкой и анализом.
Вопрос 38 — В чем разница между Business analysis (бизнес-анализом) и Business Analytics (бизнес-аналитикой)?
Ответ . Ключевое различие между бизнес-анализом и бизнес-аналитикой заключается в том, что первое связано с большим количеством функций и процессов, а второе — с данными.
Бизнес-анализ — признает потребности бизнеса и определяет пути решения этих проблем. Инструменты и методы, такие как SWOT, PESTEL, CATWOE, MOST, FIVE WHY и т. Д., Используются для бизнес-анализа.
Бизнес-аналитика — обрабатывает данные и анализирует данные, чтобы получить представление о бизнесе. Наконец, он генерирует отчеты. В основном используются четыре типа бизнес-аналитики, а именно: описательная аналитика, решающая аналитика, предписывающая аналитика и прогнозная аналитика Для этой цели используются такие инструменты и технологии, как большие данные, BI.
Вопрос 39 — Что такое process design (разработка процесса)?
Ответ: Процесс проектирования — это способ, который помогает бизнесу анализировать проблемы в бизнесе и находить для них эффективное решение. Благодаря процессу проектирования создаются рабочие процессы, позволяющие получить наилучший результат в кратчайшие сроки.
Вопрос 40 — Назовите самые эффективные навыки бизнес-аналитика для решения любой проблемы?
Ответ:
- Лидерский навык
- Отличный навык общения
- Навык анализа проблем
- Технические знания
- Базовые знания
Вопросы для подготовки к интервью на должность Agile бизнес-аналитик
Вопрос 41 — Что такое Agile Manifesto?
Ответ: Agile Manifesto — это руководство по программному обеспечению о принципах Agile-разработки, которые обеспечивают итеративные решения.
Вопрос 42 — Назовите основные профессиональные качества Agile BA?
Ответ: Agile BA должен уметь:
- Ожидается, что BA будет сотрудничать с владельцем продукта и разработчиками, чтобы выявить требования. БА также должен работать над разработкой реалистичных функциональных требований.
- БА должен выполнять выявление требований итеративным способом
- БА должен сделать спецификации требований, модели данных и бизнес-правила как можно более легкими.
- БА должен быть технически исправным, чтобы он мог понять, как компоненты системы взаимодействуют друг с другом. Кроме того, он должен понимать гибкие термины, выступая в качестве посредника между заказчиком и командой проекта.
- БА должен сконцентрироваться на требованиях и критериях испытаний, достаточных для своевременной реализации гибкого проекта.
Вопрос 43 — Когда следует использовать Waterfall model (модель водопада) вместо Scrum?
Ответ: Если требование простое и конкретное, мы должны использовать модель водопада вместо Scrum.
Вопрос 44 — Что такое жизненный цикл бизнеса? На какие этапы можно разделить жизненный цикл бизнеса?
Ответ: Жизненный цикл бизнеса — это поэтапное развитие бизнеса с течением времени.
Один из способов повысить потенциал создания и поддержания успешного бизнеса — это понять 4 ключевых этапа Business Development, также часто называемых жизненным циклом бизнеса или жизненным циклом бизнеса.
Независимо от того, является ли кто-то новым владельцем бизнеса или опытным профессионалом в области развития бизнеса, этапы жизненного цикла бизнеса являются важными знаниями. Каждый этап жизненного цикла бизнеса содержит определенные задачи, которые часто требуют инновационных решений.
Определив, на каком этапе жизненного цикла бизнеса находится компания, гораздо проще разработать стратегию роста прибыльности и успеха бизнеса.
Четыре этапа жизненного цикла бизнеса включают:
- 1. Startup (Запуск)
- 2. Growth (Рост)
- 3. Maturity (Зрелость)
- 4. Decline (Упадок) or Renewal (Возрождение)
Вопрос 45 — Что вы знаете о Kanban (Канбан)?
Ответ: Kanban — это инструмент, который помогает гибкой команде визуально направлять и управлять работой по мере ее прохождения. Кроме того, он работает как система планирования в Agile-производстве точно в срок. Доска Канбан используется для описания текущего состояния разработки.
Вопрос 46 — Назовите несколько самых важных agile metrics (гибких метрик)
Ответ: Ниже приведены некоторые важные гибкие матрицы.
- Скорость — используется для отслеживания хода выполнения проекта.
- Матрица спринта — это помогает отследить работу, проделанную со спринтом.
- Приоритет работы
- Распределение категорий работ. Этот показатель помогает получить представление о приоритете распределения работ и категорий работ.
- Диаграмма накопленного потока — равномерный поток работы можно проверить с помощью этой диаграммы совокупного потока. Здесь ось X представляет время, а ось Y обозначает количество усилий.
- Осведомленность об удалении дефектов — это помогает производить качественную продукцию.
- Ценность доставленного бизнеса — используется для оценки эффективности работы команды. Он связывает 100 точек для измерения.
- Временной охват — оценивает время, затраченное на кодирование во время тестирования. Это отношение количества строк кода, вызываемых набором тестов, к числу относительных строк кода.
- Время устранения дефекта — это время обработки для обнаружения и исправления ошибок. Там процессы, участвующие в этом для:
- исправление ошибок
- устранение ошибки
- Планирование исправления
- Фиксация дефектов
- Передача отчета о резолюции
Вопрос 47 — Объясните термин «increment»?
Ответ. Инкремент относится к сумме всех элементов журнала невыполненных работ, выполненных в спринте. Новое значение приращения также включает приращение предыдущих спринтов.
Вопрос 48 — Какие типы гибких методологий вы знаете?
Ответ: Некоторые из известных гибких методологий:
- Scrum
- Бережливая разработка программного обеспечения и экстремальное программирование (XP)
- Функционально-ориентированная разработка (FDD)
- Методология кристаллов
- DSDM (метод динамической разработки программного обеспечения)
Вопрос 49 — Есть ли разница между инкрементальной (incremental) и итеративной (iterative) разработкой?
Ответ: да. В итеративной разработке разработка программного обеспечения происходит без каких-либо перерывов. Здесь циклы разработки программного обеспечения, которые обычно состоят из спринта и выпуска, повторяются до получения конечного продукта. Принимая во внимание, что в инкрементальной модели разработка программного обеспечения следует за дизайном продукта, внедрением и тестированием постепенно, пока продукт не будет закончен. Следовательно, это включает в себя разработку и обслуживание.
Вопрос 50 — Разница между extreme programming (экстремальным программированием) и Scrum?
Ответ: Scrum и экстремальное программирование следуют итерациям, которые известны как спринты. Однако спринты в Scrum-процессе длятся от двух недель до одного месяца, тогда как в команде экстремального программирования (XP) итерация длится одну или две недели. Экстремальное программирование более гибкое, чем Scrum, так как Scrum не допускает никаких изменений во время итераций.
Несмотря на то, что мы разделили вышеупомянутые вопросы интервью бизнес-аналитиков на основе уровней опыта, тем не менее, они могут быть смешанными и соответствовать любому уровню карьеры в зависимости от организации и их требований.