Всё, что вы хотели знать о “заваленных” ГИС-проектах, но боялись спросить

МЕНЕДЖМЕНТ

Известно, что о неудачных проектах люди обычно рассказывают гораздо менее охотнее, чем об успешных. А если и рассказывают, то, как правило, обвиняют в случившемся кого (и что) угодно, но только не себя. Так, одна моя подруга, врезавшаяся на горных лыжах в одиноко стоявшее на приличном удалении от трассы дерево, после месячного лежания в больнице не поленилась приехать на злополучный склон и, громко ругаясь, пнула дерево ботинком. О столкновении она рассказывала всегда одинаково: “Представляете, еду я спокойно - и вдруг откуда ни возьмись дерево!”. Между тем нежданные деревья, похоже, иногда вырастают на пути не только у лыжников и саночников, но и у ГИС-специалистов, от спорта, казалось бы, далеких.

В недавно опубликованном исследовании североамериканской компании KPMG (www.kpmg.com), осуществляющей финансовое и налоговое консультирование, утверждается, что 85% выполненных ГИС-проектов не удовлетворяют критериям успешности, являясь по сути проектами-неудачниками. Дэвид Хэмил из компании MESA Solutions, в частности, утверждает, что это “настоящая эпидемия” (http://spatialnews.geocomm.com/features/mesa1). Согласно отчету KPMG, из неудачных проектов 87% потребовали более чем на половину больших финансовых вложений, чем это было запланировано, результаты 45% проектов не оправдали ожиданий их разработчиков, а 86-92% - намного превысили запланированные сроки.

Геоинформатикам хуже всех

Оценки количества неуспешных проектов по ИТ-индустрии в целом также неутешительны. Компании всего мира тратят на информационные проекты на миллиарды долларов больше, чем было первоначально намечено. Так, META Group (www.metagroup.com) в своем отчете, опубликованном в 2000 г., утверждает, что примерно половине ИТ-проектов, выполненных в США, потребовалось дополнительное финансирование. Еще более печальные данные приводит Standish Group (www.pm2go.com), исследование которой показывает, что 53% всех ИТ-проектов в Северной Америке превышает сроки и требует увеличения бюджета, а 31% так и не был доведен до конца; и только 16% были завершены в намеченные сроки и в пределах выделенных средств. Таким образом, геоинформатика по этому печальному показателю в принципе шагает практически в ногу со всей остальной ИТ-индустрией. Правда, в отчете KPMG особо подчеркивается, что “в геоинформатике управление проектами все еще часто осуществляется в чрезвычайно любительском стиле”.

Какой он, “заваленный” проект?

В уже упомянутом исследовании KPMG к неуспешным отнесены проекты, которые либо были отложены или отменены ввиду того, что не оправдали возложенных на них надежд, либо потребовали как минимум на 30% больше времени/денег на выполнение. Причинами были названы: 1) ошибка в планировании; 2) недостаточно активная поддержка проекта со стороны высшего менеджмента компании; 3) низкий профессиональный уровень руководителя проекта; 4) слабое взаимодействие с заказчиком и/или конечными пользователями.

Хороший план - не для слабаков

Роджер Томлинсон, “отец ГИС”, создавший первую в Канаде геоинформационную систему, считает, что тщательное планирование чрезвычайно важно, без него все дальнейшие шаги особого смысла не имеют.

Планирование любого ГИС-проекта должно, в идеале, состоять из двух этапов - предварительного исследования и разработки детального плана реализации.

Основная задача предварительного исследования заключается в ответе на вопрос, быть или не быть проекту. По мнению Дэвида Хэмила, главное - определить цели и задачи проекта. Выяснить, насколько четко они определены, помогает простой тест, заключающийся в том, что “человека со стороны” (лучше, если это будет действительно так) просят ознакомиться с проектом, а потом рассказать, в чем, собственно, по его мнению, смысл этого самого проекта. Если рассказ неспециалиста о том, какие проблемы, с его точки зрения, призван решать проект, хотя бы в общих чертах совпадет со взглядами на этот вопрос руководства компании-разработчика, цели и задачи можно считать определенными.

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

Результатом предварительного исследования становится не просто ответ на вопрос “быть или не быть”, но и выработка общей концепции, оценивающей трудоемкость, требуемые ресурсы и определяющей главные этапы проекта. Предварительное исследование часто требует значительного времени и задерживает переход собственно к реализации проекта, но при этом резко повышает шансы на его выполнение в срок и в рамках заложенного бюджета.

В главе второй труда, носящего название “Как гарантированно завалить проект” (www.interface.ru/erp/news/m010726554.htm), сказано: “Забудьте о хорошем плане - это для слабаков. Вам не нужны все эти бизнес-консультанты и системные архитекторы, на которых впустую уходят деньги. Ваши идеи столь хороши сами по себе, что их реализация не встретит никаких проблем. Кроме того, инвесторы не очень любят оплачивать счета на проектные работы и подготовку спецификаций. Вы - единственный незаменимый сотрудник, который позволит сэкономить на таких счетах”. К сожалению, такие высказывания “кое-где у нас порой” все еще звучат всерьез.

Детальный план реализации проекта создается на базе предварительного исследования и, согласно инструкциям PMI (Project Management Institute, www.pmi.org), содержит общее описание проекта, его целей и задач, оценку стоимости, дату начала и график работ, имена лиц, ответственных за каждый из этапов, критерии успешности проекта, оценку основных рисков и др.

Поддержка проекта “сверху”

Если руководство организации (либо компании-разработчика, либо компании-заказчика, либо обеих сразу) теряет интерес к проекту, пиши пропало, поскольку проект неизбежно начнет страдать от недостатка специалистов, которым подберут другой фронт работ, а также задохнется в тисках недофинансирования. Ключевая роль тут принадлежит руководителю проекта, который должен поддерживать отношения с вышестоящим начальством, пользователями/заказчиками и со своими сотрудниками. Если ему не удастся найти общий язык с начальством, то ресурсы будут неизбежно утекать в те проекты, руководство которых такой контакт наладить смогло.

Культура разработки ПО, персонал и личность менеджера

Для успешной реализации проекта важное значение имеет культура разработки ПО. Один из худших вариантов описан в уже упомянутой статье “Как гарантированно завалить проект”: “Что требуется для реализации критически важного проекта корпоративного масштаба? Набрать смышленых сотрудников, способных пахать по 20 часов в день, и терпеливо ждать результатов их работы. Если кто-то падает от усталости, привяжите его к креслу”. То есть авторы предлагают больше делать, меньше думать - схему, которая уже давно, к счастью, доказала свою неэффективность, но все еще иногда применяется.

В последнее время все большую популярность завоевывает метод разработки ПО, получивший название Rational Unified Process (RUP, www.rational.com), широко использующий язык моделирования UML (Unified Modeling Language) и предназначенный для создания систем, использующих методологию ООП.

К сожалению, аббревиатуры RUP и UML известны в России еще далеко не всем, особенно в геоинформатике, которая всегда стояла несколько особняком от основного потока развития ИТ, а личность аналитика ГИС-проектов до сих пор вызывает яростные дискуссии. Во-первых, даже на западе такой специалист может скрываться за семью различными названиями (GIS Analyst, GIS Technician, GIS Data Specialist, GIS Specialist, GIS Mapping Technician, GIS Mapping Assistant и GIS Application Specialist). Во-вторых, сумма знаний, необходимых для того чтобы занять такую должность, намного больше, чем у стандартного ИТ-аналитика (http://careers.geocomm.com/resources/gisanlystskills.html). ГИС-аналитик обязан владеть двумя и более картографическими пакетами, разбираться в математике и матстатистике, знать макроязыки, С/С++ и VB, Oracle или другую промышленную СУБД и уметь разрабатывать приложения в такой среде, а также понимать основы картопостроения, географии и пространственного анализа. Зарплата же за все эти знания предлагается обычно невысокая.

Есть проблемы и с персоналом более низкого уровня. Так, по мнению г-на Кислова по прозвищу “Мышь”, известного своими мудрыми высказываниями на специализированных форумах и не понаслышке знающего о проблемах ГИС-проектов в области геологии/геофизики, картографические проекты требуют огромного количества монотонной ручной работы, которая тем не менее может быть выполнена только высококвалифицированными сотрудниками. “Где взять людей на такую зарплату?” - восклицает г-н Кислов.

Менеджер проекта, как уже упоминалось, - ключевая фигура, часто несущая основную ответственность за “заваливание”. Именно он должен контролировать технические вопросы, следить за межличностными отношениями в коллективе и решать любые возникающие проблемы в любой момент времени. Такой человек обязательно должен иметь соответствующее образование. В статье “Как гарантированно завалить проект” по этому поводу сказано следующее: ”Положитесь на здравый смысл. Подумываете об образовании в области управления проектами? Ерунда! Все, что вам нужно, - это здравый смысл, хорошие инстинкты и побольше удачи”. Нужно ли говорить, что такой подход часто оборачивается проблемами.

Долой “дедовщину”

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

На деле все получилось не совсем так. В подчинении у П. оказались опытные и грамотные специалисты, во-первых, не привыкшие, чтобы им рявкали “подъем, салаги! строем на обед!”, а во-вторых, моментально раскусившие профессиональную некомпетентность нового начальника. Некомпетентность эта была столь вопиющей, что подчиненные, быстро поняв, что проект под угрозой, бросили все силы на свержение г-на П., но мятеж был жестоко подавлен. Тогда они выдвинули из своих рядов неформального лидера и решили делать проект своими силами, одновременно всячески пытаясь донести свою точку зрения до вышестоящего руководства. Единственное, чего они не учли, был тот факт, что г-н П. получал на своей теперешней должности зарплату, о которой ранее и мечтать не мог, а посему был готов на все, чтобы сохранить свое положение. Завязалась отчаянная борьба, в результате которой неформальный лидер был уволен. О проекте речь уже не шла вообще - все его участники ушли на баррикады. Чем ближе был час “икс”, тем больше нарастало напряжение. Г-н П. тщательно формировал список виновных в провале проекта и собирал на них компромат, подчиненные строчили докладные записки. Чем все это закончилось, представить легко - компания лишилась крупного заказчика, из нее было уволено порядка 60 человек и сегодня она дышит на ладан, пытаясь восстановить пошатнувшуюся репутацию.

Дочки-матери, а также заказчики-исполнители

Еще одним важным моментом любого проекта является постоянный контакт исполнителей с заказчиками/пользователями, иначе может оказаться, что последние имели в виду совсем не то, что делали первые. Пользователи системы должны стать частью команды, иначе, как сказал г-н Кислов, работать с ПО сможет только тот, кто его создавал.

Интересно, что в России, по мнению г-на Кислова, существует целый пласт проектов, созданных на деньги каких-либо (чаще государственных) организаций и абсолютно никому не нужных. В результате разработчики получили свою прибыль, заказчики истратили деньги по статье, не облагаемой налогом, а проект как бы внедрили, издав соответствующую справку. В результате все довольны, но можно ли такой проект назвать успешным - вопрос как минимум спорный.

Медленно и печально

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