Бизнес-аналитик - свой человек за линией фронта

Слагаемые успеха

Я участвовал во многих собеседованиях при найме на работу бизнес-аналитиков, и ни разу не видел в комнате для переговоров всех «семи нянек» одновременно. Наверное, потому что требования к соискателям были сформулированы заранее, попробуем их перечислить:

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

Моделирование является очень важной формой работы бизнес-аналитика. Одна форма модели используется для общения с клиентами, другая – для последующего проектирования и разработки. Задача бизнес-аналитика – обеспечить соответствие между ними, творчески применяя различные методы и нотации. Слишком часто модели и диаграммы становятся игрушкой в руках аналитиков, и оказываются бесполезны для практической работы – клиент их не понимает, при изменении требований они не сопровождаются, а разработчики предпочитают общаться на языке кода. Среди зарекомендовавших себя нотаций – IDEF, UML, eEPC, DFD и т.п. – нет лучших или худших. Знание различных методологий, умение творчески применять их, а при необходимости еще и быстро объяснить коллегам – это как раз то, что отличает «профи».

Умения работать с современными программными продуктами – ARIS, Rational Suite, All Fusion – это не то же самое, что знание нотаций. Практически каждый продукт имеет свою специфику даже при использовании стандартных видов моделей. Отдельный вопрос – это коллективная работа надо проектом с использованием автоматизированного средства разработки. Опыт показывает, что аналитики, которые раньше работали в одиночку, не сразу включаются в принятую технологию коллективной работы; по меньшей мере, такая технология должна быть разработана и документирована. Средства моделирования и анализа – не единственное программное обеспечение, с которым работают аналитики. Современные аналитические приложения и средства администрирования базами данных получают все более дружественные интерфейсы, так что умение «читать» структуры баз данных, кубов OLAP и xml-документы следует уже отнести к правилам хорошего тона.

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

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

Архитектор и бизнес-аналитик – это разные роли, и об этом уже шла речь выше. Но это не означает, что вопросы архитектуры должны быть terra incognita для бизнес-аналитика. Он должен представлять себе архитектуру стандартного решения, представляемого компанией, и принципы современных архитектур информационных систем. Слова «клиент-сервер», «распределенная архитектура» и «асинхронный обмен сообщениями» должны быть для него понятны – более того, он должен быть в состоянии изложить неспециалисту основные их черты, достоинства и ограничения. Достаточно часто пользователь затрудняется в формулировке требований и пытается помочь аналитику в проектировании архитектуры – очень важно при этом «вернуть его на землю» и при этом продемонстрировать свою компетентность в вопросах архитектуры.