В материале изложена логика разделения рисков и проблем в управлении проектами. Сначала даются четкие определения: риск — это вероятное событие, проблема — уже свершившийся факт. Далее разбираются классические стратегии реагирования на риски (уклонение, передача, снижение) и доказывается их полная неприменимость к проблемам. На конкретном примере «недостаточной квалификации заказчика» показан механизм возникновения путаницы и метод корректной идентификации: многие мнимые риски на деле являются данностью для планирования. В завершение критикуется концепция универсальных типовых рисков и обосновывается необходимость накопления опыта об областях неопределенности для уникального анализа каждого проекта.
Основные мысли
В результате изучения лекции слушатель будет способен:
1. Воспроизвести определения риска и проблемы, указав ключевое различие между ними.
2. Объяснить, почему стратегии уклонения, передачи и снижения не работают применительно к проблемам.
3. Проанализировать формулировку «недостаточный уровень квалификации персонала заказчика» и классифицировать ее как данность для планирования, а не как риск.
4. Сравнить понятия «типовой риск» и «типовая область неопределенности», выявив недостатки использования универсальных перечней.
5. Отличать мнимые риски от реальных неопределенностей в проектной практике.
6. Обосновать необходимость уникального анализа рисков для каждого отдельного проекта.
7. Составить рекомендацию по переходу от ведения реестра типовых рисков к фиксации областей, потенциально порождающих неопределенности.
Показывать лекцию целиком
Краткое изложение
Управление рисками: отличия от проблем и практический анализ
Что такое риск и что такое проблема
Риск проекта — это неопределенное событие или условие, которое в случае возникновения оказывает позитивное или негативное воздействие как минимум на один из параметров проекта: сроки, стоимость или результат. Хотя в общем случае риски могут быть позитивными, мы для упрощения будем говорить только о негативных. Управление позитивными рисками требует выхода на определенный уровень технологической зрелости компании.
Итак, ключевое различие таково: риск — это то, что может произойти, а проблема — это то, что уже произошло и существует. Риск — потенциальное будущее, проблема — свершившийся факт. К сожалению, в проектах эти два понятия массово путают.
Почему путаница опасна: стратегии реагирования
Для управления рисками существуют классические стратегии и подходы. К ним относятся:
• Уклонение — исключение угрозы, ограждение целей проекта от последствий реализации риска.
• Передача — переложение негативных последствий угрозы вместе с ответственностью за реагирование на третью сторону.
• Снижение — понижение вероятности или последствий негативного события до приемлемых пределов. Сюда входит принятие предупредительных мер по уменьшению вероятности наступления риска или смягчению его последствий.
Эти подходы эффективны для рисков, но абсолютно не пригодны для проблем. От проблемы нельзя уклониться, потому что она уже существует. Проблему нельзя передать — никто не возьмет на себя ответственность за уже случившийся инцидент. И уж тем более нельзя понизить вероятность проблемы — событие уже состоялось, никаких вероятностей больше нет. Именно поэтому так важно не путать риски с проблемами, а корректно идентифицировать каждый из них.
Пример путаницы: «недостаточная квалификация персонала заказчика»
При анализе рисков необходимо вдумчиво анализировать реальное положение дел. Рассмотрим один из самых распространенных примеров формулировки, которую часто записывают в реестр рисков: «Недостаточный уровень квалификации персонала заказчика».
Подойдем к этой формулировке критически. Во-первых, риск — это событие, которое еще не произошло. Тогда получается, что на момент идентификации риска персонал заказчика имеет достаточный уровень квалификации, но мы предполагаем, что в проекте случится нечто, из-за чего они внезапно станут менее квалифицированными. Такая картина выглядит абсолютно нереальной.
С другой стороны, персонал заказчика по отношению к внедряемой нами информационной системе почти всегда объективно имеет недостаточную квалификацию. Скорее всего, эту систему они видят впервые в жизни. Они не могут обладать достаточными знаниями по определению.
Таким образом, перед нами не риск и даже не проблема. Это данность для планирования. Мы изначально понимаем, что квалификация персонала недостаточна — иной она и не может быть ни при каких обстоятельствах. Следовательно, не нужно «раздувать из мухи слона» и заносить это в риски. Вместо этого необходимо запланировать методы по обучению персонала и заложить их в план проекта.
Типовые риски или типовые области неопределенности?
Часто в практике управления проектами оперируют понятием «типовые риски» и составляют их перечни. Однако типовой риск — это примерно как типовой человек (две руки, две ноги, голова). Подобное описание никому не принесет пользы, потому что оно слишком поверхностно.
Риски каждого проекта уникальны. Единственное, что действительно нужно накапливать, — это опыт о тех ситуациях или областях, в которых могут появляться риски, то есть тех областях, где существуют неопределенности, порождающие риски.
Примеры таких областей, где неопределенности возникают регулярно:
• Распределенная обработка и хранение данных. Опыт показывает, что распределенные системы всегда запускать значительно сложнее, чем централизованные.
• Работа с оборудованием. Подключение оборудования всегда сопряжено с непредвиденными сложностями. Даже USB-принтер не всегда удается подключить с первого раза, не говоря уже о более сложных устройствах вроде терминалов сбора данных.
Вместо того чтобы полагаться на бесполезные типовые перечни, нужно накапливать опыт именно по таким проблемным областям. А затем — вдумчиво анализировать каждый новый проект на предмет его уникальных особенностей. Необходимо проводить глубокий анализ неопределенностей, а не механически переносить в проект шаблонные формулировки.
Краткие итоги
Ключевая управленческая ловушка, описанию которой посвящен материал, кроется в неспособности многих команд провести четкую границу между будущим и настоящим проекта. Умение разделять вероятностные события и свершившиеся факты — это не терминологическая придирка, а фундамент для выбора рабочей стратегии действий. Традиционные инструменты (уклонение, передача, снижение) созданы для работы с вероятностью и неопределенностью. Их применение к тому, что уже существует, не просто бесполезно, а деструктивно: оно создает иллюзию контроля там, где требуются прямые административные действия и эскалация. Механическое перенесение шаблонных стратегий реагирования на проблемы приводит к параличу управления, поскольку команда пытается «снизить вероятность» того, что уже произошло, вместо того чтобы решать инцидент.
Центральной аналитической ошибкой является подмена объективных ограничений проекта мнимыми рисками. Ситуация с квалификацией персонала заказчика наглядно демонстрирует, как фундаментальное условие среды принимается за неопределенность. Это говорит о необходимости более жесткого тестирования любой формулировки риска: если событие не может не произойти или оно уже является неотъемлемым свойством окружения, работа с ним должна вестись через механизмы планирования, а не через реестр рисков. Перевод «мнимого риска» в категорию «данность для планирования» немедленно смещает фокус с бесплодных гаданий на разработку конкретных компенсирующих мероприятий, таких как обучение персонала.
Следствием такого подхода становится критика стремления к унификации и созданию каталогов типовых рисков. Глубинная проблема здесь — в смешении причины и следствия. Общими и повторяющимися из проекта в проект являются не сами риски (которые всегда уникальны в силу специфики стейкхолдеров и контекста), а источники их происхождения — технические или организационные области неопределенности. Практическая ценность заключается в переносе фокуса с поиска готового перечня ответов на развитие насмотренности и опыта в идентификации «зон турбулентности», таких как распределенные системы или сложная аппаратная периферия. Это превращает управление рисками из бюрократической процедуры заполнения чек-листов в зрелый аналитический процесс, требующий глубокого погружения в архитектуру и окружение каждого отдельного проекта.
Что такое риск и проблема
Риск проекта — это неопределенное событие или условие, которое в случае возникновения оказывает воздействие (обычно негативное) на сроки, стоимость или результат проекта. Ключевой признак риска: он еще не произошел, он лишь может случиться.
Проблема — это событие, которое уже произошло и существует как свершившийся факт. Риск — потенциальное будущее, проблема — существующее настоящее.
Стратегии управления рисками и их ограничения
Для работы с рисками используются три классические стратегии:
1. Уклонение — полное исключение угрозы, защита проекта от последствий риска.
2. Передача — переложение последствий и ответственности за риск на третью сторону.
3. Снижение — уменьшение вероятности наступления риска или смягчение его последствий до приемлемого уровня.
Все эти стратегии работают только с вероятностью и будущими событиями. Они абсолютно бесполезны для решения проблем. От уже существующей проблемы нельзя уклониться, ее никто не возьмет (передача), а ее вероятность уже равна 100%, поэтому снижать ее бессмысленно. Путаница между рисками и проблемами приводит к тому, что команда пытается применить профилактические меры к свершившемуся факту, что парализует управление.
Практический анализ: ошибка идентификации
Часто в реестр рисков попадает формулировка: «Недостаточный уровень квалификации персонала заказчика». Проанализируем ее:
• Если это риск, значит, сейчас квалификация достаточна, и мы боимся, что она внезапно упадет. Это нереалистичный сценарий.
• На самом деле, персонал заказчика при внедрении новой системы почти всегда сталкивается с ней впервые. Его квалификация в данной системе не может быть достаточной по определению.
Следовательно, это не риск, а данность для планирования. Это объективное свойство среды проекта. Действие в такой ситуации — не внесение в реестр рисков, а разработка и включение в план проекта конкретных мероприятий, например, плана обучения пользователей.
Недостатки «типовых рисков» и области неопределенности
Оперировать «типовыми рисками» и их готовыми перечнями неэффективно. Типовой риск — это слишком поверхностное описание (как «типовой человек»), которое не учитывает специфику конкретного проекта.
Риски каждого проекта уникальны. Вместо накопления типовых перечней необходимо накапливать опыт о типовых областях неопределенности — архитектурных или организационных блоках, где сложности возникают чаще всего. Примеры таких областей:
• Распределенная обработка и хранение данных. Запуск распределенных систем всегда сложнее, чем централизованных, и содержит больше непредсказуемых состояний.
• Работа с оборудованием. Подключение любой аппаратной периферии, от простого принтера до терминала сбора данных, всегда сопряжено с потенциальными техническими нестыковками.
Практический вывод: в каждом проекте необходимо проводить вдумчивый, индивидуальный анализ неопределенностей, опираясь на знание проблемных областей, а не механически копировать шаблонные риски.
Выводы
1. Риск — это вероятное событие в будущем, а проблема — уже свершившийся и существующий факт.
2. Ключевые стратегии работы с рисками (уклонение, передача, снижение вероятности и последствий) полностью неприменимы к проблемам.
3. Проблему нельзя устранить профилактическими мерами: от нее нельзя уклониться, ее нельзя передать, а ее вероятность не может быть снижена.
4. Смешение рисков и проблем парализует управление, заставляя команду искать неверные способы реагирования на свершившиеся события.
5. Формулировка «недостаточная квалификация персонала заказчика» в большинстве случаев является не риском, а объективной данностью для планирования.
6. Если условие является неотъемлемым свойством проектной среды, его не нужно вносить в реестр рисков, а нужно компенсировать плановыми мероприятиями (например, обучением).
7. Обучение пользователей — это не реакция на риск, а элемент проект-менеджмента, вытекающий из анализа ограничений предметной области.
8. Концепция «типовых рисков» и их перечней неэффективна, так как создает слишком поверхностное и бесполезное описание, оторванное от реальности.
9. Риски каждого отдельного проекта по-настоящему уникальны и требуют индивидуального анализа.
10. Вместо накопления типовых рисков следует накапливать опыт о типовых областях неопределенности (например, распределенные системы, работа с оборудованием).
11. Технически сложные области, такие как интеграция аппаратных комплексов, являются генераторами непредвиденных проблем, а не источником стандартных рисков.
12. Качественное управление рисками подразумевает отказ от шаблонов и переход к вдумчивому выявлению неопределенностей в каждом уникальном контексте проекта.
Вопросы для самопроверки
1. Чем принципиально отличается риск от проблемы с точки зрения их существования во времени?
2. Почему стратегия уклонения (исключения угрозы) является бессмысленной при столкновении с проблемой?
3. Можно ли передать решение проблемы третьей стороне так же, как передается ответственность за риск? Обоснуйте ответ.
4. Приведите пример того, как типичная формулировка «недостаточная квалификация персонала» противоречит вероятностной природе риска.
5. Что означает термин «данность для планирования» и как он должен менять действия руководителя проекта?
6. В чем состоит практическая бесполезность описания «типового человека» по аналогии с «типовым риском»?
7. Какую информацию о неопределенностях следует накапливать и систематизировать от проекта к проекту вместо типовых рисков?
8. Почему распределенная обработка данных считается областью, требующей повышенного внимания при анализе неопределенностей?
9. В чем заключается уникальность рисков каждого проекта, если многие из них связаны с одними и теми же технологиями (например, оборудованием)?
10. Какие управленческие действия следует предпринять, если в ходе анализа выяснилось, что состояние «недостаточной квалификации» было зафиксировано еще до старта проекта?
11. Что произойдет с вашим проектным планом, если вы ошибочно идентифицируете проблему как риск и попытаетесь применить к ней стратегию снижения?
