Материал: 970

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

130

2. Организация бизнеса

Исходными данными для планирования управления рисками служат:

·основные принципы и подходы к управлению рисками, определяющие отношение и толерантность к риску организаций и лиц, участвующих в проекте;

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

·подробное описание содержания проекта;

·план управления проектом — формальный документ, в котором указано, как будет исполняться проект и как будет происходить мониторинг и управление проектом.

План управления рисками обычно включает:

·определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте;

·распределение ролей и ответственности выполнения каждого мероприятия (позиции), включенного в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности;

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

·структуризацию, систематизацию и всестороннюю идентификацию рисков с нужной степенью детализации;

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

·определение уровней вероятности наступления рисков, шкалы воздействия и близости рисков на проект.

В общем случае любой риск может быть описан следующими характеристиками [26] (рис. 2.11):

·причинами, обусловливающими наступление риска;

Основы управления программными проектами

131

·симптомами, указывающими на то, что событие риска произошло или вот-вот произойдет;

·последствиями — проблемами, которые могут появиться при реализации проекта в результате произошедшего риска;

·воздействиями на возможность достижения целей проекта (изменение стоимости, графика и технических параметров разрабатываемого ПП).

Проект

 

 

Заказчик

не обеспечен

 

 

отказался

ресурсами

Формулировка риска

от продукта

 

 

Первопричина

Условия

Последствия

Стоимость

убытка

Роли разработчика

следовательно … наш продукт может

и тестировщика

были объединены

иметь много ошибок

в этом проекте…

 

Рис. 2.11. Основные характеристики риска и их взаимосвязи

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

Согласно [26] возможны четыре вида таких мероприятий: уклонение от риска, передача риска, снижение рисков, принятие риска.

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

132

2. Организация бизнеса

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

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

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

Например, если высока вероятность увольнения сотрудников, то введение на начальной стадии в проект дополнительных (избыточных) трудовых ресурсов снижает потери при увольнении членов команды, поскольку не будет затрат на привлечение к выполнению проекта новых участников.

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

В [26] при разработке мер по предотвращению рисков предлагается выделить две категории рисков:

Основы управления программными проектами

133

1)«известные неизвестные». Это риски, которые можно идентифицировать и подвергнуть анализу. В отношении таких рисков можно спланировать ответные действия;

2)«неизвестные неизвестные». Это риски, вызванные непредвиденными обстоятельствами, которые невозможно идентифицировать и, следовательно, спланировать ответные действия. Единственное, что можно в этом случае предпринять, это создать резерв бюджета проекта на случай незапланированных, но потенциально возможных изменений. Расходование резерва осуществляется руководителем проекта, как правило, при одобрении вышестоящего руководства. Финансовые резервы на непредвиденные обстоятельства не входят в базовый план по стоимости проекта, но включаются в бюджет. Они не распределяются по проекту, как бюджет, и поэтому не учитываются при расчете освоенного объема.

Множество рисков, относящихся к категории «известных неизвестных», в свою очередь, условно можно разбить на определенные группы.

Риски, обусловленные непредвиденными изменениями рыночной ситуации:

1)изменениями нормативного регулирования деятельности компании;

2)изменениями ситуации на рынке программно-аппаратных средств;

3)изменениями ситуации на финансовом рынке;

4)ненадежной работой аутсорсинговых компаний.

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

Риски, обусловленные конкурентной борьбой:

1)ошибочными прогнозами объема продаж, не учитывающими высокий уровень конкуренции;

2)дискредитацией программного продукта со стороны конкурентов.

134

2. Организация бизнеса

Возможные ошибки в объемах продаж непосредственно связаны с непредвиденной конкуренцией. Рекомендации по минимизации рисков в этом направлении сводятся к следующему:

·поставляемый продукт не должен быть полным аналогом существующих на рынке программных систем;

·захват рынка (ускоренное завершение разработки продукта и выведение его на рынок прежде, чем это сделают конкуренты, даже если это приведет к увеличению затрат на первый экземпляр).

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

вслучае незапланированных отклонений.

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

Внутренние (собственные) риски проекта:

1)требования заказчика не всегда точны и подвержены частым изменениям;

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

3)отсутствие эффективного взаимодействия с заказчиком;

4)недостатки планирования проекта, появление «забытых

работ»;

5)недооценка сложности проекта, ошибки в оценках трудоемкости и сроков работ и, как следствие, нереалистичные сроки

ибюджет проекта;

6)отсутствие у команды необходимых ресурсов и опыта;

7)недостатки во внутренней организации работ, неумение работать в реальном времени;

Источник: https://studfile.net/preview/16438421/