Agile: как сделать гибкой всю вашу компанию

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

Один из основных принципов Agile отражен в названии, и говорит о таком свойстве, как гибкость. Что такое гибкость применительно к системе управления? Хочу предложить следующую интерпретацию.

Самый простой способ понять: насколько компания гибкая – это оценить, сколько времени она способна проработать без вашего вмешательства. В ранее опубликованной статье «Можно ли использовать в менеджменте принципы термодинамики» я размышляю о том, как преобразуется энергия в бизнесе как в системе. Основная мысль: энергия склонна затухать, система в этом случае становится малоподвижной, что, как мы понимаем, смерти подобно. Самым важным результатом преобразования энергии является ответ на вопрос, надо ли создателю бизнес-системы постоянно ее толкать, либо она способна ряд задач решать самостоятельно. Системы, способные функционировать подобным образом, попадают под определение «самоорганизующиеся», если использовать методологию физики. А если следовать методологии менеджмента, то более корректно использовать термин «самоуправляющиеся системы».

Чем важна гибкая методология управления

Способность быстро меняться – ключевая в конкурентной борьбе. Определяющий фактор – скорость принятия решений и их последующая реализация. Очевидно, что чем самостоятельней подразделения могут принимать решения, чем меньше согласований им вменено, тем быстрее бизнес развивается. Важна оперативная независимость от центра принятия решений (ЦПР). И не важно, является ли центром принятия решений один человек, в виде генерального директора, либо некая структура в виде управляющей компании.

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

Принципы, лежащие в основе Agile, неплохо ложатся в основу управленческой платформы, построенной на новой методологии управления. Вот некоторые из них:

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

Главные правила внедрения agile-управления

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

  • Правило маленьких шагов. В портфолио каждого управленца есть несколько образцовых кейсов, описывающих, как умирают масштабные проекты изменений, так и не дожив до победы. Но Agile категорически не нужны большие и редкие победы. Не стесняйтесь ставить маленькие и очень понятные цели. Даже если цель – просто вовремя начинать и заканчивать совещания.
  • Правило максимальной итерационности шагов. Итогом каждого шага по развитию проекта должен быть результат, уже на этапе предварительного результата устраивающий все группы лиц, иное может обнулить всю работу.
  • Правило «Договорились – делаем». Крайне важный пункт. Никто в одностороннем порядке не отменяет никаких договоренностей. Организатор совещания не может вдруг его пропустить с посылом «вы сами как-нибудь все обсудите, а я потом все пересогласую». Двойные стандарты – первый враг самоуправляющихся систем.
  • Правило «Для народа и с народом». Важно учитывать интересы каждого участника процесса, а не просто спускать инициативу сверху. Равноправие каждого участника процесса принципиально. Все попытки кем-либо продавить «удобное» или «правильное» решение, обнулят активность людей на корню, сделав всю систему принятия решений крайне ригидной и сопротивляющейся. Это касается и первого лица: ничто так не душит на корню желание сотрудников быть гибкими, как «царские указы».

Как начать движение к системе, основанной на гибких принципах

Далее я предлагаю семь шагов, позволяющих начать внедрение принципов СУС в компании. Их последовательность может быть разной. Каждый управленец-практик понимает, насколько жизнь далека от теории. Но главное при этом не впасть в соблазн вообще не делать какие-то обязательные шаги в надежде, что «все образуется само».

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

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

Шаг первый: подготовка к делегированию полномочий

Цель – начать процесс снижения участия первого лица в принятии оперативных решений.

Удаление первого лица от оперативки – первейшая задача при построении СУС. С этой мыслью необходимо сжиться, изменить суть своего подхода к управлению, образ действия. Основная задача – построить такую модель управления, которая позволит, в идеале, не участвовать в оперативном управлении вообще. Первое лицо, как дух вездесущий: обладает полным объемом информации и не имеет никаких возможностей подрулить в процессе.

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

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

Шаг второй: начать диалог с сотрудниками

Цель – определить, под какие блоки задач на данном этапе есть люди, а где провал. Люди – основа СУС.

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

Соответственно, крайне важно начать диалог со своими сотрудниками, понять, кто из них готов быть в команде, какие препятствия стоят на пути их интеграции. Хочу заметить, что диалог – ключевой инструмент при внедрении СУС. Принуждение и СУС – несовместимы.

Шаг третий: разработать финансовую модель

Цель – создать единое понимание того, как считаются деньги в компании.

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

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

Рекомендации руководителю. Если вам, как первому лицу, кажется, что экономическая модель компании уже существует, проверьте себя простым вопросом: все ли ключевые люди вашего бизнеса (топ-менеджмент, при наличии) согласны с методикой ее формирования? Или вот вопрос для самых отважных: все ли ваши топ-менеджеры согласились бы с утверждением, что они владеют достаточным объемом информации о том, как рассчитываются экономические результаты, и что их мнение при этом учитывается? Очевидно, что если в этом фундаментальном вопросе вы решили все «царским указом» – нет у вас ни мотивированной команды, ни самоуправления. И, конечно, я молчу о тех случаях, когда финмодель – тайна за семью печатями, которой босс ни с кем не делится.

Шаг четвертый: конкретизировать задачи команды

Цель – создать предпосылки для формирования целей на определенный период.

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

Часто руководитель, действующий в таком стиле, весьма непоследователен и противоречив: сегодня одно, завтра – другое. И менеджмент, после нескольких безуспешных попыток успеть за ним, просто опускает руки и ждет. Первое лицо постоянно что-то меняет, что окончательно демотивирует людей, гасит потенциал команды. Как следствие, руководитель становится одной из точек блокирования СУС, одним из «узких» мест в развитии бизнеса в целом.

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

Данный шаг – это попытка начать фиксировать понимание того «куда идем и какие задачи решаем», хоть в неком, пусть незначительном временном периоде.

Шаг пятый: создать архитектуру бизнес-процессов верхнего уровня

Цель – договориться с командой, как выглядят, что включают в себя основные блоки бизнес-процессов, какова их последовательность.

На данном этапе начинается формирование предпосылок для перехода системы менеджмента на новый уровень самоуправления. Речь идет о создании верхнего уровня системы управления, о нарезке структуры компании блоками крупных задач, опираясь на основные бизнес-процессы. Изначально блоки обычно выглядят максимально крупно, без общих слов. Пример для производителя электроники: финансы, коммерческая активность, R/D, производство, управление качеством.

Рекомендация руководителю. Если вы будете спускать свое видение команде директивно, данная модель никогда не заработает, это будет абстрактное конструирование. Здесь предельно важен живой диалог с командой.

Шаг шестой: установить границы и правила

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

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

В целом это весьма понятная задача. Самое сложное – в течение определенного времени дать возможность людям и подразделениям поработать в соответствии с принятыми решениями. Это может быть что-то совсем простое: раньше директор каждый день интересовался, как дела в подразделении, теперь – раз в неделю.

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

Рекомендации руководителю: на этом этапе решите, какие именно полномочия вы готовы реально передать, и не вмешиваться некоторое время в деятельность своих подчиненных.

Шаг седьмой: построить систему мотивации команды

Цель – сформировать видение того, что является, по мнению всех заинтересованных сторон, справедливой оценкой результата.

Очевидно, что построение команды, основанной на принципах СУС, это игра в долгую. Также очевидно, что невозможно удержать, знающих себе цену профессионалов, не решив денежный вопрос. Это непростая задача, у каждой из сторон есть свои доводы. Но, откладывая решение «на потом», вы рискуете запустить неуправляемые процессы.

Это тот случай, когда уместно вспомнить поговорку: «жадность приводит к бедности». Как вы платите людям, так они и работают. И чем выше по уровню профессионал, тем сильнее его оскорбляет несправедливость. Он либо уходит из компании, либо объявляет итальянскую забастовку. А вы получаете очередную точку блокировки формирования СУС.

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

Шаг восьмой: запланировать новый цикл улучшений

Цель – планирование следующего шага на пути к самоуправляющейся системе.

Основная задача всей активности, связанной с формированием СУС, это последовательное движение. Безостановочное. Не должно быть иллюзий, что этот процесс будет сам себя поддерживать. Как писал я в статье о термодинамике и управлении, энергия в системе затухает. Задача первого лица – постоянно поддерживать движение этого процесса. И при этом важно, чтобы активность руководителя затрагивала все больше процессов и людей.

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

Выводы

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

Расскажите коллегам:
Комментарии
Управляющий директор, Москва
Святослав Бирюлин пишет:
Мне кажется, Agile - это все-таки больше про управление проектами, тогда как TPS - это про управление производством. В них общего то, что и то, и другое про организацию потока, внутренней логистики процессов и/или информации, однако в нюансах они очень сильно отличаются. Agile призвана построить систему, гибко реагирующую на изменения, а TPS призвана повысить скорость процессов.

Соглашусь, у каждого инструмента есть свое поле.

Для решение задач в контексте управления бизнесом в целом необходима интеграция.

Управляющий директор, Москва
Владимир Селезнев пишет:
Борис,
большое спасибо за статью. Действительно продуманный путь в рамках философии "постоянного улучшения".
Такое ощущение, что Вы чего-то утаили и не написали в этой статье ))
Очень похоже, что у Вас есть еще что сказать на данную тему.

Спасибо на добром слове!

Тема бездонная, буду пробовать ее развивать далее.

Если есть вопросы применительно к вашей ситуации - обращайтесь, буду рад посодействовать.

Управляющий директор, Москва
Владимир Токарев пишет:
Критическая цепь
Николай Лисовский пишет:

Присоединяюсь к вопросу Владимира Токарева.

Давайте посмотрим на вопрос шире.

Agile нас не интересует. Это инструмент для управления разработкой ПО. Но он входит в методики "гибкого управления".

и вот основной вопрос - почему появилась потребность в новом подходе к управлению в целом. В частности, Греф об этом много сейчас говорит. Про конкуренцию моделями управления.

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

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

Владимир Токарев +15105 Владимир Токарев Генеральный директор, Нижний Новгород
Борис Тунников пишет:
В частности, Греф об этом много сейчас говорит. Про конкуренцию моделями управления....ни даже Адж ( в чистом виде) не отвечают на такие вопросы, как например: (1) как сделать бизнес легко перестраиваемым под разные задачи? (2) как обеспечить высокую скорость принятия решений? (3) как преодолеть сопротивление и "лень" сотрудников? (4) как снизить затраты на управление в целом?

Вроде как Греб финансист? Что о нем вспоминать всуе, когда обсуждается менеджмент, про который он "слышал". Поскольку если говорить о его практике менеджмента - то ее легко увидеть по качеству услуг Сбера, к сожалению, мне приходится это делать, мои соболезнования, если и вам.

1. Для этого есть проектное управление, и здесь нужно соревноваться с ТОС.

2. Здесь многое решает объем делегирования. Чем оно плохо?

3. По сопротивлению изменениями и даже управлению ленью - написано много и инструментарий я бы назвал избыточным. Применяется 10%, если не меньше.

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

Researcher, Москва

О статье:

Что ж делать?.. Речью неискусной
Занять ваш ум мне не дано...
Все это было бы смешно,
Когда бы не было так грустно… (М.Лермонтов)

Смешно - когда ради рекламы и чтоб "прокукарекать" консультанты цепляются за любое звучное слово/термин.

Грустно что такие статьи серьезно обсуждаются …

Agile как идеология родилась в недрах информационных технологий как подход к решению проблемы взаимодействия команды разработчика ПО (программного обеспечения) и ЗАКАЗЧИКА из бизнес-среды.

А сама проблема заключалась в том, что ЗАКАЗЧИК не мог четко и однозначно сформулировать ТРЕБОВАНИЯ к ПО. Неоднозначность ТРЕБОВАНИЙ вызывала необходимость делить всю разработку на этапы и согласовывать каждый следующий этап после передачи ЗАКАЗЧИКУ предыдущего.

Понятно, что при планировании каждого следующего этапа, при коллективной разработке, требуется согласование действий каждого из разработчиков. Ведь они все! должны закончить этап ОДНОВРЕМЕННО и передать ЗАКАЗЧИКУ.

Я это описал к тому что ОСНОВНОЙ игрок - ЗАКАЗЧИК, основная цели проекта УДОВЛЕТВОРЕНИЕ заказчика, задача команды разработчиков ОРГАНИЗОВАТЬ свой труд согласно цели!!.

Организация труда разработчиков ПО - это и есть методы управления, и они могут быть самые разные в зависимости от задачи и от компетенции разработчиков. Один из часто обсуждаемых (у нас)- это Scram.

Поэтому я считаю, что нет Заказчика с неопределёнными требованиями к продукту -- НЕТ И AGILE.

При утвержденном ТЗ (техническом задании) никакого Agile не нужно.

Генеральный директор, Москва
Валерий Овсий пишет:
О статье:
Что ж делать?.. Речью неискусной
Занять ваш ум мне не дано...
Все это было бы смешно,
Когда бы не было так грустно… (М.Лермонтов)
Смешно - когда ради рекламы и чтоб "прокукарекать" консультанты цепляются за любое звучное слово/термин.
Грустно что такие статьи серьезно обсуждаются …
Agile как идеология родилась в недрах информационных технологий как подход к решению проблемы взаимодействия команды разработчика ПО (программного обеспечения) и ЗАКАЗЧИКА из бизнес-среды.
А сама проблема заключалась в том, что ЗАКАЗЧИК не мог четко и однозначно сформулировать ТРЕБОВАНИЯ к ПО. Неоднозначность ТРЕБОВАНИЙ вызывала необходимость делить всю разработку на этапы и согласовывать каждый следующий этап после передачи ЗАКАЗЧИКУ предыдущего.
Понятно, что при планировании каждого следующего этапа, при коллективной разработке, требуется согласование действий каждого из разработчиков. Ведь они все! должны закончить этап ОДНОВРЕМЕННО и передать ЗАКАЗЧИКУ.
Я это описал к тому что ОСНОВНОЙ игрок - ЗАКАЗЧИК, основная цели проекта УДОВЛЕТВОРЕНИЕ заказчика, задача команды разработчиков ОРГАНИЗОВАТЬ свой труд согласно цели!!.
Организация труда разработчиков ПО - это и есть методы управления, и они могут быть самые разные в зависимости от задачи и от компетенции разработчиков. Один из часто обсуждаемых (у нас)- это Scram.
Поэтому я считаю, что нет Заказчика с неопределёнными требованиями к продукту -- НЕТ И AGILE.
При утвержденном ТЗ (техническом задании) никакого Agile не нужно.

Валерий, БРАВО!

Нач. отдела, зам. руководителя, Москва

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

Существует достаточно много методологий организации разработки ПО, которые относятся к классу Agile, и они отличаются чем-то друг от друга, у каждой методологии есть своё название. Мы используем одну из методологий -> XP где-то с конца 2003 года, и она вполне конкретна, и наполнена определённым смыслом. В "чистом" виде, без элементов стандартных методов, эджайл вряд ли где-то используется, и это уже обсуждалось в дискуссиях по поводу Scrum на этом сайте -> нельзя быть настолько "гибким", чтобы забыть о планировании. И ещё, зачем заимствовать термин Agile - придумайте свой, отличный от других, его уже используют все кому не лень ...

Нач. отдела, зам. руководителя, Москва

Когда стали появляться различные методологии Agile? -> Когда появились средства быстрой разработки приложений - ПО (Rapid Application Development - RAD). Т.е когда можно было быстро представить заказчику макет приложения, и затем работать с ним в полном контакте, малыми шагами, быстро предоставляя ему готовые решения. С тех пор развивались не только средства разработки, но и различные методы работы с такими Проектами.

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

Гибкость управления в Agile - это гибкое управление проектом, но не управление компанией. То что перечислено в разделе статьи Чем важна гибкая методология управления можно найти во многих компаниях с Функциональным управлением: ~ 3 - 20 сотрудников, очень небольшое число уровней управления - всё на виду. Гибкость такого управления настолько велика, что самый экстремальный пример :), когда за время от нескольких часов до нескольких дней можно сменить даже предмет деятельности - вот здесь участвуют все сотрудники компании. Да, и то не всегда - кто-то ведь должен деньги зарабатывать.


Нач. отдела, зам. руководителя, Москва
Автор пишет в статье: Способность быстро меняться – ключевая в конкурентной борьбе.

И название статьи: Agile: как сделать гибкой всю вашу компанию

"Гибкое" - это прилагательное, которое говорит только о возможностях, но не о скорости изменений, а Agile означает подвижный, проворный, быстрый.

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

Требование Быстро меняться не конструктивно, потому как насколько быстро меняться не определено - "баланса" в этом нет - дёргаться ведь тоже не нужно. Вообще, можно было бы использовать термин АДАПТИВНОСТЬ - это означает ещё желание изменяться и изменять, преобразовывать окружающий мир, и это подходит для всех типов управления . И критерии по скорости изменений тоже становятся понятны - нужно успевать Адаптироваться, или даже предвидеть изменения.

Мне представляется, что термин Agile здесь лишний, дань моде.

Нач. отдела, зам. руководителя, Санкт-Петербург
Владимир Токарев пишет:
Я из советского времени, потому как-то привык к другому алгоритму - есть тема или задача, есть старые методы решения, но у них такие-то недостатки. Новая метода за счет того-то решает эти проблемы. Например Голдратт так предлагал своей метод Критическая цепь, критикуя Метод критического пути.
Вопросы к автору - какие недостатки есть у метода критической цепи, за счет чего они преодолеваются в Agile?

С точки зрения разработки ПО, есть некоторые плюсы у Agile/Scrum в сравнении с CCM, как наверно и минусы.
1) меньшее время на изначальное планирование. Это миф, что при старте Agile/Scrum проекта необходимо иметь представление всего на один спринт (2-4 недели), но при этом не надо выстраивать всю цепь.
2 и 3 связаны) при разработке ПО будет то продуктовка (в меньшей степени), и заказная разработка (в большей степени), приоритеты необходимого к разработке могут изменяться каждую неделю-две в зависимости от требований рынка/заказчиков/возникших проблем/технических ограничений. Предположу, что перепланирование/переприоритезация Scrum бэклога (набора задач), произойдет прозрачнее и быстрее, чем перестраивание цепи. У меня нет данных по современным инструментам работы с CCM, но если это до сих пор MS Project, то инструменты планирования Scrum удобнее, быстрее и проще (Jira, Liquid Planner, ..)

4) Работая по Scrum нет проблемы выстраивания приоритетов и взаимосвязей задач, будь их несколько сотен. Построение критической цепи (или нескольких групп их таких цепей) , а также, актуализация ее будет куда более сложной задачей.


При этом, Scrum и CCM можно объединить: большие задачи спринтов (итерации разработки, 2-4 недели) могут быть элементами критической цепи.


Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Треть профессионалов не доверяют своему руководству

Специалисты меньше, чем руководители и директора, склонны к доверию.

Зарплатные ожидания IT-специалистов превышают возможности работодателей в 1,5-2 раза

Общий рост зарплат в IT-сфере за первые 9 месяцев 2023 года составил 15-20%.

Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

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