Риски проекта: что это, какими бывают и как с ними работать

Риски проекта — это всё, что может пойти не так: сорванная поставка, ушедший специалист, передумавший заказчик. Разобрали, чем риск отличается от проблемы, как его сформулировать, чтобы с ним можно было работать, как считать матрицу и сколько закладывать резерва в деньгах и днях. Внутри библиотека из 20 готовых формулировок, шаблон реестра на 9 колонок и чек-лист из 15 вопросов: по нему первый список рисков собирается за 20 минут. Пригодится и на рабочем проекте, и на ремонте квартиры.
Статью написал:
Ваня Буявец, продюсер, основатель Checkroi
Ваня Буявец
Основатель Checkroi, продюсер, эксперт в выборе онлайн-курсов
Все 2478 статей автора Подписаться на Телеграм-канал
Одобрено экспертом:
Наташа Буявец, основатель Checkroi, эксперт по онлайн-курсам
Наташа Буявец
Основательница Checkroi, продюсер Youtube-каналов, эксперт по онлайн-курсам
Все 3138 экспертных мнений Подписаться на Телеграм-канал
Обложка: Риски проекта: что это, какими бывают и как с ними работать

На старте проекта все риски выглядят одинаково: «ну, что-то может пойти не так». Через три месяца выясняется, что подрядчик сорвал поставку, ключевой разработчик ушёл в другую компанию, а заказчик передумал насчёт половины требований. Обидно тут одно: каждая из этих трёх вещей была предсказуема ещё до старта. Их просто никто не записал.

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

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

Если проект вы только собираете и до рисков ещё не дошли, начните с материала «Концепция проекта: что это и как её составить»: риски логично появляются уже после того, как зафиксированы цель, границы и бюджет.

Статья пригодится не только тем, у кого в трудовой написано «менеджер проектов». Ремонт квартиры, запуск нового направления в компании, переезд офиса, дипломная работа и свадьба на 120 человек устроены одинаково: есть срок, бюджет и куча вещей, которые могут поехать. Кстати, о сроках: как их вообще перестают срывать, мы разбирали в статье про дедлайны.

А если хочется освоить проектное управление системно, загляните в подборку курсов по управлению проектами: там программы от коротких интенсивов до годовых, и почти в каждой есть блок про риски. Отдельно про то, как выглядит вход в профессию, у нас есть разбор «Как стать менеджером проектов с нуля».

CheckroiCheckroiПодборка курсов по управлению проектами455 курсов • 42 школыСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить

Что такое риск в проекте и чем он отличается от проблемы

Рой-менеджер проектов у доски с карточками рисков

Риск — это неопределённое событие, у которого есть вероятность произойти и есть последствия для проекта. Два слова тут ключевые: неопределённое и последствия. Пока событие не случилось, это риск. Как только случилось, это уже проблема, и работать с ней надо по-другому.

Разницу проще всего показать на одной фразе. «Подрядчик может не успеть к 15 октября» — риск, с ним можно что-то сделать заранее. «Подрядчик не успел к 15 октября» — проблема, тут остаётся только тушить.

Новички чаще всего путают четыре вещи, которые в документах живут рядом. Вот они все:

Что это Определение Пример Что с этим делают
Риск Может случиться, а может нет Ключевой разработчик может уволиться Оценивают, придумывают план на случай
Проблема (issue) Уже случилось Разработчик написал заявление Решают здесь и сейчас, эскалируют
Допущение То, что вы приняли за правду без доказательств «Заказчик согласует макеты за три дня» Проверяют, а невыполненное превращается в риск
Ограничение Жёсткая рамка, которую нельзя двигать Бюджет 2 млн, дата запуска 1 декабря Планируют внутри неё

Практический смысл этой таблицы простой. Каждое непроверенное допущение — это будущий риск. Если вы пишете в плане «предполагаем, что данные от бухгалтерии придут в первую неделю», то в реестре рисков должна появиться строка «данные от бухгалтерии могут прийти позже первой недели». Это самый быстрый способ найти половину рисков проекта: просто перечитайте свои допущения.

Формула риска: причина, событие, последствие

Риск состоит из трёх частей, и если хоть одной не хватает, работать с ним невозможно.

  • Причина — то, что уже есть в реальности прямо сейчас. Факт, а не предположение.
  • Событие — то, что может произойти из-за этой причины.
  • Последствие — как это ударит по срокам, бюджету, качеству или репутации.

Пример полной формулировки: «Из-за того, что дизайн отдан единственному подрядчику без резервного исполнителя (причина), макеты могут прийти позже 20 октября (событие), и тогда вёрстка сдвинется на две недели, а запуск не попадёт в предновогодний сезон (последствие)».

Длинно, зато с таким описанием сразу понятно, что делать: искать второго подрядчика или закладывать буфер. К формулировкам мы ещё вернёмся отдельным разделом с примерами «до и после».

Позитивные риски: почему риск бывает хорошим

В проектном управлении риском называют любое отклонение от плана, в том числе приятное. Такие риски называют возможностями, и они тоже требуют подготовки.

Живой пример. Вы запускаете онлайн-курс и рассчитываете на 300 продаж. Есть вероятность, что блогер, с которым вы договорились, даст 3000 заявок вместо ожидаемых 300. Звучит прекрасно, пока не выясняется, что кураторов у вас на 300 человек, платформа ляжет на 800, а отдел заботы состоит из одного Кости. Нереализованная возможность стоит денег ровно так же, как реализованная угроза.

Быстрая проверка. Если ваш реестр рисков состоит только из плохого, вы наверняка пропустили пару сценариев, где всё пошло лучше плана и команда к этому не готова.

Какими бывают риски проекта

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

По источнику: внутренние и внешние

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

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

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

По влиянию: угрозы и возможности

Здесь всё просто. Угроза ухудшает результат, возможность улучшает. В реестре их держат вместе и помечают знаком, чтобы возможности не терялись на фоне более громких угроз.

По степени известности: четыре квадрата

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

  • Известное известное. Знаем о риске и знаем ответ. Например, декабрьский аврал у подрядчиков: закладываем сроки заранее.
  • Известное неизвестное. Знаем, что фактор есть, но не знаем масштаба. Например, аудит безопасности найдёт замечания, вопрос только, сколько их будет.
  • Неизвестное известное. В компании кто-то это знает, а до вас информация не дошла. Самая обидная категория, лечится разговорами с соседними отделами.
  • Неизвестное неизвестное. Никто не предвидел. Здесь спасает только общий резерв времени и денег.

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

По природе: библиотека из 20 типовых рисков

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

Группа Формулировка риска По чему бьёт
Сроки Оценка задач сделана без исполнителей и окажется заниженной Сроки
Согласование у заказчика займёт больше недели на каждой итерации Сроки
Смежная команда не отдаст интеграцию к нужной дате Сроки
Бюджет Подрядчик поднимет цену при подписании договора Бюджет
Курс валюты вырастет, а часть закупок номинирована в долларах Бюджет
Объём работ вырастет из-за требований, которых не было в брифе Бюджет, сроки
Люди Ключевой специалист уволится или уйдёт на другой проект Сроки, качество
Команда наберёт отпуска в один и тот же месяц Сроки
Заказчик сменит куратора, и решения придётся согласовывать заново Сроки
Требования Заказчик изменит требования после старта разработки Бюджет, сроки
Стороны понимают приёмку по-разному, и сдача затянется Сроки, репутация
Появится новый заинтересованный отдел со своим списком хотелок Содержание
Технологии Выбранный сервис не выдержит планируемой нагрузки Качество
Поставщик закроет доступ из России или сменит тарифы Бюджет, сроки
Данные из старой системы окажутся грязными, и миграция затянется Сроки
Внешние Изменится регулирование в отрасли и потребует доработок Бюджет, сроки
Конкурент выпустит похожий продукт раньше нас Ценность результата
Подрядчик обанкротится или потеряет лицензию Сроки, бюджет
Возможности Спрос окажется втрое выше прогноза, и мощностей не хватит Качество, репутация
Освободится сильный специалист из соседнего проекта Сроки, качество

Двадцать строк выше — библиотека для вдохновения, из которой берут подходящее. Реальный список у небольшого проекта обычно 10–15 пунктов, у крупного 30–60. Всё, что сверху, обычно перестают читать.

Канал основателя Checkroi Вани Буявца3 700 человек читают мой Телеграм-канал про нейросетиСобрал промпты для Claude Code и ChatGPT, разборы ИИ-инструментов и лайфхаки по продвижению бизнеса в одном местеПрисоединиться

Пять шагов управления рисками

Схема из пяти шагов управления рисками, Рой идёт по кругу

Управление рисками проекта устроено как цикл, который крутится всё время, пока идёт проект. Разовым упражнением на старте тут не обойтись. Этапы управления рисками описаны и в международном своде знаний PMBOK (справочник Института управления проектами, PMI), и в российском ГОСТ Р ИСО 31000-2019, причём похоже. Если убрать канцелярит, весь риск-менеджмент проекта сводится к пяти действиям, и процессы управления рисками на любом проекте повторяют этот круг.

Шаг 1: договориться о правилах

До того как искать риски, команда решает, как вообще будет с ними работать. Ответить нужно на пять вопросов: где живёт реестр, кто его ведёт, по какой шкале оцениваем, как часто пересматриваем и с какого уровня риск идёт наверх к спонсору проекта.

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

Шаг 2: найти риски

Идентификация рисков — тот шаг, который недооценивают чаще всего. Красивая матрица бесполезна, если половину важного в неё не занесли. Работающие способы поиска:

  • Мозговой штурм с командой. Час, доска, правило «глупых рисков не бывает». Фильтровать будете потом.
  • Перечитать допущения. Каждое «предполагаем, что…» из плана переворачивается в риск за минуту.
  • Спросить тех, кто делал похожее. Соседняя команда за полчаса выдаст то, до чего вы дошли бы за три месяца.
  • Разобрать прошлый проект. Отчёт о закрытии или ретроспектива предыдущего запуска обычно содержит готовый список.
  • Диаграмма Исикавы. Схема в виде рыбьего скелета: в голову ставят нежелательный итог, в кости причины по группам (люди, процессы, инструменты, внешняя среда).
  • Метод Дельфи. Экспертов опрашивают анонимно и в несколько кругов, чтобы мнение самого громкого участника не задавило остальных.
  • SWOT-анализ. Слабые стороны и угрозы из него почти дословно переезжают в реестр.

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

Шаг 3: оценить

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

Качественный анализ отвечает на вопрос «насколько это страшно» словами и баллами. Каждому риску ставят вероятность и влияние по шкале от 1 до 5, перемножают, получают рейтинг и сортируют список. Занимает полчаса, покрывает 90 % потребностей обычного проекта.

Количественный анализ переводит риски в деньги и дни. Сюда входят расчёт ожидаемой стоимости, дерево решений (схема, где на каждой развилке считают выгоду с учётом вероятности), анализ чувствительности и метод Монте-Карло (компьютер прогоняет тысячи вариантов проекта со случайными отклонениями и показывает распределение сроков). Это история для строек, инвестпроектов и бюджетов от сотен миллионов. На проекте за два миллиона Монте-Карло стоит дороже, чем спасает.

Шаг 4: решить, что делать

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

Шаг 5: следить и пересматривать

На мониторинге разваливается большинство внедрений. Реестр заводят на старте и открывают второй раз на разборе полётов. Рабочая частота такая: раз в спринт или раз в две недели, десять минут на статусной встрече. Смотрят три вещи: появились ли новые риски, изменились ли оценки у старых, сработал ли где-то триггер.

Ориентир по времени. На проекте длиной в полгода вся работа с рисками занимает примерно четыре часа на старте и по десять минут каждые две недели. Это дешевле любого сорванного дедлайна.

Как сформулировать риск, чтобы его не переписывали пять раз

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

Лечится это одним шаблоном: «Из-за <причины> может произойти <событие>, что приведёт к <последствию>». Причина обязана быть фактом сегодняшнего дня, последствие обязано быть измеримым.

Как пишут обычно Что не так Как надо
Сорвём сроки Нет причины, нет масштаба, нечего оценивать Из-за того, что оценку задач делали без разработчиков, трудоёмкость может оказаться выше на 30 %, и релиз сдвинется на месяц
Проблемы с подрядчиком Непонятно, какие именно, и кто за это отвечает Из-за того, что у подрядчика единственный дизайнер, макеты могут прийти позже 20 октября, и вёрстка сдвинется на две недели
Нехватка бюджета Похоже на проблему, а не на риск Из-за того, что 40 % закупок номинированы в долларах, рост курса на 15 % может увеличить смету на 600 тысяч
Заказчик может передумать Всегда верно, поэтому бесполезно Из-за того, что финальные требования не подписаны, заказчик может добавить личный кабинет после старта разработки, что даст плюс 3 недели
Риск увольнения Чьего, когда и с каким эффектом Из-за того, что интеграцию знает только один backend-разработчик, его уход остановит направление на 2–3 недели, пока новый человек разбирается

Проверить формулировку можно одним вопросом: «из неё понятно, что делать завтра?» Если да, риск сформулирован нормально. Если хочется сначала уточнить пять деталей, переписывайте.

CheckroiCheckroiПодборка курсов для менеджеров проектов432 курса • 53 школыСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить

Матрица рисков: как оценить вероятность и влияние

Матрица рисков — таблица, где по одной оси стоит вероятность, по другой влияние, а на пересечении видно, насколько риск важен. Её ещё называют тепловой картой, потому что зоны красят в зелёный, жёлтый и красный.

Сначала договоритесь о шкалах. Вот рабочий вариант на пять баллов, который можно взять как есть.

Балл Вероятность Влияние на сроки Влияние на бюджет
1 Почти исключено, до 10 % До 2 дней До 1 % сметы
2 Маловероятно, 10–30 % До недели 1–3 %
3 Возможно, 30–50 % До двух недель 3–7 %
4 Вероятно, 50–70 % До месяца 7–15 %
5 Почти наверняка, выше 70 % Больше месяца Больше 15 %

Шкалу влияния подгоняют под проект: для ремонта квартиры «до месяца» это катастрофа, для стройки жилого дома погрешность. Числа в правых колонках вы задаёте сами один раз, дальше вся команда пользуется ими одинаково.

Дальше считаем рейтинг: вероятность умножаем на влияние. Получается число от 1 до 25, по которому список сортируется сверху вниз.

Влияние ↓ / Вероятность → 1 2 3 4 5
5 5 10 15 20 25
4 4 8 12 16 20
3 3 6 9 12 15
2 2 4 6 8 10
1 1 2 3 4 5

И самое главное: что с этими числами делать дальше. Пороги обычно ставят так.

  • Красная зона, 15 и выше. Нужен план действий с ответственным и датой. Такие риски выносят на статус перед заказчиком и спонсором проекта.
  • Жёлтая зона, 6–12. Достаточно назначить владельца и следить. План на случай срабатывания пишут коротко, в две-три строки.
  • Зелёная зона, 5 и ниже. Просто держат в списке и пересматривают раз в месяц. Тратить на них время не нужно.

Отдельно стоит смотреть на риски с низкой вероятностью и влиянием 5. Формально они попадают в жёлтое, по факту способны убить проект целиком: отзыв лицензии у банка-партнёра, уход единственного поставщика с рынка. Такие риски выносят в отдельный список независимо от рейтинга.

Реестр рисков: девять колонок и как его вести

Раскладка инструментов проектного менеджера на столе

Реестр рисков (по-английски risk register) — таблица, в которой живут все риски проекта вместе с оценками, ответственными и планами. Формат не важен: Яндекс Таблицы, Excel, страница в корпоративной базе знаний или отдельный тип задач в трекере. Важно, чтобы файл был один и лежал там, куда команда заглядывает без напоминаний.

В рабочем минимуме девять колонок.

Колонка Что писать Пример
ID Короткий номер для ссылок в переписке R-07
Описание Формулировка по схеме «причина, событие, последствие» Из-за единственного дизайнера у подрядчика макеты могут прийти позже 20 октября, вёрстка сдвинется на 2 недели
Категория Сроки, бюджет, люди, требования, технологии, внешнее Сроки
Вероятность Балл 1–5 по общей шкале 4
Влияние Балл 1–5 по общей шкале 4
Рейтинг Произведение двух предыдущих, считает формула 16
Стратегия Избежать, передать, снизить или принять Снизить
Действия и срок Что делаем и до какого числа Найти второго дизайнера до 1 октября, отдать ему шапку и карточку товара
Владелец Один человек с именем, а не отдел Марина, арт-директор

Дальше три детали, которые отличают живой реестр от мёртвого.

Владелец риска — всегда конкретный человек. Не «отдел закупок» и не «команда», а Марина или Сергей. Владелец следит за своим риском и поднимает руку, когда что-то меняется. Строка без имени в 99 % случаев остаётся без действий.

Триггер — признак, по которому понятно, что риск начал сбываться. Его полезно добавить десятой колонкой. Для риска с макетами триггер выглядит так: «13 октября у подрядчика не готовы первые два экрана». Без триггера команда узнаёт о срабатывании тогда, когда спасать уже нечего.

План на случай срабатывания — отдельная вещь. Стратегия говорит, как уменьшить вероятность заранее. План на случай (его называют контингенс-планом или планом B) описывает, что делать, если риск всё-таки случился: кому звонить, откуда брать деньги, что резать в объёме. Для красной зоны такой план обязателен.

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

CheckroiCheckroiПодборка курсов для риск-менеджеров82 курса • 18 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить Ваня БуявецКанал основателя Checkroi Вани БуявцаЗабирайте промпты и обучение по нейросетям в моём Телеграм-каналеБольше 3 700 человек уже применяют Claude Code, ChatGPT и другие нейросети в работе, учёбе, бизнесе и жизниПерейти в канал

Четыре стратегии реагирования и когда какую выбирать

Классических стратегий для угроз четыре. Они описаны и в PMBOK, и в ГОСТ Р ИСО 31000-2019, и по сути повторяют житейскую логику.

Стратегия Суть Пример Когда выбирают
Избежать Меняем план так, что риск исчезает Отказываемся от зарубежного сервиса и берём российский, чтобы не зависеть от санкций Риск в красной зоне, а обходной путь не сильно дороже
Передать Отдаём последствия тому, кто справится лучше Страхуем груз, прописываем в договоре штраф за срыв срока, отдаём участок на аутсорс с фиксированной ценой Риск финансовый и его можно посчитать в деньгах
Снизить Уменьшаем вероятность или силу удара Второй дизайнер на подхвате, буфер в три дня на каждом этапе, парное ведение критичного модуля Самая частая стратегия, подходит почти всегда
Принять Ничего не делаем заранее, держим в поле зрения Возможный дождь на выездной съёмке: переносить нельзя, страховать дорого, снимаем запасной павильонный план Риск дешевле пережить, чем предотвратить

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

Для возможностей стратегии зеркальные: использовать (сделать так, чтобы хорошее точно случилось), усилить (поднять вероятность), разделить (взять партнёра, который поможет забрать выгоду) и принять. С тем самым блогером и 3000 заявок стратегия «усилить» выглядит так: заранее договориться с тремя кураторами на подработку и проверить, что платформа держит тысячу человек одновременно.

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

Дешёвая проверка на адекватность. Если стоимость мер по снижению риска выше ожидаемого ущерба, меры не нужны. Охрана за 200 тысяч рублей у склада с товаром на 80 тысяч — это не управление рисками.

Сколько закладывать резерва времени и денег

Вопрос, на который конкуренты обычно отвечают «зависит от проекта». Зависит, конечно, но ориентиры существуют, и считать их умеет любой человек с калькулятором.

Начнём с расчёта. Ожидаемая денежная стоимость риска (EMV) — это вероятность, умноженная на сумму ущерба. Риск с вероятностью 30 % и ущербом 600 тысяч рублей стоит 180 тысяч. Складываем такие числа по всем рискам реестра и получаем нижнюю границу резерва.

Пример на маленьком проекте с бюджетом 2 млн рублей:

Риск Вероятность Ущерб Ожидаемая стоимость
Подрядчик поднимет цену 40 % 200 000 ₽ 80 000 ₽
Требования вырастут после старта 50 % 300 000 ₽ 150 000 ₽
Уход ключевого специалиста 20 % 250 000 ₽ 50 000 ₽
Миграция данных затянется 30 % 150 000 ₽ 45 000 ₽
Резерв на известные риски 325 000 ₽

Получилось около 16 % от бюджета, и это деньги на риски, которые вы уже нашли. Их принято называть резервом на непредвиденные обстоятельства: распоряжается им менеджер проекта, тратит по конкретным сработавшим строкам реестра.

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

  • Понятный проект в знакомой области: 5–10 % сверху к бюджету и срокам.
  • Новая для команды технология или подрядчик: 15–20 %.
  • Исследовательский проект, где неизвестен даже результат: 30 % и выше, и лучше идти короткими этапами с пересчётом после каждого.

С временем работает то же самое, но есть нюанс. Буфер лучше оставлять одним куском в конце, а не размазывать по задачам. Спрятанный внутри задачи запас команда съедает всегда: работа занимает всё отведённое на неё время. Общий буфер виден, тратится осознанно и по нему сразу понятно, сколько осталось.

Как вести риски в Agile-команде

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

Как это выглядит на практике:

  • Сам итеративный подход уже снижает риск. Короткий спринт ограничивает цену ошибки двумя неделями работы.
  • Критерии готовности задачи к работе ловят риск «взяли в спринт то, по чему нет решения». Задача не попадает в спринт, пока не согласован макет и не понятен доступ к данным.
  • На планировании спринта команда вслух проговаривает, что может помешать взятым задачам. Пять минут, без таблицы.
  • Ретроспектива превращает сработавшие риски в изменения процесса.
  • Спайк (короткая исследовательская задача) снимает техническую неопределённость раньше, чем она превращается в сорванный срок.
  • Доска рисков из 5–7 стикеров рядом с основной доской заменяет полноценный реестр на небольшом продукте.

Отдельно стоит посмотреть на методологию P3.express: она заметно легче классического подхода и встраивает проверку рисков в регулярный месячный и недельный цикл. Хороший вариант для команд, которым PMBOK велик, а чистый Scrum мал.

Дополнительно помогают инструменты, которые делают ход проекта видимым: диаграмма Ганта показывает, где буфер уже съеден, а матрица RACI закрывает целый класс рисков про «я думал, это согласовывает Петя».

Восемь ошибок, из-за которых реестр становится мёртвым документом

Все эти грабли выглядят безобидно по отдельности и хоронят работу с рисками в совокупности.

  1. Реестр заводят один раз на старте. Проект меняется каждую неделю, а список рисков остаётся февральским. Лечится десятиминутным пунктом в повестке регулярной встречи.
  2. Риски пишет один человек. Менеджер физически не видит технических и юридических угроз. Половина реального списка живёт в головах команды.
  3. Формулировки без причины и последствия. «Проблемы с подрядчиком» нельзя ни оценить, ни поручить.
  4. У риска нет владельца. Строка, за которую отвечают все, не принадлежит никому.
  5. Оценка вместо действия. Красивая матрица с цветами, где ни у одного риска не прописано, что делаем и до какого числа.
  6. Реестр на 60 строк. Список, который невозможно прочитать за пять минут, не читают вообще. Верхние 10 строк работают лучше, чем полный каталог.
  7. Риски прячут от заказчика. Логика «не будем пугать» приводит к тому, что заказчик узнаёт о риске в день его срабатывания. Честный список на старте доверие обычно повышает.
  8. Нет резерва. Можно идеально вести реестр и всё равно встать, если на реакцию не заложено ни рубля и ни дня.

Признак, что всё работает. На статусе кто-то из команды говорит «у нас сработал триггер по R-07, включаем план B». Значит риск нашли заранее, договорились о действиях и заметили вовремя.

Чек-лист: 15 вопросов, чтобы найти риски проекта за 20 минут

Рой отмечает галочки в чек-листе и доволен результатом

Быстрый способ собрать первый список, если проект уже стартует, а реестра нет. Соберите команду, пройдите по вопросам и записывайте всё, что всплывает. Дальше формулировки причешете по шаблону из раздела выше.

  1. Какие сроки в плане мы поставили, не спросив исполнителей?
  2. Что мы приняли за правду, но не проверили?
  3. Кто в проекте незаменим и что будет, если он выпадет на две недели?
  4. У кого из команды отпуск или защита диплома в разгар проекта?
  5. Что нам нужно от людей, которые нам не подчиняются?
  6. Какие требования до сих пор не подписаны?
  7. Что мы делаем впервые: технологию, подрядчика, формат?
  8. Что сломается, если результатом воспользуется втрое больше людей, чем ждём?
  9. От каких внешних сервисов и поставщиков мы зависим и есть ли замена?
  10. Что в бюджете зависит от курса, тарифов или цен поставщика?
  11. Какие согласования и проверки могут занять дольше, чем в плане?
  12. Что пошло не так на прошлом похожем проекте?
  13. Как заказчик понимает приёмку и совпадает ли это с нашим пониманием?
  14. Какие изменения в законах или правилах площадок нас касаются?
  15. Что должно случиться хорошего, к чему мы окажемся не готовы?

Из пятнадцати вопросов обычно рождается 20–30 сырых пунктов. Оцените их по матрице, оставьте в активной работе верхние десять, остальное держите в наблюдении. Это и будет ваш первый рабочий реестр.

Где научиться управлять проектами и рисками

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

Мы собрали обучение управлению проектами в одном месте: от коротких интенсивов на пару недель до годовых программ с дипломом и подготовкой к международной сертификации.

КурсШколаСтоимость со скидкойВ рассрочкуДлитель­ностьОбзор курса от Checkroi
Профессия «Менеджер проектов»
Перейти на сайт курса
SkillboxSkillbox105 903 ₽4372 ₽/мес.6 месяцевОбзор курса
Менеджер проектов (со специализацией)SkyproSkypro165 240 ₽6750 ₽/мес.10 месяцевОбзор курса
Менеджер проектовSkyproSkypro102 000 ₽4167 ₽/мес.6 месяцевОбзор курса
Менеджер проектов в IT + ИИ
Перейти на сайт курса
SkillboxSkillbox169 915 ₽3416 ₽/мес.6 месяцевОбзор курса
Менеджер проектов: тариф Оптимальный
Перейти на сайт курса
Академия ЭдюсонЭдюсон119 600 ₽9966 ₽/мес.5 месяцевОбзор курса
Менеджер проектов + ИИ
Перейти на сайт курса
Академия СинергияАкадемия Синергия90 636 ₽3777 ₽/мес.6 месяцевОбзор курса
ДО Профессия Менеджер проектов
Перейти на сайт курса
GeekBrainsGeekBrains122 477 ₽3167 ₽/мес.5 месяцевОбзор курса
Менеджер проектов
Перейти на сайт курса
НетологияНетология98 400 ₽3313 ₽/мес.6 месяцевОбзор курса
Профессия: Менеджер проектов + ИИ
Перейти на сайт курса
ProductStarProductStar60 134 ₽2088 ₽/мес.6 месяцевОбзор курса
Профессия: Менеджер проектов
Перейти на сайт курса
ProductStarProductStar63 000 ₽2917 ₽/мес.6 месяцевОбзор курса

Больше программ — в полном каталоге курсов по управлению проектами

Если интересует именно риск как отдельная специальность, посмотрите разбор «Кто такой риск-менеджер»: там про то, чем банковский риск отличается от проектного и кому эта работа подходит. А если хочется сначала понять, на какие деньги можно рассчитывать в проектном управлении, у нас есть свежий разбор зарплат менеджеров проектов и статья про координатора проектов: с этой роли в профессию чаще всего заходят без опыта.

Из бесплатного полезно посмотреть ГОСТ Р ИСО 31000-2019, российскую версию международного стандарта по менеджменту риска. Читается тяжеловато, зато даёт словарь, на котором говорят в крупных компаниях и на госпроектах.

Часто задаваемые вопросы

Чем риск отличается от проблемы в проекте?

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

Сколько рисков должно быть в реестре проекта?

Для небольшого проекта рабочий объём — 10–15 строк, для крупного 30–60. Ориентируйтесь не на полноту каталога, а на читаемость: список, который нельзя просмотреть за пять минут, команда перестаёт открывать. В активной работе держите верхние 10 рисков по рейтингу, остальные переводите в наблюдение и пересматривайте раз в месяц.

Как посчитать рейтинг риска?

Рейтинг = вероятность × влияние. Обе величины оценивают по общей для команды шкале от 1 до 5, поэтому итог получается от 1 до 25. Рейтинг 15 и выше — красная зона, тут нужен план действий с ответственным и датой. 6–12 — жёлтая, достаточно владельца и наблюдения. 5 и ниже — зелёная, риск просто держат в списке. Отдельно выносят маловероятные риски с влиянием 5: формально они жёлтые, но способны остановить проект целиком.

Где вести реестр рисков и есть ли готовый шаблон?

Формат вторичен: подойдут Яндекс Таблицы, Excel, страница в корпоративной базе знаний или отдельный тип задач в трекере вроде Jira, Kaiten или Weeek. Важнее, чтобы файл был один и лежал там, куда команда заходит каждый день. Рабочий минимум колонок: ID, описание, категория, вероятность, влияние, рейтинг, стратегия, действия со сроком, владелец. Десятой колонкой полезно добавить триггер — признак того, что риск начал сбываться.

Что писать в плане управления рисками?

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

Какой резерв закладывать на риски?

Нижнюю границу считают через ожидаемую стоимость: вероятность каждого риска умножают на сумму ущерба и складывают по всему реестру. Сверху добавляют управленческий резерв на непредвиденное. Ориентиры: 5–10 % к бюджету и срокам для понятного проекта в знакомой области, 15–20 % при новой технологии или новом подрядчике, от 30 % для исследовательских проектов. Резерв времени лучше держать одним куском в конце: спрятанный внутри задач буфер команда съедает всегда.

Нужно ли управлять рисками в Agile, если у нас спринты?

Нужно, просто без тяжёлого документа. Работа с рисками встраивается в обычные ритуалы: на планировании спринта команда пять минут проговаривает, что может помешать взятым задачам; критерии готовности не пускают в спринт задачи без согласованного решения; спайк снимает техническую неопределённость заранее; ретроспектива превращает сработавшие риски в изменения процесса. Вместо реестра на 60 строк небольшому продукту хватает доски из 5–7 стикеров. Сам короткий спринт уже работает как способ снижения риска: цена ошибки ограничена двумя неделями.

Бывают ли положительные риски и зачем их записывать?

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

Читайте Checkroi первым в Google
Добавьте Checkroi в избранные источники — и наши разборы курсов и обзоры школ будут показываться выше в вашей выдаче Google.
Оставить комментарий
0 комментариев
Форма комментария

Оставьте комментарий

Напишите, что думаете. Нам важно ваше мнение!