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

1. Software Project Management
Conference
Проект без рисков – удел
неудачников! Главные причины
провалов проектов
С. Архипенков
Казань
6 декабря 2013

2. Определение ()
• Риск - неопределенное событие или
условие, наступление которого
отрицательно или положительно
сказывается на целях проекта.
• Риск это проблема, которая еще не
возникла, а проблема – это риск,
который материализовался.
• Риск характеризуется вероятностью
наступления и последствиями
воздействия на проект. Пример
Майка Ньюэлла.
{
{
2

3. Категории рисков ()
{ • Известные неизвестные
• Неизвестные неизвестные
{
3

4. Список Б.Боэма ()










Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
“Золотая сервировка”, перфекционизм, ненужная
оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах,
определяющих окружение системы или вовлеченных в
интеграцию.
Недостатки в работах, выполняемых внешними (по
отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
“Разрыв” в квалификации специалистов разных областей
знаний.
{
{
4

5. Список Демарко и Листера ()
Изъяны календарного планирования
Текучесть кадров
Раздувание требований
Нарушение спецификаций
Низкая производительность
{
{ 




5

6. Мой список ()
{  Требования заказчика отсутствуют / не



{

полны / подвержены частым
изменениям.
Отсутствие рабочего взаимодействия с
заказчиком.
Отсутствие необходимых ресурсов и
опыта.
Неполнота планирования. «Забытые
работы».
Ошибки в оценках трудоемкостей и
сроков работ.
6

7. Методы реагирования ()
{ • Уклонение от риска (Risk Avoidance).
• Передача риска (Risk Transference).
• Снижение рисков (Risk Mitigation).
• Принятие риска (Risk Acceptance).
Важно помнить о вторичных рисках
(Secondary Risks), которые возникают
в результате применения
реагирования на риски.
{
7

8. Неполнота требований ()
{ Функциональные:
•Программы установки, настройки,
конфигурации.
•Миграция данных.
•Интерфейсы с внешними системами.
•Справочная система.
Нефункциональные:
•Производительность.
•Надежность.
•Открытость.
•Масштабируемость.
•Безопасность.
•Портируемость.
•Эргономичность.
{
8

9. Изменения требований ()
{ Способы реагирования:
• Переоценка проекта каждый раз,
когда требования добавляются /
изменяются (уклонение).
• Итерационная разработка. Контракт
на основе «Time&Materials»
(передача риска Заказчику).
• Учет (резервирование) в оценках
трудоемкости и сроков возможности
роста требований, например, на 50%
(резервирование риска).
{
9

10. Отсутствие ресурсов и опыта ()
{ Способы реагирования:
• Привлечь экспертовконсультантов на начальных
этапах.
• Учитывать в оценках обучение
сотрудников.
• Уменьшать потери от текучести
кадров, привлекая избыточное
число участников.
• Учесть в оценках «время
разгона» для новых
сотрудников.
{
10

11. Взаимодействия с заказчиком ()
{ Способы реагирования (снижение):
• Открытость, установление
доверительных отношений.
• Непрерывное взаимодействие.
• Прототипирование и
согласование пользовательских
интерфейсов.
• Периодические поставки
тестовых версий конечным
пользователям.
{
11

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

13. Раннее разрешение рисков ()
• Реализуйте в
первую очередь
80% разработки
важные
обусловлена
требования.
Риски
Важность
20% требований.
80%
• Реализуйте в
потребления
первую очередь
ресурсов (время
архитектурнои память)
значимые
приходится на
требования.
20%
компонентов.
{
{
13

14. Software Project Management
Conference
Спасибо за внимание!
14