Управление разработкой программного продукта на основе рисков

[@axilirator]

Используйте <habracut />.

[@SVVer]

Интересно, а есть ли примеры, где сами разработчики/менеджеры реальных проектов описывают свой процесс управления рисками? В блогах, например? Они его как-то формализуют или управление рисками происходит на уровне «ощущений и инстинктов»?

[@dovnmr]

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

[@monolithed]

По статистике только 28% программных проектов завершены в срок и в рамках бюджета, 23% разработок отменяются до завершения, и половина проектов превышает бюджет на 50%.

Откуда эти цифры?

[@dovnmr]

Standish Group report за 1995 год. Немного староват, но на моей практике ситуация не сильно изменилась

[@monolithed]

Более свежая статистика:

Standish Group’s 2011 CHAOS Report found that more than
half of software projects conducted between 2002 and 2010 were either described
as challenged or complete failures; just 37 percent were classified as
successful

[@dovnmr]

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

[@dovnmr]

Спасибо! Хотя честно говоря, мне кажется это чересчур пессимистичная оценка

[@gandjustas]

Странно что на 100500 статей, про управление рисками практически нет кейсов, где была бы адекватно заполнена таблица и прослеживалась динамика.

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

Например увеличение сроков реализации функциональных блоков — риск. Такой риск можно оценить и что-то сделать. Его можно нивелировать созданием ранних прототипов и уточнением оценки, или параллельной реализацией альтернативного варианта.

Но есть другой тип неопределенности — новые требования от заказчика после демонстрации системы. Мы заранее не можем ни предугадать вероятность их возникновения, ни объем. Защититься от этого нельзя, нивелировать тоже нельзя. Можно, конечно, заложить буферы в планы, но это не всегда возможно, особенно на долгих проектах.

В итоге чем больше неопределенность проекта, тем сложнее управление рисками и меньше работают методики, описанные в этой статье.

[@VolCh]

На достаточно типовых задачах для разных заказчиков из одной предметной области некоторые изменения в требованиях можно предсказывать чуть ли не на 100%.

[@gandjustas]

Когда у нас все «достаточно типовое», то проектная деятельность превращается в операционную и 90% инструментария УП становится ненужным.

[@dovnmr]

Типовые задачи встречаются довольно редко. Разве что при создании WEB сайтов, да и то для не очень требовательных клиентов. Любая разработка «с нуля», с одной командой, одним заказчиком и в одной сфере все равно будет проходить по разному — окружение меняется, человеческий фактор подводит и пр.

[@dovnmr]

У меня в голове, зреет статья по примеру конкретных рисков. Я думаю сделать вымышленный проект и попытаться на его примере создать модель управления. Надеюсь времени хватит :) Так что, если у кого есть желание участвовать или дать на разработку «учебный проект» — велком.

[@student_ivan]

Много текста в статье. Прямо как на уроке каком-нибудь. Я одно время учился в универе по специальности программная инженерия. Вот там был как раз такой предмет — введение в специальность. Что-то подобное рассказывали, но интереса особо не было никогда к таким вещам. Как будто статья ради статьи. Напишите хотя бы кейсы какие-то, где вы эти самые риски оценивали, сколько на это тратили времени и зачем. И почему не могли делать проект сразу, без оценки рисков.