понедельник, 27 января 2014 г.

Риски при разработке программного обеспечения

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

Риски, условно можно разделить на:
1. Бизнес риски.
2. Социальные риски.
3. Технические риски.
4. Риски связанные со стоимостью и сроками.
Итак по порядку.
Бизнес риски - это риски возникающие в связи с тем, что бизнес может не знать чего он хочет. Т.е. вы разрабатываете систему, а бизнес не получает от ее внедрения тот профит на который рассчитывал. Или, в  случае положительного риска, может оказаться, что решая основную проблему, вы решили и дополнительные проблемы, которые позволяю бизнесу выполнять свою функцию более эффективно.
Социальные риски - это те риски, которые связаны с командой разработки и возможно с заинтересованными лицами. Например, у вас уходит ведущий разработчик, или, один из заинтересованных лиц, ходит к бизнес-заказчику и нудит что все плохо, что делают не то что надо и т.д. С другой стороны, к вам в команду может прийти великолепный разработчик или вы получите поддержку со стороны заинтересованного лица, на которую не могли рассчитывать.
Технические риски - это все те риски которые связаны с применяемыми технологиями, инструментами, каналами связи, серверами и т.д. Незнакомая технология в проекте - это риск негативный, но и доставшийся от другой команды тестовый сервер, повышающий скорость тестирования - может оказаться позитивным риском.
Риски связанные со стоимостью и сроками - все предыдущие риски тоже в той или иной степени влияют на сроки и стоимость проекта, но есть еще ряд рисков, которые нельзя отнести к предыдущим группам. В основном это риски определяющие, сможем ли мы поставить продукт в разумные сроки, за разумные деньги. К таким рискам относится и изменение политической обстановки в стране и срыв сроков субподрядчиками, и т.д.

Самое главное, что нужно не забывать при оценке рисков и, главное, при работе над ними, это то, что риск - это неопределенность. Или, иными словами, отсутствие знания. Повышая знания о том или ином аспекте, мы уменьшаем неопределенность и риск становится либо менее вероятен, либо неизбежен. Вся работа с рисками состоит из двух частей:
1. Уменьшить вероятность негативных рисков и увеличить вероятность позитивных рисков.
2. Нивелировать последствия негативных рисков и максимально эффективно использовать позитивные риски.
Но об оценке рисков и работе с ними, как-нибудь в другой раз.

Ссылки:
Картинка взята здесь - http://infobank.by/691/default.aspx, там про бизнес-риски, но если кому интересно, то почему нет...

2 комментария:

  1. Я бы хотела добавить именно об управлении данных рисков. Самая лучшая практика - это управление рисками по шагам: 1) Определить возможные риски; выявить, что может пойти не так 2) Сделать анализ - оценить вероятность того, что может произойти и его влияние; что нужно будет делать, если это действительно произойдет 3) Определить степень влияния и возможность возникновения; влияние может быть незначительным, допустимым, критическим, и катастрофическим; возможность – маловероятная, вероятная (высокая вероятность). 4) Разработать план на случай непредвиденных обстоятельств, чтобы управлять этими рисками, имеющие высокую вероятность и высокое влияние

    С уважением,
    Intechcore

    ОтветитьУдалить
  2. Не могли бы Вы, как-нибудь в одном из постов привести описание конкретного кейса из вашей практики по оценке технологического риска. Очень интересная тема. Особенно, если есть такие примеры для корпоративных приложений, функционал которых связан с ERP или документооборотом.

    ОтветитьУдалить