Мастерская бизнес-анализа

Ит- бизнес аналитик – роль, популярность которой растет часть 3

22.06.2014 at 16:00 4 комментария

Эта статья была подготовлена летом 2013 года по инициативе коллектива, создающего российский чаптер IIBA (Международного института Бизнес-Анализа) и задумавшего электронный журнал этого чаптера.

Начало — Когда компьютеры были большие
Часть 2- Пришли большие перемены

Годы нынешние — ИТ- БИЗНЕС АНАЛИТИК – посредник, мост, шпион, интерфейс, переводчик, адвокат, врач, шаман, архитектор, инженер – кто еще?

«Я понял — это намек, я все ловлю на лету,

Но непонятно, что конкретно ты имела в виду?»

Несчастный случай, «Что ты имела в виду»

Уже лет 10-15 никто не оспаривает, что в ИТ проектах необходим бизнес-анализ, и выполнять его могут разные специалисты, но в том числе и специалист, имя которому «ИТ бизнес-аналитик».

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

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

Главные вопросы, по которым до сих пор нет единства:

1. Существует ли при проектировании ИС две разных роли, или два разных по уровню подготовки специалиста: ИТ бизнес-аналитик и системный аналитик. Если да, то какая между ними разница, где пролегает граница?
2. Бизнес-аналитик при проектировании информационной системы – на стороне разработчика или на стороне клиента?
3. Если речь идет о бизнес-аналитике при проектировании информационной системы – сфера его интересов и ответственности только собственно автоматизация, или все же соучастие в совершенствовании бизнес-процессов?

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

Из того, что можно добавить к определениям, вынесенным в подзаголовок:

«Одна из целей ИТ Бизнес-Аналитика — Уравновешивание потребностей бизнеса с возможностями ИТ, одна из ролей БA в проекте — быть глазами и ушами бизнеса в процессе разработки, искать отклонения, во время тестирования БA должен понять, как пользователи используют систему. Действительно ли они видят преимущества, предусмотренные при заказе системы», «Внедрение бизнес-анализа, ит бизнес-аналитиков и uml»  Эдгар Хачатрян

«Бизнес-аналитики — это невоспетые герои бизнеса. Они демонстрируют идеальное сочетание деловой хватки и технического опыта». «Скрываете данные от ваших бизнес-аналитиков?» Rob Karel

Но есть еще один вопрос, по которому у большинства разработчиков, в том числе и бизнес-аналитиков мнение общее, но с которым очень трудно согласиться. Это о взаимоотношениях с заказчиками и пользователями, о том «клиент прав или не прав». Вот только из одного высказывания о роли «великого бизнес-аналитика»: он должен «выслушать заказчика…Понять иногда «птичий» язык заказчика и сформулировать его требования понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований. В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика».А. Назаров «Становление аналитика». У автора мнение по этому вопросу другое, прямо противоположное. Клиенты почти всегда знают чего они хотят. Это мы их не понимаем. Одна из основных причин – разные языки. Клиент говорит, и говорит, как правило, превосходно, на своем профессиональном языке. А «птичий» язык – это у нас с вами, да еще щедро пересыпанный англоязычными терминами, с совершенно не очевидными для не-ИТ специалистов значениями на русском языке. Да, то, что клиент высказывает вслух, часто не определяет впрямую его истинные проблемы и потребности. Но на то ведь и бизнес-аналитик, чтобы в этом разобраться. Пора уже расстаться с любимой метафорой, запущенной еще в 2005г Б. Шлаиным – «Свой человек за «линией фронта». Для популярности статьи метафора была удачной, но она не совсем правильна с точки зрения отношений между участниками процессов создания ИТ систем. Соглашаясь с таким подходом, мы признаем, что являемся противниками с Заказчиком, стоим по разные стороны баррикад. Но тогда наши усилия обречены на провал по определению. Гораздо лучше звучат слова Шлаина в другой части статьи: «Бизнес-аналитик – это по сути – «информационный» представитель клиента в проекте по всем вопросам, касающимся требований и предметной области». Только в условиях создания партнерских отношений между разработчиками и заказчиками, будущими пользователями, грамотного и адаптированного к ситуации разделения между ними работы по проектированию, и возможно создание работающего продукта, приносящего пользу заказчику и деньги и моральное удовлетворение разработчику. Как при разработке внутри одной компании, так и при налаживании «интерфейса» между различными организациями, одна из которых – ИТ-компания, функциональная роль бизнес-аналитика – интерфейс между бизнесом и ИТ – остается практически постоянной, вне зависимости от «юрисдикции». Задача бизнес-аналитика помочь пользователям изъяснить и описать свои проблемы, потребности, преобразуя их в требования так, чтобы «сблизить языки», мягко и аккуратно преодолевая языковые проблемы. В этой связи, не очень удачен перевод на русский язык названия этапа «Requirements elicitation» как «выявление требований». Он не точно отражает то, что происходит на самом деле. Нету, как правило, готовых требований, которые надо у пользователя «выявить», выспросить, обнаружить, извлечь. Их нужно сформировать – вместе с пользователем, на базе информации пользователя. Здесь тот случай, когда требуется не точный словарный перевод, а более подходящий для русской терминологии, да и практики, термин. Представляется более удачным говорить о сборе информации для формулировки требований. Причем, с учетом того, что «IT-проект — это не только софт, а еще и его внедрение, использование, поддержка, прекращение его использования –все части жизненного цикла, мало сделать ПО. Надо еще сделать его так, чтобы оно вписывалось в бизнес заказчика, чтобы использование программы приносило ожидаемую выгоду. Хотя программный продукт – это некий набор функциональности, но бизнес не работает через «фичи». Бизнес, как правило, лучше описывается как набор процессов» «Аналитик — врач, инженер, шаман». П. Газарян. Поэтому и требуется на этапе бизнес-анализа заниматься описанием бизнес-процессов, формулируя   бизнес-требования. Возможно, именно здесь лежит граница ролей бизнес-аналитика и системного аналитика. Бизнес-аналитик определяет на всех доступных ему языках (сначала пользовательском, потом более формальном) – Что нужно пользователю. Далее определяется (не так уж и важно кем) — Что и как будет делать программный продукт, ИТ система. Это разные задачи, и разные требования.

В результате представляется:

1)      Главное в работе бизнес-аналитика – это разработка (чего – читаем у разных авторов, в ВАВОК и т.д.)

2)      Средство для этой разработки – взаимодействие (с пользователями, клиентами, заказчиками – с одной стороны, с проектной командой с другой стороны). И лишь дополнительными средствами служат самые разные инструменты – технические, коммуникативные и другие.

3)      Роль – представитель клиента в проекте. Если на всем протяжении проекта в команде есть специалист, который смотрит на все происходящее с точки зрения клиента, отношения с самим клиентом будут складываться намного спокойнее. В этом, собственно, и есть роль бизнес-аналитика в управлении рисками. Бизнес-аналитик в команде разработчика, имитирующий взаимодействие с клиентом, фактически защищает команду от конфликтных ситуаций и существенно снижает риски. Если бизнес-аналитик работает у Заказчика, то риски команды сильно возрастают. Хотя, конечно, очень многое зависит от того, как складываются личные отношения и кто именно тот бизнес-аналитик. Для того, чтобы эту роль выполнять, бизнес-аналитик должен понять потребности бизнеса на уровне специалиста этого бизнеса очень высокой позиции. Бизнес-аналитик должен завоевать доверие клиента, установить с ним такие отношения, чтобы и тот воспринимал его как своего представителя – человека, защищающего его интересы (а не засланца-разведчика).

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

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

Окончание статьи Будущее уже на пороге – готовы ли бизнес-аналитики

Entry filed under: Бизнес/аналитик. Tags: ИТ специалист, бизнес-анализ, бизнес-аналитик.