Elicitation and collaboration из BABOK®Guide для бизнес-аналитика

Что такое «выявление и сотрудничество»: 5 задач babok®guide

В отличие от других областей знаний, описанных в BABOK®Guide, Elicitation and Collaboration прежде всего требует от бизнес-аналитика так называемых soft skills с фокусом на общение с людьми. Поэтому из 6 категорий базовых компетенций, которые мы рассматривали здесь, для успешного выявления потребностей и требований стейкхолдеров, а также сотрудничества с ними, для бизнес-аналитика особенно важны следующие:

• поведенческие характеристики (Behavioral Characteristics);
• коммуникативные навыки (Communication Skills);
• навыки взаимодействия (Interaction Skills).

Примечательно, что по этой области знаний в сертификационном экзамене по BABOK на уровень CBAP предлагается меньше всего вопросов: 14, что составляет 12% от общего количества тестов. А вот в сертификациях CCBA и ECBA —  уже больше: 20% от общего количества тестов.

В область знаний «Выявление и сотрудничество» входят следующие задачи:

• подготовка к выявлению (Prepare for Elicitation);
• проведение выявления (Conduct Elicitation);
• подтверждение результатов выявления (Confirm Elicitation Results);
• сообщение информации бизнес-анализа (Communicate Business Analysis Information);
• управление сотрудничеством со стейкхолдерами (Manage Stakeholder Collaboration).

Что представляет собой каждая задача, рассмотрим далее.

Зачем нужен русскоязычный по техникам babok для международной сертификации iiba

Прежде чем приступить к самому тесту, напомню, что сам сертификационный экзамен IIBA является международным и проходит на английском языке, поэтому обычно симуляторы и другие тренажеры являются англоязычными. Примеры таких вопросов, которые могут встретиться в сертификационном экзамене IIBA® на уровни CBAP, CCBA и ECBA, мы разбирали здесь и здесь, в тесте по ситуационным задачам типа case study.

Однако, следующие вопросы на русском языке помогут кандидатам на сертификацию CBAP, CCBA и ECBA проверить степень усвоения материала по техникам, упомянутым в BABOK®Guide, чтобы выявить пробелы в знаниях и лучше подготовиться к настоящему экзамену IIBA.

Концепция определений из guide to product ownership analysis

Однако, критерии приемки и оценки нужны для уже готового решения, а при разработке ТЗ и спецификации требований бизнес-аналитику пригодится концепция определений, приведенная в Guide to Product Ownership Analysis. Выделяются следующие определения (Definitions of…)

• определение готовности (Definition of Ready) – согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога (требование, задача, баг) готовым для начала реализации, т.е. взять его в работу;
• определение доставки (Definition of Delivery) – согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога (требование, задача, баг) необходимым для включения в выпуск (релиз) продукта;
• определение выполненного (Definition of Done) – согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога (требование, задача, баг) выполненным, т.е. реализованным так, как предполагалось изначально.

Таким образом, Definition of Done (DoD) применяется для приемочных испытаний готового продукта, например, успешное прохождение 95% тестов. Definition of Ready можно рассматривать как чек-лист для верификации требования, т.е. что оно является атомарным, непротиворечивым, полным и пр.

Помимо концепции определений, в продуктовой разработке также выделяют критерии приемки (Acceptance Criteria, AC), смысл которых практически не отличается от техники BABOK с похожим названием, что мы рассмотрели выше. AC тесно связаны с DoD: при приемо-сдаточных испытаниях DoD является необходимым условием, а AC – достаточным.

Проще говоря, DoD позволяют проверить, что задача/требование реализованы, а AC – что реализованы именно так, как надо стейкхолдерам. Поэтому в отличие от Definition of Done и Definition of Ready, Acceptance Criteria для каждой задачи/требования будут уникальными.

Например, для нефункционального требования по производительности «Система должна обрабатывать не менее 90% пользовательских запросов за время не более 1 секунды при количестве подключений до 1000», критериями приемки здесь будут следующие:

• система обрабатывает большинство запросов не дольше 1 секунды;
• доля запросов, которые обрабатываются дольше 1 секунды, не превышает 10%;
• система поддерживает до 1000 одновременных подключений.

Определения выполненного будут такие:

• пользователи имеют возможность посылать запросы в систему;
• система корректно обрабатывает запросы пользователей, т.е. выполняет необходимые вычисления и преобразования данных;
• система успешно прошла более 95% тестов.

Освоить эту и другие техники Guide to Product Ownership Analysis, а также попутно познакомиться с BABOK®Guide и Agile-расширением к нему, вы сможете на нашем новом курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика».

А тем, кто хочет во всех деталях освоить содержание руководства к профессиональному своду знаний по бизнес-анализу, подготовиться к сдаче сертификационного экзамена IIBA по BABOK®Guide на уровни CBAP, CCAB, ECBA и получить необходимые часы профессионального развития, мы предлагаем авторизованные курсы Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Критерии приемки и оценки для анализа нефункциональных требований: техники babok®guide

Анализ нефункциональных требований – это техника не только классического бизнес-анализа из BABOK®Guide. Новый профильный справочник IIBA®, Guide to Product Ownership Analysis, тоже упоминает эту технику как способ исследования требований к продукту, определяющий критерии, по которым можно судить о работе продукта, а не о конкретном (функциональном) поведении. В продуктовой парадигме нефункциональные требования фиксируются в понятиях определений или критериях приемки.

BABOK отмечает, что критерии приемки и оценки (Acceptance and Evaluation Criteria) определяют измеримые и проверяемые показатели для объективной оценки и последовательного сравнения решений, а также их альтернативных дизайнов.

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

Иначе говоря, они описывают минимальный набор требований, которые должны быть выполнены, чтобы реализация конкретного решения имела смысл и помогают определить, может ли решение или его компонент удовлетворять требованию. Обычно критерии приемки применяются к одному возможному решению, а результаты такой проверки дискретны: «принято» или «не принято».

В случае выбора между несколькими решениями используются критерии оценки – метрики для оценки набора требований, которые позволяют ранжировать альтернативы по их ценности для стейкхолдеров. Каждый критерий оценки выражается единицах измерения определенного атрибута решения: стоимость, производительность, удобство использования и прочие нефункциональные требования, которые отражает потребности стейкхолдеров.

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

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

Подготовка к выявлению

В этой задаче бизнес-аналитик разрабатывает план действий по выявлению, который включает следующие аспекты:

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

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

Подтверждение результатов выявления

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

Проведение выявления

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

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

Сообщение информации бизнес-анализа

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

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

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

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

Наконец, в рамках задачи сообщения или предоставления информации бизнес-анализа, решается вопрос о каналах и способах передачи данных: групповая или индивидуальная коммуникация, письменно или с устными комментариями на интервью, ревью или семинаре.