9.4 Традиционные методы управления проектом

Richard E. (Dick),
Перевод: Дюмин А.Г.

Источник: Richard E. (Dick) Fairley Managing and leading software projects // a John Wiley & Sons, inc., publication. 2009.

Традиционные методы управления проектом, представленные в этом тексте, можно рассматривать как институционализирование управления рисками. Со временем он стал отдельным от применяемых методов, таких как:

- планирование и оценка;
- требования управления;
- структуры подготовки работы;
- сети, устанавливающие график работы;

А также процесс измерения, использующий такие методы как:

- интерактивное развитие;
- бинарное отслеживание;
- плата за пользование;
- усовершенствование возможного успеха путем сокращения риска эксплуатации.

Другими словами, лучше сделать традиционный проект управления, чем не сделать его. Управление рисками дополняет традиционные методы управления проектами. Определенное управление допущениями и ограничениями, например, это ключевой элемент управления рисками. Как было описано раньше (глава 4), допущение – это предполагаемые условия, которые будут справедливы, но не могут быть проверены в ходе планирования. Вы должны принять, например, что достаточное количество персонала, имеющего необходимый опыт, будет предоставлено в случае необходимости. Или Вы могли бы принять, что сложность продукта не будет представлять для Вас проблемы, потому что вы рассчитываете иметь разработчиков программного обеспечения, которые знакомы с такого рода системой. Допущение – это потенциальная проблема (факторы риска); ложное допущение создает реальные проблемы. Ограничения – внешне наложенные условия, которым должен удовлетворять Ваш проект (т.е. факторы, которые не поддаются контролю управления проекта). Эти ограничения вызваны такими условиями проекта, как:

- график;
- бюджет;
- доступные средства;
- программное обеспечение;
- используемые технологии;

- взаимосвязь с другими системами.

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

Факторы риска, создаваемые ограничениями проекта, можно иногда избежать путем модифицирования ограничений. Ограничения процесса (графики или расписания, бюджет, средства) и продукт ограничения (особенности и качественные признаки) следует изучить. Некоторые ограничения могут быть важными для успешного выпуска. Другие при более тщательном исследовании можно послабить или устранить. Операционные требования для «мгновенного времени ответа» могут быть удовлетворены пятисекундным временем ответа больше чем требованием времени ответа за 2 секунды. Увеличение времени ответа может значительно снизить вероятность фактора риска, который впоследствии станет проблемой. Управление рисками дополняет обычные методы управления проектами (по крайней мере) тремя способами.

Во-первых, Вы можете активно управлять допущениями и ограничениями:

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

Во-вторых, Вы можете:


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

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

Как отмечалось, существуют приемлемые и неприемлемые способы компенсации проблем программного обеспечения.

Приемлемые методы включают:

-увеличение графика;
-увеличение бюджета;
- привлечение дополнительных ресурсов;
- привлечение лучших ресурсов;
- сокращение требований;
- улучшение процессов работы.

Неприемлемые методы включают:

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

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

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

Таблица 9.3 факторы риска и технологии управления риском

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

Программное обеспечение часто имеет факторы риска, которые неизвестны во время предварительного планирования, но становятся явными позже в проекте. Нет необходимости иметь резерв, который будет использоваться, когда неизвестные факторы риска позже появятся в проекте. Количество денег на случайный резерв может колебаться от 10 до 50 % и более проектируемого бюджета в зависимости от уровня неопределенности в период первоначального планирования.

Многие традиционные технологии управления проектом могут быть использованы для управления факторами риска. Таблица 9.3 перечисляет некоторые технологии, которые могут быть использованы в управлении факторами риска, перечисленными Боэмом в его списке ТОП-10 факторов риска программного обеспечения. Следующая секция посвящена методам определения риска, анализа, приоритета факторов риска и смягчающих стратегий риска.