Управление подобным проектом, а также архитектурный и технический надзор – основные вызовы, с которыми сталкивается проектная команда в ходе создания СЦ. В свою очередь, главная задача менеджера проекта и архитектора – это обеспечение комплексной интеграции методологических, программных, технологических, инженерных и строительных решений, применяемых на каждом этапе создания комплекса, умелое привлечение и оркестровка профильных компетенций членов команды. Причем без потери «леса» за деревьями.
Теперь перейдем к сложностям, с которыми мы сталкивались в подобных проектах, и вариантам их решения. Один из наиболее сложных этапов при внедрении ИАС – этап сбора требований. Реализовав не один проект в этой сфере, мы пришли к выводу, что, к сожалению, накопленные компетенции наших аналитиков сложно переиспользуются в каждом новом СЦ. К примеру, мы создавали 2, на первый взгляд, похожих ситуационных центра, причем в одной компании. Один из них автоматизировал управление кризисными ситуациями и оперативное реагирование, другой был предназначен для управления комплексной безопасностью. И эти СЦ в конечном итоге отличались настолько сильно, что порой опыт предыдущего проекта не помогал, а наоборот, играл против нас. Дело в том, что любой СЦ – это чаще всего верхушка определенной сферы деятельности заказчика, и от проекта к проекту деятельность, которую мы представляем посредством ситуационного центра, существенно отличается. Это как если бы вы строили заборы, но каждый раз это нужно было бы делать на разных планетах. Банковский аналитик без труда сориентируется в любом новом банке, а аналитик по СЦ каждый раз погружается в новую тематику.
Разумеется, нельзя сказать, что нет ничего общего между модулями ИАС, функционирующими в разных СЦ. Модули анализа, планирования, прогнозирования, обеспечения взаимодействия в том или ином виде присутствуют везде, однако в каждом случае к ним предъявляются разные требования, да и смысл, вкладываемый заказчиком в тот или иной модуль, зачастую отличается. К тому же деятельность в рамках самого СЦ – это почти всегда не детерминированный процесс, а кейс-менеджмент и поддержка принятия решений, которые крайне сложно поддаются моделированию и описанию (не существует блок-схем, способных с достаточной точностью описать процесс мозгового штурма). Поэтому наши аналитики, приступая к работе над новым ситуационным центром, готовы к тому, чтобы «оставить за дверью» большую часть накопленного на предыдущих проектах багажа знаний и погрузиться в новую предметную область.
При этом, как уже было отмечено выше, СЦ включает не только софт – это и комплекс помещений, и специализированные мультимедийные системы, и видеоконференцсвязь, и телефония и т.д. Причем у каждого заказчика свои требования к подобным технологическим системам: кто-то смотрит на СЦ в первую очередь как на ИАС, кто-то привык идти от оборудования, которое в нем используется, а для кого-то ситуационный центр – это люди и регламенты. Например, органы государственной власти при построении СЦ чаще определяют его как помещение, оснащенное оборудованием, с которым работают люди, использующие различные программы. И ИАС в данном случае является лишь одной из составляющих ситуационного центра. Но есть и другие примеры, так, в нашем проекте для крупной нефтяной компании информационная система (а именно подсистема поддержки принятия решений) являлась с точки зрения заказчика главным компонентом СЦ.
Так или иначе наши аналитики неизбежно расширяют кругозор, одновременно углубляясь в технические, методологические и программные аспекты. Мы пришли к выводу, что лучшим рецептом для грамотной реализации этой стадии проекта является как можно более раннее погружение аналитиков в деятельность компании, формирование на старте команды, которая на 100% погружена в проект и плотно взаимодействует с представителями заказчика.
Стоит подчеркнуть, что тема СЦ – достаточно новая для нашей страны, по ней сформировано не так много best practices. Порой это приводит к тому, что заказчик не до конца понимает, что именно должна делать ИАС, его представление об этом может быть довольно размытым. Например, один из наших заказчиков на старте проекта хотел, чтобы система «думала», имея ввиду поддержку принятия решений, но, к сожалению, идеи не всегда были сформулированы достаточно четко для того, чтобы наши программисты смогли воплотить их в жизнь. В подобных ситуациях мы, опираясь на опыт и экспертизу, предлагаем заказчику уже наработанные практические кейсы и конкретику, даже рискуя «не попасть». Практика показала, что, несмотря на то, что не все предложенные кейсы принимаются, сам процесс наталкивает заказчика на рассуждения в практической плоскости и генерацию более конкретных требований, которые мы впоследствии формализуем и реализуем.
Иногда на подобных проектах возникает дрейф требований. Ведь в их ходе проходит большое количество интересных и в то же время непредсказуемых с точки зрения планирования развития проекта мозговых штурмов. И это может повлечь за собой сложности, особенно когда на завершающих стадиях реализации прикладного ПО возникают требования, не реализуемые на архитектурном уровне. Обычно мы снижаем подобные риски двумя способами. Первый – это прототипирование. Еще до того как разработчики приступают к написанию первой строчки кода, мы показываем специалистам заказчика наглядные описания сценариев работы, максимально приближенные к реальности макеты интерфейсов системы (до полей и кнопок), экранные формы отчетов (нередко в виде прототипа BI-системы с тестовыми данными). Вместе с итеративным процессом разработки это позволяет на ранних стадиях выявлять неучтенные (либо изменившиеся) требования.
Второй способ: мы используем в качестве ядра построения ИАС разработанную нами платформу-конструктор справочников. Эта платформа позволяет достаточно гибко модифицировать объекты и логику работы системы зачастую без необходимости привлечения разработчиков (либо с минимальным привлечением). Например, на одном проекте наш заказчик захотел серьезно поменять логику учета ЧС/происшествий. Требовалось, чтобы происшествие могло относиться сразу к нескольким типам одновременно (Пожар + ДТП), при этом к нему применялись бы бизнес-правила обоих типов. Другой случа й: потребовалось, чтобы параметры происшествия (в карточке происшествия их было более 200) могли вноситься не только сотрудниками самого СЦ, но и смежными подразделениями, причем независимо, с сохранением истории и возможностью динамически менять как состав полей, так и ответственных за их заполнение. В обоих случаях нам удалось практически без доработок реализовать новые пожелания, несмотря на то, что они возникли уже по ходу проекта. Так что в подавляющем большинстве случаев мы готовы изменить систему даже под те требования, реализация которых в обычных условиях привела бы к принципиальному изменению программной архитектуры модулей.