?

Log in

No account? Create an account
Риски - dz

> Свежие записи
> Архив
> Друзья
> Личная информация
> DZ Online

Октябрь 14, 2011


Previous Entry Поделиться Next Entry
02:48 pm - Риски
Риски. Все знают, что с ними как-то надо работать. Очень не все работают.

Для каждого риска, как вы знаете, должны быть сформулированы:

- вероятность. От 0 до 1.
- импакт - в долларах США или иной валюте проекта. хорошо оценивать в человеко-днях. Смысл: на сколько мы влетим, если ЭТО реально случится.
- предупреждающие действия: что мы сделаем ДО того, чтобы снизить вероятность (и сколько эти действия стоят, и насколько упадёт вероятность)
- исправляющее действие - что мы сделаем для решения проблемы, если ЭТО, паче чаяния, случилось.

Я попытаюсь сделать сводку видов рисков, которые встречаются в заказной разработке ПО достаточно часто. You're welcome to add, да и про эти если есть что сказать - не таите. :)
  • Отсутствие опыта в технологии
На удивление частый и недооцененный риск. Реально это не обязательно "клиенту нужно на питоне, а мы на нём ни разу не писали - но хрен с ним, разберёмся" - это уж совсем крайний случай. Реально это бывает куда в более банальном виде. Проект на яве, мы всю жизнь писали на яве, но ни разу не делали на яве генерацию вордовских документов. Взали библиотеку, вставили, но - она глючит, и ловля глюка (даже если есть исходники) - три дня. А запланировано - один день (подключить либу, отдать данные, получить файл - чего там морочиться-то?) - налицо превышение сроков в три раза.

Да что там - в моём опыте был случай, когда виноуз-разработчики с многолетним стажем нарвались на то, что чуть-чуть нетривиальное использование контрола привело к войне на полмесяца - ну, оказалось, именно этот вариант разработчики ос виндоуз не тестировали. Глючит он безбожно. (давно было, деталей не помню)

Вообще этот риск напоминает старый анекдот - "вы, когда в Советский Союз въезжали, красный флаг на границе видели?" - настолько он омнипрезент, не побоюсь этого (несуществующего?) слова... :)
  • Отсутствие у заказчика опыта в реализации таких (любых?) проектов.
Второе место в моём личном хит-параде - и первое по импакту. Если учесть, что таковых - большинство, то это просто беда. Ну да - мы про неё много говорили. Предупреждающие работы по этому риску потенциально очень объёмны и малополезны. Тем не менее - ощутимо помогает: устав проекта с зонами ответственности, управление изменениями, выделение компактного ядра проекта, итеративность работы и постоянный мониторинг за клиента его целей и движения к ним. Важно иметь чёткие критерии успеха - причём для всех этапов реализации, и явно проговаривать их достижение.
  • Неполнота данных для интеграции
"А ещё это всё надо интегрировать с одинэсом" - ужасно люблю эту фразу. Впрочем, это ещё ладно - действительно, есть типичные сценарии (хотя знаю я проекты, в которых интеграция с 1с - это забрать из одинэса список сотрудников, а вовсе не то, что вы подумали). Интеграция - часто - означает, что у клиента есть какая-то хрень, от которой потеряли исходники, и которая живёт только в силу того, что сисадмин знает, что именно надо удалять из базы раз в три дня, чтобы оно не сдохло. Важно: прописать юзкейзы по интеграции и получить письменный ответ на вопрос, кто делает ответную часть. В плане проекта добавить полгода на пункт "заказчик бегает за чуваками, которые напишут ему коннектор для интеграции с нами". Напечатать этот пунк 48-м кеглем и повесить его на монитор менеджеру проекта со стороны заказчика.
  • Недостаточное понимание заказчиком итогов проекта
Устав проекта - ваш друг. Но: устав не поможет вам донести до заказчика, что создание софтверной части проекта - это не весь проект. Что внедрение неизбежно и оно не будет простым. Что после окончания разработки софта он уже будет знать о проекте СИЛЬНО больше, чем на момент запуска разработки, и что это знание покажет ему, что изначальные посылы были не вполне верны и что проект надо дорабатывать. И что так бывает всегда.
  • Учёт требований не от всех стейкхолдеров.
Тут есть две типичные ветви - забыли того, кто в итоге платит (и он подключился на сдаче, сказал "всё херня, переделывайте" и отказался платить), и забыли тётю Машу в углу, которая никто, но которая каждую пятницу корректирует данные, которые вы внесли в бизнес-процесс как некорректируемые. Вписывает личные комиссии агентов, о которых дядя Петя лично же и договаривается. И всё это выясняется на введении в эксплуатацию.

--- на сём поставим это на паузу --





(23 комментария | Оставить комментарий)

Comments:


[User Picture]
From:vit_r
Date:Октябрь 14, 2011 11:08 am
(Link)
- вероятность. От 0 до 1.
- импакт - в долларах США или иной валюте проекта. хорошо оценивать в человеко-днях.


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

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

Кстати, в списке нет сигналов раннего оповещения. Единственное, что стоит продумывать тщательно.
From:mad_god
Date:Октябрь 14, 2011 11:33 am
(Link)
" В плане проекта добавить полгода на пункт "заказчик бегает за чуваками, которые напишут ему коннектор для интеграции с нами". Напечатать этот пунк 48-м кеглем и повесить его на монитор менеджеру проекта со стороны заказчика."

Это прекрасно, говорю как бывший "менеджер проекта со стороны заказчика" :)
[User Picture]
From:pascendi
Date:Октябрь 14, 2011 11:40 am
(Link)
Ох, счастливый Вы человек -- с госзаказами не работаете...
[User Picture]
From:dz
Date:Октябрь 14, 2011 11:45 am
(Link)
работаем. эту песню надо петь отдельно. :)
[User Picture]
From:pascendi
Date:Октябрь 14, 2011 11:49 am
(Link)
Да...
Эта песня состоит из одних рисков с высокой вероятностью реализации...

И первый из них -- что контракт будет заключен в ноябре (при сроке исполнения -- 15 декабря).
[User Picture]
From:dz
Date:Октябрь 14, 2011 12:37 pm
(Link)
это не риск. это - норма. :)
[User Picture]
From:step_e
Date:Октябрь 14, 2011 12:51 pm
(Link)
Про отсутствие опыта в технологии - в виде "нарвались на глюк" такой риск присутствует всегда и на него запас закладывать надо прямо в план, а не в список рисков. Вот новая библиотека - таки да, можно и в риски (но и в план тоже, в виде выполнения пилотного прототипа и опять же запаса).


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

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

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

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

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

Ну и для большинства рисков стоит прописывать индикаторы.
[User Picture]
From:vovkodav
Date:Октябрь 14, 2011 01:31 pm
(Link)
вот сегодня просили оценить проект.. :)
сделать можно и с точки зрения софта работать будет..
но по факту никогда не внедрится, потому что заказчик придумал потенциальную хрень.

Вот сижу и думаю: браться или нет?
Для заказчика делаем много чего. Но этот проект явно никогда не закончится. Конечно можно подстраховаться и сказать, что я вас предупреждал: но от этого потом никому не легче и смотреть будут косо - валить на реализацию..
[User Picture]
From:dz
Date:Октябрь 14, 2011 01:38 pm
(Link)
вечная проблема. потом не докажешь, что они сами хотели фигню. :(
[User Picture]
From:veresk69
Date:Октябрь 14, 2011 11:45 pm

а зачему нужно потом доказывать?

(Link)
разве нельзя в самом начале спросить Заказчика [вежливо и настойчиво]: "по каким признакам мы(вы) узнАем(те), что достигли цели?" [и, пока он не опомнился, зафиксировать ответ]??
[User Picture]
From:d_zh
Date:Октябрь 14, 2011 02:17 pm

В песочницу пришел дядя-экскаваторщик

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

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

Такая детализация сильно упрощает принятие решения о том, нужно ли писать устав проекта или нет. Потому что иногда писать дороже, чем принять это как риск.
[User Picture]
From:beskov
Date:Октябрь 15, 2011 03:56 pm
(Link)
ну вы вообще технократы)

думаю, диме сейчас полезнее расширение словаря типовых рисков, чем их атрибутики
[User Picture]
From:d_zh
Date:Октябрь 15, 2011 06:57 pm
(Link)
Без этого работа смысла не имеет. Что толку перечня рисков, если большинство из них очень специфичны и за пределами одного проекта вряд ли выстрелят. Например, "недостаток опыта" - это вообще не риск, ибо в общем случае в этом нет проблемной ситуации.
[User Picture]
From:cavaler
Date:Октябрь 14, 2011 03:15 pm
(Link)
Не очень понятно, как у рисков типа первого - оценивать вероятность и Impact, если это риски почти что по определению "может случиться неожиданная херня", как вижно из примеров.
[User Picture]
From:freedom_of_sea
Date:Октябрь 14, 2011 04:23 pm

+1

(Link)
бумага все стерпит
[User Picture]
From:step_e
Date:Октябрь 14, 2011 05:20 pm
(Link)
Я выше писал. На неожиданную херню, типа "напоролись на проблему на ровном месте" закладывается запас в проект просто по определению. Так называемый резерв менеджера проекта. Это не риск как таковой, как раз потому что его невозможно заранее как то оценивать и ничего невозможно предпринять. Shit happens, в общем.

А вот "первый раз используем библиотеку" - риск вполне оцениваемый, его можно предвидеть и запланировать как действия по уменьшению (сделать прототип), так и в случае наступления (например, использовать другую библиотеку, отказаться от функционала, написать свою библиотеку).
[User Picture]
From:d_zh
Date:Октябрь 15, 2011 06:54 pm
(Link)
Первое в Димином описании - это вообще не риск, ибо не обозначена пролемная ситуация. Если сложно оценить риск, значит он неправильно сформулирован, или это несколько рисков, собраные в один.
[User Picture]
From:egorfine
Date:Октябрь 14, 2011 07:23 pm
(Link)
Можно увидеть пример устава проекта?
[User Picture]
From:kholodova
Date:Октябрь 14, 2011 09:06 pm
(Link)
Из тех наших рисков, которые могут быть интересны тебе:
- неконтролируемое увеличение масштаба проекта на этапе анализа требований;
- неконтролируемое увеличение масштаба проекта на этапе приемки из-за того, что результат действия Исполнителя оказывается не тем, что ожидает Заказчик (причем есть его подриски: пользователи не поняли требования, не выявлены все ключевые лица и пр);
- сдвиг сроков из-за долгого согласования документов Заказчиком / генеральным подрядчиком;
- не принимают проект из-за смены ключевых лиц проекта (это мой любимый :))

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

Я с недавнего времени это в обязательном порядке от наших PM требую.
Потому что потом при начале проекта PM смотрит на реестр и начинает понимать план своего проекта :)
[User Picture]
From:pingback_bot
Date:Октябрь 15, 2011 09:36 am

Риски

(Link)
User spacediver referenced to your post from Риски saying: [...] Дум-дум. Оригинал взят у в Риски [...]
From:bowhill
Date:Октябрь 15, 2011 12:27 pm
(Link)
Про красный флаг -- это бальзам :)

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

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

Ну да это я лирически отвлёкся, а предложить я хотел категорию рисков эксплуатации. Предмет кажется наименее интересный разработчику и весьма интересный заказчику. :)
[User Picture]
From:beskov
Date:Октябрь 15, 2011 03:53 pm
(Link)
omnipresent = вездесущий
[User Picture]
From:beskov
Date:Октябрь 15, 2011 04:08 pm
(Link)
«Отсутствие опыта у заказчика в реализации такого рода проектов» — этот риск существует только на стадии продажи, если он существует уже после инициации проекта, то непонятно, нафига вы в проект вписывались.

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

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

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

> Go to Top
LiveJournal.com