Как и кто делает BI-системы

«Begin at the beginning,», the King said, very gravely, «and go on till you come to the end: then stop.»
Lewis Carroll
На сегодняшний день, ИТ-индустрия, в силу многообразия создаваемых решений, динамичности потребностей конечных пользователей и высокой интеллектуальности и географической мобильности человеческих ресурсов, задействованных в процессе производства является одним из главных драйверов развития методологии управления проектами. В таких условиях вырастает все многообразие как подходов и идеологий организации, планирования, управления и оценки для выполняемых проектными командами задач, так и состава самих команд.

Успех проектов по созданию информационно-аналитических систем в нашей стране так же как и другие проекты в сфере ИТ чрезвычайно зависим от правильной организации работ и состава задействованных специалистов. Однако, информационная модель бизнеса заложенная в Хранилище Данных (лежащее в основе ИАС), представляет собой достаточно статическую стуктуру, поскольку сам бизнес не в состоянии постоянно изменятся: торговая сеть за полгода не превратится в финансовое учреждение, а промышленное производство не сможет в обозримое время превратиться в поставщика телекоммуникационных систем.

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

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

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

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

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

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

В заключение хотелось бы сказать следующее: всегда следует помнить о том, что не существует универсальной «правильной» методологии ведения проектов и «идеального» состава команды. Для каждого проекта отдельно следует рассматривать все аспекты и принимать решение о том, кто и как будет делать систему. BI-системы в данном случае не исключение, и я буквально на днях получил этому подтверждение — на новом проекте, который охватывает только малую часть всего бизнеса заказчика требования оказались настолько же зыбкими, насколько срочно нужно давать первые результаты, так что agile нас похоже не минует.

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


2 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

У больших команд все же есть ряд недостатков, например, более высокие трудозатраты за счет сложной системы управления. Если же объемы работ значительные — то за каждой ролью в команде будет отдельный человек. Хотя от таких структур врядли можно как-то отказаться в крупных проектах.

Подписаться на комментарии