Анализ эффективности применения механизмов управления ресурсными рисками проектов разработки по

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

Исследование сотрудников Гарвардской школы бизнеса выявило, что организации, уже добившиеся успеха, с гораздо большей вероятностью достигнут его и в новых проектах (шансы на успех составляют 34 %). В то время как организации, чьи первые начинания потерпели неудачу, имеют практически ту же вероятность последующего успеха, что и организации, только вышедшие на рынок, – только 23 % [5].

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

Рассмотрим подход гибкой методологии разработки ПО «Agile» [ Ошибка! Неизвестный аргумент ключа. ]:

• 1.    Итеративность.

• 2.   Инкрементальность: получение в конце каждой итерации

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

Принцип разработки программного продукта по гибкой методологии «Agile»:

• 1.    Резерв проекта (беклог проекта). Анализ требований заказчика, исходя из резерва проекта.

• 2.    Резерв спринта (беклог). Составление списка работ по резерву проекта.

• 3.    Расстановка приоритета работ: что будет реализовано из беклога в следующей итерации.

• 4.    Команда разработчиков составляет список задач на две-четыре недели (беклог итерации).

• 5.   Демонстрация проделанной работы заказчику.

• 6.    Начало новой итерации (переход к шагу 3).

Схематичное представление принципа разработки программного продукта по Agile представлено на рисунке 6.

Преимущества модели команды по Agile [ Ошибка! Неизвестный аргумент ключа. ]:

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

• 2.    Сравнительно легкая масштабируемость. Каждый элемент в схеме команды может быть в свою очередь циклом. В отличие от альтернативной методологии разработки — «Каскадная модель», когда заказчик получает через заранее определенный срок, к примеру, через год строго то, что изначально запланировали в проекте, в Аgile изменения можно вносить по мере необходимости в процессе разработки.

• 3.    Сильная положительная мотивация труда и равновысокая заинтересованность всех участников в конечном успехе. Самоорганизация позволяет уйти от излишней структуры менеджмента. Методология Agile предполагает наличие только представителя заказчика, который выражает интересы бизнеса. Кроме того, нет необходимости в проверке каждого участника: команда сама распределит задачи и ответственность внутри

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

Рисунок 6– Схематичное представление принципа разработки программного продукта по Agile

Увеличение прозрачности и открытости в проекте позволяет уменьшить воздействия рисков, направленных на качество и ценность продукта. При использовании Agile инструментами, предоставляющими прозрачность и открытость, являются Доска задач (SCRUM) и ежедневные короткие совещания (Стендапы).

Многие проекты страдают регулярным переключением сотрудников между задачами. В Agile команда проекта не берет работы больше, чем может сделать за время итерации (2-4 недели). Ограничение одновременно выполняемых задач приводит к сокращению незавершенной работы — это еще один из принципов минимизации рисков. В этом случае воздействие идет на группу рисков, влияющих на качество и срок проекта.

Создание команды является ключевым аспектом в применении методологии Agile. Для ведения и завершения проекта в команде разработки ПО должны присутствовать следующие роли:

• 1.    Проектировщик/постановщик задач высшей или I категории.

• 2.   Проектировщик II или III категории.

• 3.   Программист БД.

• 4.   Программист интерфейсов.

• 5.    Программист/постановщик задач высшей или I категории.

• 6.   Тестировщик.

Самый первый и самый простой способ определиться с будущими рисками – составить так называемую матрицу ответственности, но измененную под функции, необходимые для реализации проекта. Каждый член команды ставит «+» напротив функции, в которой он разбирается/является специалистом, «*» - сможет овладеть необходимыми навыками при поддержки более компетентных участников команды, либо повышением квалификации, «-» - данная область неизвестна специалисту. Пример матрицы ответственности на основе выше описанных ролей под проектные нужды разработки ПО представлен в таблице 2.

Таблица 2 – Матрица ответственности

	Роли
Функции	1	2	3	4	5	6
MS SQL	*	-	+	*	+	-
MacromediaFlash	-	-	*	+	+	-
HTML5, ASP.NET	-	-	*	*	*	-
3DSMax	-	-	-	+	-	-
Обследование предметной области	+	*	*	-	+	*
Документация	+	+	-	-	-	*
Составление смет	+	*	-	-	*	*
Проверка продукта	+	-	*	-	+	+
Обучение персонала заказчика	+	*	*	*	+	+

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

Таблица 3 – Минимизация ресурсных рисков

№	Ресурсный риск	Минимизация ресурсного риска
1	Декомпозиция спецификации	Должен быть ресурс готовый отвечать на вопросы и осуществлять решения в проектах. Традиционные проекты страдают от декомпозиции спецификации, когда никто не исполняет такую роль, и появляются конфликтующие предположения и решения. Проекты должны обладать некой ролью владельца проекта в составе команды для обеспечения своевременного принятия решений.
2	Уровень сотрудничества	Проведение итераций: -    совещания (2 раза в день), где оговариваются результаты о пройденной работе, текущей работе и планируемой; -    встречи с заказчиком и уточнение вопросов по ходу реализации ПО; -    документирование хода работы и ее результатов; -    демонстрация функционала и выявление приоритета задач.
3	Низкая продуктивность	Доска задач SCRUM обеспечит менеджеру проекта прозрачность ресурсов: - Информация по текущей задаче (в работе):

№	Ресурсный риск	Минимизация ресурсного риска
		временные рамки решения текущей задачи. -    Общее количество текущих задач (в работе). -    В каких задачах ресурс заинтересован. -    Выполненные задачи. -    Задачи, которые необходимо сделать. Таким образом, менеджер проекта сможет оптимально распределять задачи между ресурсами и использовать их потенциал.
4	Ошибки, присущие расписанию	Периодические совещания и определение на соответствие срокам. Вовлечение команды в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком.
5	Координация работы	В отличие от альтернативной методологии разработки — «Каскадная модель», когда заказчик получает через заранее определенный срок, к примеру, через год строго то, что изначально запланировали в проекте, в Аgile изменения можно вносить по мере необходимости в процессе разработки. Это облегчит весь процесс разработки и сдачи программного продукта
6	Качество ресурсов	Организация собрания и определение основных ролей по проекту.

Для анализа эффективности реализации механизма управления ресурсными рисками воспользуемся инструментом Тома ДеМарко и Тимоти Листера, авторами книги "Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения", Riskology Simulator.

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

Riskology Simulator использует для расчетов моделирование методом Монте-Карло. Программа предлагает установку пяти факторов риска, присутствующих в реестре рисков (см. табл. 2):

• -    изъяны календарного планирования проекта;

• -    текучесть кадров проекта;

• -    раздувание требований к продукту проекта;

• -    нарушение спецификаций продукта;

• -    низкая производительность персонала.

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

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

Таблица 4 – Исходные данные по проекту

Критерий	Значение
Дата начала проекта	01.12
Предполагаемая идеальная дата завершения проекта	08.17
Вероятность возникновения рисков: Наихудшее значение Вероятное значение Наилучшее значение	20% 10% 0%
Вероятность   возникновения   рисков   при   использовании механизмов гибких методологий: Наихудшее значение Вероятное значение Наилучшее значение	10% 5% 0%

В результате моделирования наиболее вероятное завершения проекта в первом квартале 2020 года, при использовании механизмов управления ресурсными рисками гибких методологий – четвертый квартал 2018 года. Результаты моделирования представлены на рисунках 17 и 18

соответственно.

АСУ производства: Моделирование проекта (500

Рисунок 17 – Моделирование вероятной даты завершения проекта

АСУ Производство: Моделирование проекта (500

Рисунок 18 – Моделирование вероятной даты завершения проекта с использованием механизмов управления ресурсными рисками

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