Поговорим о рисках
Что такое риски? Что является риском, а что нет? Как учитывать риски при оценке трудоёмкости ПО и планировании проекта? Об этом я предлагаю поговорить в этом топике. В то же время, чтобы не раздувать топик и не повторяться, здесь не будут обсуждаться вопросы идентификации и митигации рисков — действий по выявлению, уменьшению вероятности возникновения рисков и минимизации их последствий.
После публикации статьи о смертных грехах в оценке трудоёмкости программного обеспечения мне указали, что ни автор, ни я ничего не сказали о рисках. Хочу исправить это досадное недоразумение и поведать вам немного о рисках и моём опыте работы с ними.
Типичные риски
Ниже приведу список типичных для проекта по разработке ПО рисков.
- отвлечение сотрудников от текущего проекта к работам с других проектов
- болезни, внеочередные отпуска, свадьбы, беременность, отгулы и пр.
- необоснованная задержка согласования требований
- непредсказуемое изменение/расширение требований со стороны заказчика
- использование относительно новых технологий в разработке
- уход ключевых разработчиков/архитекторов
- изменение ключевых сотрудников/представителей на стороне заказчика
Что НЕ является риском
Является ли риском глобальное потепление? А изменение ситуации на рынке? А возможный распад компании заказчика или, не дай Бог, вашей компании?
Правильнее спросить так: «Какие из этих рисков нужно учитывать в вашем проекте?»
Как-то мы проводили оценки трудоёмкости очередного проекта. Обжегшись на недавнем проекте, мы постарались заложить в оценку будущего проекта как можно большое рисков. Получился очень внушительный список.
Просмотрев этот список, мой предыдущий руководитель и наставник сказал нам: «Не надо закладывать свой непрофессионализм в риски!» Как? Меня и моих коллег обвинили в непрофессионализме?! Я тогда немного обиделся на него. Мы были вынуждены исключить довольно много пунктов, которые нам действительно казались рисками. С тех пор прошло некоторое время, я немного остыл, почитал книги, переосмыслил свой предыдущий опыт. Теперь я могу сказать, что вынужден с ним согласиться по ряду пунктов. Итак, перечислю некоторые случаи, которые не стоит считать рисками.
Риски, вероятность которых стремится к 100%
- недостаточная квалификация сотрудников — это не риск по той причине, что квалификация должна изначально закладываться в оценки (например, используя фокус-фактор)
- регулярные отпуска сотрудников — их можно спрогнозировать более или менее заранее и внести в план проекта
- прогнозируемые изменения требований — могут возникать в случае выбора определённой модели разработки (например, Fixed Team)
Риски, вероятность которых стремится к 0
Этот список может показаться немного надуманным. Он приведён только для иллюстрации возможных «невероятных» рисков. Важно понимать, что одни и те же риски могут становиться невероятными в зависимости от характера проекта и его продолжительности.
- изменение существующего законодательства, в течение времени реализации краткосрочных проектов
- полная потеря исходных кодов проекта
Работы, которые являются частью проекта или методологии
- ревью кода — бывает, что эту активность относят к рискам
- рефакторинг — говорят так: «может потребоваться рефакторинг». Слово «может» сбивает с толку и наталкивает на мысль, что это риск. По сути же, рефакторинг относится к тем работам, которые планируют заранее.
Учёт рисков при планировании
Тут нужно сделать небольшое лирическое отступление и объяснить, почему риски необходимо учитывать. Как говорил Том Де Марко, "чтобы управлять проектом, достаточно управлять его рисками". Но! Это касается момента, когда проект уже стартовал. Когда есть, чем управлять. А теперь представим, что оценка и планирование проекта ведётся ещё до его старта. И вообще неизвестно, будет ли проект запущен или нет. Нужно ли учитывать риски на этом этапе? И да, и нет…
С одной стороны, на начальном этапе, обладая недостаточной информацией, мы можем как перезаложиться на риски, так и недооценить их. С другой стороны, это не повод совсем их игнорировать. Приходится искать разумный баланс и всё же каким-то образом учитывать наиболее существенные для данного проекта риски, которые мы идентифицировали ещё в самом начале.
Определение терминов
Введём понятие «чистой трудоёмкости»
Чистую трудоёмкость определим как трудоёмкость в «идеальных человеко-днях», необходимую для реализации той или иной задачи. Для объяснения, что же здесь имеется в виду, я воспользуюсь описанием, взятым из книги Scrum and XP from the Trenches от опытного Scrum Master'а Henrik Kniberg'а. Итак:
"Идеальный человеко-день – это максимально продуктивный день, когда никто и ничто не отвлекает от основного занятия. Такие дни – редкость." (с) Henrik Kniberg
Другими словами, будем считать, что задача обладает такой трудоёмкостью при условии, что ни один из рисков не реализуется.
Равномерное распределение рисков по задачам или методика «спрятанной шляпы»
В качестве «вводной» приведу анекдот, рассказанный нам одним из топ-менеджеров в ответ на представленные оценки недавнего проекта:
Сотрудник приезжает из командировки, подаёт expense report, а там, среди прочего, значится «Шляпа: $100»
Его в бухгалтерии спрашивают…
— Что за шляпа такая?
— Ну купил себе шляпу… классная… все дела.
— $%&*#! Иди меняй отчет!
Ну приносит новый, там опять «Шляпа: $100»
Ну опять "$%&*#!", иди меняй, чтобы не было никакой шляпы.
Приносит… Смотрят — нормально все… не подкопаешься, шляпы нет… но сумма финальная как была так и осталась.
Спрашивают:
— А шляпа где?
— Да там она… там… только вы ее хрен найдете!
Так вот, подобный метод можно применить и при учёте рисков.
Например, один или несколько рисков, выраженные в виде некой дополнительной трудоёмкости, можно просто равномерно распределить по остальным конкретным задачам, как указано на фрагменте диаграммы Ганта ниже:
Здесь синим цветом обозначены прямоугольники задач с чистой трудоёмкостью. Подписи — назначенные на задачи ресурсы (люди). Красным цветом обозначим прямоугольник, в котором сосредоточена трудоёмкость, которая добавляется за счёт срабатывания риска.
Таким образом достигается, с одной стороны, учёт рисков в оценке, а, с другой стороны, нефокусирование на них. Именно такой метод учёта я встретил в книге, на которую ссылался выше. Отмечу, что в этой книге явно не сказано, что это именно учёт рисков, но аналогия прослеживается очень чётко. Если заинтересует, то смотрите главу про планирование.
Выделение самостоятельных задач
Теперь представим, что мы идентифицировали какой-то риск, который завязан на оба ресурса, но не увеличивает продолжительность работ по решаемым ими задачам. Взгляните на диаграмму ниже:
Из рисунка видно, что общая продолжительность всех задач не увеличилась, т.к. прямоугольник риска расположен параллельно с другими прямоугольниками. Такой подход имеет смысл применять в том случае, если риск, увеличивая общую трудоёмкость задач, не сдвигает итоговых сроков. Такое бывает (когда общая продолжительность проекта не увеличивается), к сожалению, очень редко.
Теперь обратимся к другой диаграмме:
Здесь красная задача-риск идёт последовательно (встык) с другими задачами. Таким образом, общая продолжительность работ (срок) увеличивается.
Подход учёта рисков путём выделения самостоятельных задач имеет смысл в том случае, если для потребителей плана требуется обозначить риски в явном виде. Важно помнить, что задача-риск является фиктивной. В итоге, при реализации проекта данная задача либо выродится в конкретную задачу (новый синий прямоугольник), либо «вольётся» в состав других задач, либо вообще не будет выполняться. Подобный учёт важен именно на начальном этапе планирования, чтобы не потерять возможный сдвиг сроков или увеличение бюджета.
Выводы
Сделаю дополнительный акцент на том, что учёт рисков не означает отказ от борьбы с ними, это не попытка ухода от проблемы вместо её решения. Во многих случаях правильней будет именно создать такие условия, когда риск из разряда вероятных переходит в разряд невозможных. Возможно, однако, что часть рисков так и не смогут быть устранены. Именно в этом случае и будет полезно учесть подобные риски.
Прошу простить, если топик оказался слишком длинным. Я и так ограничивал себя, где только мог. В частности, в посте совсем ничего нет о том, каким образом учёт рисков можно использовать в методике PERT. Если тема окажется достаточно востребованной, то на эту тему будет создан отдельный топик.
Спасибо тем, кто дочитал до конца!
