Управление проектами

• только 16% проектов заканчиваются вовремя и в срок;
• закрываются, не завершившись, 31% проектов;
• выросли по цене (более чем на 89%) 53% проектов;
• во всех завершенных проектах только 61% требуемых позиций был реализован.

Кроме этих печальных цифр приведем еще несколько соображений, почему надо управлять рисками.

• Бизнес компаний находится в прямой зависимости от работоспособности средств автоматизации.
• Сроки подобных проектов очень важны. Понятие 'just-in-time software' становится все более популярным.
• Возрастают требования к качеству программных средств.
• Одновременно возрастают требования к предоставляемому уровню безопасности; растет число вирусов, взломов сетей и серверов, компании теряют миллионы долларов.
• У компаний-заказчиков появился выбор: теперь компьютерный рынок настолько богат, что и 'авантюрист', и осторожный клиент найдут тут свой товар. Всегда есть возможность предпочесть проект с прекрасными возможностями, но с громадными рисками, следует только помнить про 'бесплатный сыр в мышеловке' (риск - 100%).
• В проекты вовлекается обычно очень много людей; созданная программная система не должна отражать взгляд одного человека.

Хирург (управление рисками)

Не надо пугаться. Далеко не всегда управление рисками связано с хирургическим вмешательством в проект. Но 'скальпель' желательно иметь под рукой.

Основным методом управления рисками должен стать комплексный подход. В этом случае постановка вопроса не сильно отличается от проблем управления рисками на обычном производстве, например при выпуске деталей. Создается комплекс планов, и для каждого плана назначается свой ответственный.

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

1. Временной метод. Отслеживает риски по этапам жизненного цикла проекта.
2. Метод управления. Связан со взаимоотношениями внутри команды разработчиков.
3. Метод окружающей среды. Связан с оборудованием и стандартным (готовым) программным обеспечением - операционной системой (системами), базами данных и т.д.
4. Метод качества. Занимается триадой: время-сроки-качество.
5. Технологический метод. Опасно не только использовать новые 'непроверенные', 'сырые' технологии, но и старые, так называемые 'наследуемые'.

Лечебная физкультура (уменьшение рисков)

Подводя итоги, приведем некоторые практические меры, направленные на защиту от последствий рисков.

• Страхование. Хотя это и новинка на компьютерном рынке России, уже появляются первые примеры.
• Резервирование. Сознательное завышение сроков или бюджета проекта с учетом возможных рисков.
• Хеджирование и диверсификация. Компенсация одного проекта другим для снижения суммарного риска.
• Разграничение. Подразделение, отвечающее за качество, должно отличаться от подразделения, отвечающего за сроки.
• Техническая грамотность. Необходимо использовать и проверять новые технические решения, например компонентные системы - баланс между готовыми (меньше все риски, кроме функциональных; вспомните, сколько коробок пылится в каждом отделе ИТ) и разрабатываемыми (большие риски и обычно большая цена) для уменьшения рисков.

Заключение лечащего врача

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

Анализ рисков помогает понять и увидеть те ключевые 'тонкие' моменты проектов, которые могут привести к подобным печальным результатам, и заставляет начать с ними бороться.