Что предпринимается в IT-компаниях, в случае, когда начинает истекать буфер критической цепи?

Если говорить о чистом Методе Критической Цепи (CCPM) (не о "Pulse Management" с дополнительными метриками) и если ПЛАН составлен верно (с применением Дерева перехода aka "Дерева предпосылок"), то единственный вопрос который нужно обсуждать: Как вернуть проект в зелёную зону?

Для этого обычно делают:
1. Проверяют скорость достижения промежуточных целей и ищут способы её повышения.
2. Договариваются об изменении объёма работ пока еще есть шанс.
3. Находят способы уменьшения объема работы и достижения всех целей. (см ИКР)
4. Договариваются об изменении сроков
5. Проверяют, а точно ли нужно делать всё то что там запланировали для достижения Цели.
6. Добавляют еще ресурсов, если есть возможность залить проект деньгами и мощность можно нарастить без ущерба для скорости.

На картинках ход выполнения ИТ-проектов в варианте "Pulse Management" с расчетом расхода буфера на основе скорости (синяя) и освоенного объема (коричневая).
Когда идет назад и вверх = добавили объём работ..

#ответы_на_вопросы
#метод_пульса #ccpm #Agile

Почему в Методе "Pulse Management" идет речь о Правилах работы, если есть уже давно применяемый термин "регламент".

Правила - это то о чем вы договоритесь с командой сами. Их НЕЛЬЗЯ писать в одиночку, как и в одиночку оставлять Устав проекта. Если вы пишете Правила работы в одиночку, то будут проблемы:
1. Вы не учли реальные факторы и условия среды по которым работают люди.
2. Люди будут нарушить Правила потому у них ДРУГИЕ условия среды. (следствие из п.1)
3. Люди будут нарушать Правила потому что ОНИ ИХ НЕ САМИ придумали. А люди охотней делают то, что сами придумали.
4. У вас просто не будет козырей для аргументации своей позиции. "Я начальник" это очень неустойчивая позиция в условиях когда рынок принадлежит соискателю. А искать замену сотрудника долго и дорого

Примечание: Если в вашей отрасли - рынок работодателя и у вас люди взаимозаменяемые за 1 день - предпосылки пункта 4 утрачивают силу.

ВАЖНО!! Правила не отменяют регламенты по технике безопасности и защите конфиденциальной информации и схожим. Правила - это способ договориться делать работу лучше и чтобы каждый нёс ответственность за их соблюдение.

Так почему же не "Регламенты"?
1. Как правило документы типа "Регламент" пишет "кто-то".
2. Руководитель считает что это он тот самый "кто-то" кто ДОЛЖЕН писать регламент.
3. Однако, у руководителя нет на времени чтобы писать "какие-то там регламенты", работать надо. И поэтому в компании все бегут в разных направлении у каждого свои бизнес-процессы в голове.
4. "Регламент" воспринимается как что-то высеченное в камне. Бывают конечно другие культуры на предприятиях. Но обычно, если на написание регламента руководитель "с трудом" выделил время то менять он его по каждому чиху не будет.
4. Если регламент тяжело поменять то сотрудники будут КАК УДОБНО, а не как надо для максимальной продуктивности компании.

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

Договаривайтесь о Правилах! Правила программируют организацию.

#метод #метод_пульса #ответы_на_вопросы

Иллюстрация к Правилам.

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

#метод #метод_пульса

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

#метод #метод_пульса #теория_ограничений

Мы никогда не знаем точный маршрут. У нас есть только поверхностые знания о том, как будет выполняться проект. Потому, что видим только верхушки. Но если планиовать от Цели, то становится более интересней, вы пробовали бегать спиной назад?

#метод #метод_пульса

Две оценки лучше чем одна оценка. Оптимистичный и пессимистичный сценарий дадут разброс в общей длительности проекта. Вы сможете заложить достаточный резерв расписания проекта чтобы обеспечить надежную поставку результатов точно в срок.

#метод #метод_пульса

То самое чувство, когда план проекта превратился в "беклог продукта" который никогда не полный.

На "графике температур" все линии принадлежат одному и тому же проекту в разных стратегиях расчета:

1. На основе прогноза даты завершения на основании скорости выполнения работ

2. На основе отклонения освоенного объема работ

И то же самое но учетом работ, длительность которых еще не была оценена. Автор идеи учета работ без оценок Евгений Айдаров.

Зачем использовать данные о работах без оценки

Если вы думаете, что успеваете, но еще не все задачи в проекте оценены (потому что, например, недопроектированы) - то это не совсем так.

#метод #метод_пульса #CCPM

Коллеги, на сайте Метода управления вышла новая статья Юлианы Кузнецовой (@juliana_kuznetsova) о применении Устава проекта для маркетинговых экспериментов при примении подхода "эскперимент как проект".

https://pulsemanagement.org/article-ot-ustava-proekta-k-kartochke-jeksperimenta/

#метод #метод_пульса

Немного об ИТ.

Особенности контрактов (проектов) "время и материалы" (T&M) в том, что:
1.1 Исполнителю ВЫГОДНО делать проект дольше, потому что он больше заработает
1.2 Исполнителю ВЫГОДНО задействовать в проекте больше ресурсов, потому что он больше заработает
1.3 Исполнителю ВЫГОДНО перекладывать риски на Заказчика (любой каприз за ваши деньги).

А с другой стороны
2.1 , маржа Исполнителя фиксирована и на рынке возможен демпинг трудовых ставок. Что может привести снижению оплаты сотрудников и потере экспертизы компании в отрасли.
2.1 Заказчику выгодно, чтобы проект делался БЫСТРЕЕ.

И для ИТ-проектов Agile-подходы дают ощущение быстрого результата на старте, но так ли они выгодны в долговременной перспективе?

Pulse Management - "Управление Пульсом", если мы мы чем-то можем управлять, то нужно понять "как управлять" и "чем управлять". Для этого применим метод аналогии. "Аналогия Пульса" - это как?

Аналогия Пульса - "Пульс" - это ритм живого у организма. А у любого ритма есть амплитуда и частота. Если мы говорим про предприятие то:
* Частота - частота принимаемых решений.
* Амплитуда - влияние принимаемых решений.
Таким образом, управляя частотой Пульса - мы меняем количество совещаний в зависимости от текущего состояния "здоровья" компании, а управляя амплитудой Пульса мы меняем сами решения и их влияние на предприятие.

#метод #метод_пульса

Ключевая ценность Метода - Различные элементы Метода в стыковке с мыслительными процессами Теории Ограничений помогают "Занять место под солнцем без кровавой грызни".

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

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

#метод #метод_пульса

BIPULSE: Мы упростили интеграцию с Bitrix24 и теперь подключить интеграцию может любой пользователь Bitrix24 даже без прав администратора.

Мы упростили интеграцию BIPULSE с Bitrix24 и теперь подключить интеграцию может любой пользователь Bitrix24 даже без прав администратора.

Что это даёт

Тотальный контроль всех проектов в Битрикс24, прогнозирование сроков завершения, автоматическое планирование расписания проектов планирование, и главное: Увидеть лес за деревьями.

#bipulse

Вышла печатная книга о Методе управления проектным бизнесом.

Теперь её можно заказать.
https://ridero.ru/books/upravlenie_proektnym_biznesom/

В чем отличия от версии 1.11 выложенной на сайте PulseManagement:
а) Это печатная книга
б) Она с бумажными страницами
в) На полях страниц можно писать
г) На страницах можно делать закладки
д) На страницах можно делать закладки со своей версией Правил.
е) Её можно подарить!

ps: Будет хорошо, если оставите отзывы на сайте Ridero

#TOCICO проводит вебинар Fundamentals of Flow-Based Scheduling

==
Fundamentals of Flow-Based Scheduling - Seeking Feedback from TOC Experts presented by Sanjeev Gupta

Join us on September 29th! This interactive webinar is a follow-up from Sanjeev's keynote at the 2021 TOCICO International Conference. Revisiting TOC knowledge, and presenting a synthesis and distillation of what we have practiced and known over the years. Sanjeev believes that formalizing the ideas of flow-based scheduling is necessary for their wider adoption. That's why he is seeking feedback from TOC Experts who have implemented TOC's DBR, Replenishment, or CCPM solutions, on the concepts, verbalizations, how to encapsulate them, etc. in the process of creating a structured body of knowledge to better understand and derive new solutions for Flow Scheduling.

Please join us on September 29th! This LIVE Webinar is from 10:00 AM through 12:00 PM EDT (New York USA) and includes Live Q&A with Sanjeev Gupta.

https://www.tocico.org/events/EventDetails.aspx?id=1553709&group=
===

Бесплатно для членов, и всего $19 для гостей. Для России членство - всего $99.

#метод #ccpm
Заметка о критической цепи и буферах в ней.

В критической цепи есть:

Буфер проекта = буфер критической цепи проекта = 50% длительности цепи

Питающий буфер цепи = буфер питающей цепи = 50% длительности питающей цепи ( (и нет с словаре TOCICO - или разница между поздним и ранним финишем, что меньше)

Буфер мощности = ресурсный буфер виртуального барабана = защита старта следующего (эшелонированного) проекта от неопределённости предыдущего проекта (проектов). Вставляется при эшелонировании проектов по виртуальному барабану

Питающий буфер барабана = Питающий буфер виртуального барабана = Защищает старт работы виртуального барабана при эшелонировании проектов от неопределенности в ПРЕДШЕСТВУЮЩЕЙ цепи проекта. Буфер гарантирует что для виртуального барабана будет работа, когда он перейдет с другого проекта.


Тонкость в том , что если произойдет ситуация когда виртуальный барабан завершит работу И НЕ ПОТРАТИТ буфер мощности , то для него ДОЛЖНА быть работа которая может быть ЗАДЕРЖАНА в предшествующей цепи. Таким образом нам НУЖЕН питающий буфер виртуального барабана который исключит простои барабана (напомню что Барабан ограничивает способность зарабатывать деньги компанией) . И значит дата начала второго проекта будет:

ДатаНачала(2) =  ДатаФинишаБарабана(1)
   + БуферМощности(1) 
   - ДлительностиПредшЦели(2) 
   - БуферПитающийБарабана(2)

Но есть другой сценарий: Когда ПРЕДШЕСТВУЮЩАЯ цепь перед первой работой виртуального барабана в эшелонированном проекте ДЛИННЕЕ чем критическая цепь перед виртуальным барабаном, в этом случае буфер питания виртуального барабана будет БОЛЬШЕ, чем буфер мощности. И есть угроза, что нам не хватит буфера мощности для отсекания неопределенности в предшествующей цепи.

Но! Ситуации в которых когда виртуальный барабан завершит работу И НЕ ПОТРАТИТ буфер мощности слишком редки. Так, как цепь считается по оптимистичной оценке задач (или 50% вероятность завершения задачи в эту оценку). А значит, буфер мощности ГАРАНТИРОВАНО будет потрачен.

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

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

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

Примечание: Косвенно в этой цепи есть фаза "продажа (услуг) проектов" (пресейл). В этом случае, ритм привлечения Клиентов задаёт виртуальный барабан. Но если мы примем за константу, что время контрактования 3-6-9 месяцев, то уже неважно какой у нас питающий буфер виртуального барабана в днях. Мы обязаны иметь очередь проектов для начала исполнения. то есть мы переходим к схеме "барабан-буфер-канат для производства". И начинаем отслеживать уровень буфера в "единицах запасов". Это даёт возможность динамического управления ценой контракта в зависимости от уровня "запасов".