Долгое время я воспринимал scrum как инструмент для использования в разработке программного обеспечения. Наиболее яркой чертой метода для меня являлось то, что он позволяет выполнять проекты с неопределенным содержанием конечного результата. Метод критической цепи определенно создан для проектов с заранее известным результатом. Это, конечно же, огромное различие, что, наверное, и проводило к тому, что в моей голове эти два метода лежали на разных полочках.
Но все-таки условия использования – это важное, но не главное. К каким главным изменениям в организации труда приходят CCPM (Critical Chain Project Management, метод критической цепи) и scrum? В условиях известного конечного результата (CCPM) гибкость нам нужна только для преодоления неопределенностей в исполнении и в наличие ресурсов, возникающих в ходе выполнения. С ними нам отлично помогает справиться буфер времени (вся подстраховка для критической цепи, агрегированная в одном месте) и система приоритетов на его основе. Задачи известны и определены. Система приоритетов прозрачна. Каждый в любой момент знает, что ему делать. У менеджера задач есть список задач, он уделяет особое внимание задачам в «красном», при необходимости перераспределяет ресурсы и это его ответственность. А еще он выдает инструкции, как именно выполнять ту или иную задачу. Ведь задача в критической цепи – это набор работ. У одной задачи может быть несколько исполнителей. То есть ролью менеджера является координация усилий разных ресурсов.
При определении критической цепи, на этапе планирования, встает вопрос определения длительности задач. Необходимо ее определить, удалив из длительности всю обычную подстраховку, которую привыкли закладывать подчиненные. Считается, что конечная длительность задачи должна составлять половину от обычной длительности. Урезать отведенное на выполнение время наполовину может оказаться трудной задачей с психологической точки зрения. Затем на этапе исполнения менеджеру, с одной стороны, не нужно давить на подчиненного относительно скорости выполнения работы, с другой стороны, каждый день оценивать какое время осталось до завершения задачи. Давит или не давит менеджер на подчиненного – можно узнать только у самого подчиненного. Тут лучше даже задать другой вопрос: ощущает ли подчиненный давление со стороны менеджера? И такое ощущение (со всеми вытекающими последствиями) вполне может быть, даже если давления как такового нет. Получается, что мы являемся заложниками того, как ведет себя менеджер и того, как ощущает поведение менеджера подчиненный. Тонкая материя, однако…
Теперь рассмотрим управление на основе scrum. Задачи здесь известны только на коротком промежутке времени одного спринта, никакая цепь задач не вводится, а соответственно нет и буфера. На каждом спринте возникает необходимость расставить приоритеты между задачами. Лучше всего это может сделать заказчик, или его представитель. Поэтому появляется роль владельца продукта. В ней не было необходимости в CCPM. Владелец продукта определяет самые приоритетные характеристики продукта, которые могут быть разработаны на ближайшем спринте, формулирует цели спринта через конкретные характеристики конечного продукта, а в конце спринта принимает работу через демонстрацию работающих характеристик. Задачи спринта формулируются уже командой проекта.
Задачи в спринте вообще не оцениваются во времени, они оцениваются в «стори поинтах» (относительных единицах). Команда способна сделать за время спринта определенное количество этих самых поинтов (величина определяется экспериментально). «Вес» задачи в поинтах определяется экспертным голосованием. В этом процессе нет руководителя, который потом будет спрашивать за выполнение обязательств. То есть вопроса закладки в длительность задачи подстраховки по времени не встает вообще. Да, в определении веса каждой задачи возможна ошибка. Но нас интересует не вес одной задачи, а вес всего спринта. Ошибка на одной задаче компенсируется ошибкой в другую сторону на другой задаче. То есть в scrum также заложен эффект агрегации, несмотря на то, что у нас нет буфера!
Что происходит дальше? Команда проекта каждый день проводит scrum митинг в течение 15 минут. Обсуждается три вопроса:
- что ты сделал вчера, чтобы помочь команде выполнить задачи спринта;
- что ты будешь делать сегодня;
- что тебе мешает выполнить стоящие перед тобой задачи?
Если тебе что-то мешает, тебе тут же помогут или решат, как помочь. За то, чтобы на эти вопросы были получены ответы, отвечает scrum master, который не является формальным руководителем. Он такой же, как все. Иерархии в команде нет. Каждый отвечает перед остальными членами команды. Члены команды – такие же, как и ты. Нет никакой субординации. Тебе вряд ли удастся что-то скрыть и представить в выгодном тебе цвете. Да и зачем тебе это делать, если ты разделяешь цели команды и ее стремление сделать проект лучше и быстрее? То есть задача создания условий для принципа эстафеты: взял палочку – беги, что есть мочи, решается в scrum совсем по-другому – через организацию работы в команде, через ответственность перед такими же, как и ты, через взаимопомощь.
Если есть решение, значит, есть проблема. Если решение – scrum, то в чем была проблема? Что именно убрал scrum? На мой взгляд – иерархию. Исходную посылку, согласно которой важные решения могут приниматься только руководством. В scrum все важные решения принимаются заказчиком и командой. Команда наделяется автономией и самоорганизуется для выполнения проекта. Каждый член команды имеет ежедневную обратную связь от других членов команды, команда имеет частую обратную связь от владельца продукта. Они постоянно анализируют свою работу и вместе ее совершенствуют.
И в результате – scrum справляется с проектами, в которых есть не только неопределенность в процессе выполнения, но и неопределенность в самом содержании работ. И справляется хорошо.
Возникает законный вопрос: может ли отказ от исходной посылки, заключающейся в том, что проектная команда должна строиться по иерархическому принципу, помочь в улучшении выполнения проектов по методу CCPM? А может ли помешать? А как тогда должна быть организована работа? Возможна ли такая организация на крупных предприятиях?
Критическая цепь. Управление проектами по ТОС
Цель любого проекта: «Завершить проект в срок, в полном объеме и в рамках выделенного бюджета». Для этого необходима методика, умеющая справляться с возникающей неопределенностью. Метод Критической цепи позволяет эффективно управлять неопределенностью. Использование буфера проекта позволяет вовремя получать информацию о задачах, которые ведут к опозданию проекта и ставят под угрозу его бюджет.
Тренеры: В.В. Вальчук, В.Е. Краснов. Старт: 3 июня 2024.
ПОДРОБНЕЕ
Книга в подарок
Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!
Telegram
VKontakteПохожие статьи
Борьба с неопределенностью как важнейший элемент управления организациями
Почему Критическая цепь работает
Новогоднее решение: прекратить многозадачность
Применение Теории производственного потока к управлению строительством
Управление проектами в больнице: от хаоса к успеху
Время – деньги! Особенно в проектной среде
К.ф.-м.н., директор ГК «АРБ», бизнес-консультант, тренер Школы бизнеса «Управляй будущим». Сертифицированный TOCICO специалист по Теории ограничений (Мыслительные процессы, Управление цепью поставок, Управление проектами, Управление производством, Управление финансами и показателями).
В моем опыте применения элементов SCRUM на крупном машиностроительном заводе нельзя было без иерархии — руководителя проекта, назначенного Приказом ген. директора. Из классики метода были ежедневные 15 минутные митинги. Было сокращено количество согласующих документы, которые нужно было принять на заводе в процессе проекта. Руководитель не давил, сумел выполнить роль scrum мастера. При этом он — топ-Менеждер завода. Команда помогала каждому участнику решать сложности по его задаче.
Результат — быстрое устранение замечаний заказчика на изделие завода
Игорь,
Спасибо, Игорь. Да, это удивительное свойство SCRUM. Он может быть использован в отдельном подразделении и чаще всего используется именно так — в организации присутствует иерархия, а в scrum команде ее нет. Руководство организации чувствует, что старые методы не работают и идет на то, что поддерживает (или закрывает глаза на) новую организацию труда в отдельных подразделениях. Где то я читал, что будущий собственник VALVE работал в таком подразделении Microsoft, где все было не так, как во всей остальной организации. Но в конце концов это прекратили и он создал собственный бизнес уже полностью на новых принципах.
Я говорю «удивительное свойство» потому, что обычно сдвиг парадигмы в отдельном подразделении очень плохо уживается в материнской организации, в которой царит другая парадигма. Возьмите например теорию ограничений. Она «стоит» на глобальной оптимизации бизнеса в противовес локальной оптимизации, на учете прохода вместо учета затрат. Противоречие касается всей организации сразу, поскольку затрагивает общий поток.
Поэтому на крупном предприятии (где обычно царит иерархия) scrum может прижиться в таких подразделениях, которые: разрабатывают новую продукцию (особенно если это не пересекается с основным производством), обособленно производят какой то продукт от и до, выводят на рынок и обеспечивают маркетинговую поддержку, осуществляют IT поддержку.
Виктор Вальчук,
Спасибо, Виктор!
У Вас есть опыт применения ТОС для проектирования и производства продукции машиностроения на основе контракта жизненного цикла изделия?
Игорь,
Опыт применения для машиностроения есть, но на основе именно КЖЦ — нет. А в чем там будет специфика? Есть опыт запуска завода с нуля на основе ТОС — исследования, управление проектом, проектирование и отладка производственного процесса, процесса распределения товара, разработка предложения рынку, обучения персонала и т.д.