Как управлять рисками проекта: советы и шаблон таблицы для анализа

Digital-агентство «Атвинта» пишет про основы управления рисками на примере веб-разработки. Статья будет полезна тем, кто делает первые шаги в риск-менеджменте.

4 октября почти на шесть часов отказали WhatsApp, Instagram и Facebook. В Facebook объяснили, что многочасовой сбой произошел из-за изменений конфигураций магистральных маршрутизаторов, которые координируют сетевой трафик между центрами обработки данных.

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

Последствия известны: акции Facebook упали на 4,89%, состояние Цукерберга снизилось на $5,9 млрд, а к конкурентному мессенджеру Telegram на фоне сбоя присоединились 70 миллионов новых пользователей.

Кейс в масштабах одной из самых крупных IT-компаний мира показывает, насколько важно бизнесу работать с рисками и заранее прорабатывать план работы на случай, если что-то пойдет не так.

Управлять рисками важно не только гигантам вроде нынешней Meta — игнорирование рисков в любой компании приводит к негативным последствиям. Для digital-агентства самые частые:

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

Управлять рисками — это значит при планировании проекта зафиксировать, что может пойти не так, и что с этим делать, если это произойдет.

Чем плох подход, когда мы просто «держим в голове» возможные риски? Во-первых, нет глубокой проработки всех рисков, учитываются только наиболее очевидные. Во-вторых, когда риск случится, команда не всегда сможет оперативно разработать оптимальное решение и найти на него ресурсы.

Зачем работать с рисками:

Первым делом нужно составить список рисков проекта. Они могут быть общими и специфическими. Например, к общим относится отпуск сотрудника — это актуально для любого проекта. К специфическим можно отнести риски, связанные с работой с госзаказчиком, где есть свои стандарты разработки сайтов.

Удобный инструмент — общий реестр рисков. Когда у компании набирается достаточное количество кейсов и практики успешного управления рисками, формируется документ со всеми рисками, которые встречались в проектах компании. Ценность такого инструмента в ретроспективе — так как риски собраны на основе закрытых проектов, команда может более достоверно оценить их вероятность и отметить, как сработали те или иные решения.

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

Приведем примеры рисков, с которыми сталкивались наши проджект-менеджеры:

Некоторые из них мы разберем в разделе «Пример анализа рисков».

Один из самых наглядных и удобных инструментов — реестр рисков, который составляется отдельно для каждого проекта digital-агентства. Для этого мы создаем таблицу со следующими колонками:

За основу взяли следующую матрицу определения рисков:

Особое внимание нужно уделять рискам с красным и оранжевым маркером (существенная, недопустимая степень). Даже если все риски проекта с зеленым маркером, среди них нужно выделить приоритетные.

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

Таблицу можно составлять только для внутреннего пользования или добавлять ее в документацию по проектам.

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

Еще одна рекомендация — сформировать топ-10 рисков проекта, которые всегда будут в поле зрения проджект-менеджера.

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

Когда риск выступает как возможность, а не угроза, можно придерживаться следующих стратегий:

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

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

Проанализируем два риска по таблице выше.

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

Источник: внешний, на стороне заказчика

Ответственный: проджект-менеджер, так как он взаимодействует с заказчиком и контактным лицом

Вероятность: низкая. По опыту нашего агентства, риск случается редко.

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

Степень влияния на проект: по матрице рисков умеренная, желтый маркер.

Степень управляемости: управляемый, так как проджект-менеджер может принять меры для улучшения ситуации

Разберем ситуацию, в которой у дизайнера наступил творческий кризис. Такое случается, например, если заказчик не принимает дизайн-концепцию и дизайнеру не удается попасть в его видение. Он потерян, и не понимает, что делать дальше.

Источник: внутренний, на стороне агентства

Вероятность: низкая. По опыту нашего агентства, риск случается редко.

Ответственный: проджект-менеджер, так как он управляет проектом, является связующим звеном между дизайнером и заказчиком, а также обладает ресурсами для разрешения ситуации.

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

Степень влияния на проект: по матрице рисков терпимая, зеленый маркер.

Степень управляемости: управляемый, так как проджект-менеджер может принять меры для улучшения ситуации

Так будет выглядеть заполненная таблица с рисками:

Ссылка на таблицу для использования.

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

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

Заказчик может не понимать, как устроена проектная деятельность и создание сайта, поэтому объяснять, к чему приведет игнорирование запросов агентства — задача исполнителя.

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

Правки не приняли — объяснили, что это слишком масштабные изменения, которые приведут к срыву сроков. Заказчик понял, что работа более сложная, чем ему виделось, и затягивать разработку не в его интересах. Узнав о последствиях риска, клиент осознал его и согласился с решением уклониться от угрозы.

На крупных проектах есть риск потерять какую-либо информацию, поэтому все нужно фиксировать текстом. Для этого можно создать пространство, где команда будет закреплять все важные аспекты проекта. Например, это можно делать в Notion.

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

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

Отсутствие регламентов и ответственных на крупных проектах ведет к хаосу. Чтобы управлять рисками эффективнее, назначайте ответственного за риск. Им не обязательно будет проджект-менеджер, ответственными могут быть и разработчики, и дизайнеры, и тестировщики.

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

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

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

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

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

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

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

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