PMsoop: Глава №11: Определяем риски

В ролях – Менеджер Проекта, Команда Проекта

Артефакты – список рисков

Суть – Менеджер Проекта определяет основные риски проекта

Переходим к следующей цели:

Цель 8. Определить основные риски проекта

Я не буду пытаться в рамках данной главы охватить всю область управления рисками – она слишком обширна. Попробую дать только некоторые общие понятия и рекомендации на тему «что стоит сделать даже для маленьких проектов». Всем желающим изучить область рисков и управления оными подробнее – в Гугл, читать статьи и книжки, и ходить на тренинги. Впрочем, настоящее понимание приходит только с практикой

Начнём с попытки определения, что есть риск. В разной литературе можно встретить разные формулировки, более или менее правильные в зависимости от контекста. Я бы сказал так:

Риск – это некоторый момент неопределённости, который не позволяет со 100% вероятностью предсказать результат управляемого процесса.

Пример риска – неопределённость оценки трудозатрат для некоторой задачи проекта. Задача может быть выполнена как за 8 часов, так и за 12. Поэтому мы не можем уверенно рассчитать срок окончания задачи.

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

Риски есть всегда в любых проектах, это нормально. Всегда есть, например, риск необходимости замены разработчика в процессе разработки, которая может вызвать задержки в сроках по причине необходимости ввода нового разработчика в курс дел. Точность оценок – всегда риск. Почти есть всегда риск при планировании пропустить некоторые задачи, такие как например подготовка среды для заливки кода (об этом позже).

Риски условно можно разделить на критичные и слабо критичные для общего развития проекта. Критичными можно назвать риски, при реализации которых потребуется сдвигать сроки сдачи версии(й) и пересогласовывать новые сроки с Заказчиком, чего Заказчики обычно не любят. Слабо критичным можно назвать риск, при реализации которого особых «телодвижений» делать не придётся. Например, выполнение таска за 10 часов а не за 8 всё равно позволит уложиться в назначенный срок сдачи версии, так как пр планировании были сделаны соответствующие «закладки» по трудозатратам.

Управлением рисками можно назвать выделение рисков и предусмотрение мер их предотвращения, либо ликвидации последствий. Как говорится, «знал бы, где упал – …», вот и пробуем догадаться.

Любимым инструментом управления рисками является создание «закладок» при планировании сроков сдачи версий и всего проекта в целом. Делается это простым образом – для всех задач ставятся максимальные оценки, плюс иногда добавляются «мифические» задачи которые по сути есть «буфер» дополнительного времени. Нормальным размером «закладки» является порядка 15 – 20% от рассчитанного по точным оценкам срока сдачи версии. Такие закладки позволяют справиться с реализацией слабо критичных рисков, а иногда и одиночных критичных рисков, без принятия дополнительных мер.

На практике, закладки в 15 -20% «съедаются» почти всегда за счёт неточности оценок, непредвиденного отсутствия на работе участников проектной команды (болезни и т.п.), ошибок в разработке и планировании. За счёт наличия «закладки» у Разработчика не возникает необходимости просить Заказчика сдвинуть сроки или увеличить бюджет при появлении каждой мелкой проблемы, которые есть фактически всегда. В случае, если закладка не была «съедена» – это время можно потратить на более детальное тестирование и оптимизацию кода версии.

При работе по схеме fixed scope & fixed cost «закладки» обычно больше чем при работе по схеме time & material, так как согласование изменений сроков и бюджета в фиксированной схеме обычно несколько сложнее, а возможностей «поймать» Заказчика для выяснения требований меньше, из-за чего неидеальность требований становится дополнительным риском. Кроме того, размер «закладок» обычно растёт обратно пропорционально качеству требований на момент старта проекта – для компенсации этого же риска.

Ещё раз повторюсь, что «закладки» являются инструментом управления преимущественно слабо критичными рисками. Теперь посмотрим что можно (и нужно) сделать с критичными рисками.

В первую очередь, их нужно определить. То есть, нужно представить возможные ситуации, реализация которых может привести к серьёзным изменениям сроков и бюджета проекта, либо к невозможности проекта. Таких ситуаций может быть очень, очень много – начиная от падения астероида и вплоть до… Поэтому ограничиваем рассмотрение теми ситуациями, на которые можно повлиять, и выписываем их в порядке убывания критичности.

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

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

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

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

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

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

- до старта разработки по возможности провести максимально глубокое исследование сторонних компонент на предмет наличия/отсутствия блокирующих разработку дефектов.

- предусмотреть и прописать в Контракте, либо просто согласовать с Заказчиком, процедуру изменения требований – чтобы для Заказчика изменение сроков по причине изменения требований не было сюрпризом.

Помощь Менеджеру Проекта в определении и поиске инструментов минимизации критических рисков может оказать команда проекта, эксперты и другие сотрудники компании-Разработчика. Если вы в чём то не уверены – можно и нужно задавать вопросы и искать ответы. Кроме того, большинство технических рисков определяются на этапе определения концепции архитектуры и составления таск-листа – вспомните про спорные моменты и оценки с большим разбросом, выясните подробности у специалистов – и оценивайте критичность.

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

Вообще, вся суть управления рисков может быть сведена к старой поговорке «надейся на лучшее, но готовься к худшему». Управление рисками есть в повседневной жизни каждого человека, только не каждый об этом задумывается и называет свои действия умными словами. Прослушать прогноз погоды и взять с собой на улицу зонтик – это тоже пример управления рисками. Риск – намокнуть, зонтик – инструмент минимизации риска.

Многие Менеджеры Проектов управляют рисками неосознанно, просто совершая определённые действия, основанные на предыдущем опыте. Я же, вместе с авторами книжек по Управлению Рисками, рекомендую делать это осознанно – тогда опыт будет лучше усваиваться, и ошибок будет меньше.

Проверка достижения цели – наличие списка определённых критичных рисков и инструментов их минимизации.