С тех пор бизнес-аналитики (или ВА) складывают воедино фрагменты пазла из бизнес-требований заказчика, сроков выполнения проекта, технических возможностей и ограничений, бюджета и т.д. При этом периодически отвечают на самые популярные вопросы: нужно ли уметь кодить для старта в профессии и обязательно ли иметь опыт в другой отрасли для понимания специфики того или иного бизнеса.

Однако, мы пропустим эти вопросы, а вместо этого объясним и проиллюстрируем примерами из обычной жизни 10 терминов бизнес-анализа, которые должен знать каждый начинающий. Разобраться в теме помогает Мария Басюк, Марія Басюк, Senior Business Analyst в EPAM.

1. Requirement (или Требование) — обобщающее понятие для набора изменений, имеющих ценность для заказчика проекта, реализация которых принесет ему определенную выгоду. Требования бывают разных типов: от бизнес-требований, например, увеличение прибыли или количества клиентов и пр., до функциональных — добавление новых возможностей на сайт, изменение функционала и т.д.
2. Stakeholder (или Заинтересованное лицо) — любой человек, влияющий на проект: заказчик, который предоставляет требования, разработчик, который пишет код, спонсор, который выделяет бюджет и еще много других участников процесса.
3. Interview (или Интервью) — одни из наиболее распространенных форматов общения бизнес-аналитика с заказчиком для выяснения требований. Бизнес-аналитик должен тщательно готовиться к интервью, чтобы как можно больше узнать о специфике запроса и проблемах, которые необходимо решить. Интервью — это эффективный инструмент общения один на один, но в зависимости от опыта интервьюера может проводиться и для группы лиц.
4. User story (или Пользовательская история) — задача, которую создает бизнес-аналитик для команды разработчиков. Такая задача должна соответствовать определенным критериям: INVEST ­— independent, negotiable, valuable, estimable, small, testable.
5. Verification и Validation (Верификация и Валидация) — очень похожие, на первый взгляд, понятия, которые, на самом деле, в корне отличаются. Верификация — это проверка того, может ли конкретное требование быть реализовано имеющимися инструментами. Тогда как валидация помогает выяснить соответствует ли реализация требований бизнес-интересам заказчика и поможет ли она достичь определенных бизнес-целей. Запутано? Объясним на примере мебели. Допустим, ми запланировали собрать книжную полку. Во время верификации нам нужно убедиться, что у нас достаточно досок, гвоздей и свободного времени на эту задачу. А валидация поможет убедиться действительно ли нам нужна именно полка. Возможно, учитывая количество книг, нам нужно собрать целый шкаф.
6. Backlog (или Беклог) — список, набор будущих (Product Backlog) или текущих задач (Sprint Backlog), над которыми работает команда. Они могут быть разных типов — пользовательские истории, дефекты, и т.д. Бизнес-аналитики постоянно работают с беклогом, ведь именно здесь требования фиксируются в том виде, в котором команда разработки берет их в работу.
7. Domain Knowledge (или Знание предметной области) — это понимание процессов, деталей той отрасли, к которой относиться ваш проект. Конечно, если вы хорошо ориентируетесь, например, в индустрии красоты, медицине или авиации, вам будет легче сразу включиться в проект из этой сферы и работать продуктивно. Но это вовсе не означает, что вы не сможете взяться за проект без опыта в той или иной отрасли. Вам просто нужно будет очень много учиться.
8. Change request (или Запрос на изменение требований) — довольно распространенная ситуация, когда команда уже взяла требование в работу, но со стороны заказчика пришел запрос на его изменение. Важно помнить, что еще до начала работы над проектом должна быть процедура запроса на измененя, согласованная с заказчиком. В соответствии с этой процедурой любые изменения, внесенные в требования на этапе разработки, должны пройти оценку как бизнес-аналитиком, так и командой. Это позволяет определить уровень сложности реализации изменений.
9. Prototype (или Прототип) — это визуализация решения, которая дает возможность еще до начала этапа разработки получить обратную связь от фокус-группы. Прототипы разрабатывают дизайнеры в тесном сотрудничестве с бизнес-аналитиками.
10. Diagram (или Диаграмма) — одна из форм фиксации требований, так как некоторые сложные процессы намного легче изобразить визуально, чем описать словами. Тип диаграммы зависит от того, что нужно отобразить: структуру, процесс, класс, последовательность и пр. Наиболее распространенный язык для моделирования диаграмм — UML, или Unified Modeling Language.

Узнайте больше на обучающих программах по направлению Business Analysis и регистрируйтесь на открытые наборы!