Сравнительные диаграммы расписания 2 страница

5.4. Организация управления качеством

Обеспечение качества - процесс выполнения плановых систематических операций по качеству, которые обеспечивают выполнение всех предусмотренных процессов, необходимых для того, чтобы проект соответствовал установленным требованиям по качеству [23]. Функцию обеспечения качества может выполнять команда проекта, руководство исполняющей организации, заказчик или спонсор, другие участники проекта. Для контроля качества проекта проводятся аудиторские проверки, целью которых является выяснение соответствия качества проекта стандартам, установленным в плане обеспечения качества.

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

Для обеспечения процесса оценки качества проекта на стадии планирования разрабатываются контрольные списки качества - таблицы с инструкциями для проверяющего лица. Пункты контрольного списка должны быть достаточно значимыми, поскольку, если контрольный список будет перегружен, его не будут использовать (см. табл. 4.4). Контрольные списки качества - это метрики качества, которые определены для каждого этапа проекта на основании ожиданий заказчика, этим метрикам присвоен свой статус: критический, серьезный, важный. Включение в контрольные списки качества неважных метрик нежелателен, так как иначе данный список не будет использоваться. Преимуществом его применения является простота, даже на малых проектах для данного инструмента не требуется больших затрат ресурсов и времени, при этом с помощью контрольного списка качества можно на этапе выполнения работ отследить, что не было выполнено из требований заказчика [11].

Таблица 4.4. Пример контрольных списков проверки качества

Этап проекта	Ожидаемый результат	Тип	Да	Нет
Регулирование настроек	Процент настроек, соответ-ствующих описанию в документации (допустимая погрешность 3%)	Критичный
Определение требований к среде	Список требований	Критичный
Настройка инфраструктуры	Список настроек	Критичный
Разработка функциональных характеристик	Количество возникших оши-бок при работе.Процент ошибок в ходе работы	Критичный
Определение параметров разработки и плана тестирования	Список параметров разработ-ки.План тестирования.Про- цент исходов, не учтенных в плане тестирования	Критичный
Анализ проекта	Наличие протоколов по анализу результатов каждой фазы проекта	Серьезный
Управление изменениями	Документирование всех запро-сов на изменение в соответствии с принятой формой и их сохранение в единой базе	Критичный

Пояснения к заполнению формы контрольных списков

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

· Ожидаемый результат - метрика качества, которую необходимо достичь.

· Тип - присвоенный тип данной метрики, может быть критический, серьезный, желательный.

· Да/Нет - достигнут ли ожидаемый результат. Заполняется на этапе контроля и обеспечения качества проекта.

Данные о результатах контроля передаются исполняющей организации для использования в процессе обеспечения качества, для повторной оценки и анализа стандартов качества на последующих фазах ЖЦ ИС. Пример формы представления результатов контроля качества приведен в табл. 4.5.

Таблица 4.5. Форма представления результатов контроля качества

№ п.п.	Объект контроля качества	Дата замечания	Замечание	Автор замечания

На рис. 4.1 приведено графическое изображение процедуры разработки контрольных списков качества.

Рис. 4.1. Процедура разработки контрольных списков (графическое изображение)

Для выполнения операций по обеспечению (оценке) качества используют аудит. Аудит качества - независимая экспертная оценка, определяющая, насколько операции проекта соответствуют установленным в рамках проекта или организации правилам, процессам и процедурам. Целью аудита качества является выявление неэффективных и экономически неоправданных правил, процессов и процедур, используемых в проекте. Количество и сроки плановых проектных аудитов могут определяться основными этапами проекта или ключевыми событиями. Внеплановые аудиты проводятся по запросам заказчика, руководителей департаментов и отделов. Аудиты качества проводятся на основе критериев, каждый из которых является следствием требований нормативной документации системы менеджмента качества (требование ISO 9000) и системы управления проектами (PMBOK). Схема проведения внутреннего аудита качества проекта может выглядеть следующим образом:

· анализ исправления замечаний предыдущей проверки;

· проведение проверки проекта в соответствии с контрольными списками;

· оформление отчета о контроле качества;

· информирование команды проекта о появлении новых отчетных документов.

Ниже приведен шаблон для регистрации списка отклонений и описание процедуры обеспечения качества (табл. 4.6).

Таблица 4.6. Шаблон регистрации отклонений

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

Рис. 4.2. Графическое описание процедуры управления качеством

6. Планирование рисков проекта

Основные понятия управления рисками. Определение уровней вероятности возникновения рисков и их последствий. Методики идентификации рисков. Организация управления рисками. Пример процедуры управления рисками.

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

Риск проекта - это кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта [23]. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и следовательно, невозможно спланировать действия по реагированию на такой риск.

Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту [23].

Вероятность возникновения риска - вероятность того, что событие риска наступит [23]. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.

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

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

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

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

Планирование реагирования на риски включает разработку плана управления рисками - документа, разрабатываемого в начале проекта и представляющего собой график работы с рисками в течение всего ЖЦ проекта. План содержит следующую информацию [18].

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

Роли и обязанности - раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта.

Бюджетирование - определяет бюджет для управления рисками проекта.

Временные рамки - устанавливают частоту процессов управления рисками.

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

Контроль - раздел, определяющий формат плана реагирования на риски.

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

Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework) [11]. MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта.

Методы управления проектными рисками для малых и средних проектов достаточно проработаны и позволяют эффективно снижать уровень рисков и трудозатраты по проекту (см. табл. 5.1) Для ведения крупных проектов "стандартного" набора методов оказывается недостаточно [15].

Таблица 5.1. Примеры управления рисками

Масштаб проекта	Число работ	Число подпроектов	Связность работ	Методы управления
Малый	too	Нет	Низкая	PMI ^1 FMEA MSF, личный опыт руководителя
Средний	50-100	Единицы	Низкая, средняя	Стандартные методики (ASAP ^2 PJM ^3 PMI), SPICE^4 COBIT
Крупный	100-1000	От нескольких десятков до нескольких сотен	Высокая	Проработаны слабо

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

На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:

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

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

· идентифицировать риски.

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

6.2. Определение уровней вероятности возникновения рисков и их последствий

Общие определения уровней вероятности и уровней воздействия адаптируются отдельно для каждого проекта в ходе процесса планирования управления рисками и используются в процессе качественного анализа рисков. Можно применить относительную шкалу, на которой вероятность обозначена описательно, со значениями от "крайне маловероятно" до "почти наверное", или шкалу, на которой вероятности соответствует цифровое значение, например: 0,1 - 0,3 - 0,5 - 0,7 - 0,9. В табл. 5.2 представлено семиуровневое разделение вероятности [11]. Для каждого интервала вероятностей выполнена относительная и числовая оценка.

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

Таблица 5.2. Семиуровневая оценка вероятности возникновения риска

Интервал вероятностей	Значение вероятности, используемое для вычислений	Словесная формулировка	Числовая оценка
От 1% до 14%	7%	крайне маловероятно
От 15% до 28%	21%	низкая вероятность
От 29% до 42%	35%	скорее нет
От 43% до 57%	50%	50-50
От 58% до 72%	65%	возможно
От 73% до 86%	79%	весьма правдоподобно
От 87% до 99%	93%	почти наверняка

Таблица 5.3. Шкала для оценки последствий риска, измеряемых в деньгах

Оценка	Денежное выражение
	до $100
	$100-$1000
	$1000-$10,000
	$10,000-$100,000
	$100,000-$1,000,000
	$1,000,000-$10 миллионов
	$10 миллионов-$100 миллионов
	$100 миллионов-$1 миллиард
	$1 миллиард-$10 миллиардов
	свыше $10 миллиардов

Когда денежные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки последствий риска (см. табл. 5.4). Система оценки воздействий должна отражать политику и ценности организации и проектной группы.

Таблица 5.4. Шкала для оценки последствий риска, измеряемых отклонениями в стоимости, сроках и технических условиях проекта

Оценка	Перерасход средств	Календарный график	Технические условия
1 (низкая)	до 1%	сдвиг на 1 неделю	небольшая потеря производительности
2 (средняя)	до 5%	сдвиг на 2 недели	умеренное снижение производительности
3 (высокая)	до 10%	сдвиг на 1 месяц	серьезный ущерб для производительности
4 (критическая)	от 10%	сдвиг более 1 мес.	задача не может быть выполнена

Таблица 5.5. Определение шкалы оценки воздействия для четырех целей проекта

Определенные условия для шкалы оценки степени возможного влияния риска (показаны только примеры негативных воздействий)
Цель проекта	Показаны значения по относительной и числовой шкалам
Очень низкое	Низкое	Умеренное	Высокое	Очень высокое
0,05	0,10	0,20	0,40	0,80
Стоимость	Незначительное увеличение	Увеличение < 5%	Увеличение 5-10%	Увеличение 10-20%	Увеличение > 20%
Сроки	Незначительное увеличение	Увеличение < 5%	Увеличение 5-10%	Увеличение 10-20%	Увеличение > 20%
Содержание (объем)	Изменения незаметны	Незначительные изменения	Значительные изменения	Неприемлемое для клиента изменение	Достижение конечных результатов невозможно
Качество	Изменения незаметны	Незначительные изменения	Изменения требуют согласия клиента	Неприемлемое для клиента изменение	Достижение конечных результатов невозможно

Рис. 5.1. Матрица воздействия (вероятностей и последствий) рисков

Относительная шкала последствий разрабатывается каждой организацией самостоятельно. Шкала содержит только описательные обозначения, например, "очень низкий", "низкий", "средний", "высокий" и "очень высокий", расположенные в порядке возрастания максимальной силы воздействия риска согласно определению данной организации. То же самое можно сделать иначе, путем присвоения данным последствиям цифровых значений, которые могут быть линейными и нелинейными, например, 0,1 - 0,3 -0,5 - 0,7 - 0,9 или 0,05 - 0,1- 0,2 - 0,4 - 0,8. В табл. 5.5 представлены как относительный, так и цифровой (в данном случае нелинейный) способы обозначения последствий риска для четырех целей проекта [23].

Шкала уровней воздействия является основой для построения матрицы вероятности и последствий.

Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий, средний или высший [23]. Матрица может содержать описательные термины или цифровые обозначения (см. рис. 5.1) и строится на основании шкал оценки вероятности и оценки степени влияния возможного риска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняются результатами перемножения значений этих шкал. Сопоставляя значение ячейки матрицы со шкалой оценки воздействия, риски можно разделить по категориям: малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рис. 5.1. Риски, имеющие очень высокую вероятность, но незначительные последствия, а также риски, имеющие низкую вероятность и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета), имеют среднее воздействие на проект. Риски, которым необходимо уделять особое внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом).

6.3. Методики идентификации рисков

Для идентификации рисков используют следующие методы [11,23].

Мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.

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

Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности.

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

Опросы экспертов с большим опытом работы над проектами.

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

Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа - оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрыв между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.

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

Метод аналогии. Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов.

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

Таблица 5.6. Сравнение методов идентификации рисков

Метод идентификации	Преимущества	Недостатки
Мозговой штурм	Способствует взаимодействию членов группы. Быстрый. Недорогой	Может проявиться преобладание одной личности. Можно сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы
Метод Delphi	Нет доминирования одной личности. Может проводиться дистанционно, через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы	Занимает много времени. Высокая загрузка ведущего
Метод номинальных групп	Уменьшается эффект доминирующей личности. Обеспечивает взаимодействие участников. Дает упорядоченный список рисков	Требует много времени. Высокая загрузка ведущего
Карточки Кроуфорда	Быстрый. Легко реализуется. Должен участвовать каждый член группы. Вырабатывается большое количество идей. Можно проводить с группами большеобычного размера. Уменьшает эффект доминирующей личности	Меньшее взаимодействие между участниками
Опрос экспертов	Используется прошлый опыт	Эксперт может быть предвзятым. Требует много времени
Контрольные списки	Конкретный и упорядоченный. Легко использовать	Предвзятость. Может не содержать конкретных элементов для данного проекта
Метод аналогии	Использует прошлый опыт для исключения проблем в будущем. Подобные проекты содержат много сходных черт	Требует много времени. Легко получить результаты, не подходящие для данного случая. Аналогия может быть некорректной
Методы с использованием диаграмм	Ясное представление участвующих процессов. Легкость построения. Для них имеется много компьютерных инструментов	Иногда вводит в заблуждение. Может занимать много времени

Сравнение методов идентификации рисков проекта [11] представлено в табл. 5.6.

Идентифицированные риски документируются в так называемых реестрах рисков.

Примеры шаблонов реестра рисков [11] приведены в таблицах 5.7и 5.8.

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

Таблица 5.7. Шаблон реестра рисков

ИДЕНТИФИКАЦИЯ РИСКА
№	Датавозникновенияриска	Датарегистрациириска	Наименование и описание риска	Инициатор	Причины	Последствия	Владелец риска	Дата окончания действия риска
.
.

Таблица 5.8. Пример заполнения реестра рисков (упрощенный)

Первопричина	Условие	Последствие
Необеспеченность кадрами	Могут быть объединены проектные роли. Несовместимые роли: менеджер по качеству и разработчик,тестировщик и разработчик	Совмещение ролей может затруднить контроль и оценку результатов, что снизит качество программного продукта
Изменения в технологии	Разработчикам придется осваивать новые технологии и использовать их впервые	Увеличится время на разработку программного продукта. Возможно снижение качества________
Организация работы	Участники проекта территориально удалены	Обмен информацией внутри группы затрудняется. Время на достижение целей проекта увеличивается_____

Таблица 5.9. Пример заполнения расширенного журнала рисков

Дата добавления: 2015-04-29