Лекция 16. Концептуальная база проекта:

управление рисками и качеством,

отслеживание связей

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

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

В предыдущей лекции мы рассмотрели вопросы определения мето­дологического основания программного проекта и показали необходи­мость осознанного формирования концептуальной базы проекта. В част­ности, было указано, что эта база служит основой выработки общего пла­на проекта, составляющими которого являются планы по направлениям проектной деятельности. Мы рассмотрели части концептуальной базы, без которых проект как целенаправленная деятельность невозможен, — концепция развития проекта и план релизов. В данной лекции будут обсу­ждаться работы системы деятельностей проекта (см. лекцию 4), которые призваны обеспечивать устойчивость траектории развития. Без осознан­ного их выполнения достижение целей проектов весьма сомнительно. Речь пойдет об управлении рисками, управлении качеством и отслеживании связей. Эти виды деятельности тесно взаимосвязаны. Без специальной уп­реждающей заботы о реакции разработчиков на рискованные ситуации невозможно организовать качественный процесс, а следовательно, трудно ожидать и приемлемого качества получаемых результатов. В свою очередь, взаимосвязанность и переплетение деятельностей проекта есть фактор ри­ска, и отслеживание связей в одном из аспектов можно рассматривать как инструмент снижения рисков. В то же время эти три деятельности целесообразно рассматривать по отдельности, поскольку каждая из них имеет свое содержание, которое не сводится к обслуживанию других.

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

Управление рисками

Понятие риска в бытовом смысле чаще всего связывается с негатив­ным влиянием на какую-либо деятельность. В то же время иногда говорят и о позитивном влиянии рисков: «Без риска нет успеха». По-видимому, правильнее всего говорить о том, что с риском связывается некая неопре­деленность в развитии событий, которая способна оказывать влияние на результативность процессов. Применительно к программным проектам рисками называют неопределенные события, негативно, позитивно влия­ющие или не влияющие на ход развития проекта (нейтральные). И един­ственное, в чем сходятся все трактовки поведения в рисковых ситуациях, это то, что к ним нужно готовиться заранее. Управление рисками проекта (Project Risk Management) включает в себя процессы, обеспечивающие планирование возможности рисков, их идентификацию, анализ, разра­ботку откликов и контроль в течение жизненного цикла проекта.

Для позитивных рисков подготовленность означает рациональное использование появляющегося резерва (времени или ресурсов). Неподго­товленность к негативным и нейтральным рискам — это всегда потеря возможностей.

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

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

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

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

При составлении плана управления рисками нужно быть совершен­но уверенным в том, что рассматриваются только подлинные риски, а не известные проблемы или условия, т.е. причины беспокойства за проект, которые не влияют на достижение целей проекта. Таким образом, нужно различать:

• причины риска — определенные события или обстоятельства в про­екте или в его окружении, которые вызывают неопределенность;

• риски — неопределенные события или обстоятельства, возникнове­ние которых может привести к воздействию на процесс достиже­ния целей проекта:

• к негативному воздействию, если в результате траектория про­ектной деятельности выходит из области допустимости;

• нейтральному воздействию, если траектория не выходит из этой области;

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

• последствия — незапланированные отклонения траектории выпол­нения проекта, возникшие в результате того, что событие или об­стоятельство, квалифицированное как риск, имели место.

Это разбиение рисков на составляющие принято, например, в стан­дарте PMBOR [48]. При описании стратегии оперирования рисками мы придерживаемся рекомендаций этого стандарта. Схематически составля­ющие рисков показаны на рис. 16.1. Разный способ показа составляющих риска на схеме (блок причины — прямоугольник, сам риск — облако, воз­действие — овал) отражает степень неопределенности. Стрелка от причи­ны к воздействию через риск отражает развитие рисковых событий, кото­рыми нужно управлять в проекте. Приведенная схема была предложена Дэвидом Хилсоном [42], которого, подчеркивая безусловную компетен­цию в вопросах управления рисками, часто называют Доктором Риск.

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

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

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

Реальные риски — это те события, которые действительно характери­зуются неопределенностью. Если причина детерминировано ведет к со­бытию, то это не риск, а штатная ситуация, план преодоления которой к управлению рисками отношения не имеет. Следовательно, нужен анализ связей причин и событий.

В результате идентификации рисков формируется список идентифи­цированных реальных рисков.

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

В результате выставления приоритетов определяются риски, которые будут отслеживаться в проекте. Остальные риски не отслеживаются, но иг­норируются обоснованно, так как реально в проекте можно отследить не более 10-15 рисков, а потому нужно выбрать наиболее существенные из них.

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

1. Исключение риска (avoid). Некоторые рискованные ситуации мож­но исключить полностью. Например, чтобы увольнение работника с ключевой ролью не сильно сказалось на продолжении развития про­ екта, целесообразно с самого начала предложить для исполнения этой роли двух человек сравнимой квалификации. В начале проекта их дискуссии полезны для выработки объективных решений, а если один из них откажется от контракта, второй все еще сможет продол­ жать дело. Полезные дискуссии — эта та жертва, которая во многих случаях возможна для исключения риска. К сожалению, дублирова­ние не может быть рекомендовано для исключения всех рискован­ных ситуаций.

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

2. Переключение риска (transfer). Это частный случай исключения, когда риск переносится из сферы влияния проекта на окружение. Например, если рыночная ценность создаваемого изделия кажет­ся сомнительной, для его разработки комфортнее договориться с заказчиком об авансовых платежах, тем самым заставив его само­го решать задачу преодоления риска и освободив от этого разра­ботчиков (возможно, за счет снижения оплаты проекта). К этому уровню относятся все варианты контрактных соглашений, но не только они. Оперируя рисками, всегда нужно стараться предусмо­треть способы переключения.

К сожалению, эта стратегия является исключением риска только для разработчиков, но не для проекта в целом.

3. Уменьшение риска (mitigate). Если риск не может быть исключен, можно постараться уменьшить вероятность его появления на пра­ктике (оперирование причинами). Продолжая пример с увольне­нием сотрудника, для снижения вероятности этого следует преду­гадать причины поступка и постараться создать для сотрудника более комфортные условия (повысить заработную плату, создать льготы и т.п.). Нужно, чтобы подобные решения делались не в от­ вет на заявление об увольнении, а заранее. Это сохранит опреде­ленную стабильность в коллективе, которая сама по себе является методом уменьшения риска.

Другой пример уменьшения риска — объявление (для заказчика, руководства и коллектива) о пересмотре требований, когда стано­вится понятным, что график выполнения работ может быть сор­ван. Как и в предыдущем случае, важным моментом здесь являет­ся упреждение, т.е. пересмотр требований не в ответ на нарушение графика, а в качестве превентивной меры.

4. Предупреждение ущерба от риска (accept). Когда не получается удо­влетворительно уменьшить риск, следует подготовиться к встрече с ним так, чтобы минимизировать потери, т.е. снизить вероят­ность негативного воздействия и уменьшить само воздействие (оперирование последствиями). Если это удается, то продолжение проекта во многих случаях оказывается успешным. В примере с увольнением следует как можно скорее найти замену данному со­труднику. Естественно, время выполнения проекта увеличится (в частности, потому что нового человека придется вводить в курс дела), но работа все-таки будет продолжена. Это так, но при одном условии: на всех уровнях проектирования заложена возможность отделения результатов труда от разработчиков. Если результаты персонифицированы, то трудности подмены для некоторых ролей могут оказаться непреодолимыми.

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

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

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

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

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

Очень важно, чтобы исполнители проекта были осведомлены о воз­можных рисках и о плане управления ими. Это создает уверенность в ус­пехе и подготавливает работников к преодолению трудностей. Для менед­жера при составлении плана самое важное — не упустить все возможные рискованные ситуации.

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

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

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

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

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

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

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

• задержка начала проекта никогда не компенсируется;

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

• если пользовательский интерфейс не является интуитивно понят­ным и превышает уровень компетенции потребителя изделия, про­дукт будет плохо распространяться;

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

• не протестированный продукт снижает репутацию разработчиков;

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