Само понимание рисков и проблем – это приёмы проактивного поведения, то есть сделать что-то до того, как случилась неприятность. При этом проблема – это уже свершившийся факт, а риск – это то, что может случиться в будущем. Но даже если негативные последствия проблемы уже проявились, могут быть и новые последствия, пока сама проблема не была устранена. Могут ли проблемы и риски пересекаться? Думаю, да.

Например, устаревшая платформа, на которой реализуется решение. Является ли это проблемой? Да, потому что ты можешь умножить все сроки на 1,5, но проблема может продолжать наносить ущерб:

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

Является ли устаревшая платформа риском? Нет, потому что риск – это событие, например, срыв сроков в связи с задержками сроков разработки. Нужно ли анализировать и риски, и проблему? Думаю, да. А теперь разберём отдельно, как управлять проблемами и как управлять рисками.

Управление проблемами

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

Другими словами, в карточке есть две основных составляющих:

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

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

В анализе могут возникнуть несколько проблем (упс, рекурсия):

• Не учли все последствия
• Не вышли на требуемый уровень анализа

В последнем случае достаточно знать, что человек может держать в сознании 3-7 объектов, иначе наступает перегруз. Люди, которые выносят на Управляющий комитет, например, куски кода, и рассказывающие о том, что именно сломалось в каком API, не выполнили своё домашнее задание. Не перегрузить, но при этом рассказать главное с необходимым и достаточным количеством деталей – в этом заключается мастерство на презентациях любого уровня, одной из которых является выход с проблемой / изменением / риском на Управляющий комитет.

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

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

Управление рисками

С оценкой рисков есть много подходов, мне кажется важным отделять последствия от вероятности реализации. В таком случае делается таблица (реестр) рисков, в которой итоговое количество баллов по риску считается как произведение тяжести последствий (оценивается от 1-го до 3-х) на вероятность их реализации (также от 1-го до 3-х).

Как пример:

Понятно, что в случае форс-мажоров все могут остаться без проекта (и без работы), но насколько они вероятны, эти форс-мажоры?

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