Как подарить конкуренту 70 миллионов пользователей из-за неучтенного риска
4 октября почти на шесть часов отказали WhatsApp, Instagram и Facebook. В Facebook объяснили, что многочасовой сбой произошел из-за изменений конфигураций магистральных маршрутизаторов, которые координируют сетевой трафик между центрами обработки данных.
Если судить по новостям, компания не была готова к проблеме — кроме самого сбоя на сотрудников свалилось еще множество трудностей. Они не могли попасть в дата-центр, так как у них не срабатывали электронные пропуска, а также в штаб-квартире не работали внутренние службы, что затянуло исправление сбоя.
Последствия известны: акции Facebook упали на 4,89%, состояние Цукерберга снизилось на $5,9 млрд, а к конкурентному мессенджеру Telegram на фоне сбоя присоединились 70 миллионов новых пользователей.
Кейс в масштабах одной из самых крупных IT-компаний мира показывает, насколько важно заранее прорабатывать стратегию управления рисками компании на случай, если что-то пойдет не так.
Риски в digital-агентстве
Управлять рисками важно не только гигантам вроде нынешней Meta — игнорирование рисков в любой компании приводит к негативным последствиям. Основные виды рисков для digital-агентства:
- срыв сроков
- снижение качества разработки
- разлад в команде
- снижение доверия клиента
- ухудшение репутации
Если в компании управление рисками не закреплено как процесс, и у нее нет соответствующих методик и регламентов, то риски в какой-то степени все равно учитываются, но интуитивно. Например, при планировании контуров проекта проджект-менеджер держит в голове, что согласование или разработка могут затянуться, и закладывает дополнительное время на такой случай.
Управлять рисками — это значит при планировании проекта зафиксировать, что может пойти не так, и что с этим делать, если это произойдет.
Чем плох подход, когда мы просто «держим в голове» возможные риски? Во-первых, нет глубокой проработки всех рисков, учитываются только наиболее очевидные. Во-вторых, когда риск случится, команда не всегда сможет оперативно разработать оптимальное решение и найти на него ресурсы.
Зачем проводить оценку рисков в организации:
- Команда будет готова к ситуациям, которые могут снизить качество проекта или задержать его реализацию
- Команда сможет контролировать риск, устранить, уменьшить или использовать его последствия
- На этапе продаж агентство может делать более точную оценку проекта, заложив в нее наиболее вероятные риски
- При составлении календарного плана проджект-менеджер будет знать, где необходимо подстраховаться и заложить дополнительное время
Как можно выявить риски
Первым делом нужно составить список рисков проекта. Они могут быть общими и специфическими. Например, к общим относится отпуск сотрудника — это актуально для любого проекта. К специфическим можно отнести риски, связанные с работой с госзаказчиком, где есть свои стандарты разработки сайтов.
Способы выявления рисков
- Спросить коллег, у которых были аналогичные проекты. Самый простой способ — проанализировать опыт других проджект-менеджеров, которые уже работали с похожим проектом.
- Поговорить с заказчиком. Проект — это совместная работа команды и заказчика, поэтому он должен понимать, что риски зависят и от него. Заказчик лучше знает свои бизнес-процессы и заранее может сообщить, что в них может пойти не так. Например, один из наших клиентов предупредил, что из-за большой цепочки лиц, принимающих решения, согласование будет долгим, поэтому в договоре мы заложили 12 дней на согласование этапов, хотя обычно фиксируем меньшее количество времени.
- Обсудить с командой. Разработчики и дизайнеры заранее могут выявить риск, связанный с их частью работы.
- Подумать об интеграциях. Интеграция — узкое место любого проекта, которое всегда связано с риском, потому что зависит не только от исполнителя, но и от заказчика. Например, при подключении платежных систем может понадобиться заключить договор. Также заранее нужно получать доступы и требования к серверам.
- Учесть специфику заказчика (особенно, если это государственные проекты). Например, если команда делает сайт для государственной структуры, то на нем обязательно должна быть версия для слабовидящих.
- Учесть человеческий фактор. Внутренние моменты в команде несут большие риски: выгорание, конфликты и другие проблемы сотрудников могут навредить проекту.
Удобный инструмент — общий реестр рисков. Когда у компании набирается достаточное количество кейсов и практики успешного управления рисками, формируется документ со всеми рисками, которые встречались в проектах компании. Ценность такого инструмента в ретроспективе — так как риски собраны на основе закрытых проектов, команда может более достоверно оценить их вероятность и отметить, как сработали те или иные решения.
Например, во время проекта уволился сотрудник, и компания передала его часть работы проверенному аутсорсеру. Проект закрыт успешно, подход сработал удачно, значит, и в будущем этот риск можно решать привлечением стороннего специалиста.
Риски в проектах digital-агентства
Приведем примеры рисков, с которыми сталкивались наши проджект-менеджеры:
- Заказчик не готов менять свои бизнес-процессы
- Незаинтересованность контактного лица в проекте
- Смена менеджера со стороны заказчика или с нашей стороны в процессе проекта
- Недостаточная квалификация исполнителей проекта или контактного лица
- Увольнение или болезнь сотрудников
- Ошибки календарного плана
- Изменение требований заказчика в процессе проекта
- Низкая производительность команды
- Творческий кризис у дизайнера
- Несвоевременное предоставление доступов со стороны заказчика (например, к платежной системе)
- Разлад в команде
Анализируем риски по таблице
Один из самых наглядных и удобных инструментов управления рисками проектов — реестр рисков, который составляется отдельно для каждого проекта digital-агентства. Для этого мы создаем таблицу со следующими колонками:
- Риск — обозначаем название риска
- Источник — может быть внешним или внутренним (внутренний исходит от агентства, внешний — от других участников проекта, например, заказчика)
- Ответственный — проджект-менеджер, специалист команды, контактное лицо со стороны заказчика и т.д.
- Вероятность — может быть низкой, средней или высокой, определяется на основе опыта агентства (например, сотрудник уходит на больничный в одном из десяти проектов, значит, вероятность низкая) или оценки от проджект-менеджера, который учитывает специфику проекта
- Последствия — критичные, умеренные или незначительные
- Степень влияния на проект — определяем по матрице рисков на основе соотношения вероятности и последствий. По ней риск может быть незначительным, допустимым, умеренным, существенным, недопустимым.
За основу взяли следующую матрицу определения рисков:
Особое внимание нужно уделять рискам с красным и оранжевым маркером (существенная, недопустимая степень). Даже если все риски проекта с зеленым маркером, среди них нужно выделить приоритетные.
- Степень управляемости — управляемый или неуправляемый, зависит от того, может ли команда своими действиями повлиять на риск
- Что делать с риском — определяем действия на случай, если риск произошел
Лучше заполнять таблицу исходя из приоритетности: риски из оранжевой и красной зоны идут в первую очередь, а менее опасные риски - после.
Таблицу можно составлять только для внутреннего пользования или добавлять ее в документацию по проектам.
Актуализировать риски рекомендуется раз в две недели. Если проект будет длиться полгода, то к третьему месяцу перечень рисков может измениться: какие-то риски станут более вероятны, а какие-то, наоборот, совсем минуют проект.
Еще одна рекомендация — сформировать топ-10 рисков проекта, которые всегда будут в поле зрения проджект-менеджера.
Если риск случился
Самая важная графа в таблице — с действиями, которые мы будем выполнять, когда риск станет реальной ситуацией. План помогает действовать оперативно и заранее запланировать ресурсы не только на проект, но и на случай форс-мажора.
Варианты действий:
- Уклониться. Например, риск — слабый разработчик на проекте. В этом случае можно запросить более сильного разработчика и устранить риск.
- Передать третьей стороне. Если заказчик не предоставляет необходимую для проекта информацию, то можно объяснить ему, что без нее дальнейшая разработка невозможна. Так мы передаем риск заказчику.
- Снизить вероятность или силу риска. В одном из наших проектов на макете был разработан слишком сложный дизайн, который бы затянул сроки разработки. Чтобы снизить вероятность этого риска, мы упростили макет.
- Принять риск, но подготовить план. Например, если проджект-менеджер уходит на больничный, он может погрузить другого человека в проект и передать дела ему. Так мы принимаем риск, но имеем план на случай угрозы.
- Эскалация. Подключаем руководство, чтобы противостоять угрозе.
Когда риск выступает как возможность, а не угроза, можно придерживаться следующих стратегий:
- Использовать. Принять меры, чтобы возможность реализовалась.
- Увеличить. Повысить вероятность наступления события или силу его воздействия.
- Принять. Подготовить план использования возможности, но при этом не предпринимать действий для повышения вероятности события.
Пропишите действия по каждому риску, а также подготовьте ресурсы для них.
Вернемся к примеру с заболевшим сотрудником — если вы рассматриваете возможность замены заболевшего сотрудника аутсорсером, то необходимо найти контакты профессионала с портфолио, которое соответствует задачам проекта. Когда решение нужно принимать срочно, вам вряд ли удастся быстро найти хорошую замену члену команды.
Пример оценки рисков компании
Проанализируем два риска по таблице выше.
Риск № 1: незаинтересованность контактного лица в проекте
Разберем ситуацию, в которой заказчик перевел коммуникацию на сотрудника с низкой заинтересованностью и вовлеченностью в проект.
Источник: внешний, на стороне заказчика
Ответственный: проджект-менеджер, так как он взаимодействует с заказчиком и контактным лицом
Вероятность: низкая. По опыту нашего агентства, риск случается редко.
Последствия: критичные. Если контактное лицо не будет предоставлять необходимую информацию, присутствовать на созвонах и проводить согласование, проект окажется на грани срыва.
Степень влияния на проект: по матрице рисков умеренная, желтый маркер.
Степень управляемости: управляемый, так как проджект-менеджер может принять меры для улучшения ситуации
Действия:
- объяснить ответственность и последствия низкой вовлеченности в проект (контактному лицу важно отчитаться перед руководством о проделанной работе)
- эскалировать — сообщить о проблеме руководителю контактного лица, попросить заменить контактное лицо
Риск № 2: творческий кризис у дизайнера
Разберем ситуацию, в которой у дизайнера наступил творческий кризис. Такое случается, например, если заказчик не принимает дизайн-концепцию и дизайнеру не удается попасть в его видение. Он потерян, и не понимает, что делать дальше.
Источник: внутренний, на стороне агентства
Вероятность: низкая. По опыту нашего агентства, риск случается редко.
Ответственный: проджект-менеджер, так как он управляет проектом, является связующим звеном между дизайнером и заказчиком, а также обладает ресурсами для разрешения ситуации.
Последствия: умеренные. Творческий кризис может привести к тому, что заказчик не согласует дизайн-концепцию, или дизайнеру потребуется больше времени на работу. Последствия достаточно весомые, но не критичные.
Степень влияния на проект: по матрице рисков терпимая, зеленый маркер.
Степень управляемости: управляемый, так как проджект-менеджер может принять меры для улучшения ситуации
Действия:
- привлечь руководителя, чтобы расширить круг ответственных и осведомленных о риске сотрудников
- провести брейншторм с дизайнерами
- составить мудборд, чтобы синхронизироваться по стилистике и видению дизайна, цветов, иллюстраций с заказчиком
- принять помощь другого дизайнера
- заменить дизайнера
Так будет выглядеть заполненная таблица с рисками.
Ссылка на таблицу для использования.
Способы минимизации рисков: 5 советов из нашей практики
Чтобы снизить вероятность того, что риск произойдет, можно проводить «профилактику». Для этого нужно добавить особые действия в ежедневную работу команды и коммуникацию с заказчиком. Расскажем, какие из способов снижения проектных рисков работает у нас.
Держите заказчика в курсе рисков и объясняйте его ответственность
Некоторые задачи проекта ложатся на клиента, и во время коммуникации мы объясняем его ответственность в этой части. Например, если команда не получит контент, то мы не сможем приступить к дизайну и разработке.
Заказчик может не понимать, как устроена проектная деятельность и создание сайта, поэтому объяснять, к чему приведет игнорирование запросов агентства — задача исполнителя.
Другая частая ситуация — когда на этапе разработки заказчик хочет добавить еще одну функцию. Например, сейчас мы делаем образовательную игру, где заказчик уже в процессе разработки попросил добавить одно условие. Оно предполагало создание новых сценариев и огромный пул дополнительных работ с коррекцией того, что уже сделано.
Правки не приняли — объяснили, что это слишком масштабные изменения, которые приведут к срыву сроков. Заказчик понял, что работа более сложная, чем ему виделось, и затягивать разработку не в его интересах. Узнав о последствиях риска, клиент осознал его и согласился с решением уклониться от угрозы.
Фиксируйте все договоренности текстом
На крупных проектах есть риск потерять какую-либо информацию, поэтому все нужно фиксировать текстом. Для этого можно создать пространство, где команда будет закреплять все важные аспекты проекта. Например, это можно делать в Notion.
Чтобы вся важная информация была под рукой, создайте вики проекта. На скрине выше пример возможного наполнения, которое может варьироваться в зависимости от потребностей проекта и команды.
Оценивайте задачи и закладывайте коэффициент неопределенности
При расчете объема работ полезно закладывать коэффициент неопределенности на случай, если что-то пойдет не так, и реализовавшиеся риски продлят выполнение задач. На скрине ниже — один из примеров, где коэффициент неопределенности помог правильно скорректировать объем работ и попасть в точку с итоговым количеством часов.
Назначайте ответственных и составляйте регламенты
Отсутствие регламентов и ответственных на крупных проектах ведет к хаосу. Чтобы управлять рисками эффективнее, назначайте ответственного за риск. Им не обязательно будет проджект-менеджер, ответственными могут быть и разработчики, и дизайнеры, и тестировщики.
Сотрудник должен понимать и принимать ответственность, нести ее. Для этого закрепляйте ответственных в таблице и во время митингов ставьте сотрудника в курс дела, чтобы он был внимателен к рискам, которые находятся под его контролем.
В долгих и крупных проектах может затеряться важная информация, и на этот случай лучше иметь памятку. Здесь пригодятся регламенты. Их можно фиксировать в чате или пространстве проекта, как мы показывали выше, чтобы они всегда находились под рукой.
При работе нескольких дизайнеров на проекте важно договориться о различных правилах при помощи UI-кита. Например, закрепить стандарты отступов на макетах и выделить ведущего дизайнера. Это поможет уменьшить влияние риска, связанного с работой нескольких дизайнеров и получить единообразные макеты.
Также можно фиксировать и мелкие организационные инструкции. Например, план бронирования переговорок, чтобы члены команды знали заранее, когда и куда идти.
Не забывайте про баланс: слишком много регламентов — это тоже плохо. Если чересчур контролировать разработчиков или дизайнеров, можно задушить инициативу, и тогда сотрудники перестанут разбираться в вопросах самостоятельно.
Если пытаться предотвратить все риски, можно стать параноиком
Сформируйте адекватное отношение к рискам, это поможет спокойно заниматься проектом и относиться к угрозам как к рутине. Все риски предотвратить нельзя — какие-то из них можно игнорировать, но держать в поле зрения до того момента, пока они не станут критичными.
Введите управление рисками как один из рутинных процессов работы с проектом, тогда вероятность негативного события не потревожит команду, ведь у нее будет понятный план действий на случай, если что-то пойдет не так.
Подведем итоги
- Введите управление рисками, чтобы повысить эффективность ведения проекта, не срывать сроки и сохранить репутацию агентства, проводите расчет рисков
- Составляйте реестр рисков по каждому проекту
- Проводите анализ рисков в управлении проектами по таблице
- Уделите особое внимание проработке плана действий на случай возникновения угроз и возможностей
- Ведите общий реестр рисков для будущих проектов
- Группируйте риски по степени влияния на проект, риски с оранжевым и красным маркером должны находиться под особым контролем
- Актуализируйте риски проекта каждые две недели и формируйте топ-10 рисков, которые должны быть в поле зрения команды
- Регулярно проводите работу по предотвращению рисков, например, закрепляйте регламенты и разъясняйте заказчику последствия угроз
- Не становитесь параноиком — все риски все равно предотвратить нельзя
В комментариях предлагаем поделиться рисками, которые встречались в вашей практике, и рассказать, какие действия вы предприняли для их разрешения.
