Управление проектами - это философия управления, а не инструмент или техника

Снижение уровня рисков и увеличение вероятности успеха проекта

Индекс материала
Снижение уровня рисков и увеличение вероятности успеха проекта
Итеративный подход, основанный на риске
Все страницы

Страница 1 из 2

Поскольку информационные системы являются ядром современного бизнеса, то разработка нового программного обеспечения и поддержка существующего весьма важны для производительности и прибыли. Модернизация технологий программного обеспечения за последние 20 лет позволяла создавать более сложные продукты, предоставляющие компаниям возможность предлагать клиентам новые сервисы и товары. Тем не менее, проекты по разработке ПО до сих пор страдают от всё тех же проблем и характеристик, что и несколько лет назад, независимо от используемых технологий.

Отчет от Standish Group свидетельствует, что надежность предоставления ПО за последние годы не была значительно улучшена. Рисунок 1 отображает результаты за 2001 год, и они очень похожи на диаграмму того же источника за ранние 90-е.

Рис. 1: Проекты по разработке ПО (49% - успешны; 23% - имели препятствия; 28% - потерпели крах)

Важным вопросом является то, почему же разработка ПО настолько рискована?

Изменения неизбежны

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

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

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

Но какой путь является наилучшим? Основное влияние на данный аспект оказывает выбранный вами процесс разработки, а не используемые технологии.

Выбор правильного процесса

В качестве руководителя проекта вам, скорее всего, захочется попробовать исключить изменения в вашем проекте посредством строгой политики «не производить никаких изменений».

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

К примеру, как это показано на рисунке 2, сбор Требований (Requirements) завершается до старта этапа Анализа (Analysis). Планирование продукта (Design) не может быть начато до того, как будет завершен и одобрен этап Анализа (Analysis) и т.д. .

Следующий рисунок отображает типичный жизненный цикл процесса водопадной разработки.

Рис. 2: Водопадная модель разработки

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

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

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

Рис. 3: Работа с изменениями

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

Профиль риска водопадной модели, отображенный на Рис. 4, не подходит для разработки ПО.

Рис. 4: Водопадный профиль риска

Фундаментальной проблемой водопадной модели является то, что она предполагает предсказуемость прогресса проекта разработки ПО с определенной точностью, а дата завершения может быть надежно вычислена согласно данному предположению. Исходя из того, что цикл разработки будет предсказуем, вы считаете, что высокий риск маловероятен в этом проекте, а это глупо! Водопадный процесс разработки - это неверный подход к разработке ПО.

Итеративная разработка и низкий уровень риска

Риски проекта ассоциируются с чем-то неизвестным. Это могут быть технические, организационные или ориентированные на бизнес риски, например, такие как:

Как будет наша система общаться с системой A?
Как мы можем управлять удаленной группой разработчиков?
Действительно ли требования к системе отображают нужды пользователей?
И т.д...

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

Ключевые принципы

Не существует единственно верного правила, которое бы гарантировало успех проекта, но следующие ключевые принципы значительно увеличат ваши шансы в достижении такого результата: