Учёт рисков при оценке трудоёмкости ПО и планировании проекта

    Поговорим о рисках


    dice
    Что такое риски? Что является риском, а что нет? Как учитывать риски при оценке трудоёмкости ПО и планировании проекта? Об этом я предлагаю поговорить в этом топике. В то же время, чтобы не раздувать топик и не повторяться, здесь не будут обсуждаться вопросы идентификации и митигации рисков — действий по выявлению, уменьшению вероятности возникновения рисков и минимизации их последствий.
    После публикации статьи о смертных грехах в оценке трудоёмкости программного обеспечения мне указали, что ни автор, ни я ничего не сказали о рисках. Хочу исправить это досадное недоразумение и поведать вам немного о рисках и моём опыте работы с ними.

    Типичные риски


    Ниже приведу список типичных для проекта по разработке ПО рисков.
    • отвлечение сотрудников от текущего проекта к работам с других проектов
    • болезни, внеочередные отпуска, свадьбы, беременность, отгулы и пр.
    • необоснованная задержка согласования требований
    • непредсказуемое изменение/расширение требований со стороны заказчика
    • использование относительно новых технологий в разработке
    • уход ключевых разработчиков/архитекторов
    • изменение ключевых сотрудников/представителей на стороне заказчика

    Что НЕ является риском


    Является ли риском глобальное потепление? А изменение ситуации на рынке? А возможный распад компании заказчика или, не дай Бог, вашей компании?
    Правильнее спросить так: «Какие из этих рисков нужно учитывать в вашем проекте?»

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

    Просмотрев этот список, мой предыдущий руководитель и наставник сказал нам: «Не надо закладывать свой непрофессионализм в риски!» Как? Меня и моих коллег обвинили в непрофессионализме?! Я тогда немного обиделся на него. Мы были вынуждены исключить довольно много пунктов, которые нам действительно казались рисками. С тех пор прошло некоторое время, я немного остыл, почитал книги, переосмыслил свой предыдущий опыт. Теперь я могу сказать, что вынужден с ним согласиться по ряду пунктов. Итак, перечислю некоторые случаи, которые не стоит считать рисками.

    Риски, вероятность которых стремится к 100%

    • недостаточная квалификация сотрудников — это не риск по той причине, что квалификация должна изначально закладываться в оценки (например, используя фокус-фактор)
    • регулярные отпуска сотрудников — их можно спрогнозировать более или менее заранее и внести в план проекта
    • прогнозируемые изменения требований — могут возникать в случае выбора определённой модели разработки (например, Fixed Team)

    Риски, вероятность которых стремится к 0


    Этот список может показаться немного надуманным. Он приведён только для иллюстрации возможных «невероятных» рисков. Важно понимать, что одни и те же риски могут становиться невероятными в зависимости от характера проекта и его продолжительности.
    • изменение существующего законодательства, в течение времени реализации краткосрочных проектов
    • полная потеря исходных кодов проекта

    Работы, которые являются частью проекта или методологии

    • ревью кода — бывает, что эту активность относят к рискам
    • рефакторинг — говорят так: «может потребоваться рефакторинг». Слово «может» сбивает с толку и наталкивает на мысль, что это риск. По сути же, рефакторинг относится к тем работам, которые планируют заранее.

    Учёт рисков при планировании


    Тут нужно сделать небольшое лирическое отступление и объяснить, почему риски необходимо учитывать. Как говорил Том Де Марко, "чтобы управлять проектом, достаточно управлять его рисками". Но! Это касается момента, когда проект уже стартовал. Когда есть, чем управлять. А теперь представим, что оценка и планирование проекта ведётся ещё до его старта. И вообще неизвестно, будет ли проект запущен или нет. Нужно ли учитывать риски на этом этапе? И да, и нет…

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

    Определение терминов


    Введём понятие «чистой трудоёмкости»
    Чистую трудоёмкость определим как трудоёмкость в «идеальных человеко-днях», необходимую для реализации той или иной задачи. Для объяснения, что же здесь имеется в виду, я воспользуюсь описанием, взятым из книги Scrum and XP from the Trenches от опытного Scrum Master'а Henrik Kniberg'а. Итак:
    "Идеальный человеко-день – это максимально продуктивный день, когда никто и ничто не отвлекает от основного занятия. Такие дни – редкость." (с) Henrik Kniberg

    Другими словами, будем считать, что задача обладает такой трудоёмкостью при условии, что ни один из рисков не реализуется.

    Равномерное распределение рисков по задачам или методика «спрятанной шляпы»


    image
    В качестве «вводной» приведу анекдот, рассказанный нам одним из топ-менеджеров в ответ на представленные оценки недавнего проекта:
    Сотрудник приезжает из командировки, подаёт expense report, а там, среди прочего, значится «Шляпа: $100»
    Его в бухгалтерии спрашивают…
    — Что за шляпа такая?
    — Ну купил себе шляпу… классная… все дела.
    — $%&*#! Иди меняй отчет!
    Ну приносит новый, там опять «Шляпа: $100»
    Ну опять "$%&*#!", иди меняй, чтобы не было никакой шляпы.
    Приносит… Смотрят — нормально все… не подкопаешься, шляпы нет… но сумма финальная как была так и осталась.
    Спрашивают:
    — А шляпа где?
    — Да там она… там… только вы ее хрен найдете!

    Так вот, подобный метод можно применить и при учёте рисков.
    Например, один или несколько рисков, выраженные в виде некой дополнительной трудоёмкости, можно просто равномерно распределить по остальным конкретным задачам, как указано на фрагменте диаграммы Ганта ниже:
    image
    Здесь синим цветом обозначены прямоугольники задач с чистой трудоёмкостью. Подписи — назначенные на задачи ресурсы (люди). Красным цветом обозначим прямоугольник, в котором сосредоточена трудоёмкость, которая добавляется за счёт срабатывания риска.
    Таким образом достигается, с одной стороны, учёт рисков в оценке, а, с другой стороны, нефокусирование на них. Именно такой метод учёта я встретил в книге, на которую ссылался выше. Отмечу, что в этой книге явно не сказано, что это именно учёт рисков, но аналогия прослеживается очень чётко. Если заинтересует, то смотрите главу про планирование.

    Выделение самостоятельных задач


    Теперь представим, что мы идентифицировали какой-то риск, который завязан на оба ресурса, но не увеличивает продолжительность работ по решаемым ими задачам. Взгляните на диаграмму ниже:
    image
    Из рисунка видно, что общая продолжительность всех задач не увеличилась, т.к. прямоугольник риска расположен параллельно с другими прямоугольниками. Такой подход имеет смысл применять в том случае, если риск, увеличивая общую трудоёмкость задач, не сдвигает итоговых сроков. Такое бывает (когда общая продолжительность проекта не увеличивается), к сожалению, очень редко.

    Теперь обратимся к другой диаграмме:
    image
    Здесь красная задача-риск идёт последовательно (встык) с другими задачами. Таким образом, общая продолжительность работ (срок) увеличивается.

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

    Выводы


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

    Прошу простить, если топик оказался слишком длинным. Я и так ограничивал себя, где только мог. В частности, в посте совсем ничего нет о том, каким образом учёт рисков можно использовать в методике PERT. Если тема окажется достаточно востребованной, то на эту тему будет создан отдельный топик.
    Спасибо тем, кто дочитал до конца!
    Поделиться публикацией

    Комментарии 26

      +1
      Вполне полезная статья. И как раз, хотелось бы прочитать в «более широком» спектре.
      Особенно интересует процесс автоматизации учета рисков.
        +1
        Вот здесь: http://pmo.ru/riskology/ доступны инструментальные средства для оценки рисков Вашего проекта. Посмотрите — возможно, это то, что Вы ищите.
        +1
        Спасибо за статью.
        Есть у меня проблема, которая, как я понял решается в основном только опытом PM. Как рассчитывать время? Глупый вроде вопрос, но сколько книг\статей прочитал так и не понял. Как узнать сколько времени затратит команда на эту задачу? А с учётом рисков?

        Я понимаю, что универсального ответа нет, но может просто поделитесь своим опытом расчета? Когда вы только начинали работу.
          0
          Когда ты начинаешь работать с новой командой, то есть два варианта развития событий:
          1. (Идеал) В компании есть учет времени выполнения проектов, работает какая либо методология управления проектами. В этом случае есть шанс, что просмотрев выполненные проекты данной командой, ты составишь для себя некое представление об способностях каждого члена команды… а так же, если команда сплоченная, и о системном эффекте их совместной работы (есть такой термин эмерджентность).
          2. (Реалии). Увы ни о каком учете времени, задач и вообще никто нечего не знает. Тут только на собственных шишках получать опыт. Ну правда можно уменьшить последствия рисков. Взять старого PM менеджера (или кого нибудь на него похожего), засесть с ним за чашкой кофе/пива/колы/молочного коктейля и выпытать кто есть кто, и что от него ждать.

            0
            2 вариант думаю ближе к реалии, вы правы, но что делать, если не старого PM, т.к. команда и проект новые + не могу сравнить с конкурентами, т.к. продукт новый и нет аналога на рынке?
              0
              Делаешь начальную оценку трудоемкости..(пальцем в небо), заручаешься пониманием команды (смогут / не смогут; делали раньше/ не делали), делаешь запас времени и денег и приступаешь к работе.

              После этого на контрольных точках делаешь ревизию проекта: что сделано и что нет. На основании этого оцениваешь персонал и трудоемкость задач. Чем чаще это будет сначала, тем лучше… можно сразу скорректировать сроки, бюджет, либо убить проект.
            +1
            Спасибо за отзыв.
            Универсального ответа действительно нет.
            Но есть методики, которые могут помочь оценить трудоёкость предполагаемой работы: экспертные оценки, групповые оценки, использование исторических данных и т.п.
            Чуть позже планирую осветить эти методы в других публикациях.
            В данном топике я предполагал, что чистая трудоёмкость уже определена.
            +1
            Основные вопросы:
            1. Что такое риски?
            2. Что является риском, а что нет?

            Попробую ответить кратко:
            1. Риск — это то, что влияет на проект, но происходит НЕ по инициативе руководителя проекта.
            2. Имеет смысл учитывать только те риски, которыми руководитель проекта может реально управлять. Остальное — форс-мажер. (Перекликается с цитатой Тома Де Марко.)
              0
              Замечательная статья.
              Но хотелось бы немножечко откомментировать кое-что.

              Берем первую диаграмму, показываем ее заказчику — отлично. Он представляет себе реальное время, которое мы заложили.

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

              Есть мысли, как этого избежать?

              У меня так только одна :). Иметь разные диаграммы на разные случаи жизни. Одну для РП, одну для исполнителей, одну для Заказчика.
                0
                Я думаю ваш вариант наилучший.
                  0
                  Мне кажется, что это в значительной мере усложняет работу PM. Достаточно одного раза, чтобы ваша команда узнала о существовании второго плана для Заказчика, и после этого описанная вами ситуация повторится.
                  Я практикую другой подход: добавлять контрольные точки. Точкой может быть завершение некой части проекта… или просто конкретная дата. После этого можно проанализировать состояние проекта и предпринять некие действия.
                  Кроме того, необходимо работать с персоналом. Сюда входит как разъяснения, что нужно от человека и какая перед ним стоит задача, так и какие последствия это вызовет, и много еще чего.
                    0
                    При определённом уровне зрелости команда вполне может и знать о существовании «другого» плана. Это не всегда является проблемой. Проблемой может стать Ваше отношение к команде.
                    Если люди почувствуют, что Вы искусственно занижаете допустимые сроки, игнорируя объективную потребность времени.
                    Если поймут, что Вы игнорируете мнение экпертов, тех, кто действительно понимает, сколько нужно усилий.
                    Если осознают, что Вы фактически «продавливаете» сроки.
                    В этом случае можно очень быстро потерять доверие команды. И вот тогда уже действительно придётся выкручиваться.
                      +1
                      Ну да… это и имел ввиду. Другими словами: наличие второго плана, где указаны другие сроки, команда может расценить как отсутствие доверия к ним. Нужно этот риск учитывать.
                      0
                      Прочитав в вашем комментарии про контрольные точки (про которые я, конечно же и раньше знал), пришел к выводу о том, как можно было бы оптимально иметь один план для всех, но при этом исключить работу программиста как синенькое+красненькое. К примеру у нас проект разбит на несколько контрольных точек, после которых имеем функционал, который заказчик апрувит и платит деньги по расписанию проекта. У программистов делаем 2/3 зарплаты окладом, 1/3 зарплаты премией. Контрольная точка, когда должно быть все готово назначается заранее до даты отправки клиенту. Время между контрольной точкой и датой отправки = время на риски. Если программисты не укладываются к контрольной точке, а работают как синенькое+красненькое, то недосчитываются части премии (о чем уведомляются ПМ'ом или системой, если она настолько продвинута).
                      В дополнение, я пропагандирую подход, когда премии недосчитывается не один программист, а все, кто в данный момент занят на данном проекте. Таким образом, коллективная ответственность повышается, мы имеем один план для клиента и сотрудников, мы замотивировали сотрудников работать не всё время включая риски, а укладываться в безрисковый срок, мы замотивировали других программистов помогать тем, у кого есть проблемы с реализацией задачи.
                      0
                      Да, Вы абсолютно правы. Так называемый закон Паркинсона говорит нам о том, что работа стремиться занять всё выделенное на неё время.
                      Если по каким-либо причинам мы не можем себе позволить прозрачное планирование (политический обстоятельства, внешние факторы и т.п.), то наиболее выгодным является возможность иметь несколько планов в зависимости от потребностей.
                      0
                      Статья действительно хорошая! Выскажу мнения насчет посчета времени.

                      Когда я начинаю подсчитывать время я всегда дроблю проект на как можно мелкие задачи, ведь если вам сказать, что нужно подняться на Эверест — это покажется нереально, а важно верить и видить свою цель. Так уж сложилось у меня, что я обжегся не раз на прогнозах програмистов, поетому всегда умножаю время на 2 (для каждого програмиста коэфициент свой :), также закладываю время на код-ревью.

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

                      Вспомнилась одна стандартная фраза для собеседования:«Выне успеваэте здать проектили задачу до установленого срока, сегодня пятница вечер, а нужно на понедельник утро, ваши действия?». Правильный ответ — поставить в извесность менеджера проектов. К этому я и приучаю своих сотрудников. Но при этом для клиента у меня один график, для програмистов и других сотрудныков второй график с малениким люфтом, а для себя я знаю где и какой у меня есть запас.
                        0
                        Извените конечно, но у меня есть топик, но мало кармы желающим помочь опубликовать буду рад.
                          0
                          Публикуйте статью в личном блоге. Карма вырастет, если статья будет толковой.
                          0
                          У вас что-то с пробелом =) Рекомендую почистить клаву…
                          0
                          За попытку поднять тему респект. Но весь топик можно свести к принципу «Имейте запас по времени при планировании задач проекта». Если же автор имел что то другое, то увы… это осталось за границей моего понимания.

                          Системный подход управления рисками (методология PMbok) уже поднимался на Хабре. habrahabr.ru/blogs/pm/73571/

                            0
                            Да-да, поднимался. Посмотрите, пожалуйста, внимательно на введение. Там я указал ссылку на эту статью и объяснил, что рассматриваю проблему с другой стороны.
                            «Запас по времени» — это слишком общая формулировка. Каждый «запас» должен быть обоснован, иначе Вам не удастся защитить свои оценки как перед руководством, так и перед заказчиком. Как минимум, нужно быть честным перед самим с собой. В первую очередь, Вам самому себе надо объяснить, почему Вы закладываете больше времени, чем это нужно в идеальных условиях. Иногда это нужно делать в явном виде (выделение отдельных рисковых задач), иногда сознательно скрывать, распределяя между задачами.
                            +1
                            1. Так и не нашел в книге «Scrum and XP from the Trenches» тот самый подход по аналогии с которым вы предлагаете распределять работы, вызванные рисками, по другим работам. Подскажите номер страницы, чтоб я мог понять.

                            2. У вас статья названа «Управление рисками ПРИ ОЦЕНКЕ трудоемкости… » а по тексту вы к диаграммам ганта обращаетесь, которые обычно рисуют уже ПОСЛЕ оценки. Нестыковочка…

                            3. В начале статьи вы приводите примеры того, что такое риск а что не риск. А потом, в списке понятий вы не написали «что такое риск». Если есть трудности — предлагаю определение из книги Hall, Elaine. Managing Risk. Reading: Addison Wesley, 1997. «Risk is a consequence of the uncertainty in our work, not a reflection of our own ability.”
                              0
                              1. Глава: «5.2 Velocity – a useful metric for reality checks», а точнее стр. 13. Я не прадлагал «распределять работы», я предлагал распределять дополнительную трудоёмкость. В книге, на которую я ссылаюсь, нет указания поступать именно так. Аналогию я увидел только в том, как учесть неидеальность оцененной трудоёмкости. В моём случае, эта «неидеальность» обуславливается рисками.
                              2. Статья называется «Учёт рисков при оценке трудоёмкости ПО и планировании проекта». Обратите внимание на выделенные слова.
                              3. Да, спасибо за определение. Учту.
                                0
                                Чем «Распределять дополнительную трудоемкость » отличается от «распределять работы»?

                                Все что я нашел на стр 13 — предлагается планировать с запасом изза неидеальности оценки. Неоригинально, но бесспорно.

                                Ок, сместимся от оценок в сторону планирования…

                                То что на трудоемкость, следующую из рисков, надо откладывать запас по времени, и этот запас можно распределять в календарном плане проекта как минимум 3мя разными способами — это тривиально.

                                Вы и в прошлой статье и в этой сосредоточились на оценке трудоемкости, следом за Макконелом. Макконел и правда хоть и говорит о software estimation ( что существенно шире ) в своей презентации приводит примеры time estimation.

                                Но риски влияют не только на сроки выполнения работ, а и на стоимость (которая складывается не только из потраченных человекочасов) и на функциональность продукта. И в крупном проекте вы могли бы это почувствовать, но из статьи как то не видно. Впрочем, если вы разработчик, то что вам стоимость?
                              0
                              Статья, пардон, бесполезная. Для теоретиков.

                              Про риски знаю одну стоящую книгу «Вальсируя с медведями».
                                0
                                Не за что извиняться. Негативный отзыв — тоже отзыв. Спасибо.
                                Насчёт «теоретиков». В статье, скорее, именно чисто практический взгляд. В теории так не должно быть. В теории с рисками нужно всегда бороться, избегать и минимизировать их.
                                На практике же (по разным причинам) не все риски удаётся победить и минимизировать. Именно поэтому их приходится учитывать.
                                Методы учёта рисков (помимо их митигации), описанные в этой статье, в течение длительного времени в том или ином виде применялись мной и моими коллегами на очень крупном проекте. Возможно, они не самые правильные, но они позволяли нам защитить как своих коллег-разработчиков, так и себя самих от многих проблем. В этом топике я попытался обобщить опыт и выделить ключевые направления.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое