Каким образом – рассказывает эксперт Максим Якубович.

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

На главной оси откладывается потенциальная проблема – например, срыв сроков
проекта. На больших «костях» диаграммы откладываются источники возникновения
риска.

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

Все записи на диаграмме – это и есть риски проекта, которые, однако, надо еще
правильно сформулировать. Правильная формулировка должна включать в себя
описание условия возникновения риска и его последствия.

К примеру, на диаграмме есть запись такого последствия, как «Болезни членов
команды». Как правильно сформулировать риск?

Можно сформулировать так:

Эпидемии инфекционных заболеваний в зимний период приведут к болезням членов
команды проекта.

Или так:

Жаркое лето вызовет необходимость использования кондиционеров в офисе, что
приведет к болезням участников проекта.

Как видим, последствие у риска одно, а условия возникновения – разные.

Давайте сформулируем риски «Изменения требований» для источника «Заказчик
проекта»:

1. Недостаточно глубокая проработка требований на старте проекта приведет к
необходимости изменения требований по ходу проекта.
2. Сложность понимания заказчиком требований к продукту проекта приведет к
частым изменениям требований по ходу получения первых результатов.

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

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

Диаграмма Исикавы – базовый инструмент для поиска причинно-следственных связей
по рискам. С ее помощью мы заставляем себя думать о рисках и искать причины их
возникновения.

Еще один простейший способ поиска рисков – изучение документов по проекту,
таких как иерархическая структура работ (ИСР) проекта, техническое задание на
продукты проекта, поиск аналогичных проектов в архиве компании. Если
руководители похожих по содержанию проектов вели «Журнал проблем» в проекте или
хотя бы написали «Усвоенные уроки» – это уже хороший источник для идентификации
рисков.

Следующий способ – это поиск и изучение отраслевых классификаторов рисков.
Это, по сути, отрефлексированный опыт отрасли. Такие классификаторы очень
полезны – ничего выдумать не надо, риски из отраслевого классификатора
рассматриваем как риски нашего проекта.

Хорошим примером классификатора рисков я считаю документ, выпущенный SEI
(Software Engineering Institute) под названием Taxonomy-Based Risk
Identification. Документ описывает три класса рисков для софтверных проектов,
каждый класс декомпозируется на элементы и атрибуты.

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

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

Думайте о рисках.

Максим Якубович, www.probusiness.by