Цитаты из книг автора «Сергей Дерцап»

Итак, представим, что у нас уже есть список рисков и мы знаем, как они могут сказаться на проекте. Теперь нужно определиться с тем, как на них реагировать. Существует пять стратегий реагирования. Эскалация (Escalation). Руководитель проекта эскалирует риск на следующий уровень менеджмента — руководителя программы или портфеля проектов. Эскалировать риск нужно в том случае, если команда или спонсор проекта понимает, что работать с риском на уровне проекта нет возможности. Вы не просто должны сообщить о риске вышестоящему руководителю, но и убедиться, что он принял на себя владение этим риском. После эскалации команда проекта не ведет мониторинг риска, хотя эта угроза может быть внесена в реестр рисков для информации. Уклонение (Avoid). В этом случае за рамки проекта выводятся те работы, которые содержат этот риск, — их не делают вообще. Таким образом, риски просто исчезают. Рассмотрим эту стратегию на примере. При обсуждении устава проекта с заказчиком менеджер понимает, что один из компонентов поставки нереально сделать к сроку, на котором настаивает заказчик. У него два варианта действий: взять на себя этот риск и попытаться с ним работать; предложить вынести этот компонент поставки за рамки данного проекта. Важно понимать, что при исключении рисков из проекта исключаются и возможности, с которыми риски ходят рука об руку. Передача (Transfer). Риск можно передать, например, субподрядчику. Допустим, у менеджера есть сомнения в том, что его команда справится с частью работы, но он знает, что есть компания, которая обладает для этого достаточным уровнем квалификации. В этом случае можно передать сложную работу ей. Важно помнить, что при этом менеджер все равно несет ответственность за результат работы перед заказчиком. На субподрядчика она не перекладывается. Снижение (Mitigate). Вероятность наступления риска можно попытаться снизить. Например, менеджер видит, что ключевой сотрудник (пусть это будет архитектор) уже несколько раз приходил на работу в костюме, а в течение дня куда-то отпрашивался. Скорее всего, он ищет новую работу и посещает интервью. Оценим вероятность этого риска в 40%. Если он все же уйдет, то на поиск и адаптацию нового специалиста уйдет время, а это могут быть потери, например, в 35 000 единиц. Можно попытаться снизить вероятность этого риска — например, пообещав архитектору премию за успешное завершение проекта. И вот уже вероятность его ухода падает с 40% до 10%, так как теперь он мотивирован довести проект до конца.

Для того чтобы оценить степень влияния риска на проект, ему следует присвоить рейтинг (severity). Рассчитывается он по формуле: Рейтинг риска = вероятность риска × влияние риска. Матрица вероятности и воздействия — это инструмент, который сопоставляет вероятность возникновения и влияние риска. В зависимости от правил компании могут использоваться описательные или числовые значения. Давайте посчитаем рейтинг риска. Сделать это можно по образцу таблицы, показанной на рисунке 13. После того как вы посчитали рейтинги рисков, нужно отобрать самые опасные и отслеживать именно их. Для чего? По закону Парето, 20% рисков несут в себе 80% проблем. Соответственно, если мы будем контролировать 20% самых опасных рисков, то сможем избежать 80% проблем.

Качественный анализ рисков — это процесс определения приоритетов рисков в соответствии с их потенциальным влиянием на достижение целей проекта. Для этого оценивают и суммируют вероятности наступления выявленных рисков и их последствия для проекта. Что нужно сделать: оценить вероятность наступления каждого риска. На этом этапе рекомендуется использовать только порядок вероятности (низкая, средняя, высокая), а не конкретные значения; определить последствия: сколько дополнительных средств или времени понадобится, если риск реализуется. Здесь также можно использовать определение на уровне порядка: низкие, средние, высокие; расставить приоритеты рисков на основании вероятности их наступления, последствий, а также критичности; выявить риски, которыми можно управлять и которые требуют внимания в первую очередь. Результатом этого процесса станет обновленный реестр рисков, где появится информация о приоритетности и возможных последствиях.

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

Для идентификации рисков можно использовать следующие инструменты. Мозговой штурм. Это практика, которая подразумевает творческое состояние и творческий способ мышления. В мозговом штурме участвуют команда проекта и модератор. Существует множество подходов к организации мозгового штурма, некоторые мы рассмотрим далее. Важно понимать общие правила проведения и суть метода. Задача команды — генерировать идеи в рамках условий, озвученных модератором. Задача модератора — определять канву для идей и следить за соблюдением базовых правил. Правила очень простые: любая идея, даже самая невероятная, поощряется. Критика на данном этапе недопустима. Мозговой штурм требует определенного уровня доверия между членами команды, ведь никто не хочет выглядеть глупо в глазах своих коллег. Поэтому если кто-то вдруг начинает критиковать идеи, то люди закрываются и мозговой штурм может провалиться. Карточки Кроуфорда. Одна из техник мозгового штурма. Всем членам команды раздают карточки и просят написать один самый значимый, по их мнению, риск проекта. Заполненные карточки помещаются в центр стола. Затем все повторяется 5–10 раз с единственным условием: нельзя указывать риски, которые участник написал в предыдущих итерациях. Этот подход позволяет избежать влияния одного авторитетного члена команды на остальных и дает возможность высказаться всем. Это важно, если в процессе участвует, например, генеральный директор. В таком случае все может свестись лишь к его опросу, так как остальные будут стесняться озвучивать свои мысли. После генерации идей их категоризируют и обсуждают. Метод «Дельфи». Техника объединяет в себе опрос экспертов и мозговой штурм. Экспертами могут быть как члены команды, имевшие опыт работы над подобным проектом, так и внешние по отношению к команде специалисты с релевантным опытом. Такой подход отнимает гораздо больше времени, но зато исключает влияние членов команды друг на друга за счет того, что на первом этапе проводится индивидуальный опрос экспертов для формирования общей картины. При выявлении противоречий опросник редактируется и уточняется, чтобы лучше понимать природу этих противоречий. На последнем этапе, когда собранные данные позволяют объединить и сблизить мнения экспертов, проводится мозговой штурм для генерации решений. Данные методы не привязаны только к идентификации рисков и могут применяться на всех этапах проекта, где нужны творческий подход и нестандартные решения.

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

Для чего нужно планирование? Убедиться, что все заинтересованные стороны одинаково понимают, что такое риск: на какие события нужно реагировать, а какие можно оставить без внимания. Договориться о доступных команде инструментах, которыми она обязательно будет пользоваться при управлении рисками. Часто возникает ситуация, когда команда, только увидев весь арсенал инструментов для управления рисками, собирается использовать их все: метод Дельфи, диаграмму «торнадо», метод Монте-Карло и т.д. Когда же дело доходит до их применения, то оказывается, что мало кто знает, как ими пользоваться. И тогда уже команда невольно старается отложить эти активности на потом. Ведь требуется больше усилий, чтобы сначала погрузиться в вопрос, а затем научиться применять новые знания на практике. Когда же инструмент знаком, то им пользуются охотнее, а результаты появляются намного быстрее. Договориться о минимальном времени, которое команда готова тратить на управление рисками. Важно определить именно минимальное время на эту активность. В самом начале проекта, когда команда еще полна энтузиазма, она, например, может принять решение проводить двухчасовые встречи по управлению рисками еженедельно. Правда, обычно от этой идеи легко отказываются при первом же сомнении, что время тратится с пользой. В то же время договоренность встречаться минимум раз в две недели на 30 минут выполнить проще. В этом чаще видят пользу. Определить уровень толерантности к рискам заинтересованных сторон проекта, в том числе и организации-заказчика. Толерантность к рискам индивидуальна, поэтому иногда два человека, говорящих об одном и том же событии, абсолютно не понимают друг друга. Вернемся к примеру с рулеткой. Сколько вы готовы поставить на красное? А на зеро? Представьте себе, что руководитель проекта предлагает спонсору поставить на красное X условных единиц, чтобы использовать выигрыш для компенсации сверхурочного времени, которое потратила команда для возвращения проекта в запланированное расписание. Если спонсор — азартный человек, который ежедневно делает ставки, в несколько раз превышающие Х, то ему это предложение может показаться весьма здравым. Если же спонсор — человек не азартный и за квартал обходит казино, то, скорее всего, менеджер будет уволен.

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

Даже если вы провели прекрасную работу по сбору и утверждению требований, вам следует постоянно быть готовым к изменениям. Бизнес меняется, и его требования меняются тоже. И когда вас как менеджера проекта просят внести изменения, не нужно отказываться, ссылаясь на подписанные ранее документы. Если бизнесу что-то потребовалось, то у него на это есть свои причины. И если новые требования отвечают целям бизнеса, то нужно их принимать и согласовывать вместе со всеми изменениями в содержании работ, бюджете и расписании. Не бывает проектов, в которых не было бы изменений. Даже если речь о небольшом двухнедельном спринте, то, скорее всего, даже на этом отрезке появятся какие-то корректировки. Изменения — это хорошо, мы им рады и умеем ими управлять, но об этом будет отдельная глава. Работая по модели с MVP (минимально жизнеспособный продукт) и прототипом, мы много раз сталкивались с одним интересным заблуждением. MVP или прототип — это быстро созданные решения, которые слабо масштабируются. Несколько таких решений могут накладываться друг на друга, что со временем затрудняет очередное расширение функционала. Это ведет к необходимости переделывать часть программы. При этом заказчик уверен, что у него уже есть полный функционал, который работает замечательно. Менеджер должен предупреждать заказчика о подобных рисках.

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