Что вы знаете о риске?

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

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

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

Дальнейшие размышления привели меня к тому, что даже эти крупные водопадные проекты внутри себя использовали Scrum, пусть и не в чистом виде.
Я достала из тумбочки Scrum Guide 2020 года — знаете, сколько раз там повторяется слово «риск»? Четыре раза. Фреймворк, который позиционирует себя как инструмент управления (рисками в том числе), посвящает этой теме буквально четыре упоминания — и ни одного конкретного инструмента.

Основные области влияния рисков по PMBOK: качество, сроки, бюджет, содержание, ресурсы, репутация.

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

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

Из шести областей влияния два уже пресечены на корню (бюджет и ресурсы), ещё два нивелируются основными принципами Scrum — Прозрачностью, Инспекцией и Адаптацией (сроки и содержание). Лично у меня опасения вызывают только качество и репутация.

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

А вот с качеством вопрос, на мой взгляд, обсуждаемый. Баги на проде, размытые требования и прочие сопутствующие проблемы разработки мы отловим на Демо, придумаем план митигации на Ретро и внедрим в жизнь на ближайшем Планировании. Но что делать с масштабными ошибками?У Scrum нет понятия архитектуры — предполагается, что всё масштабируется и шестерёнки автоматически совпадают друг с другом. Но зачастую именно этот риск возвращает нас к водопаду и масштабному планированию. При встраивании проекта в существующий ландшафт, объединяющий несколько систем, никаким иным способом, кроме как заранее разобрать систему до винтика, качественный риск не избежать и не минимизировать.

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

А менеджерам-тревожникам хочется напомнить, принятие – это тоже стратегия реагирования на риск. Менеджеры рвут на себе волосы с криками «что делать, что делать», хотя иногда правильный ответ звучит именно так: ничего. Просто принять.Не всё в нашей проектной жизни поддаётся контролю. Регулятор выпустил новое требование - не избежать. Смежная команда живёт в своём ритме - не ускорить. Рынок изменился - не отмотать назад. И в этих случаях осознанное принятие риска - это не слабость и не бездействие. Это взрослое управленческое решение, зафиксированное в реестре.Мораль простая: «принятие» стоит в одном ряду с минимизацией, избеганием и передачей - и не хуже них. А нервы, потраченные на борьбу с неизменяемым, в реестр не внесёшь и не вернёшь.