Чем на самом деле заняты бизнес-аналитики: выводы опроса 2020 года

Все цифры ниже взяты из этого опроса (Д. Гобов (D. Gobov) и И. Гученко (I. Huchenko), DataArt, 2020). Они описывают рынок одной страны с большой долей ИТ в один момент времени и основаны на ответах самих респондентов. Считайте их ориентиром, а не универсальной истиной.

Главные идеи#

Кто отвечал#

49% работали в аутсорсинговых компаниях и 18% — в продуктовых ИТ-компаниях.
Больше половины работали в компаниях, где 1 500 сотрудников и больше.
Примерно у трети опыт в анализе был меньше трёх лет; примерно у 16% — больше десяти лет.
Крупнейшая отрасль — финансы и банки: около 25%.
58,6% работали по гибким подходам; только 14,8% — по предиктивным (каскадная модель или RUP).
Сертификат CBAP был только у 7%.

Выявление#

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

Спецификация и документирование#

Самые популярные техники спецификации — пользовательские истории (79%) и варианты использования (65%); не использовали ни то, ни другое только 13%. Прототипирование применяли 54%.
Чаще всего документировали функциональные требования, бизнес-требования и глоссарий.
Реже всего документировали анализ затрат и выгод (8%) и метрики успеха продукта (15%).
Из нефункциональных требований чаще всего фиксировали удобство использования, затем безопасность и производительность.
Половина респондентов пользовалась шаблонами своей компании.

Верификация#

Два самых распространённых способа верификации — ревью с командой разработки (79%) и самопроверка (77%). Только 18% ответили, что проблем с качеством требований у них нет. Больше всего трудностей вызывали полнота и атомарность (одно требование в одной формулировке).

Управление требованиями#

Самые распространённые техники приоритизации — анализ зависимостей (49%), MoSCoW (45%) и соотношение трудозатрат и ценности (45%).
Совсем не вели трассировку только 11%, но связи между бизнес-требованиями и требованиями к решению поддерживали лишь 37%.
78% поддерживали документацию в актуальном состоянии.

Как аналитики оценивали анализ на своих проектах#

Только 15% были недовольны состоянием бизнес-анализа на своём проекте. Причины недовольства: слишком мало времени на анализ (23%), в компании нет устоявшегося подхода (20%), проблемы во взаимодействии с ключевыми заинтересованными сторонами (17%). Причины удовлетворённости: устоявшийся процесс анализа (56%) и качественные требования (35%).

Проблемы, причины и последствия#

Главные проблемы: меняющиеся цели, процессы или требования (43%) и неполные или скрытые требования (41%).
Основные причины: нет коммуникации с ключевыми заинтересованными сторонами (70%), у заказчика нет ясного видения продукта (62%), у заинтересованных сторон заказчика нет согласованной позиции (43%).
Последствия: превышение трудозатрат или бюджета (59%), разрастание границ (scope creep) (58%) и неверные оценки (54%).

Компетенции#

Если сравнивать с базовыми компетенциями из Руководства BABOK®, легче всего, по мнению респондентов, развивать аналитическое мышление (55% — легко, 11% — трудно), поведенческие характеристики (65% / 14%) и коммуникативные навыки (63% / 12%). Труднее всего — навыки взаимодействия (40% / 28%) и знание бизнеса (42% / 20%). Главные причины — нехватка практики (58%) и отсутствие наставничества (53%).

Как применять#

Эти выводы — интерпретация результатов, а не заключения авторов опроса.

Сначала обеспечьте доступ к заинтересованным сторонам. Чаще всего причиной проблем называли отсутствие коммуникации с ключевыми заинтересованными сторонами. До начала детального выявления внесите в план конкретных людей, их доступность и пути эскалации.
Запишите видение. Неясное видение у заказчика — вторая по частоте причина. Короткий документ концепции и границ, согласованный на раннем этапе, даёт точку отсчёта, с которой можно сверять меняющиеся запросы.
Проверяйте полноту и атомарность явно. Добавьте оба критерия в чек-лист ревью. Разбивайте составные формулировки; ищите пропущенные случаи с помощью приёмов со страницы Как найти пропущенные требования.
Трассируйте бизнес-требования к требованиям к решению. Большинство команд что-то трассируют, но немногие связывают бизнес-цели с требованиями к решению. Именно эта связь позволяет безопасно сокращать границы, когда цели меняются.
Документируйте метрики успеха и ценность. Анализ затрат и выгод и метрики успеха документировали реже всего. Даже несколько строк о метриках и KPI делают возможной последующую оценку решения.
Не ограничивайтесь ревью в команде. Преобладают ревью с разработчиками и самопроверка. Короткое ревью с заинтересованными сторонами со стороны бизнеса выявляет ошибки другого рода.
Ищите практику и наставника для навыков взаимодействия. Респонденты считали эти навыки самыми трудными и винили в этом нехватку практики и наставников. Вызовитесь провести встречу и попросите старшего коллегу понаблюдать и дать обратную связь.

Пример#

Аналитик «Мастерской», вымышленной сети из 12 веломастерских, на старте проекта использует результаты опроса как чек-лист рисков: доступен ли владелец каждую неделю? Записано ли видение? Трассируется ли каждая пользовательская история к бизнес-требованию? Согласованы ли показатели успеха (меньше звонков о статусе ремонта, меньше задержек с запчастями)? На два вопроса ответ «нет», и оба попадают в реестр рисков проекта.

Источники и что почитать#

D. Gobov, I. Huchenko. State of Business Analysis in Ukraine 2020. DataArt, 2020.