Метод критической цепи

    Метод критической цепи: эффективное управление проектами с использованием буферов времени и ресурсов


    Работа стремится занять все время, отпущенное на нее.
    Закон Паркинсона.
    Если какая-нибудь неприятность может произойти, — она случается.
    Закон Мерфи.

    Немного статистики


    Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех.
    По данным многочисленных исследований Standish Group1 для традиционных методов управления проектами, только 44% проектов обычно завершаются вовремя. В среднем проекты занимают 222% процента от изначально запланированной длительности, 189% от начального бюджета. 70% проектов сокращают исходный объем работ проекта, 30% проектов закрываются досрочно.
    И хотя в последнее время, с развитием инструментов и техник управления проектами, эти цифры стали уменьшаться, общая картина говорит о том, что мы как менеджеры проектов плохо делаем свою работу.
    Данная статья рассматриваем использование относительно новый метод управления проектами, метод критических цепей (МКЦ), сравнивая его с традиционным подходом к управлению проектами.

    Традиционный подход к управлению неопределенностью и рисками


    При традиционном подходе к управлению проектами, проблемы, связанные с неопределенностью (т.е. с законом Мерфи), законом Паркинсона и одновременной работой сотрудников над несколькими задачами (например, в нескольких проектах), решают следующими способами.

    Включение в оценку задачи рисков и неопределенностей


    Часто и сотрудник, и его руководитель стремятся заложить в оценку задачи неопределенности и риски, которые они предвидят. Неопределенность, к примеру, может быть связана с такими факторами, как новая технология, неопытность исполнителя в области выполнения задачи, недостаток информации о задаче на момент оценки.
    Минимизировать риски пытаются тем, что добавляют резервное время для каждой задачи. Поскольку время окончания задачи определяется не одной цифрой, а распределением вероятности, то графически оценку задачи в традиционном управлении проектами можно изобразить так, как показано на Рис. 1.

    Рис. 1. Время окончания задачи как распределение вероятности
    В оценку задачи включаются риски с целью минимизировать влияние закона Мерфи. И хотя такая оценка делается экспертами или исполнителями оцениваемой задачи (что хорошо и правильно), время на неопределенность часто добавляется «на глаз».
    Таким образом, почти каждая задачи содержит дополнительный запас прочности, превышающий действительно ожидаемое время завершения данной работы. Часто оценки рисков задачи больше самого времени выполнения работы.
    Со стороны работника такой подход приводит к следующим негативным тенденциям. Проявляется «синдрома студента»: когда работник видит, что у него больше чем достаточно времени для выполнения задачи, он начинает работу позже. Таким образом, ресурсы выполняют более срочные задачи или тратят время резерва на работу над самой задачей, считая, что все время выделено на работу над ней. И если риски, заложенные в резервном времени, срабатывают, задача запаздывает.

    Фокус на запланированных датах начала и окончания задачи


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

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

    Управление неопределенностью и рисками с использование метода критической цепи


    Метод критической цепи (МКЦ) был предложен Элияу Голдраттом (Eliyahu Goldratt) в 1997 году2. МКЦ – это метод планирования и управления проектами, который обращает большее внимание на ограничения, связанные с ресурсами проекта. Он основан на методах и алгоритмах теории ограничений3. Этот метод противоположен методам критического пути или PERT в том смысле, что он не предполагает жесткой последовательности задач и жесткого планирования. Напротив, календарный план, составленный с использованием МКЦ, содержит выровненную нагрузку ресурсов по времени, но требует от исполнителей задач быть гибкими по ношению ко времени начала выполнения задач и быстро переключаться между задачами и цепочками задач (но не работать над ними одновременно), с целью удержать весь проект в рамках запланированного времени.
    То есть МКЦ предлагает сконцентрировать внимание не на достижении оценок задач и промежуточных вех, а на достижении единственно важной даты – обещанной даты завершения проекта.
    МКЦ вводит такое понятие, как критическая цепь задач, или просто критическая цепь. Критическая цепь – это последовательность задач, от длительности которых зависит общая длительность всего проекта.
    МКЦ устраняет перечисленные выше недостатки планирования, выполнения и контроля классического управления проектами с помощью следующих подходов.

    Устранение влияния закона Паркинсона


    Напомним, закон Паркинсона гласит, что работа займет все время, отведенное на нее, сколько резервного времени мы бы в нее не закладывали.
    Работа ресурсов над задачей в традиционном менеджменте проектов занимает все отведенное время ввиду комбинации следующих причин: наличие жестких дат окончания задачи и «безопасных» оценок задачи, включающих резервы времени4. Для устранения этих проблем МКЦ предлагает следующие действия:
    • Создавать календарный план, используя достаточно плотные оценки длительности задач. Чаще всего в МКЦ в качестве длительности задачи принимается оценка с 50% обеспечением риска, так называемая агрессивная оценка (см. Рис. 1).
      Избавиться от жестких дат окончания задачи (но не проекта). Безусловно, задачи по-прежнему оцениваются и имеют дату окончания в календарном плане. Но эта дата не рассматривается как обязательство исполнителей закончить работу над задачей именно в указанный срок.
      В матричной организационной структуре имеет смысл наделить менеджеров проектов достаточной полнотой власти, чтобы они могли защитить ресурсы проекта от «более срочных» задач других проектов или подразделений.
      Рассмотрим, что нам дают эти правила. Поскольку задачи оцениваются с 50% обеспечением риска по времени, то требование МКЦ о построении календарного плана с использованием только времени, необходимого для выполнения задач, выполняется. И т.к. мы убрали обеспечение безопасности из оценок задач, то рассматривать конечные даты завершения каждой задачи как нечто непременно выполнимое, смысла больше не имеет.
      Таким образом, описанные техники помогают нам избавиться от закона Паркинсона.

      Использование положительных моментов досрочного завершения задачи для достижения успеха проекта


      МКЦ условно делит ресурсы на две категории: ресурсы, выполняющие критические задачи, и ресурсы некритических задач. В этом контексте, те ресурсы, о которых мы действительно должны заботиться, — это ресурсы критических задач, т.к. их использование напрямую влияет на длительность проекта. И мы хотим быть уверены, что когда задача в критической цепи завершается, ресурсы для выполнения следующей задачи критического пути будут готовы и доступны.
      Два простых шага, выполняемых с известной долей профессионализма, позволят использовать преимущество раннего завершения для задач в критической цепи. Во-первых, необходимо собрать информацию у ресурсов: за сколько нужно их предупреждать, что они должны прервать свою текущую работу и переключиться на более важные задачи критической цепи. Во-вторых, требовать, чтобы ресурсы периодически предоставляли оценки о времени, требуемом для завершения их текущих задач («буфер предупреждения»).
      Имея эту информацию, мы можем отслеживать когда оценка оставшегося времени текущей задачи критической цепи становится меньше буфера предупреждения исполнителя зависимой задачи, и уведомлять последнего о том, чтобы он был готов вскоре начинать свою задачу.
      По сравнению с традиционным управлением проектами, это шаг от мониторинга и отчетов вида «что было сделано», используя процент завершения работ (который, кстати сказать, довольно субъективен), к тому, что следует считать имеющим ценность с точки зрения статуса проекта – сколько осталось времени для выполнения незавершенных задач.

      Использование буферов времени и ресурсов для предотвращения действия закона Мерфи


      Отлично, мы сократили оценки до минимально допустимых, тем самым сконцентрировав все усилия на выполнении задачи. Мы используем преимущества раннего завершения задач. Но если у нас теперь нет «железной» даты, до которой задача должна быть завершена, как мы узнаем, когда ресурс у нас будет доступен для других задач? И, кроме того, как теперь быть с рисками, которые теперь не минимизируются дополнительным временем задач?
      Для того чтобы защитить дату окончания всего проекта от вариаций задач, МКЦ использует буферы ресурсов и времени.
      В этом разделе описывается использование буферов времени. В МКЦ особое внимание уделяется задачам критических цепей. Все, что мы делаем, это аккумулируем резервное время всех задач цепи, которое составляло от 50% до 90% покрытия неопределенности, оставляя для самих задач только 50% покрытия. Эти размазанные по всем задачам резервы суммируются в единый буфер времени, который помещается в конце цепи (см. Рис. 3). Таким образом, вариации в критической цепи не имеют прямого влияния на обещанную дату окончания проекта, т.к. они гасятся буфером времени.

      Рис. 3. Буфер времени, помещенный в конец цепи, предохраняет ее от задержек по времени
      Поскольку мы оставляем только 50% покрытия рисков в оценке задачи, мы можем ожидать, что в половине случаев задачи завершатся раньше запланированного, в половине – позже. В МКЦ мы активно используем преимущество раннего завершения задач. Что до запаздывающих задач, то их будет компенсировать буфер цепи. Не вдаваясь в статистику, констатируем, что суммарный буфер должен быть значительно меньше составляющих его отрезков времени от резервов индивидуальных задач (на 30-50%).
      Что касается задач некритической цепи, то здесь мы не хотим заниматься микро-менеджментом для каждой задачи и исполнителя, как в случае с критическими цепями, с использованием уведомлений о завершающихся задачах. Тем не менее, мы также хотим, чтобы задачи некритического пути также не повлияли на успех проекта.
      Что предполагает традиционный подход к управлению задачами некритического пути? Начинать задачи как можно раньше и надеяться, что запаса времени некритических задач хватит для покрытия рисков.
      В отличие от традиционного управления проектами, в МКЦ мы используем не только свободное время (float) для некритических задач, но и тот же подход с буфером в конце цепи (теперь уже некритической), который был описан для критических задач. Этот буфер, назовем его «питающим», предохраняет зависимые критические цепи от вариаций по времени в некритических цепях.

      Рис. 4. Составление расписания по МКЦ
      Для некритической цепи мы не используем каких-либо дополнительных инструментов для того, чтобы избежать последствия задержки выполнения задач (например, предупреждение о приближающейся работе). Для таких задач у нас и без того имеется двойной буфер: свободное время некритической цепи (float) и питающий буфер.
      Таким образом, составление расписания по МКЦ использует «питающие» и проектные буферы времени, а также буферы ресурсов (описывается в следующем разделе).

      Использование буфера ресурсов


      Особо интересным инструментом в МКЦ является использование буферов ресурсов. Можно условно выделить два вида таких буферов.
      Во-первых, то время, за которое мы предупреждаем исполнителя о том, что скоро у него возникнет задача из критической цепи, и является ресурсным буфером.
      Второй тип буфера – это выделение альтернативных (дополнительных) ресурсов для задач критической цепи. Этот буфер имеет смысл, когда задачи могут подвергаться частым изменениям. В этом случае, добавление ресурсов означает защиту от рисков финальной даты окончания проектов.

      Рис. 5. Критическая цепь в данном случае состоит из задач, выполняемых ограниченными ресурсами
      На Рис. 5 показана критическая цепь, которая образована ограниченными ресурсами. Соответственно, буферы, используемые в этой ситуации, используются скорее не для того, чтобы предотвратить недостаток времени (неверные оценки). Буферы ресурсов времени в этом случае используются для управления рисками, связанными с ограниченными ресурсами.
      Питающие буферы стоят перед задачами критических ресурсов, предохраняя таким образом задачи критической цепи от сдвига по времени в случае задержки задач некритических цепей.

      Буфер как средство мониторинга и контроля


      Прогресс проекта и точность планирования с использованием МКЦ часто отслеживается не по классической технике анализа освоенного объема (earned value analysis), а по проценту использованных буферов. Т.е. чем больше времени, запланированного в качестве буфера, использовано, тем большее влияние неопределенности на проект в виде реализовавшихся рисов. Отслеживание оставшегося буферов времени для задачи используется в МКЦ для мониторинга статуса задачи: при достижении минимального порогового значения буфера необходимо предпринять корректирующие действия. Аналогично, процент использования проектного буфера служит как триггером для определения выполнимости обещанной даты завершения, так и показателем успешности проекта (например, если использовали не более 50% проектного буфера времени, проект следует считать очень успешным).

      Практические шаги для использования МКЦ


      Суммируя все описанное, можно порекомендовать следующий комплекс практических шагов для использования МКЦ:
      • Объяснить исполнителям, что они должны защищать свои оценки от давления со стороны начальства и других заинтересованных сторон проекта.
        В качестве оценки длительности задач брать оценки с 50% покрытием неопределенности.
        Исключить конкуренцию за ресурсы путем выравнивания нагрузки. Это также уберет необходимость переключения ресурсов между задачами. Критическая цепь теперь может быть определена как наиболее длинная цепь пути и зависимости ресурсов.
        Вставить проектный буфер в конце проекта для аккумуляции резервного времени (изначально – примерно 50% от длины пути критической цепи).
        Защитить критические цепи от недоступности ресурсов с помощью буферов ресурсов.
        Рассчитать и расставить питающие буферы для всех путей, от которых зависят критические цепи.
        Планировать задачи, которые не зависят ни от каких других задач, от конечной даты проекта к его началу. Это будет дополнительным обеспечением отсутствия многозадачности ресурсов.
        Отслеживать и добиваться запланированной производительности ресурсов. Исполнители должны работать над задачами так быстро, как это возможно, и отдавать результат своей работы, как только она завершена.
        Предоставлять ресурсам информацию о длительности и об оценочном времени начала задачи, но не о вехах проекта. Это должно заставлять ресурсы отдавать результаты свой работы как только она закончена.
        На этапе выполнения проекта происходит активное управление выделенными буферами времени и ресурсов, чтобы минимизировать задержки выполнения задач, но сохранить реалистичным одно из главных обещаний проекта – дату его завершения.
        Таким образом, МКЦ помогает избежать действия закона Паркинсона и, в то же время, защититься от закона Мерфи. Рассмотренный метод концентрирует вниманием менеджера проекта на производительности команды, предлагает новый метод отслеживания прогресса проекта на основе использования буферов времени и ресурсов. МКЦ может применяться практически в любых областях, где применяется методология управления проектами, не требую значительного перестроения процессов в проекте.



        1 http://www.pqa.net/ProdServices/ccpm/W05002001.html
        2 Eliyahu M. Goldratt. Critical Chain. (1997) ISBN 0-88427-153-6.
        3 http://en.wikipedia.org/wiki/Theory_of_constraints
        4 http://www.focusedperformance.com/articles/ccpm.html  

        © Олег Клименко
        Взято отсюда
    Share post

    Comments 96

      +3
      Супер. Спасибо.
        +2
        Очередной рационализаторский подход к иррациональному делу.

        "Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех."

        Вы прикалываетесь? По отдельности слова понятны, но предложения?
        Управлять неопределенностью это очень, очень сильно.

        Но за статью спасибо.
          0
          По-моему, гиблое дело применять такой аппарат при работе над ЛЮБЫМ проектом, не только в Сети. Люди - не константы, всегда (опять же по закону Мерфи) найдетс человек, который сдвинет все ваши диаграммы далеко за пределы буферов.

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

          Текст классный (Roman_Mix уже отъехал), много букаф - но читать и вникать - извините.

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

          Если интересно, как работаем мы - отпишитесь, попробую рассказать
            +1
            Для меня вполне понятно откуда у статьи растут ноги. Когда бизнес целиком завязан на успешную продажу проектов и последующего их выполнения в соответствии со сроками и бюджетом, то тем кто планирует очень важно совершенствоваться в составлении планов. То что могут быть люди которые съедают буфер совершенно не отменяет того факта что бывают хорошие планы, а бывают плохие планы.
              0
              Согласен. Попробую расширить и подытожить.

              Планы - планами. Замечательные такие планы - но результат зависит на 80% от исполнителей этого плана. Его не только составить-нарисовать надо, его надо соблюсти, потестировать систему, промотивировать исполнителей, утирая попутно сопли заказчику.

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

              Ну а рассматривать все это в комплексе - тянет на кандидатскую.

              Автору поста - еще раз спасибо от ожившей аудитории)
                0
                На своем опыте скажу что с хорошими исполнителями и плохими планами намного сложнее чем с хорошими исполнителями и с хорошими планами.
                  0
                  Это было просто замечание по жизни, а не какое-либо возражение )
                    0
                    Никто не говорит, что планы и их дальновидное составление с использованием различных техник (как, например, этой) может навредить)

                    Обеспечить качество и сроки - стремится выжать 100% из имеющихся исходных данных и ресурсов. И я даже погорячился насчет 20% успеха, которые выделил на грамотный план - в некоторых проектах он тянет на все 50%.
                0
                Отписываюсь, расскажите, пожалуйста.
                Я управляю своими проектами исключительно "по наитию", без специального образования, подобных заумных статей и "брутальных терминов". Возможно, все эти вещи применимы для управления проектами запуска освоения новых нефтяных источников, но для разработки в вебе это чересчур.
                Однако, мне всегда интересен конкретный опыт занятых в той же области, что и я.
                  0
                  Кратко: есть deadline, установленный по утвержденному с заказчиком плану. За 2-3 суток до deadline'а ставится внутренний redline. Итерация этапа (milestone - мы этим словом пользуемся) оканчивается к redline'у - у нас появляется буфер для тестирования, исправления багов.

                  В этот буфер часть участников плотно общается с QA, фиксит баги (удается за этот буфер найти и обезвредить процентов 80%-90%).
                  Вторая половина (lead и его свита - скажем так) идет дальше и начинает следующую итерацию.

                  1. Выкатываем заказчику на deadline с svn'а ту версию, которая должна быть по milestone'у
                  2. Играем на опережение - буфер может расти к концу проекта, может быть потрачен на задачи, на которые время было рассчитано неверно (менеджер с каждым разом все точнее бьет в цель).

                  Естественно, заказчик и менеджер также должны утверждать следующий milestone минимум за несколько дней до deadline'а.

                  Думаю, порядок ясен))
                    0
                    Ну понятно, это вполне стандартная схема. Еще раз убеждаюсь, что данный пост предназначен для других задач, вроде "моделирования стохастических процессов в бизнесе"
                    Ну а мы по старинке :)
                    • UFO just landed and posted this here
                        +2
                        Согласен, когда уровни моих разработок и проектов уткнутся в подобную необходимость, я достану этот пост из избранного )
                          0
                          Лучше пусть всю жизнь пылится в избранном, если это для людей. Ибо такой подход (я его прочитал наконец-то) это вообще что-то с чем-то.
                          Коллеги, это клиника, претендующая на уникальность. Нарисовать нормальное распределение, немножко его ужать справа (график разъ) и радостно заявить о буфере безопасности. Н-да. Ладно, закон Паретто автор не читал, ладно он не смотрел как работают люди, ладно он сам никогда не пытался организовать работу людей. Но, блин, хотя бы подумать больше 15 минут можно? Потому что тогда придет в голову простая и незатейливая мысль, что в реальном мире очень мало линейной работы, выполняемой человеками, что работа команды зависит от действий каждого члена этой команды, часто без результата, полученного одним человеком, другой работать не начнет. Где это все в вышепредлагаемой схеме? Где синхронизация отедлов? Где, наконец, потери от организационной структуры? Где непрямые издержки? Где трансакционные издержки?
                            0
                            Всё правильно говорите. И автор поста прав по-своему.
                            Как разживусь кармой, напишу в этот блог пост об управлении проектами с ЧЕЛОВЕЧЕСКОЙ точки зрения, где ни один из этих законов работать не будет, но при этом, с данным вопросом сталкиваются гораздо чаще, причем на проектах любого уровня.
                            • UFO just landed and posted this here
                                0
                                естественно эмоционально, тут же общение людей происходит, а не роботов.
                                • UFO just landed and posted this here
                                0
                                В соответствии с PMBOK есть организации у которых образ действия операционный, а есть проектный. Насколько я понял по Вашим статьям у вас больше операционный образ действия, когда надо делать какую-то работу, а не то что называется проектом.

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

                                Другие издержки менеджеру проекта обычно не очень интересны, это больше к тем кто управляет финансами и портфелем проектов.
                                  0
                                  Вот она и проблема: другие издержки никому не интересны. Вместе с этим, именно другие издержки и влияют на дело в целом. Простенький пример: вашим сотрудникам надо работать через интернет, но сеть не то чтобы лежит, она валяется. Вместе с этим, вам надо, чтобы приходили и письма, которые кто-нибудь фильтровал. Админ один. Что ему делать? Пример простенький, но вполне в схемку не впимсывающийся.
                                  Ок. Вот второй пример: у вас есть 10 программеров, которым в течение месяца надо сделать сайт. Один пишет безопасность, второй пытается оптимизировать запросы к БД, третий разрабатывает ЦМС. Вопрос: как хотя бы этих трех синхронизировать? Запланировать, что безопасность следует написать к 10 числу, а ЦМС к 13. Дык, тут такое количество проблем вылезет, что решать их все равно придется в режиме дедлайна.
                                    0
                                    Ну управление проектом и организация эффективного бизнеса разные вещи. В идеале компания должна предоставить среду для менеджера проектов, чтобы оне не думал про эти вещи, а работал в своем "проектном" мирке подключая ресурсы компании (исполнителей, сисадминов, юристов, и т.д.) когда необходимо. Эта задача уровня выше, чем выполнение какого-то конкретного проекта в срок.

                                    Насчет второго примера: ну уж извините :) Это и есть планирование. Планирование задач может в часности осуществлятся на основе архитектурной декомпозиции, когда есть на высоком уровне понимание как задачи соотносятся между собой. Нужно закладывать время на интеграцию, нужно выделять задачи и готовить архитектуру таким образом, чтобы минимизировать издержки на коммуникацию, использовать технику непрерывной интеграции, и т.д.

                                    Вообще если задача изначальна поставлена так что в течении месяца десяти программистам надо сделать сайт - это плохой сетап. Хороший сетап - когда ПМ получает хорошо оформленные требования (от заказчика, продукт менеджера, и т.д.), делает свою оценку по ним и отвечает за реализацию продукта на основе этих требований в рамках бюджета и в срок.
                                      0
                                      А если идеала не ссуществует?
                                      А если задача стоит такая, какая она есть?
                                      А если кроме нужно время для... еще и работать пытаться мотивировать сотрудников? Понимаете, я вовсе не против каких-то подходов. Просто они настолько смешны, что я не могу удержаться от иронии. :)
                                        0
                                        Ну такие эвристики из статьи больше подоходят для организаций типа где мне приходится работать. Вот случае когда на вход получаешь требования и нужно сказать когда будет готов результат и сколько это будет стоить, после чего нужно сделать по этой оценке.

                                        Когда задача ставится таким образом, что надо успеть за месяц, то фактически никто за нее не отвечает. Что если задачу в принципе нельзя сделать за месяц? Кто согласился что сделает ее за месяц? Кто виноват если через месяц нет сайта?
                                          0
                                          Вы понимаете, в чем фишка. КАк писали Стругацкие в Понедельнике, интерес не в том, чтобы найти решение решаемой задачи, а в том, чтобы найти решение задачи решение не имеющей.
                                            0
                                            Ну это кому как )
                                          0
                                          Типа: "Нам тут думать некогда, работать нужно. Все же ж сложно и непонятно, задачу фиг поймешь, сотрудников мотивировать, президент новый, а вы со своими рисками и методологиями лезете."
                                            0
                                            Сформулируйте свое понимание риска и свое понимание неопределенности. Я настаиваю на том, что неопределнность не может быть управляема. Можно выработать набор мер, направленных на компенсацию возможных отрицательных последствий неопределенности. К примеру, елси вы не уверены, что ваши сотрудники сделают проект через месяц, то можно заложить, что к 15 числу нужно сделать 70% проекта. Если к 15 числу 70% проекта сделано не будет, то к 17 надо быть способным найти людей, которые подтянут проект к 20 числу до этих 70%. Тут я соглашусь (со значительными оговорками). Тем не менее, все пишут о каком-то буфере. Отсюда я и делаю вывод, что подобные интеллектуальные извраты вещь очень интересная, значимая, но неприменимая на практике.
                                              0
                                              Риск вида "проект не будет сделан вовремя" обычно слишком выского уровня, чтобы с ним можно было иметь дела менеджеру проекта (хотя данная статья призвана помочь уменьшить вероятность именно такого риска). Это скорее риск для бизнеса заказывающего проект. Вообще нужно разделять эти роли, у бизнеса и у проекта могут быть противоположные интересы )

                                              Лично я имею в виду стандартные определения, которые можно например на википедии найти. http://en.wikipedia.org/wiki/Uncertainty, http://en.wikipedia.org/wiki/Risk_manage…
                                                0
                                                См. ссылки на википедию.

                                                Пример управления неопределенностью: мы не знаем, какая из технологий (А, Б, В) лучше подойдет нам для реализации проекта. Соответственно, не знаем каких лучше подбирать специалистов и сколько займет проект.

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

                                                (Остается только риск, что мы ее неправильно выбрали :)
                                                  0
                                                  Ну вот, видите вы уже признали, что кроме существования полубредовых РМВОК есть еще интересные вещи. То, о чем вы говорите является обычной задачей на оптиум управления с минимизацией рисков. Читайте внимательнее: минимазация рисков, но уж никак не управление ими.
                                                    0
                                                    Минимизация - это одна из стратигий в управлении рисками.
                                                      0
                                                      Хм, я бы даже сказал, что они все исходят из этого утверждения. В общем, подводя итог вышесказнному: стратегия может быть одна — основанная на математическом подходе и после прочтения учебника по теории вероятностей. А вышеназванный подход это попытка объяснить ребенку, откуда появляются дети. Сделать в принципе можно, только стыдно.
                                                        0
                                                        Да нет, стратегий может быть несколько. Например идеально (и иногда получается) когда риск продается. Например, если стороней библиотекой поддерживается функционал, то время решения нашей задачи - 1 день, если не поддерживается - то 2 недели чтобы написать с нуля. Если изначально заложить в план 2 недели и заказчик соглашается - то можно считать что риск продан.
                                                          0
                                                          Ну задача-то не только в том, чтобы написать. И то в примере с библиотекой можно за уши притянуть то, что риск минимизируется, поскольку перекладывается на других людей. Проблема в том, что это и не риск в полном смысле. Вот если вы работаете, а главный архитектор заболевает, вот тогда это риск. :)
                                                            0
                                                            Если я правильно понял вашу точку зрения, риск - это обязательно то что нельзя предвидеть заранее, а если можно предвидеть - то это не риск :).
                                                              0
                                                              Приблизительно да. Посколько все остальное поддается прогнозированию в рамках принятых математических моделей. :)
                                                                0
                                                                Понятно. Будьте готовы что вас будут неправильно понимать те кто пользуется терминологий PMBOK, Risk Management, etc.
                                                                  0
                                                                  Вряд ли я с ними когда-то повстречаюсь. А так я вполне готов мириться с их агрессией. :)
                              0
                              Если кратко, то выглядит это так: в дедлайн делается 80% нужной работе. Во время до дедлайна делается 20%. Гениально, коллега.
                                0
                                Озвучьте размеры ваших проектов в трудозатратах.
                              0
                              Все в порядке, так и делайте дальше. Должен же кто-то выполнять роль тех, на чьих ошибках остальные учатся.
                                0
                                "гиблое дело применять такой аппарат при работе над ЛЮБЫМ проектом, не только в Сети. Люди - не константы, всегда (опять же по закону Мерфи) найдетс человек, который сдвинет все ваши диаграммы далеко за пределы буферов"

                                Поздравляю - Вы только что объявили бессмысленными любые попытки управлять чем-либо, связанным с людьми. Ну да, люди же - не константы. Нахуя мне управлять космическим кораблем, если в ней человек? Он же сейчас там все тумблеры с дури понажимает, и все взорвется!!!

                                Кстати, процесс о котором Вы говорите ниже - самый обычный процесс, адаптированный для конкретно _Вашей_ команды и _Вашего_ типа проектов, и он, несмотря на все рассуждения про "гиблое дело, ..." и т.д. - вполне реально помогает Вам здесь и сейчас бороться с неопределенностью и рисками.
                                0
                                Ну если говорят об управление рисками, то почему бы не говорить об управлении неопределенностью.
                                  +1
                                  потому что никто ими не управляет. Ни риском, ни неопределенностью. Управляемая неопределенность это миф. Это такой бред, который даже с элементарной логикой не дружит.
                                    0
                                    Все менеджеры/архитекторы проектов так или иначе управляют рисками, или инстинктивно или по какому-нибудь учебнику.
                                      0
                                      Ну неужели не понятно, что это логический бред? Управление рисками. Еще больший бред это управление неопределенностью (риск является ее частью). Бред потому, что неопределенность неопределена, а вот управление вполне себе определено. Хотя бы по наличию объекта управления.
                                      Управление рисками это тоже самое, что управление машиной без тормозов с завязанными глазами, без рук и под советы 4 окружающих вас блондинок. В данной ситуации поведение водителя может быть в принципе любым, результат может быть тоже любым, но вот зависимость от поведения водителя и результата будет весьма сомнительным.
                                        0
                                        Чапек К. "Двенадцать приемов литературной полемики"

                                        11. Impossibile (здесь: нельзя допускать — лат.) . Не допускать, чтобы противник хоть в чем-нибудь оказался прав. Стоит признать за ним хоть крупицу ума и истины — проиграна вся полемика. Если иную фразу нельзя опровергнуть, всегда еще остается возможность сказать: "Господин Икс берется меня поучать...", или "Господин Икс оперирует такими плоскими и давно известными истинами, как его "открытие...", или "Дивись весь мир! Слепая курица нашла зерно и теперь кудахчет, что...". Словом, всегда что-нибудь да найдется, не так ли?
                                          0
                                          Разумеется. Вы вот привели цитату.
                                          0
                                          Почему бред? Под управлением рисками подразумевается вполне конкретный набор работ. Если минимально, то перед подготовкой плана проекта можно иметь список рисков и понимать что какие-то риски в случае их возникновения включены в план,а какие-то нет. Бывают конечно самые общие риски - вроде задача была недооценена, заняла больше времени чем предполагалась, и т.д. В данной статье как раз описано как минимизировать ущебр от этих рисков по проекту в целом. Бывают совершенно конкретные риски, которых ближе к концу проекта становится все меньше и меньше.

                                          Вообще считается что уровень неопределенности к началу проекта высок, а к концу проекта низок. Когда неопределенностью управляют - это значит что у менеджера есть понимание того как именно она уменьшается )
                                            0
                                            Для управления неопределенностью нужен объект управления. В условиях неопределенности определить объект нельзя. Если проводятся какие-то мероприятия, которые проводят все или которые логичны, это просто означает, что управление неопределенностью пытаются осущствить при помощи шаманских плясок. :) Я не уверен, что это не эффективно, я также сомневаюсь и в эффективности.
                                              0
                                              Примеры неопределенностей:
                                              - через неделю становится понятно ложится ли человек в больницу на месяц или нет
                                              - является ли third party код достаточно стабильных для использования в данном проекте
                                              - интеграция с продуктом заказчика может занять неопределенное время.

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

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

                                                Неблагодарное дело - учить нубов жизни, особенно если учиться они не собираются.

                                                Пусть товарищ снизойдет с высоты своей кармы и для начала ознакомится с PMBOK или хотя бы с вводной информацией по управлению рисками. После этого может быть хоть какой-то разговор, так - трата времени...
                                                  0
                                                  Наверное и про управление рисками на храбре будут посты :)
                                                    0
                                                    Да не будут посты: риски вещь иррациональная, поэтому тут дохрена мистики и не подходит к технарям. Не потому, что они тупые, а потому, что не в их это системе координат.
                                                    0
                                                    Ну, сдается мне, что это мне. Ок. Объясняю специалистам по РМВОК и прочих страшных слов. Задача, описываемая вами, требует типично математического подхода. В кратце необходимо найти оптиум управления по многомерным вариациям (если вы с высоты своего интеллекта способны понять о чем я). После чего можно извратиться и начать описывать при помощи тензоров (хе-хе), а возможность смены состояния системы (ляжет — не ляжет в больничку) дивергенцией тензора по времени. После чего можно забацать модель, основанную на нечеткой логике +/- другие извраты. А в моделке предусмотреть возможность ввода неверных данных (вы понимаете, что это значит?). На основе всего этого построить соответствующую модель. Вот такую модель я согласен обсудить, ибо интересно мне это.
                                                      0
                                                      Боюсь, Вам придется заниматься мозгоебством в одиночестве.
                                                        0
                                                        что ж так агрессивно?
                                                    0
                                                    Где вы взяли неопределенность? Вы работаете в системе, параметры которой определены (ляжет не ляжет — это не неопределенность). Неопределенностью можно назвать следующее: кто ляжет, когда ляжет, ляжет ли или что-то другое (останется дома и работать не сможет)? То, о чем вы говорите, подчиняется обычной простенькой задачкой, в которой следует искать оптиум управления по многомерным вариациям (в общем случае). И просто с некоторыми неопределенными параметрами в вашем примере. Вопрос, это что так сложно? Если бы автор не пытался совокупить теорию вероятностей с наукой принятия правильных решений в гуманитарном ее понимании, он бы действительно занимался управлением.
                                                      0
                                                      является задачкой. Ивзините.
                                                        0
                                                        Любую неопределенность можно как-то определить что с ней можно работать. Если неопределенности возникают постоянно и неожиданно как на поле боя - ну значит такая среда, где важнее оперативное принятие решений. Думаю под управлением можно понимать такие неопределенности которые можно идентифицировать заблаговременно, и как-то с ними работать.
                                                          0
                                                          Давайте конкретный пример. Потому чвто определить можно все, но будет ли это соответствовать действительности?
                                                            0
                                                            Лучше вы дайте пример определенности, с которой нельзя работать. Как только формируется описание неопределенности, так сразу придут на ум стратегии как можно с ней поступить, или как лучше разбить эту неопределенность на вероятные исходы. Высокоуровневые неопределенности вроде "проект не будет выполнен в срок" лучше не рассматривать.

                                                            Важно понимать что, что успех проекта может зависит от того или иного развития событий в рамках описанной неопределенности.
                                                              0
                                                              Неопределенность проявляется и в том, чтобы нельзя было ее определить. ;)
                                                              Так вот, простая задача: обеспечить получение прибыли в заданном размере через 2 месяца. неопределенность тут во всем. :)
                                                                0
                                                                Не, так не интересно. Есть ли какой-нибудь план по по достижению прибыли? Например, покупаем 40 сковородок по 20р и продаем по 60р в результате получаем нужную прибыль. Вот когда есть план можно искать неопределенности, типа "у нас же никто не купит сковородки по 60р о_О".
                                                                  0
                                                                  покупаем материалы — делаем дизайнерские сковородки == продаем их. Вот тут и наступают риски.
                                        0
                                        суть понятна. какие программные продукты из популярных и доступных с этим работают? можно привести небольшой пример, скажем, для процесса разработки сайта или пуска сервиса?

                                        кто автор? олег клименко — это вы? несколько непонятна последняя фраза. кросспост не особо радует, а если это вы и есть — так и пишите

                                        статья идеальна с точки зрения оформления. гранд респект
                                          +1
                                          Спасибо за статью.

                                          По Стивену Кови, с которым авторы, безусловно, перекликаются, наибольшая часть работы выполняется когда цель важна, но не критична по времени. Задача менеджера, соответственно, регулировать эти два параметра, мотивировать и не создавать авралов, если упрощенно.
                                          По этому методу оба параметра в описанном методе и правда регулируются, т.к. единовременно задача всегда одна, следовательно, важность единственной задачи заведомо выше ее же в числе многих, и есть заранее запланированный запас (буфер) времени.
                                          Но подача уж слишком мудреная. На основе тех здравых мыслей, коих в статье много, можно сделать схему проще, или эту проще описать.
                                            0
                                            Вот многие основываются на milestone'ах диаграмм Гантта - но ведь в каждый из них входит несколько задач!

                                            Мне больше импонирует подход с короткими итерациями, который используется в XP. Тут задача всегда единственна и максимально изолированная. Сел, сделал, прогнал тесты, пошел дальше. Не зацикливаешься. Согласны?
                                            0
                                            Сейчас занимаюсь моделированием стохастических процессов в бизнесе. Очень хорошо если бы менеджеры по управлению проектами включали недетерминированость сроков и ресурсов в свои планы. За статью плюс.
                                              0
                                              Прекраный материал, нечасто тут встречается. (А Голдрат не "Элияху" случаем? я видел такой вариант перевода в бумажной литературе)
                                                +2
                                                В статье почему-то не упоминается, что Метод критической цепи является развитием Метода критического пути, только с добавлением буферов, покрывающих риски.
                                                  –1
                                                  Просто не осилил.
                                                    –2
                                                    Это для роботов, а не для людей.
                                                    • UFO just landed and posted this here
                                                        +1
                                                        Работаю дизайнером в маленькой компании.
                                                        Пытался донести до всех что при малых ресурсах планирование должно быть еще более важно. На что все только улыбаются и разводят руками, типа зачем оно нам, раньше ведь и без планирования работали.
                                                          0
                                                          На моей практике, диаграмму ганта (он с одной т) никто действительно не соблюдает. Руководители проектов исходят из того, что перед ними обычные в общем-то люди, поэтому они и не пытаются им навязать подобный стиль мышления. Т.е. руководители проектов знают, с кем они работают.
                                                          • UFO just landed and posted this here
                                                              0
                                                              люблю слова, неподкрепленные практикой.
                                                              Про т — всегда писал с одной. Но буду знать, что правильно с двумя. :)
                                                              Планирование д.б. адаптивным. :)
                                                              • UFO just landed and posted this here
                                                                  0
                                                                  тогда остамся при своих мнениях.
                                                                  • UFO just landed and posted this here
                                                              • UFO just landed and posted this here
                                                            +1
                                                            Вот приличный заголовок, что и не говори. На первой странице. Даже и не важно что там внутри. Просто приятно открыть Хабр в присутствии посторонних, что бы все видели, что читаю я - Метод критической цепи: эффективное управление проектами. Сразу уважение у окружающих людей. Общечеловеческая жизненная карма растёт. Близкие опять же понимают - я делом занят, а не в какой-то там социальной сети вишу.

                                                            Ото зайдёшь бывает, а там что-нить типа - Кармазадроты готовят очередную революцию. Тьфу... Да. Стыдоба.
                                                              +1
                                                              Пойду перекурю вашу мысль. Уж очень она внушительная.
                                                              +1
                                                              О, а я как раз по этой теме диплом бакалавра защищал :) Писал на Ruby реализацию этого дела - высчитывало все упомянутые параметры и рисовало красивый график. Спасибо за статью.
                                                                +1
                                                                Где можно посмотреть на ваш инструмент в действии?
                                                                  0
                                                                  К сожалению нигде - валяется в сыром виде где-то на винте - защитился с тем, что успел написать, дальше развивать не стал. :)
                                                                    0
                                                                    Давай мыл, пришлю что есть :)
                                                                    +2
                                                                    А можно посмотреть ваш проект и дипломную работу? Очень было интересно почитать и то и другое.
                                                                      0
                                                                      Я поищу чуть позже и вышлю, что есть. Но предупреждаю сразу: половина работы - паливо чистейшей воды, - мне было интересно реализовать сам алгоритм на Ruby, но оформить это в полноценный продукт, довести до ума и тем более написать хорошо сопровождающий документ интереса уже не хватило. Тем более, что преподы из нашей комиссии всё равно ничего бы не поняли - они по пониманию IT остались где-то в 80х.
                                                                        0
                                                                        Мне все равно интересно будет посмотреть.
                                                                    0
                                                                    Плюс вам в карму. Спасибо за замечательную статью.
                                                                    • UFO just landed and posted this here
                                                                        –1
                                                                        Та не парься, иди лучше в дрочильную машину чем-нибудь потыкай.

                                                                        Пеар: http://ohmygod.habrahabr.ru/blog
                                                                        • UFO just landed and posted this here
                                                                        0
                                                                        Вот тут кстати прикольно про метод написано:
                                                                        http://www.headfirstlabs.com/PMP/critica…

                                                                        Only users with full accounts can post comments. Log in, please.