- вероятность. От 0 до 1.
- импакт - в долларах США или иной валюте проекта. хорошо оценивать в человеко-днях.


У меня на соответствующей папке наклейка: "Planning means replacing cance by error"

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

Кстати, в списке нет сигналов раннего оповещения. Единственное, что стоит продумывать тщательно.

(Ответить) (Thread)

" В плане проекта добавить полгода на пункт "заказчик бегает за чуваками, которые напишут ему коннектор для интеграции с нами". Напечатать этот пунк 48-м кеглем и повесить его на монитор менеджеру проекта со стороны заказчика."

Это прекрасно, говорю как бывший "менеджер проекта со стороны заказчика" :)

(Ответить) (Thread)

Ох, счастливый Вы человек -- с госзаказами не работаете...

(Ответить) (Thread)

работаем. эту песню надо петь отдельно. :)

(Ответить) (Parent) (Thread)

Да...
Эта песня состоит из одних рисков с высокой вероятностью реализации...

И первый из них -- что контракт будет заключен в ноябре (при сроке исполнения -- 15 декабря).

(Ответить) (Parent) (Thread)

это не риск. это - норма. :)

(Ответить) (Parent) (Thread)

Про отсутствие опыта в технологии - в виде "нарвались на глюк" такой риск присутствует всегда и на него запас закладывать надо прямо в план, а не в список рисков. Вот новая библиотека - таки да, можно и в риски (но и в план тоже, в виде выполнения пилотного прототипа и опять же запаса).


* Неготовность ключевых стейкхолдеров работать с исполнителем в течении проекта. А при сдаче они удивляются - шо это вы мне тут принесли?

* Назначение ответственного со стороны заказчика "для галочки". То есть его назначили и он даже с вами работал плотно, но потом выясняется что несмотря на то, что принятие решений (и визирование) делегировали ему, его босс вдруг поимел собственное мнение, в корне меняющее весь проект.

* Сильный "уплыв" требований, сверх заложенного на это резерва в планах. Не потому, что забыли кого-то опросить, а потому что у заказчика поменялось видение бизнеса вообще. Или рыночные обстоятельства. Или голова компанию купили и теперь надо интегрироваться не с той ERP, что у них была, а с той, которую внедряют по всему новому холдингу. Или ещё какая хрень.

* Срыв сроков соподрядчиками, если проект выполняется не в одно рыло. Главный вопрос - что в этом случае будем делать то?

* Весь куст проблем с персоналом - заболел, уволился, запил, забил. Все про него знают, но в официальный список не включают. А зря.

Ну и для большинства рисков стоит прописывать индикаторы.

(Ответить) (Thread)

вот сегодня просили оценить проект.. :)
сделать можно и с точки зрения софта работать будет..
но по факту никогда не внедрится, потому что заказчик придумал потенциальную хрень.

Вот сижу и думаю: браться или нет?
Для заказчика делаем много чего. Но этот проект явно никогда не закончится. Конечно можно подстраховаться и сказать, что я вас предупреждал: но от этого потом никому не легче и смотреть будут косо - валить на реализацию..

(Ответить) (Thread)

вечная проблема. потом не докажешь, что они сами хотели фигню. :(

(Ответить) (Parent) (Thread)

разве нельзя в самом начале спросить Заказчика [вежливо и настойчиво]: "по каким признакам мы(вы) узнАем(те), что достигли цели?" [и, пока он не опомнился, зафиксировать ответ]??

(Ответить) (Parent) (Thread)

Мы используем более расширенный состав аттрибутов риска. Буду иллюстрировать на примере риска "падение кирпича на голову при прогулке по стройке".

* Величина риска = вероятность * ущерб
* Меры по снижению вероятности (не ходить по стройке)
* Цена мер (не найдешь клевых электродов и гаек)
* Меры по снижению ущерба (одеть каску, заранее вызвать скорую)
* Цена мер (цена каски + падение репутации среди пацанов)
* Условие срабатывания (Ощущение удара или его наблюдение очевидцами)
* Меры в случае наступления события (первая помощь, вызвать скорую)
* Цена мер (...)
* Меры по изменению владельца риска (отправить на стройку кого-то еще)
* Цена мер (придется часть гаек отдать согласившейся малышне)
* Стратегия (принять риск, или заниматься снижением, смотря что дешевле)
* Владелец риска (тот, на ком повиснет ущерб или меры по его снижению)
* Мониторинг (однократно, еженедельно, ...)

Такая детализация сильно упрощает принятие решения о том, нужно ли писать устав проекта или нет. Потому что иногда писать дороже, чем принять это как риск.

(Ответить) (Thread)

ну вы вообще технократы)

думаю, диме сейчас полезнее расширение словаря типовых рисков, чем их атрибутики

(Ответить) (Parent) (Thread)

Без этого работа смысла не имеет. Что толку перечня рисков, если большинство из них очень специфичны и за пределами одного проекта вряд ли выстрелят. Например, "недостаток опыта" - это вообще не риск, ибо в общем случае в этом нет проблемной ситуации.

(Ответить) (Parent) (Thread)

Не очень понятно, как у рисков типа первого - оценивать вероятность и Impact, если это риски почти что по определению "может случиться неожиданная херня", как вижно из примеров.

(Ответить) (Thread)

бумага все стерпит

(Ответить) (Parent) (Thread)

Я выше писал. На неожиданную херню, типа "напоролись на проблему на ровном месте" закладывается запас в проект просто по определению. Так называемый резерв менеджера проекта. Это не риск как таковой, как раз потому что его невозможно заранее как то оценивать и ничего невозможно предпринять. Shit happens, в общем.

А вот "первый раз используем библиотеку" - риск вполне оцениваемый, его можно предвидеть и запланировать как действия по уменьшению (сделать прототип), так и в случае наступления (например, использовать другую библиотеку, отказаться от функционала, написать свою библиотеку).

(Ответить) (Parent) (Thread)

Первое в Димином описании - это вообще не риск, ибо не обозначена пролемная ситуация. Если сложно оценить риск, значит он неправильно сформулирован, или это несколько рисков, собраные в один.

(Ответить) (Parent) (Thread)

Можно увидеть пример устава проекта?

(Ответить) (Thread)

Из тех наших рисков, которые могут быть интересны тебе:
- неконтролируемое увеличение масштаба проекта на этапе анализа требований;
- неконтролируемое увеличение масштаба проекта на этапе приемки из-за того, что результат действия Исполнителя оказывается не тем, что ожидает Заказчик (причем есть его подриски: пользователи не поняли требования, не выявлены все ключевые лица и пр);
- сдвиг сроков из-за долгого согласования документов Заказчиком / генеральным подрядчиком;
- не принимают проект из-за смены ключевых лиц проекта (это мой любимый :))

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

Я с недавнего времени это в обязательном порядке от наших PM требую.
Потому что потом при начале проекта PM смотрит на реестр и начинает понимать план своего проекта :)

(Ответить) (Thread)

User spacediver referenced to your post from Риски saying: [...] Дум-дум. Оригинал взят у в Риски [...]

(Ответить) (Thread)

Про красный флаг -- это бальзам :)

Оценка рисков хороша уже тем, что стимулирует упорядочивание мыслей.

btw вот последние четые элемента я бы отнёс к риску "Заказчик не владеет собственными бизнес-процессами". Что, вообще-то не риск, а реальность данная нам в ощущениях. Что, кстати, приводит оценку рисков к уровню автономности "электробритва в каменном веке" и непрерывной необходимости оценивать несравнимое.

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

(Ответить) (Thread)

omnipresent = вездесущий

(Ответить) (Thread)

«Отсутствие опыта у заказчика в реализации такого рода проектов» — этот риск существует только на стадии продажи, если он существует уже после инициации проекта, то непонятно, нафига вы в проект вписывались.

Вообще имхо полезнее в качестве риска именовать событие, однозначно влекущее негативные последствия, например, «отказ заказчика принимать проект по причине несоответствия его ожиданиям», а не «учёт требований не от всех стейкхолдеров» — само по себе последняя ситуация не является проблемой. Стейкхолдеров по определению тысячи, важны ключевые, причём т.к. это работа с неопределённостью, никогда нельзя знать наверняка, что теперь учтены все ключевые стейкхолдеры.

Накидаю ещё россыпью:

Изменение законодательства, влекущее за собой необходимость изменения требований и сроков (более 10%)
Действия конкурентов заказчика, влекущие обесценивание результатов проекта
Смена одного из ключевых ЗЛ заказчика
Смена руководителя проекта со стороны заказчика
Отсутствие у заказчика реальной заинтересованности в результате проекта

(Ответить) (Thread)