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

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

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

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

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

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

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

• срыв сроков
• снижение качества разработки
• разлад в команде
• снижение доверия клиента
• ухудшение репутации

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

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

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

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

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

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

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

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

• Обсудить с командой. Разработчики и дизайнеры заранее могут выявить риск, связанный с их частью работы.

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

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

• Учесть человеческий фактор. Внутренние моменты в команде несут большие риски: выгорание, конфликты и другие проблемы сотрудников могут навредить проекту.

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

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

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

• Заказчик не готов менять свои бизнес-процессы
• Незаинтересованность контактного лица в проекте
• Смена менеджера со стороны заказчика или с нашей стороны в процессе проекта
• Недостаточная квалификация исполнителей проекта или контактного лица
• Увольнение или болезнь сотрудников
• Ошибки календарного плана
• Изменение требований заказчика в процессе проекта
• Низкая производительность команды
• Творческий кризис у дизайнера
• Несвоевременное предоставление доступов со стороны заказчика (например, к платежной системе)
• Разлад в команде

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

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

• Риск — обозначаем название риска
• Источник — может быть внешним или внутренним (внутренний исходит от агентства, внешний — от других участников проекта, например, заказчика)
• Ответственный — проджект-менеджер, специалист команды, контактное лицо со стороны заказчика и т.д.
• Вероятность — может быть низкой, средней или высокой, определяется на основе опыта агентства (например, сотрудник уходит на больничный в одном из десяти проектов, значит, вероятность низкая) или оценки от проджект-менеджера, который учитывает специфику проекта
• Последствия — критичные, умеренные или незначительные
• Степень влияния на проект — определяем по матрице рисков на основе соотношения вероятности и последствий. По ней риск может быть незначительным, допустимым, умеренным, существенным, недопустимым.

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

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

• Степень управляемости — управляемый или неуправляемый, зависит от того, может ли команда своими действиями повлиять на риск
• Что делать с риском — определяем действия на случай, если риск произошел

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

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

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

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

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

• Уклониться. Например, риск — слабый разработчик на проекте. В этом случае можно запросить более сильного разработчика и устранить риск.

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

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

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

• Эскалация. Подключаем руководство, чтобы противостоять угрозе.

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

• Использовать. Принять меры, чтобы возможность реализовалась.

• Увеличить. Повысить вероятность наступления события или силу его воздействия.

• Принять. Подготовить план использования возможности, но при этом не предпринимать действий для повышения вероятности события.

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

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

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

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

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

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

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

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

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

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

• объяснить ответственность и последствия низкой вовлеченности в проект (контактному лицу важно отчитаться перед руководством о проделанной работе)
• эскалировать — сообщить о проблеме руководителю контактного лица, попросить заменить контактное лицо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Введите управление рисками, чтобы повысить эффективность ведения проекта, не срывать сроки и сохранить репутацию агентства
• Составляйте реестр рисков по каждому проекту
• Анализируйте риски по таблице
• Уделите особое внимание проработке плана действий на случай возникновения угроз и возможностей
• Ведите общий реестр рисков для будущих проектов
• Группируйте риски по степени влияния на проект, риски с оранжевым и красным маркером должны находиться под особым контролем
• Актуализируйте риски проекта каждые две недели и формируйте топ-10 рисков, которые должны быть в поле зрения команды
• Регулярно проводите работу по предотвращению рисков, например, закрепляйте регламенты и разъясняйте заказчику последствия угроз
• Не становитесь параноиком — все риски все равно предотвратить нельзя

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