Почему в Методе "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 месяцев, то уже неважно какой у нас питающий буфер виртуального барабана в днях. Мы обязаны иметь очередь проектов для начала исполнения. то есть мы переходим к схеме "барабан-буфер-канат для производства". И начинаем отслеживать уровень буфера в "единицах запасов". Это даёт возможность динамического управления ценой контракта в зависимости от уровня "запасов".

Когда вы управляете продуктом, вы уверены, что у вас всего один проект в один момент времени?

А сколько проектов на самом деле?

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

Agile - как много в этом звуке, для бизнеса с подачи Грефа завелось.

Manifesto for Agile Software Development - это про ускорение бизнеса? Или это это гибкость бизнеса?

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

В одной заметке для формата телеграмма это будет много поэтому будет серия на каждый день.

Поехали!

Я приведу по пунктам свою трактовку на русской версии "Манифеста гибкой разработки программного обеспечения". В скобках "как это следует трактовать".

== Ценности ==
Agile-манифест ценности. Часть 1.

Agile-манифест разработки программного обеспечения

(читаем оригинал: Manifesto for Agile Software Development - это Манифест Гибкой разработки программного обеспечения. Это значит что он заточен на программное обеспечение и для других сред требует адаптации. )

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

(Манифест придуман инженерами по разработке ПО и для инженеров, не для менеджеров, не для руководителей, а для инженеров)

Люди и взаимодействие важнее процессов и инструментов

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

#agile

Вышли новые страницы TOC BOK

At this time, there are now 7 TOC BOK papers which TOCICO has formally recognized as new TOC knowledge:

* Standing on the Shoulders of Giants (Four Concepts of Flow) by Dr. Eli Goldratt
* The Six-Step Process for Standing on the Shoulders of Giants by Dr. Lisa Anne Ferguson
* The TOC Pillars by Humberto Baptista
* Goldratt Six Questions by Eli Schragenheim
* Mystery Analysis by Yuji Kishira
* Unique Features of Government and How Governance Could be Assisted by the Theory of Constraints by Alfredo Mycue and Eli Schragenheim
* Cash Constraint and Cash Buffer by Ravi Gilani

https://www.tocico.org/page/TOCBodyofKnowledge

#tocico

Agile-манифест ценности. Часть 2.

Работающий продукт важнее исчерпывающей документации

(Дорогой собрат инженер - твои выкладки в документах конечно хороши, но ты не забыл что Клиенту нужно чтобы что-то работало? )

Сотрудничество с заказчиком важнее согласования условий контракта

(Ты же согласен с тем что Клиент не знает что он хочет? Это значит что как бы мы не фиксировали в ТЗ все его хотелки, всё равно будут изменения. Клиенту важнее что он хочет, наше дело реализовать в полном объеме то, что хочет. И нет, мы не бизнес-аналитики и не можем указывать клиенту что ему на самом деле надо. )

Готовность к изменениям важнее следования первоначальному плану

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

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

#agile