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

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

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

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

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

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

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

Устав может корректироваться в ходе реализации проекта. Почему? Например, у бизнеса поменялись цели. Такое бывает: время не стоит на месте, рынок меняется. В управлении проектами нет документов, которые «ламинируются». Любые планы нужно будет обновлять согласно новым вводным. Обратите внимание, что такая же история происходит и со стартапами. Очень редко стартап становится успешен со своей оригинальной идеей. Обычно только в ходе работы становится понятно, что именно нужно рынку. И успеха добиваются те, кто способен быстро адаптировать свою идею под нужды рынка или, если потребуется, полностью изменить ее.

6. Ориентировочный бюджет проекта. В этом пункте указывается объем средств, который заказчик готов потратить на реализацию проекта. 7. Ключевые заинтересованные стороны. Это список людей или организаций, которые активно вовлечены в проект и могут оказывать существенное влияние на проект и его результаты. При этом проект также оказывает влияние на них. Крайне важно в самом начале идентифицировать все ключевые заинтересованные стороны, так как обычно это люди, принимающие решения. Главные требования к проекту будут исходить именно от них. Если в начале проекта менеджер пропустит хотя бы одного такого человека, то рано или поздно он обязательно появится и принесет с собой новые требования. Как правило, они существенно увеличивают содержание работ. Самое страшное происходит в случае, если этот человек появляется на стадии приемки. Тогда проект оказывается в большой беде, так как, скорее всего, многое необходимо будет переделывать. Мы рекомендуем совмещать список заинтересованных сторон с матрицей ответственности, то есть не просто узнать, кто влияет на проект, но и зафиксировать, кто и за что будет отвечать. Пример приведен в таблице 1. Вот и все содержание устава проекта. Но это не так мало, как может показаться на первый взгляд. На то, чтобы составить и согласовать со спонсором устав проекта, может уйти от пары дней до нескольких недель.

проект запущен: 6 июля; API между мобильным приложением и сервером согласованы: 5 сентября; разработка серверного решения завершена и протестирована: 10 октября; разработка мобильного приложения завершена: 4 ноября; тестирование решения завершено: 2 декабря; проект успешно завершен: 12 декабря. Обратите внимание, что ключевые события указываются в прошедшем времени, что дает менеджеру четкое понимание того, выполнены эти задачи или нет. Если писать в настоящем времени («Разработка мобильного приложения: 4 ноября»), не будет понятно, что имелось в виду: мы планировали начать разработку, вести разработку или закончить разработку к 4 ноября. Прошедшее время четко дает понять, что работа должна быть завершена к соответствующей дате.

5. Ключевые и контрольные события. В уставе проекта оговариваются ключевые и контрольные события — важные события в проекте — и то, когда они должны произойти. Например, проект начинается 6 июля. Менеджер планирует, что backend-разработчики должны сделать серверную часть по проверке фотографий из паспортов к октябрю. Для этого нужно успеть за месяц согласовать контракты API между сервером и мобильным приложением. Если удастся, то только в этом случае можно будет закончить мобильное приложение к ноябрю. К этому же времени нужно будет обучить работе с приложением десять первых представителей банка, чтобы те смогли протестировать его в «боевых» условиях. Если все пойдет именно по такому графику, то в начале декабря будут закончены испытания и выпущено приложение. Таким образом, в уставе у нас получится следующая запись. Ключевые и контрольные события: