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

Бизнес-аналитик на проекте

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

Основная роль бизнес-аналитика – это разработка непротиворечивой и достаточно полной модели требований реального бизнеса. Это задача не столько описательная и созерцательная («просто напишите, как у нас все происходит и автоматизируйте»), а творческая. Уже расхожим стало выражение об «автоматизации беспорядка», которая только ухудшает общую ситуацию. Но и «прямолинейная автоматизация» очень часто исключает из процесса те самые «отдушины» и «обходные пути», которые и обеспечивают известную российскую «нестрогость законов» и позволяют бизнес-системе в целом работать.

Соавторами бизнес-аналитика при разработке модели требований являются ключевые пользователи (или потенциальные пользователи). Таким образом, на этапе анализа задача бизнес-аналитика – собрать требования, построить непротиворечивую полную модель и «продать», представить ее клиенту.

Но достаточно часто бизнес-аналитик приступает к работе еще на этапе переговоров. В этом случае его задача – понять, насколько решение соответствует потребностям клиента, оценить «масштабы бедствия» и определить возможный объем доработок.

Однако переговорами и согласованием требований работа бизнес-аналитика в проекте, конечно, не ограничивается – хотя достаточно часто именно после согласования технического задания аналитика перебрасывают на другой проект. Известно, что требования имеют обыкновение изменяться и «плохо ложиться» на архитектуру – именно поэтому бизнес-аналитик должен сопровождать проект и на этапе проектирования, и на этапе разработки. Конечно, такая работа может уже не требовать 100% загрузки (это зависит от масштабов проекта), но она, в совокупности с регулярным представлением клиенту результатов, позволяет процессу разработки не уходить в сторону от требований бизнеса. Задача клиента – требовать, чтобы бизнес-аналитик продолжал сопровождать проект, и со своей стороны работать над проектными документами: техническим заданием, спецификацией требований, запросами на изменения. Только полнота и актуальность этих документов позволят при необходимости вовлечь в проект новых или дополнительных сотрудников.

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

То, что написано выше – не связано с какой-либо конкретной методологией RUP, MSF, ASAP и т.п., а есть некоторое обобщение их и практических подходов нескольких российских фирм.

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

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

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

Совмещение роли разработчика, или руководителя разработки, и бизнес-аналитика крайне нежелательно: это люди имеют противоположные взгляды на проект. Есть большая опасность, что результатом анализа будет неоформленная, противоречивая модель, которая потом будет непосредственно реализована в программный код. Подобный подход в России почему-то принято называть экстремальным программированием, при этом часто забываются основные принципы eXtremal Programming: предварительная разработка тестовых примеров совместно с клиентом, обязательная парная работа программистов над задачами и разработка решений сугубо «под конкретного заказчика».