Александр Бакланов, ООО ИК СИБИНТЕК, Москва, E-mail: BaklanovAV@sibintek.ru
Работа в области геоинформационных технологий напоминает бесконечную гонку. Программное обеспечение становится все более ресурсопотребляющим, требуя от «железа» постоянного роста мощности, а безудержный аппетит конечных пользователей заставляет разработчиков создавать новые программные продукты. «Цена вопроса» в этой гонке напрямую связана как с характером решаемых задач, так и со стоимостью программного обеспечения и компьютеров. Если еще совсем недавно крупные предприятия—разработчики ГИС-приложений не имели существенных преимуществ перед малобюджетными организациями, то с появлением SDE-технологий, геобаз и в ожидании выхода на рынок ArcGIS девятой версии становится очевидным то, что малые предприятия становятся заложниками своей безденежности. Единственное, что может помочь малым предприятиям выжить в конкурентной борьбе, — это рациональное использование имеющихся ресурсов, разработка дешевых решений, основанных на правильном управлении ГИС-проектами.
Начнем с того, что под ГИС-проектом мы понимаем не справочные системы с коротким жизненным циклом, затраты на создание которых значительно превышают выгоду от их применения, а интерактивные информационно-справочные приложения, основанные на постоянно обновляющихся промышленных базах данных.
ГИС-проекты подчиняются общим закономерностям любого другого проекта. Поэтому бессмысленно пересказывать содержание известных книг об управлении проектами. Стоит остановиться лишь на специфических аспектах ГИС-проекта. Он живет в трех измерениях: затраты; сроки исполнения; реализация.
Идеальная структура измерений выглядит как круг, разделенный на три равных сектора (рис. 1). За этим равенством скрывается физический смысл, выражающийся в сбалансированности объема затрачиваемых ресурсов, реализуемых задач проекта и времени на их исполнение.
Рис. 1. Идеальная структура.
Уже на ранних этапах проекта нужно учитывать, что у Заказчика и Исполнителя взгляды разнятся даже на эту простую схему. Заказчик старается увеличить сектор реализации (т.е. увеличить объем решаемых Исполнителем задач), а Исполнитель стремится уменьшить размер этого сектора (рис. 2). Как следует из жизненного опыта, обычно побеждает взгляд Заказчика, ибо даже западные авторитеты в области управления проектами признают, что при определении параметров проекта Исполнитель является лишь просителем.
Рис. 2. Две точки зрения.
Чем хуже организовано управление проектом, чем слабее взаимодействие Исполнителя и Заказчика, тем более вероятна структура проекта с непомерно раздутым сектором реализации и затянутыми сроками (рис. 3). А поскольку стоимость проекта (затраты) остается, как правило, для Заказчика неизменной, то для Исполнителя налицо — упущенная выгода.
Рис. 3. Реальная структура.
Исходя из этого видно, что для Исполнителя реальным пространством для маневра может быть лишь сектор Реализации. Рассмотрим некоторые из возможностей Исполнителя в этом секторе.
Классическим этапом подготовки проекта является оценка рисков. И Заказчика, и Исполнителя на этом этапе очень устраивают пилотные проекты, которые в значительной мере вскрывают проблемы и риски, ожидающие обе договаривающиеся стороны. Заказчик в первом приближении видит прообраз конечного продукта и старается убедиться в том, что Исполнитель видит ГИС-приложение его глазами. Исполнитель имеет возможность пустить пыль в глаза и получить некоторую передышку для того, чтобы собраться с мыслями и избрать верное направление в разработке. Причина такого поведения кроется в различном восприятии ГИС-проекта. Исполнитель всегда видит его изнутри, а Заказчик — во внешних проявлениях работы системы. Отсюда ясно, что особенности интерфейса определяет Заказчик, а пути его реализации, а также методы управления данными избирает Исполнитель.
На этом пути Исполнителя подстерегают пять «НЕ».
Первое «НЕ» в управлении ГИС-проектом: какими бы талантливыми и честолюбивыми ни были программисты в штате Исполнителя, не нужно строить приложение на основе революционных разработок «с нуля». Какими бы дорогими ни были стандартные ядра и программные компоненты признанных лидеров ГИС-технологий, они всегда будут дешевле и априори надежнее и согласованнее со всей средой разработки, чем рожденная пять минут назад гениальная процедура или функция. За каждой строкой MAP- и ARC-objects стоят сотни тысяч часов работы добровольных тестеров во всем мире.
Как правило, пилотный проект представляет собой прообраз графического интерфейса с фрагментом хорошо узнаваемой Заказчиком карты и ОЧЕНЬ маленькой тестовой базой данных. Пилотный проект призван будить воображение как Заказчика, так и Исполнителя.
Для создания действующего макета приложения из готовых компонент зачастую требуется не более двух недель. Эта простота и доступность порождает Второе «НЕ» проекта: не подпадайте под магию аббревиатур. По роковому совпадению, навязшая на зубах аббревиатура ГИС оказывает на разработчиков приложений руководящее и направляющее влияние порядком следования слагающих ее понятий: география, информация и система. Это сочетание, вполне достаточное для производства небольших электронных карт и незначительных информационных систем, совершенно не пригодно для крупных проектов.
Дело в том, что успех пилотных проектов стимулирует продолжение работ по Г-И-С схеме. В чем здесь опасность? Опасности на самом деле две.
Во-первых, красиво решать интерфейсные задачи способен любой человек, проработавший в среде Visual Basic или Delphi 1—2 месяца. Легкость создания интерфейса для листания экранных форм затягивает. Но если считать геоинформационной системой электронное приложение, способное только листать карты, то Заказчику выгоднее купить бумажный атлас. В нем информации заведомо больше, и он дешевле. Наш собственный опыт подтверждает тот факт, что очень тяжело отказываться от работ над интерфейсной частью системы в пользу поиска информации, делающей систему геоинформационной. Но в определенный момент Исполнитель начинает понимать, что имеющаяся у него скудная атрибутивная информация не стыкуется с развитым графическим интерфейсом.
Во-вторых, Заказчика дезориентирует скорость разработки интерфейсной части приложения на первом этапе. У него возникает удивление, а потом и раздражение от основного периода разработки геоинформационной системы — сбора источников данных, установления связи атрибутов с графическими элементами, разработки удобного интерфейса запросов, аналитических процедур и отчетов по выполненным запросам. У него создается впечатление, что в проекте ничего существенного не происходит.
Очень важно убедить Заказчика выделить в бюджете проекта сумму на разработку хранилища атрибутивных данных и административного инструмента для их регулярного обновления, если Заказчик не сделал этого до вас. Будьте готовы к тому, что строка бюджета проекта, посвященная хранилищу данных, будет содержать в себе самую большую цифру бюджета после строки ИТОГО. Если хранилища нет, и Заказчик отказывается нести расходы на него, от проекта выгоднее отказаться. Этот проект безнадежен.
Отсюда возникает Третье «НЕ» в управлении ГИС-проектом: не верьте Заказчику, который обещает принять у вас систему как пустой графин, который Заказчик в свое время наполнит теми данными, которые ему будут очень нужны. Такая система будет даже не атласом, а контурными картами. А Заказчик при приемке проекта будет удивлен пропастью между пилотным проектом и тем, что ему представляют в качестве конечного продукта.
Четвертое «НЕ»: не соглашайтесь на уговоры о включении в вашу систему неопределенно большого количества разнородных документов в качестве источников данных: баз данных от формата DBase и Paradox до Informix, таблиц Excel и Word. Дело в том, что даже в крупных промышленных компаниях от лица Заказчика с Исполнителем общаются узкие специалисты из той предметной области, для которой заказывается Геоинформационная система. Эти специалисты совершенно не обязаны понимать, чем отличается электронная таблица Excel от базы данных Oracle. Узкий специалист ничего не знает о форматах и целостности данных. Он представления не имеет о формально-логическом контроле. Он не обязан этого знать. Задача Исполнителя — с первого шага убедить Заказчика в том, что ГИС у него появится только после правильной организации хранилищ данных. В качестве инструмента убеждения можно воспользоваться советом Дейла Карнеги: «Объясните собеседнику, что решение вашей проблемы выгодно лично ему». Вы понимаете, что правильно организованная система хранения информации на основе СУБД MS SQL или ORACLE, а также создание системы сопровождения хранилища переводит компанию любого размера на принципиально иной уровень управления. Попытайтесь сделать так, чтобы это поняли представители Заказчика.
При таком подходе возникает одно серьезное препятствие: в компании Заказчика у вас сразу появляется множество недругов, поскольку ваша правильно организованная система хранения данных выявляет пробелы в их информационном пространстве, а также их неумение справляться с потоком данных. Выход из сложившегося положения — привлечение к управлению проектом лиц, принимающих решения на более высоком уровне, чем основные пользователи разрабатываемой вами системы.
В тот момент, когда вы решили, что ваше ГИС-приложение уже работает, и вы готовы вынести его на Высший Суд, вспомните о Пятом «НЕ»: не жалейте денег на бригаду внешних тестеров. Эти отвратительные личности, единственным жизненным кредо которых является желание свести вас в гроб нажатием бессмысленных сочетаний клавиш и созданием нештатных ситуаций, в действительности снимают 95% вашей головной боли, не допуская до Заказчика сырой продукт. Чем недружелюбнее тестеры, тем больше у вас шансов сохранить свое место на рынке.
Каков, на наш взгляд, «идеальный» проект? ГИС-проект — это пирамида, в основе которой лежит база баз данных (рис. 4). Мы уверены, что никому не удастся отбиться от четвертого «НЕ» в управлении проектом — неопределенного количества источников данных. Вам следует добиться двух вещей: ограничивать и фиксировать количество этих источников, а также пытаться не допускать в свое приложение информацию в первозданном виде. В противном случае, гарантируем, что работа по поиску ошибок в ВАШЕМ коде будет обеспечена до выхода на пенсию ваших внуков. Потому над базой баз должно находиться ваше собственное хранилище данных, снабженное блоком формально-логического контроля информации и конвертером разнородных данных в единообразный интерфейс вашего приложения. Для хранилища лучше всего подходят промышленные версии СУБД MS SQL и Oracle. Не только потому, что они мощные. Они хорошо сочетаются с SDE-сервером и позволяют построить над хранилищем данных блок управления данными на основе OLAP (On-Line Analytical Processing). Вы сами не поверите своему счастью, когда убедитесь, что OLAP снимает с вас головную боль по разработке развитого интерфейса самых изощренных запросов, которые могут возникнуть в голове Заказчика. Но намного важнее то, что ответы на запросы будут стандартизированными и в том формате, который однозначно понимает ваше приложение.
Рис. 4. Пирамида ГИС-проекта.
Собственно картографический интерфейс находится на самой вершине пирамиды. В египтологии вершина пирамиды называется пирамидионом: это — самая красивая часть пирамиды, предназначенная для общения с богами (читай: конечными пользователями). Какой будет эта вершина — дело вашего вкуса. Но ее жизненный цикл будет напрямую связан с функционированием всего, что находится ниже нее.
По большому счету, ничего нового нами не сказано. Мы всего лишь попытались показать, что для ГИС-приложений логичнее была бы аббревиатура СИГ — Система > Информация > География.
