«Проект без рисков – удел неудачников. Риски и выгода всегда ходят рука об руку» (с) Том Демарко, Тимоти Листер.

Руководителю проекта разработки ПО надо уметь делать немногое. Надо лишь уметь управлять рисками. Рисками не уложиться в срок. Рисками сделать не то, что требуется. Рисками перерасходовать проектный бюджет. Всё остальное – производные активности.

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

Таким большим оптимистам можно дальше и не читать. Для остальных продолжу.

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

Оговорюсь сразу, что самый значимый риск в разработке ПО – неадекватный РП. Но сейчас не об этом.

Коллекция Барии Боэма

(с) Barry W. Boehm. «A Spiral Model of Software Development and Enhancement», Computer, May 1988

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. “Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. “Разрыв” в квалификации специалистов разных областей знаний.

Коллекция Демарко и Листера

(с) Том Демарко, Тимоти Листер, «Вальсируя с Медведями. Управление рисками в проектах по разработке программного обеспечения», М., Компания p.m.Office, 2005

1. Изъяны календарного планирования.
2. Текучесть кадров.
3. Раздувание требований.
4. Нарушение спецификаций.
5. Низкая производительность.

Моя коллекция

1. Требования заказчика не полны.
2. Требования подвержены частым изменениям.
3. Отсутствие рабочего взаимодействия с заказчиком.
4. Отсутствие необходимых ресурсов и опыта.
5. Неполнота планирования. Забытые работы.
6. Ошибки в оценках трудоемкости и сроков работ.

И что теперь с этим делать?

Для тех, кто еще не овладел матчастью, попробую объяснить теорию на пальцах

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

• Уклонение от риска (risk avoidance).
• Передача риска (risk transference).
• Снижение рисков (risk mitigation).
• Принятие риска (risk acceptance).

Как это происходит в обыденной жизни. Предположим нам надо доставить очень ценный груз через горный перевал. Мы можем: уклониться от риска обойдя горный хребет; передать риск, наняв вертолетную компанию; снизить последствия риска, вбивая страховочные костыли через каждые пять метров подъема, и, наконец, принять риск и ничего не делать.

О чем следует помнить. Надо понимать, что реагирование на риски — это всегда затраты. Поэтому не стоит планировать мероприятия, направленные на борьбу с риском, стоимость которых превышает убытки от реализации самого риска. И еще, управляя рисками, мы меняем наш план. Поэтому стоит проанализировать вторичные риски, связанные с этими изменениями.

История про вторичные риски из космического прошлого

Двадцать лет назад, когда мы только начинали заниматься проблемой космического мусора, одна из задач, которую пришлось решать, был прогноз столкновения космических осколков с орбитальной станцией «Мир». При очередном расчете оценка вероятности столкновения получилась в раз больше, чем это было до этого. Если раньше всегда было не менее шести лидирующих нулей после запятой, то в полученной оценке их было только четыре. Пошли докладывать начальству. Начальство, резонно, спросило, а может ли реализоваться столь маловероятное событие. Мы резонно ответили, что согласно аксиоматики Колмогорова запросто могут столкнуться.
Первое решение, которое мы обсудили провести штатный подъем орбиты несколько ранее запланированного срока. Но тут мы вспомнили про вторичные риски. Мы просто не успевали еще раз пересчитать прогноз столкновений для новой орбиты. Поэтому тогда впервые был принят подход, направленный на снижение риска, который используется и теперь уже для МКС. Космонавты на время пролета опасного объекта перешли в спускаемый модуль.

Для тех, кто владеет матчастью

Требования заказчика не полны

О каких требованиях обычно забывают. Функциональные: программы установки, настройки, конфигурации, миграция данных, интерфейсы с внешними системами, справочная система. Нефункциональные: производительность, надежность, открытость, масштабируемость, безопасность, портируемость, эргономичность. Заказчик, как правило, предполагает, наличие подобных требований по умолчанию. Поэтому разумно, не дожидаться приемо-сдаточных испытаний и обсудить с заказчиком все эти требования на этапе подготовки контракта.

Требования подвержены частым изменениям

Методы реагирования: переоценка проекта каждый раз, когда требования добавляются; итерационная разработка; контракт на основе «Time&Materials»; учет (резервирование) в оценках трудоемкости и сроков возможности роста требований, например, на 50%.

Отсутствие рабочего взаимодействия с заказчиком

Что делаем: устанавливаем доверительные отношения с заказчиком, непрерывно с ним взаимодействуем, прототипируем и согласовываем пользовательские интерфейы, периодически ставим тестовые версии конечным пользователям.

Отсутствие необходимых ресурсов и опыта

Как можно бороться: привлечь экспертов-консультантов на начальных этапах, учесть в оценках обучение сотрудников, уменьшить потери от текучести кадров, привлекая избыточное число участников, учесть в оценках «время разгона» для новых сотрудников.

Неполнота планирования. Забытые работы

Работы в вашем проекте: обучение, координация, уточнение требований, управление конфигурациями, поддержка автосборки, разработка автотестов, создание тестовых данных, обработка запросов на изменения. Проходим по списку и работы, которые нужны в проекте, оцениваем и включаем в план. Другие, как правило, более оприоритетные работы, на которые будут тратить время участники: сопровождение действующих систем, повышение квалификации, участие в пресейлах, административная работа, отпуска, праздники, больничные. Боремся, планируя загрузку бойцов в проекте на 60-80%.

Ошибки в оценках трудоемкостей и сроков работ

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

ЗЫ.

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

Успехов!

Автор: craft_brother

Источник