Критическая цепь и SCRUM – общие черты и глубокое различие

Критическая цепь и SCRUM – общие черты и глубокое различие

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

Но все-таки условия использования – это важное, но не главное. К каким главным изменениям в организации труда приходят CCPM (Critical Chain Project Management, метод критической цепи) и scrum? В условиях известного конечного результата (CCPM) гибкость нам нужна только для преодоления неопределенностей в исполнении и в наличие ресурсов, возникающих в ходе выполнения. С ними нам отлично помогает справиться буфер времени (вся подстраховка для критической цепи, агрегированная в одном месте) и система приоритетов на его основе. Задачи известны и определены. Система приоритетов прозрачна. Каждый в любой момент знает, что ему делать. У менеджера задач есть список задач, он уделяет особое внимание задачам в «красном», при необходимости перераспределяет ресурсы и это его ответственность. А еще он выдает инструкции, как именно выполнять ту или иную задачу. Ведь задача в критической цепи – это набор работ. У одной задачи может быть несколько исполнителей. То есть ролью менеджера является координация усилий разных ресурсов.

При определении критической цепи, на этапе планирования, встает вопрос определения длительности задач. Необходимо ее определить, удалив из длительности всю обычную подстраховку, которую привыкли закладывать подчиненные. Считается, что конечная длительность задачи должна составлять половину от обычной длительности. Урезать отведенное на выполнение время наполовину может оказаться трудной задачей с психологической точки зрения. Затем на этапе исполнения менеджеру, с одной стороны, не нужно давить на подчиненного относительно скорости выполнения работы, с другой стороны, каждый день оценивать какое время осталось до завершения задачи. Давит или не давит менеджер на подчиненного – можно узнать только у самого подчиненного. Тут лучше даже задать другой вопрос: ощущает ли подчиненный давление со стороны менеджера? И такое ощущение (со всеми вытекающими последствиями) вполне может быть, даже если давления как такового нет. Получается, что мы являемся заложниками того, как ведет себя менеджер и того, как ощущает поведение менеджера подчиненный. Тонкая материя, однако…

Еще рекомендуем:  Agile и Критическая цепь

Теперь рассмотрим управление на основе scrum. Задачи здесь известны только на коротком промежутке времени одного спринта, никакая цепь задач не вводится, а соответственно нет и буфера. На каждом спринте возникает необходимость расставить приоритеты между задачами. Лучше всего это может сделать заказчик, или его представитель. Поэтому появляется роль владельца продукта. В ней не было необходимости в CCPM. Владелец продукта определяет самые приоритетные характеристики продукта, которые могут быть разработаны на ближайшем спринте, формулирует цели спринта через конкретные характеристики конечного продукта, а в конце спринта принимает работу через демонстрацию работающих характеристик. Задачи спринта формулируются уже командой проекта.

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

Что происходит дальше? Команда проекта каждый день проводит scrum митинг в течение 15 минут. Обсуждается три вопроса:

  1. что ты сделал вчера, чтобы помочь команде выполнить задачи спринта;
  2. что ты будешь делать сегодня;
  3. что тебе мешает выполнить стоящие перед тобой задачи?

Если тебе что-то мешает, тебе тут же помогут или решат, как помочь. За то, чтобы на эти вопросы были получены ответы, отвечает scrum master, который не является формальным руководителем. Он такой же, как все. Иерархии в команде нет. Каждый отвечает перед остальными членами команды. Члены команды – такие же, как и ты. Нет никакой субординации. Тебе вряд ли удастся что-то скрыть и представить в выгодном тебе цвете. Да и зачем тебе это делать, если ты разделяешь цели команды и ее стремление сделать проект лучше и быстрее? То есть задача создания условий для принципа эстафеты: взял палочку – беги, что есть мочи, решается в scrum совсем по-другому – через организацию работы в команде, через ответственность перед такими же, как и ты, через взаимопомощь.

Еще рекомендуем:  Один дома

Если есть решение, значит, есть проблема. Если решение – scrum, то в чем была проблема? Что именно убрал scrum? На мой взгляд – иерархию. Исходную посылку, согласно которой важные решения могут приниматься только руководством. В scrum все важные решения принимаются заказчиком и командой. Команда наделяется автономией и самоорганизуется для выполнения проекта. Каждый член команды имеет ежедневную обратную связь от других членов команды, команда имеет частую обратную связь от владельца продукта. Они постоянно анализируют свою работу и вместе ее совершенствуют.

И в результате – scrum справляется с проектами, в которых есть не только неопределенность в процессе выполнения, но и неопределенность в самом содержании работ. И справляется хорошо.

Возникает законный вопрос: может ли отказ от исходной посылки, заключающейся в том, что проектная команда должна строиться по иерархическому принципу, помочь в улучшении выполнения проектов по методу CCPM? А может ли помешать? А как тогда должна быть организована работа? Возможна ли такая организация на крупных предприятиях?

Виктор Вальчук
К.ф.-м.н., директор ООО «АРБ-Консалтинг», бизнес-консультант, преподаватель и тренер Школы бизнеса «Управляй будущим».

Стаж консультационной деятельности 20 лет, большое количество проектов в различных отраслях бизнеса. С 2008 года использует в проектах Теорию ограничений. Сертифицированный TOCICO специалист по Теории ограничений (Мыслительные процессы, Управление цепью поставок, Управление проектами, Управление производством, Управление финансами и показателями).
Ведущий семинаров по управлению производством, управлению запасами, управлению проектами, управлению финансами, принятию управленческих решений, созданию предложения ценности.
Спикер конференций «Лин саммит», «Лин без галстуков», «Быстрореагирующее производство», «Теория ограничений».
Публикации автора по вопросам управления бизнесом
Получить подробную информацию и связаться с автором



Читайте наши статьи в соцсетях или подпишитесь на рассылку

Рассылка «Управляй будущим»
Я принимаю условия «Соглашения на обработку персональных данных» и даю согласие на обработку моих персональных данных

4 комментариев “Критическая цепь и SCRUM – общие черты и глубокое различие

  1. В моем опыте применения элементов SCRUM на крупном машиностроительном заводе нельзя было без иерархии — руководителя проекта, назначенного Приказом ген. директора. Из классики метода были ежедневные 15 минутные митинги. Было сокращено количество согласующих документы, которые нужно было принять на заводе в процессе проекта. Руководитель не давил, сумел выполнить роль scrum мастера. При этом он — топ-Менеждер завода. Команда помогала каждому участнику решать сложности по его задаче.
    Результат — быстрое устранение замечаний заказчика на изделие завода

      Цитировать  Ответить

    1. Виктор Вальчук

      Игорь,

      Спасибо, Игорь. Да, это удивительное свойство SCRUM. Он может быть использован в отдельном подразделении и чаще всего используется именно так — в организации присутствует иерархия, а в scrum команде ее нет. Руководство организации чувствует, что старые методы не работают и идет на то, что поддерживает (или закрывает глаза на) новую организацию труда в отдельных подразделениях. Где то я читал, что будущий собственник VALVE работал в таком подразделении Microsoft, где все было не так, как во всей остальной организации. Но в конце концов это прекратили и он создал собственный бизнес уже полностью на новых принципах.
      Я говорю «удивительное свойство» потому, что обычно сдвиг парадигмы в отдельном подразделении очень плохо уживается в материнской организации, в которой царит другая парадигма. Возьмите например теорию ограничений. Она «стоит» на глобальной оптимизации бизнеса в противовес локальной оптимизации, на учете прохода вместо учета затрат. Противоречие касается всей организации сразу, поскольку затрагивает общий поток.
      Поэтому на крупном предприятии (где обычно царит иерархия) scrum может прижиться в таких подразделениях, которые: разрабатывают новую продукцию (особенно если это не пересекается с основным производством), обособленно производят какой то продукт от и до, выводят на рынок и обеспечивают маркетинговую поддержку, осуществляют IT поддержку.

        Цитировать  Ответить

      1. Виктор Вальчук:
        Игорь,

        Спасибо, Игорь. Да, это удивительное свойство SCRUM. Он может быть использован в отдельном подразделении и чаще всего используется именно так — в организации присутствует иерархия, а в scrum команде ее нет. Руководство организации чувствует, что старые методы не работают и идет на то, что поддерживает (или закрывает глаза на) новую организацию труда в отдельных подразделениях. Где то я читал, что будущий собственник VALVE работал в таком подразделении Microsoft, где все было не так, как во всей остальной организации. Но в конце концов это прекратили и он создал собственный бизнес уже полностью на новых принципах.
        Я говорю «удивительное свойство» потому, что обычно сдвиг парадигмы в отдельном подразделении очень плохо уживается в материнской организации, в которой царит другая парадигма.Возьмите например теорию ограничений. Она «стоит» на глобальной оптимизации бизнеса в противовес локальной оптимизации, на учете прохода вместо учета затрат. Противоречие касается всей организации сразу, поскольку затрагивает общий поток.
        Поэтому на крупном предприятии (где обычно царит иерархия) scrum может прижиться в таких подразделениях, которые: разрабатывают новую продукцию (особенно если это не пересекается с основным производством), обособленно производят какой то продукт от и до, выводят на рынок и обеспечивают маркетинговую поддержку, осуществляют IT поддержку.

        Виктор Вальчук,

        Спасибо, Виктор!

        У Вас есть опыт применения ТОС для проектирования и производства продукции машиностроения на основе контракта жизненного цикла изделия?

          Цитировать  Ответить

        1. Виктор Вальчук

          Игорь,

          Опыт применения для машиностроения есть, но на основе именно КЖЦ — нет. А в чем там будет специфика? Есть опыт запуска завода с нуля на основе ТОС — исследования, управление проектом, проектирование и отладка производственного процесса, процесса распределения товара, разработка предложения рынку, обучения персонала и т.д.

            Цитировать  Ответить

А что вы думаете?

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.