Более 85% опрашиваемых российских организаций, занимающиеся разработкой программных продуктов, учитывают ресурсные риски при разработке проекта [4]. Несмотря на это, больше половины проектов по разработке программного продукта завершаются провалом. Связанно это с отсутствием опыта управления ресурсными рисками. Ниже приведены цифры, свидетельствующие об актуальности проблемы: [7]:
- компании, у которых высокая зрелость, завершают 73% проектов в срок и 69% проектов в рамках запланированного бюджета, и лишь 10% закрываются до завершения;
- компании, у которых средняя зрелость, завершают уже 56% проектов в срок и 58% в рамках бюджета, а 11% проектов закрывается до завершения;
- компании, зрелость которых определена как низкая, завершают уже менее половины проектов в срок – 42%, 44% в рамках бюджета, и 13% заканчиваются до запланированного ранее завершения.
Оценив все ресурсные риски на этапе планирования проекта, можно заранее определить, какие ресурсы понадобятся в случае самых неблагоприятных обстоятельств, какие ресурсы не стоит использовать при реализации и как избежать опасных ситуаций.
Ресурсные риски – это риск, обусловленный недостатками в организации работы [9]. Такие риски связаны с командой разработчиков программного продукта:
- Аналитики.
- Программисты.
- Верстальщики.
- Тестировщики.
Основными причинами ресурсных рисков в проектах по разработке программного продукта являются [9]:
- недостатки координации работ и слабое регулирование основных ресурсов в проекте;
- ошибки в назначении ресурсов проекта на задачи;
- низкая продуктивность ресурсов;
- ошибки, присущие расписанию при планировании проекта;
- качество ресурсов.
Цель анализа ресурсных рисков в проектах по разработке программного продукта заключается в определении ресурсов, увеличивающие вероятность срыва проекта.
Взяв за основу иерархическую структуру проекта по разработке программного продукта (см. табл. 1) и ресурсы проекта (см. табл. 2) выделим ресурсные риски.
Таблица 1 – Иерархическая структура проекта
|
№ п/п |
Задача |
Подзадача |
|
1 |
Постановка задачи |
Предпроектное обследование |
| Подготовка документации (определение требований) | ||
| Согласование документации | ||
|
2 |
Разработка программного продукта |
Проектирование программного продукта |
| Интеграция продукта | ||
|
3 |
Тестирование программного продукта |
Тестирование |
| Исправление ошибок | ||
|
4 |
Внедрение программного продукта |
Установка программного продукта |
| Обучение персонала | ||
|
5 |
Информационная поддержка |
Доработка продукта по результатам эксплуатации |
Таблица 2 – Ресурсный план проекта
|
№ п/п |
Ресурс |
Процент загрузки |
|
1 |
Аналитик 1 |
100% |
|
2 |
Аналитик 2 |
100% |
|
3 |
Аналитик 3 |
100% |
|
4 |
Аналитик 4 |
100% |
|
5 |
Программист 1 |
100% |
|
6 |
Программист 2 |
100% |
|
7 |
Верстальщик 1 |
100% |
|
8 |
Тестировщик 1 |
100% |
|
9 |
Тестировщик 2 |
100% |
|
10 |
Менеджер проекта |
100% |
|
11 |
Куратор проекта |
100% |
Для выявления ресурсных рисков в проекте принято использовать следующие стандарты:
- PMBOK.
- FERMA.
- PRINCE2.
- Microsoft Solutions Framework (MSF).
- Oracle Application Implementation Method (AIM).
В результате анализа стандартов, нами был взят за основу стандарт «PMBOK», т.к. он стандарт, во-первых, унифицированный для всех стран, во-вторых, отображает специфику проекта, в-третьих, ориентирован на процесс и определяет для него все ресурсы, инструменты и результаты.
1 этап. Идентификация рисков
Взяв за основу иерархическую структуру проекта, причины ресурсных рисков и ресурсы проекта, составим реестр ресурсных рисков по разработке программного продукта (см. табл. 3).
Таблица 3 – Реестр ресурсных рисков проекта
|
№ п/п |
Ресурсный риск |
Описание |
|
1 |
Декомпозиция спецификации |
При старте процесса кодирования и интеграции становится ясно, что спецификация неполная и содержит конфликтные требования. |
|
2 |
Низкая продуктивность |
1. Ключевые сотрудники могут покинуть проект, унося при этом с собой критическую информацию, особенно если это связанно с разработкой программного продукта. В основном главный программист является координатором работы и не делиться с группой своими идеями, наработками и прогрессом. 2. Заказчик не имеет полного представления о желаемых возможностях программного продукта. |
|
3 |
Уровень сотрудничества |
Низкая продуктивность является следствием низкого уровня сотрудничества. Из этого вытекают следующие проблемы: - ресурс не владеет спецификацией разработки программного продукта. - ресурс не реализует уникальные навыки. |
|
4 |
Ошибки, присущие расписанию |
Благодаря своей неощутимой природе и уникальности программного продукта, процесс разработки ПО сложно оценить и расписать. |
|
5 |
Координация работы |
Программный продукт сдается заказчику по окончанию сроков разработки. В ходе разработки заказчик не видит и не пробует функционал программного продукта. |
|
6 |
Качество ресурсов |
Управление процессом разработки может лечь на плечи людей, основная специальность которых не связана напрямую с такой деятельностью – программистов, инженеров других специальностей или менеджеров, не знакомых со спецификой разработки программного продукта. |
2 этап. Качественный анализ рисков
Расставим приоритеты (вероятность наступления) рисков по 5-бальной шкале (см. табл. 4), в соответствии со спецификой проекта.
3 этап. Количественный анализ рисков
Определим влияние рисков по 5-бальной шкале (см. табл. 4). На основании вероятности наступления и влиянии риска определим уровень риска. Для определения показателей ресурсных рисков нами был рассчитан коэффициент ранговой корреляции Кенделла, где X – вероятность наступления ресурсного риска, Y – влияние ресурсного риска.
Результаты расчета:
- коэффициент корреляции Кенделла τ = 0,2;
- критическая точка Tkp = 0,8.
τ < Tkp – нулевая гипотеза; ранговая корреляционная связь между признаками ресурсных рисков незначимая. Можно сделать следующие выводы:
- Объект Y не зависит от объекта X. Рост вероятности наступления ресурсного риска никак не отразится на его влиянии (последствие проявления).
- Объект X не зависит от объекта Y. Рост увеличения влияния (последствие проявления) ресурсного риска никак не отразится на его вероятности наступления.
Таблица 4 – Результаты качественного и количественного анализа рисков
|
№ |
Ресурсный риск |
Вероятность наступления (1-5) (X) |
Влияние риска (1-5) (Y) |
Уровень риска |
|
1 |
Декомпозиция спецификации |
3 |
5 |
высокий |
|
2 |
Низкая продуктивность |
5 |
3 |
средний |
|
3 |
Уровень сотрудничества |
1 |
5 |
средний |
|
4 |
Ошибки, присущие расписанию |
3 |
5 |
средний |
|
5 |
Координация работы |
2 |
5 |
высокий |
|
6 |
Качество ресурсов |
1 |
4 |
высокий |
4 этап. Планирование реагирования на риски
Для минимизации ресурсных рисков по проекту выделим основные технологии и методы минимизации ресурсных рисков:
- Модель «SW-CMM».
- Рациональный унифицированный процесс разработки программного продукта (RUP).
- Гибкая методология разработки программных продуктов «Agile».
- Доска задач «SCRUM».
- Опросные листы.
Для минимизации ресурсных рисков по проекту разработки программного продукта мы предлагаем использовать следующую комбинацию методов и технологий:
- Гибкая технология разработки программных продуктов «Agile».
- Доска задач SCRUM.
Суть «Agile» состоит в получении оперативной обратной связи и как следствие — быстрой реакции на изменения в проекте (приоритетах, списке работ, в новых идеях заказчика).
«SCRUM» позволяет выявить текущую занятость ресурсов в проектах.
Минимизация ресурсных рисков по проекту разработке программного продукта
Во-первых, расставим приоритеты между задачами на этапе планирования проекта (см. табл. 5). Результат приоритезации – фокусирование на самых важных задачах проекта. Стоит отметить, что приоретизация задач будет меняться в результате начала проекта и работы с заказчиком.
Таблица 5 – Приоритеты задач проекта в соответствии с «Agile»
|
№ п/п |
Задача |
Приоритет |
| 1 | Постановка задачи |
1 |
| 1.1 | Предпроектное обследование |
1.1 |
| 1.2 | Подготовка документации (определение требований) | |
| 1.3 | Согласование документации |
1.2 |
| 2 | Разработка программного продукта |
2 |
| 2.1 | Проектирование программного продукта |
2.1 |
| 2.2 | Интеграция продукта |
2.1 |
| 3 | Тестирование программного продукта |
3 |
| 4.1 | Тестирование |
3.2 |
| 4.2 | Исправление ошибок |
3.1 |
| 4 | Внедрение программного продукта |
4 |
| 3.1 | Установка программного продукта |
4.2 |
| 3.2 | Обучение персонала |
4.1 |
| 5 | Информационная поддержка |
5 |
| 5.1 | Доработка продукта по результатам эксплуатации |
5.1 |
Во-вторых, избавимся от многозадачности ресурсов. Для выявления текущей загрузки ресурсов предлагаем использовать доску задач «SCRUM». На доске ресурс проекта должен ежедневно отмечать следующую информацию:
- Информация по текущей задаче (в работе): название задачи, время решения текущей задачи.
- Общее количество текущих задач (в работе).
- В каких задачах ресурс заинтересован.
- Выполненные задачи.
- Задачи, которые необходимо сделать.
- Предложения по решению текущих задач.
Это позволит увидеть многозадачность ресурса и избежать низкой продуктивности.
В-третьих, обновим план проекта (см. табл. 6) в соответствии с основной концепцией «Agile». Основная концепция «Agile» предполагает промежуточные итерации. Под итерациями, в контексте разработки ПО, понимается:
- Совещания с рабочей группой (рабочая группа по «Agile» выделяется на один проект и не претерпевает изменений в составе до окончания проекта).
- Совещания с заказчиком.
- Обсуждение открытых вопросов по проекту.
- Демонстрация функционала.
Таблица 6 – Перечень задач в соответствии с «Agile»
|
№ п/п |
Задача |
| 1 | Постановка задачи |
| 1.1 | Предпроектное обследование |
| 1.2 | Подготовка документации (определение требований) |
| 1.3 | Совещание: 2 раза/день |
| 1.4 | Согласование документации |
| 2 | Разработка программного продукта |
| 2.1 | Проектирование программного продукта |
| 2.2 | Циклическая задача: совещания, обсуждение открытых вопросов, общение с заказчиком, демонстрация функционала |
| 2.3 | Внесение изменений по результатам общения с заказчиком |
| 2.4 | Координация работ |
| 2.5 | Интеграция продукта |
| 3 | Тестирование программного продукта |
| 3.1 | Тестирование |
| 3.2 | Совещание: 2 раза/день |
| 3.3 | Исправление ошибок |
| 4 | Внедрение программного продукта |
| 4.1 | Установка программного продукта |
| 4.2 | Совещание: 2 раза/день |
| 4.3 | Обучение персонала |
| 5 | Информационная поддержка |
| 5.1 | Доработка продукта по результатам эксплуатации |
| 5.2 | Циклическая задача: совещания, обсуждение открытых вопросов, общение с заказчиком, демонстрация функционала |
В результате применения «Agile» и «SCRUM» можно минимизировать ресурсные риски. В таблице 7 представлены основные воздействия на ресурсные риски.
Таблица 7 – Минимизация ресурсных рисков
|
№ |
Ресурсный риск |
Минимизация ресурсного риска |
|
1 |
Декомпозиция спецификации |
Должен быть ресурс готовый отвечать на вопросы и осуществлять решения в проектах. Традиционные проекты страдают от декомпозиции спецификации, когда никто не исполняет такую роль, и появляются конфликтующие предположения и решения. Проекты должны обладать некой ролью владельца проекта в составе команды для обеспечения своевременного принятия решений. |
|
2 |
Уровень сотрудничества |
Проведение итераций: - совещания (2 раза в день), где оговариваются результаты о пройденной работе, текущей работе и планируемой; - встречи с заказчиком и уточнение вопросов по ходу реализации ПО; - документирование хода работы и ее результатов; - демонстрация функционала и выявление приоритета задач. |
|
3 |
Низкая продуктивность |
Доска задач SCRUM обеспечит менеджеру проекта прозрачность ресурсов: - Информация по текущей задаче (в работе): временные рамки решения текущей задачи. - Общее количество текущих задач (в работе). - В каких задачах ресурс заинтересован. - Выполненные задачи. - Задачи, которые необходимо сделать. Таким образом, менеджер проекта сможет оптимально распределять задачи между ресурсами и использовать их потенциал. |
|
4 |
Ошибки, присущие расписанию |
Периодические совещания и определение на соответствие срокам. Вовлечение команды в процесс планирования и оценки. Получите отзывы на ранней стадии и обсудите возможные ошибки и нестыковки лично с заказчиком. |
|
5 |
Координация работы |
В отличие от альтернативной методологии разработки — «Каскадная модель», когда заказчик получает через заранее определенный срок, к примеру, через год строго то, что изначально запланировали в проекте, в Аgile изменения можно вносить по мере необходимости в процессе разработки. Это облегчит весь процесс разработки и сдачи программного продукта |
|
6 |
Качество ресурсов |
Организация собрания и определение основных ролей по проекту. |
На основании планов проекта нами были идентифицированы ресурсные риски, имеющие специфику при разработке программного продукта, и создан соответствующий реестр.
Для идентификации ресурсных рисков нами был использован стандарт управления проектами PMBOK:
- На первом этапе мы идентифицировали ресурсные риски и занесли их в реестр.
- На втором этапе мы произвели качественный анализ рисков, по результатам которого проставили каждому риску вероятность наступления по 5-больной шкале.
- На третьем этапе мы произвели количественный анализ рисков, по результатам которого проставили каждому риску величину влияния по 5-больной шкале и уровень. Взяв за основу признаки ресурсных рисков: вероятность наступления ресурсного риска и влияние ресурсного риска, мы выявили зависимость между этими признаками, рассчитав коэффициент ранговой корреляции Кенделла. Зависимости не обнаружилось.
- На заключительном этапе нами был составлен план реагирования на риски. В качестве механизмов минимизации ресурсных рисков нами были взяты:
4.1. Гибка технология разработки программных продуктов Agile.
4.2. Доска задач SCRUM.
В результате мы привели проект в соответствие с механизмами минимизации ресурсных рисков:
- расставили приоритеты между задачами;
- избавились от многозадачности;
- обновили план проекта, добавив итерации.
Применение выбранных механизмов помогут во время отреагировать на ресурсные риски и максимально эффективно реализовать проект в поставленные сроки.
Библиографический список
- Agile – гибкое управление проектами [Электронный ресурс]. – 2014. – Режим доступа: http://wunderkraut.ru/agile-gibkoe-upravlenie-proektami
- FERMA. Стандарт управления рисками.
- ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом».
- Практика управления финансовыми рисками в компаниях нефинансового сектора: Результаты исследования Декабрь 2008 Бейкер Тилли Русаудит // Официальный сайт компании Бейкер Тилли Русаудит. 2012. – 15 с.
- Ресурсные риски [Электронный ресурс]. – 2013. – Режим доступа: http://www.taurion.ru/project/15/4
- Руководство к Своду знаний по управлению проектами Четвертое издание (Руководство PMBOK) Американский национальный стандарт ANSI/PMI 99-001-2004.
- Семинар Московского отделения PMI риски [Электронный ресурс]. – 2011. – Режим доступа: http://www.pmi.org
- Технология разработки программного обеспечения [Электронный ресурс]. – 2013. – Режим доступа: http://tehprog.ru/index.php_page=lecture12.html
- Характеристика рисков в различных сферах предпринимательской деятельности [Электронный ресурс]. – 2013. – Режим доступа: http://bussinesrisk.ru/lektsii-po-upravleniyu-riskom-na-predpriyatii/70-xarakteristika-riskov-v-razlichnyx-sferax.html
- Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения – Спб.: Питер, 2002. – 496 с.: ил.
- Рогов М.А. Риск – менеджмент. М., 2011. С. 15.