Цитаты из книг автора «Алексей Минкевич»

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

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

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

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

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

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

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

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

Бывает ИСР, основанная на этапах проекта, когда первый уровень представляет собой фазы проекта. Например, подготовка и согласование технического задания, планирование, исполнение и тестирование. В крупных проектах с участием многих подрядчиков ИСР может базироваться на подрядчиках проекта. Например, компания 1, компания 2, компания 3 и список работ, который выполняет каждая из них. Повторюсь, в подавляющем большинстве проектов ИСР основывается на результатах поставки. Популярный вопрос: когда нужно строить ИСР? Ответ зависит от того, на каком этапе к менеджеру попал проект. Если на этапе тендера, то менеджер сначала строит высокоуровневую ИСР (с грубой оценкой) для подготовки тендерного предложения. Если компания выиграла тендер и готовит договор с соответствующим техническим заданием, то ИСР должна быть более детальной. И если проект уже стартовал и его устав готов, то ИСР должна быть полной и детализированной до уровня пакетов работ. Важно понимать, что ИСР отвечает на вопрос «Что нужно сделать в проекте?», но не отвечает на вопросы о том, в какой последовательности будут выполняться работы, сколько они будут длиться и в какую сумму обойдутся. Ответы на эти вопросы нам дают следующие шаги: оценка и расписание. Поэтому не нужно пытаться располагать работы строго в той последовательности, в которой, по вашему мнению, они будут выполняться. ИСР — очень удобный инструмент для создания статус-отчета по проекту: выполненные работы окрашиваются в зеленый цвет, что дает наглядную картину прогресса проекта. Кстати, еще один важный момент заключается в том, что перед созданием ИСР нужно решить, каким образом она будет храниться, поддерживаться и распространяться. Возможно, это будут стикеры на стене, некий инструмент типа Microsoft Project или Smartsheet, файл где-то в облаке с возможностью общего доступа и редактирования или другой удобный для вас вариант.

Иерархическая структура работ (ИСР) — это список работ, которые необходимо выполнить, чтобы успешно завершить проект. ИСР формируется на базе требований к проекту и отражает только те работы, которые нужно выполнить в ходе проекта. Если в ИСР какой-то работы нет, то она не входит в проект, а значит, делать ее не нужно. Вот определение ИСР из PMBOK: «иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов».