Описание:
http://www.systemsguild.com/riskology (Русская версия этой страницы доступна по адресу http://www.pmo.ru/riskology)
Дилемма такова: вам доверяют работу, для вас это — вызов, вопрос престижа… но вам придется поверить в этот график. Это — цена, которую вы платите. Вы, сглотнув с трудом, говорите, что справитесь. Позднее вы укрепляете свою веру. Конечно. А почему бы и не к Рождеству? Другие проекты удавалось ведь выполнить в такие же сжатые сроки, не так ли? Вскоре вы можете почувствовать себя на самом деле уверенным. Время может доказать обратное, но на данный момент вы практически уверены, что сумеете выполнить работу.
1. Компании переводили приложения и базы данных от архитектуры «мейнфрейм с терминалами» к модели «клиент/сервер»[8] .
2. Компании перестраивались, чтобы взаимодействовать непосредственно со своими покупателями и поставщиками новыми, прежде не представимыми способами: через Интернет и с использованием интегрированных сетей снабжения, аукционов и сделок без посредников.
К сожалению, множество компаний
руководителями проектов, в явном виде не управляли имевшимися рисками, мы вели себя по-детски. В этом смысле, вся наша отрасль вела себя по-детски. Наше безрассудное увлечение позитивным мышлением и подходом «будет сделано» зацикливало нас на лучших вариантах развития событий, поскольку мы игнорировали различные факты, которые могли сделать такие варианты невозможными
Рассматривать только благоприятные сценарии и встраивать их в план проекта — настоящее ребячество. И все же мы постоянно так поступаем. И делая эти незрелые вещи, мы уверенно провозглашаем рост нашей зрелости, имея в виду совершенствование профессиональной квалификации.
Риск
1. Возможное в будущем событие, которое приведет к нежелательным результатам.
2. Сам нежелательный результат
Аналогией потери присяжного в IT-проекте будет текучесть персонала, представляющая собой один из главных рисков во всех проектах по разработке программного обеспечения. А профилактической мерой может стать включение в проект с самого начала чуть большего количества исполнителей, чтобы были достаточно квалифицированные дополнительные специалисты, на первых порах выполняющие вспомогательные роли. Когда кто-то из основного состава уходит,
Абстрагируясь от этого конкретного примера, можно выделить пять основных составляющих управления риском:
• идентификация риска: первоначальный мозговой штурм по выявлению риска, последующая сортировка и определение какого-либо механизма для обеспечения постоянного действия данного процесса.
• анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.
• планирование реагирования
на риски: что вы собираетесь делать, если и когда данный риск наступит.
• ослабление риска: меры, которые должны быть приняты предварительно, чтобы обеспечить возможность и эффективность проведения запланированных действий, если они потребуются.
• мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.
1. Требования к системе: Что именно должна делать система?
2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?
3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?
4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвиженияработы над проектом?
5. Управление: Хватит ли у руководства таланта, чтобы создать эффективные команды, поддерживать боевой дух, обеспечивать низкую текучесть кадров и координировать сложные комплексы взаимосвязанных задач?
6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?
7. Политика: Каков может быть результат использования политической силы для навязывания ограничений,
ограничений, несовместимых с успехом проекта?
8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?
9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?
10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего
ограничений, несовместимых с успехом проекта?
8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?
9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?
10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?
Ни один план не выдерживает боевого столкновения с противником
фельдмаршал Гельмут фон Мольтке
хорошим управленцем — нетривиальная задача. Нужны упорный труд, практическая смекалка и, главное, талант. Люди, которым не хватает требующегося таланта, попадают во власть механических подходов, таких, как управление по целям, планирование по Паркинсону и «культура страха», которая запугиванием вынуждает подчиненных действовать. Хотя все эти методы управления не так легко оправдать, некоторые менеджеры и даже целые организации привержены им. Эти методы несовместимы с любой схемой управления рисками.
1. Наши акционеры не являются достаточно зрелыми, чтобы смотреть риску в лицо.
«Если бы мы сказали правду, наши акционеры слишком испугались бы и отказались от проекта, поэтому мы вынуждены им лгать».
2. Уровень неопределенности слишком велик.
«Я готов указать диапазон, в котором будет дата завершения, но не такой большой».
3. Заданный в явном виде диапазон неопределенности оправдывает плохую работу.
«Если я скажу нашим разработчикам, что работу нужно сдать в любой момент между июлем и декабрем, они сразу отправятся спокойно спать».
4. Подход «управление ради успеха» лучше.
«Смотрите, мы не занимаемся управлением рисками, но следим за рисками и делаем все, чтобы они не происходили».
5. Не хватает данных для эффективного управления рисками.
«Мы недостаточно знаем про риски, которые повлияют на этот проект».
6. Опасно управлять рисками в изоляции.
«Я не осмелюсь быть единственным, кто честно осуществляет управление рисками».
Вчерашняя проблема — это сегодняшний риск.
Мы определили четыре возможности, которые вам доступны в отношении риска;
• Вы можете его избежать.
• Вы можете его сдерживать.
• Вы можете его ослабить.
• Вам удастся от него увернуться.
подверженность риску = затраты * вероятность
Что понимают под управлением рисками
Управление рисками, по сути, состоит в осуществлении следующих девяти шагов, включаемых в проект:
1. Использовать процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему проекту.
2. Убедиться, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Провести всю указанную предварительную подготовку по каждому из рисков:
• Дать наименование риску и присвоить ему уникальный номер.
• Провести мозговой штурм для выявления показателей наступления события риска (самых ранних признаков наступления риска).
• Оценить влияние риска на стоимость и расписание проекта.
• Оценить вероятность наступления риска.
• Рассчитать подверженность риску по отношению к графику и бюджету.
• Определить заранее, какие
меры придется принять, если и когда событие риска наступит.
• Определить, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включить действия по ослаблению риска в общий план проекта.
• Выписать все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Указать возможные риски-катастрофы как допущения проекта. Разработать схему делегирования управления каждым из таких рисков
рисков вышестоящему руководству.
5. Сделать первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект.
6. Использовать собственные и отраслевые факторы неопределенности (подробности в главе 13) для построения диаграммы риска с пересечением в точке N.
7. Выразить, используя диаграмму
диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом.
8. Отслеживать все риски на предмет наступления или исчезновения и осуществлять планы на случай непредвиденных обстоятельств всякий раз, когда риски наступают.
9. Поддерживать в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Пропущенные сроки, установленные расписанием, и меняющиеся требования к проекту — это не то, что случается однажды и больше не повторяется.
список этих главных рисков:
1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность
Если вы не предпринимаете серьезных усилий по определению величины программного продукта, то ваши оценки календарного планирования основаны всего лишь на принятии желаемого за действительное: «Ого! Клиент хочет получить это в мае, до мая еще 7 месяцев, поэтому наугад можно поставить в график 7 месяцев». Когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80%.
Итак, проект, по созданию продукта размером в 20000 функциональных точек[23] за два года, должен быть рассчитан на создание примерно 25000 функциональных точек программного обеспечения (20000 фт х (1.00 + 24 месяца х 1 % в месяц)).
причины, которые не дают людям озвучивать риски в любых других компаниях. Это принимает форму неписаных правил, встроенных в корпоративную культуру:
1. Не имей привычки думать о неприятностях.
2. Не поднимай проблему, если у тебя нет готового решения.
3. Не говори, что нечто является проблемой, если не можешь доказать, что это так.
4. Не будь помехой.
5. Не озвучивай проблему, если не хочешь, чтобы на тебя возложили ответственность за ее немедленное решение.
Механизм должен поощрять людей делиться своими страхами.
Этап 1: мозговой штурм по выявлению катастроф
1. Ставьте вопрос в явном виде в терминах ночного кошмара:
2. Используйте хрустальный шар: Представьте, что у вас есть доступ к хрустальному шару или способность узнавать чудом заголовки газет следующего года.
3. Опишите противоположные виды на будущее:
котором нет виновных: Как может проект потерпеть неудачу без того, чтобы это было чьей-то виной?
5. Спрашивайте о провале, в котором есть конкретные виновники:
6. Представьте себе частичную неудачу:
Этап 2: построение сценария
Этап 3: анализ основных причин
• жизненный цикл, развивающийся по спирали
• систему показателей (конкретнее, СОСОМО II)
• управление рисками
• «теорию W» группового взаимодействия
Это — способ руководства IT-проектами в свете тех проблем, которые обычно преследуют каждое такое предприятие.
Возможно, так могли бы решать проблемы управления рисками существа, наделенные даром абсолютного предвидения, но не мы. Когда проекты проваливаются, то часто это происходит примерно на середине, поэтому именно в это период управление рисками нужно проводить особенно активно. Причины проблем почти всегда возникают еще раньше, но их осознание приходит примерно на середине проекта: на начальной стадии проекта дело кажется идущим без помех, а затем все разваливается. Эту стадию проекта можно назвать «Возмездие»: к нам возвращаютсяУправление рисками, начиная с периода Возмездия
Вот наш краткий список мер по управлению рисками, которые нужно осуществлять в период с середины проекта и далее, до самого конца:
1. непрерывный мониторинг показателей наступления рисков в поисках такого риска из списка, который кажется готовым перейти из разряда «всего лишь скверной возможности» в разряд «реальных проблем»
2. продолжение выявления рисков
3. сбор данных для наполнения хранилища рисков (базы данных для определения количественного влияния проблем, наблюдавшихся в прошлом)
4. ежедневное отслеживание показателей завершенности
Инкрементная поставка — это разработка полного или практически полного плана проекта, а затем воплощение этого плана в жизнь подмножествами, где каждое следующее подмножество включает в себя предшествующие. Полная стратегия инкрементной поставки может и должна быть представлена и описана планом инкрементной поставки (см. ниже) еще до создания первого подмножества.
Множество преимуществ инкрементной
инкрементной поставки были отмечены и документированы как нами самими, так и другими авторами (см. ссылки в конце книги). Есть несколько дополнительных причин особой привлекательности этого метода для менеджеров рисков:
• Он может подтвердить гипотезы планирования проекта или доказать их несостоятельность.
• Он требует упорядоченности компонентов системы.
• Он может быть использован для оптимизации выгоды от промежуточных результатов (что особенно приятно в случае, если проект перерасходовал время и/или деньги).
• Он обеспечивает обратную связь относительно истинной эффективности разработки.
• Он дает возможность сравнительно безболезненно прекратить проект, если это окажется необходимо.
Побочным достоинством инкрементной поставки является то, что она облегчает сбор данных для оценки ООФ и его объективных показателей прогресса.
План инкрементной поставки
План инкрементной поставки — это формальная взаимосвязь между частями трех других артефактов проекта:
• рабочий план: график, показывающий нижний уровень модулей или классов, которые будут созданы, вместе с их взаимосвязями
• иерархическая структура работ (ИСР): сеть задач, которые должны быть выполнены, и их взаимозависимости
• набор приемных испытаний для версий: окончательные приемные
приемные испытания для продукта, разбитого по версиям, показывающие, какие испытания предусмотрены для каких промежуточных конструкций
Рабочий план обычно представлен в форме иерархии модулей или классов
В проектах, где критичен срок сдачи, реальным ослаблением риска является раннее начало.
Затраты и выгоды следует определять с одинаковой точностью
Что понимают под управлением рисками (уточненное и переработанное)
Управление рисками по сути представляет собой осуществление следующих шагов, включаемых в проект (пункты 6-12 включают больше всего изменений по сравнению со списком в главе 10, но мы, конечно, рассмотрим заново весь процесс):
1. Используйте процесс идентификации рисков (подробности в главе 14) для составления перечня рисков, которые грозят вашему
проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения (подробности в главе 13) представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в обший план проекта.
• Опишите все детали в специальной
специальной форме, шаблон которой приведен в Приложении Б.
4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить
завершить проект. Это отличается от принятой в отрасли практики тем, что мы предлагаем использовать нанопроцентную дату как входные данные процесса составления расписания, а не как его результат. Определите N, используя какой-нибудь из инструментов параметрической оценки, если у вас он есть, настроенный на самые оптимистичные сценарии.
6. Скачайте RISKOLOGY (см. http://www.pmo.ru/riskology). Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь
на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.
7. Выразите, используя диаграмму риска, все обязательства по
проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.
8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи,
задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.
9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого
низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.
10. Полностью разработайте план разбиения процесса разработки на части до начала осуществления проекта. Используйте это как входные данные для процесса создания плана инкрементных поставок.
11.
Когда план разбиения процесса разработки на части завершен, вернитесь к иерархической структуре работ, оцените заново веса задач и выразите задачи в процентах от работы, которую предстоит выполнить.
12. Оцените выгоды с той же точностью, что и затраты.
13. Разбейте требования, содержащиеся в спецификации, до элементарного уровня. Перечислите их в порядке приоритета. В качестве двух критериев установления приоритета выбирайте чистую выгоду для пользователя и технические риски.
14. Разработайте план инкрементных поставок, в котором весь продукт разбит на версии (множество версий, по крайней мере столько, чтобы запланировать появление новой версии примерно раз в неделю). Опишите все требования к элементам соответствующих версий, чтобы пункты с более высоким приоритетом шли раньше. Вычислите ООФ для каждой версии и
запишите в план. Рассматривайте план инкрементных поставок как главный результат проекта.
15. Разработайте технологию общих приемных испытаний для данного продукта и разделите их
на приемные испытания отдельных версий (ПИn), по одному на каждую версию.
16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерсии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.
17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым. Рассматривайте
отклонения как признак возможного наступления риска.
18. Поддерживайте в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
"+":
"-":
вывод:
Комментариев нет:
Отправить комментарий