46
Для структурирования плана работ проекта используют ИСР –
иерархическую структуру работ (Work /Breakdown Structure, WBS),
представляющая собой декомпозицию всех работ проекта. Каждый
следующий уровень иерархии отражает более детальное определение
элементов проекта.
ИСР разрабатывается на основе концепта проекта, определяющего все
ограничения проекта и его цель. ИСР позволяет выявить все работы,
требующиеся для достижения поставленной цели проекта.
К разработке ИСР необходимо подходить крайне внимательно, т.к.
при небрежном составлении ИСР существует риск забыть о каких-то важных
задачах проекта, из-за чего весь проект может стать неуспешным. Например,
многие ИТ-проекты не достигают успешного завершения, т.к. на этапе
составления ИСР были забыты такие важные вехи как тестирование или
исправление ошибок в релизе.
Декомпозиция работ проекта может быть проведена различными
способами. Например, ГОСТ 19.102-77 предлагает каскадный подход и
определяет следующие стадии разработки программной системы:
1) Техническое задание
2) Эскизный проект
3) Технический проект
4) Рабочий проект
5) Внедрение
По сути ИСР – это один из основных инструментов управления
проектом, с помощью которого измеряется степень достижения результатов
проекта. ИСР выполняет ряд важных функций, одна из которых –
предоставление всем участникам проекта информации о текущем ходе
проекта, соответствии срокам и бюджету проекта.
На протяжении всего проекта посредством ИСР можно выявлять
отклонения хода проекта по сравнению с базовым планом, т.е. планом,
принятым на начальном этапе проекта.
47
1.8.1. Планирование управления содержанием
После согласования ИСР необходимо подготовить и утвердить
порядок управления содержанием проекта. Основные шаги:
1. Определение источников запросов на изменение.
2. Установление порядка анализа, оценки и утверждения/отклонения
изменения содержания.
3. Определение порядка документирования изменений содержания.
4. Определение порядка информирования об изменении содержания.
Важно учесть, что анализ запроса на изменения должен включать ряд
мероприятий по выявлению объектов изменений. Во всех выявленных
объектах должно быть детально задокументировано требуемое изменение.
При утверждении порядка управления содержанием важно правильно
оценить затраты н выполнение указанных выше работ, а также на
тестирование изменений и потенциальное влияние на сроки проекта.
Анализ и внесение изменений – это зачастую высокозатратные
мероприятия, требующие работы различных специалистов (аналитиков,
разработчиков, проектировщиков, тестеров и пр.) Поэтому такие работы
обязательно должны быть предусмотрены в рамках бюджета проекта.
1.8.2. Планирование организационной структуры
Организационная структура проекта – это формализованное описание
распределения ролей и обязанностей в команде проекта. В зависимости от
особенностей проектов организационные структуры проектов могут иметь
различные типы. Объединяет их одно – практически всегда организационная
структура проекта – явление временное, создающееся только на время
действия проекта, т.е. не меняющее штатное расписание организации.
Особое внимание при проработке организационной структуры
проекта необходимо уделить ее стабильности, т.к. частая смена участников
проекта может стать серьезной угрозой для успешного завершения проекта,
поскольку существует цена замены сотрудника в проекте, определяющаяся
временем вхождения нового сотрудника в контекст проекта.
48
1.8.3. Планирование управления конфигурациями
В рамках процесса управления ИТ-проектом крайне важным является
конфигурационное управление. Здесь речь идет об обеспечении единого
хранилища всей проектной документации и разрабатываемого кода, а также
обеспечении сохранности и возможности восстановления информации в
случае каких-либо сбоев. Кроме того план должен предусматривать работы
по сборке промежуточных версий ПО и его конечного варианта.
Необходимо учитывать, что ряд работ в рамках конфигурационного
управления требует от специалиста определенных знаний и
соответствующих компетенций. Поэтому имеет смысл на данные работы
выделять одного конкретного специалиста, при этом для небольших
проектов ответственность за управление конфигурациями может быть
дополнительной к его основной роли.
1.8.4. Планирование управления качеством
Обеспечение качества – немаловажная работа, требующая
планирования; данная работа должна выполняться в течение всего проекта,
т.е. не только во время проведения приемо-сдаточных испытаний.
При планировании работ по управлению качеством важно помнить об
ограничениях, присущих каждому проекту, в частности о временных
ограничениях, которые не позволяют достигать наивысшего возможного
качества. Следовательно, при планировании работ по управлению качеством
необходимо исходить из требований к конечному продукту и ограничений
проекта.
Необходимо отметить, что основная деятельность по управлению
качеством заключается не в поиске недочетов в итоговом продукте, а в
предупреждении брака в процессе работы.
1.8.5. Базовое расписание проекта
После того, как трудоемкость работ определена необходимо составить
график выполнения работ, т.е. определить общие сроки, необходимые для
выполнения проекта.
49
Первый график называется «базовый план» - это утвержденный план-
график проекта, в котором указаны временные рамки проекта, контрольные
вехи и ИСР. Как правило, базовый план представляется в виде диаграммы
Ганта.
Часто базовый план включается в договор между заказчиком и
исполнителем, а контрольные вехи в нем служат для оценки состояния
проекта и принятия решения о его дальнейшем ходе.
В базовом плане необходимо продумать взаимосвязь задач – т.е.
установить последовательность выполнения задач. Если задачи не связаны
между собой, то их начало и завершения может быть когда угодно в пределах
сроков проекта. Но на практике такое бывает крайне редко. Обычно задачи
имеют четкую последовательность. Например, разработка ПО не может
предшествовать задаче написания и утверждения технического задания, а
задача по тестированию ПО должна идти строго после завершения задачи по
разработке ПО.
После составления базового плана проекта рекомендуется проследить
критический путь проекта (Critical path) – это наиболее длинная цепочка
задач в проекте. Увеличение сроков выполнения любой задачи в этой
цепочки негативно влияет на длительность проекта в целом.
В проекте всегда существует хотя бы один критический путь, но их
может быть несколько. Критический путь может меняться во время
выполнения проекта. При выполнении проекта руководитель должен
обращать внимание на исполнение задач на критическом пути в первую
очередь и следить за появлением других критических путей.
1.9. Управление рисками проекта
В силу специфики ИТ-отрасли, разработка и внедрение ПО все еще
остается и высокорискованным проектом. По сути все действия в процессе
управления проектом разработки ПО направлены на борьбу с рисками
выхода за рамки сроков или бюджета проекта, ошибки в разработке продукта
и пр.
50
Риск – неопределенное событие или условие, наступление которого
отрицательно или положительно сказывается на целях проекта.
Как правило, в случае возникновения негативного риска, практически
всегда стоимость проекта увеличивается и происходит задержка в
выполнении задач, предусмотренных графиком проекта.
На этапе инициации, когда нет необходимых данных для проведения
детального анализа, часто приходится ограничиваться качественной оценкой
общего уровня рисков: низкий, средний, высокий.
При оценке рисков всегда принимают во внимания два параметра –
вероятность наступления риска и его последствия. К примеру, всегда
существует вероятность, что на офис разработчиков упадет метеорит, что
будет иметь крайне негативные последствия. Однако вероятность
наступления такого события крайне мала и в большинстве проектов данный
риск не принимается во внимание и не требует управления.
Существует также такая категория, как неизвестные риски – по сути
это непредвиденные обстоятельства. Попытка предугадать их и/или
управлять ими обречена на провал и единственно возможное эффективное
решение относительно данной категории рисков – это создание резерва в
бюджете проекта на случай наступления таких рисков.
1.9.1. Планирование управления рисками
Управление рисками выделяют в отдельный подпроцесс в рамках
управления проектом в целом. Как и другие проектные задачи, на управление
рисками необходимы временные и ресурсные затраты. Нередко для
управления рисками выделяется отдельная штатная единица. Как и прочие
задачи проекта – управление рисками нуждается в планировании, т.е. в
определении подхода и разработке мероприятий по управлению рисками в
проекте.
Планирование управления рисками необходимо завершить на ранней
стадии планирования проекта, т.к. оно оказывает большое влияние на успех
выполнения других процессов.
51
Базовые элементы плана управления рисками:
Выработка подходов, инструментов, а также определение
источников данных, которые будут использоваться для управления рисками в
данном проекте.
Распределение ролей и ответственности в рамках процесса
управления рисками.
Оценка бюджета мероприятий, необходимых для управления
рисками.
Определение сроков и периодичности выполнения процесса
управления рисками на протяжении всего жизненного цикла проекта.
Категоризация рисков, а именно создание структуры, на основании
которой производится регулярная верификация рисков с нужной степенью
детализации.
Определение уровней вероятности, шкалы воздействия и близости
рисков на проект.
Шкала оценки воздействия отражает значимость риска в случае его
возникновения. Пример приведен в таблице 3.
Таблица 3
Пример шкалы оценки воздействия рисков
Вес
Значение
Критерий
3
Катастрофические
Потери более $50K
2
Критичные
Потери от $10K до $50K
1
Умеренные
Потери менее $10K
Несмотря на то, что риск может воздействовать как на сроки проекта,
так и на качество получаемого продукта, все последствия риска могут быть
оценены в денежном выражении. Например, последствия задержки по срокам
выпуска разработки могут быть выражены суммой штрафа, определенного
условием договора.
52
Похожая шкала применяется для оценки вероятности наступления
риска. Пример приведен в таблице 4.
Таблица 4
Пример шкалы оценки вероятности осуществления риска
Вес
Значение
Критерий
3
Очень вероятно
Шансы наступления весьма велики
2
Возможно
Шансы равны
1
Мало вероятно
Наступление события весьма сомнительно
Не менее важной характеристикой риска является близость его
наступления. Обычно, при прочих равных условиях, чем ближе дата
наступления риска, тем больше внимания ему необходимо уделить. Для
шкалы оценки близости риска может быть применена следующая градация:
очень скоро, не очень скоро, очень нескоро.
1.9.2. Идентификация рисков
Идентификация рисков – это комплекс мероприятий, направленных,
на выявление рисков, способных оказать влияние на проект, и
документирование их характеристик. Данные мероприятия периодически
повторяются на протяжении всего проекта, т.к. с течением времени могут
появляться новые риски.
Исходные данные для идентификации рисков могут браться из разных
источников.
Наиболее распространенным источником является база накопленной
информации по итогам выполненных ранее организацией проектов.
Другим источником информации может служить информация из
открытых источников. В частности различные форумы ИТ-тематики могут
дать бесценную информацию о возникших ранее проблемах в схожих
проектах.
Каждый проект задумывается и разрабатывается на основании ряда
предположений и допущений. Как правило, в описании содержания проекта
перечисляются принятые допущения, так называемые «Границы проекта» –
факторы, которые для целей планирования считаются верными, реальными
53
или определенными без привлечения доказательств. Анализ допущения
позволяет идентифицировать риски проекта, происходящие от неточности,
несовместимости или неполноты допущений.
Информация о рисках может быть получена различными путями.
Наиболее распространенные способы получения информации следующие:
Мозговой штурм
Для данного способа формируется команда квалифицированных
специалистов, которым предлагают подготовить информацию по
определенной категории рисков. На общем собрании специалисты по
очереди презентуют свои мнения. В момент презентации споры и/или
замечания не допускаются, все озвученные мысли записываются на
флипчарт. Затем риски группируются по типам.
Цель данного способа заключается в составлении списка потенциально
возможных рисков для последующего анализа.
Опрос экспертов
Цель опроса экспертов – определить и оценить риски путем интервью
квалифицированных специалистов. Специалисты высказывают своё мнение о
рисках и дают им оценку, исходя из своих знаний, опыта и имеющейся
информации. Этот метод может помочь избежать повторного наступления на
одни и те же грабли.
Перед опросом эксперту предоставляют всю необходимую вводную
информацию.
Карточки Кроуфорда
Данный метод похож на предыдущие два, отличие в том, что экспертов
просят записать на бумаге наиболее важные риски, без их озвучивания и
обсуждения. Экспертам необходимо записать 10 различных рисков, после
чего карточки с записанными рисками собираются и составляется список.
Данный список предоставляется участвовавшим экспертам для внесения
дополнений.
Метод Дельфи
54
Метод Дельфи характеризуется меньшей субъективностью, т.к. участие
в нем анонимно. Опрос проводится в несколько этапов, после каждого этапа
результаты рассылаются экспертам с целью их доработки. Данный метод
способствует достижению общего мнения специалистов о рисках.
Результатом идентификации рисков является перечень рисков с
описанием их основных характеристик: причины, условия, последствия и
ущерб.
После идентификации рисков необходимо провести их качественного
анализа.
1.9.3. Качественный анализ рисков
Качественный анализ рисков заключается в расстановке рангов для
выявленных рисков. При определении вероятности и влияния делается
допущение, что никаких мероприятий по нивелированию рисков не
производится.
Качественный анализ рисков включает:
Определение вероятности наступления рисков.
Определение тяжести последствий наступления рисков.
Определения ранга риска по матрице «вероятность – последствия».
Определение близости наступления риска.
Оценка качества использованной информации.
Для определения ранга риска используется матрица вероятностей и
последствий на рисунке 7. Ранг риска определяется произведением веса
вероятности и значимости последствий.
55
Рисунок 7. Ранг риска и матрица вероятностей и последствий
Важным аспектом при оценке рисков является точность и
адекватности информации, т.к. ошибки оценки риска также являются риском.
Критерии оценки качества используемой при анализе информации
выглядят следующим образом:
Степень понимания риска.
Доступность и полнота информации о риске.
Надежность, целостность и достоверность источников данных.
Результатом качественного анализа рисков является их подробное
описание, как, например, в таблице 5.
Таблица 5
Пример карточки с описанием риска
Номер: R-101
Категория: Технологический.
Причина: Недостаток
квалифицированных кадров.
Симптомы: Разработчики будут использовать
новую платформу – J2EE.
Последствия: Низкая
производительность разработки
Воздействие: Увеличение сроков и
трудоемкости разработки.
Вероятность: Очень вероятно.
Степень воздействия: Критичная.
Близость: Очень скоро.
Ранг: 6.
Исходные данные: «Содержание проекта», «План обеспечения ресурсами»,
Протоколы совещаний №21 от 01.06.2008, №27 от 25.06.2008.
Результаты качественного анализа необходимы для последующего
количественного анализа рисков и планирования реагирования на риски.