Особенности контрактов (проектов) "время и материалы" (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

== Agil-манифест. Принципы часть 1.==

Мы следуем таким принципам:

(Если у нас есть принципы, то мы можем из них развивать ценности. Это математика)

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

(Мы, с тобой брат, инженеры, а не аналитики. Мы умеем конструировать лучшие решения под заказ, а не выяснять проблемы в голове Заказчика. Если Заказчик не знает что хочет, мы ВЫНУЖДЕНЫ экспериментально это выяснять. Поэтому давай чаще поставлять чтобы корректировать)

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

(Если Клиент не понимает "что хочет", значит давай запроектируем гибкую архитектуру и применим всю мощь XP/Crystal/Agile-process для поддержания надежности продукта чтобы он не развалился при изменениях)

#agile

Agile-манифест. Принципы часть 2.

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

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

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

(Ты помнишь, что Клиент может быть недоволен нашей работой? Если он не доволен , то он не заплатит. Потому повышай прозрачность и вовлекай Заказчика в процесс. Тогда это будут "его решения" и он не сможет отвертеться. И в дискуссиях есть шанс что он наконец-то найдет то что ему действительно нужно. А если не найдет, пусть платит. )

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

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

#agile

Agile-манифест. Принципы часть 3.

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

(Брат, инженер, Ты помнишь что мы живем в индивидуалистичном обществе и хорошие кабинеты нам заменили кубиклы 2х2 метра. А я знаю что ты, как и я интроверт и любишь тишину чтобы проектировать крутые системы. Но лучше один раз пообщаться, чем писать много писем. Встречаться и общаться нужно, хотя это и не хочется)

Работающий продукт — основной показатель прогресса.

(Мы с тобой, брат инженер, понимаем как ценно для нас создавать идеальную архитектуру которая будет превосходить всё что мы с тобой создали прежде. Но помни, что Клиенту важны не твои выкладки, документы, классы и прототипы. Ему нужно чтобы продукт работал! Поэтому не уходи в паралич анализа, а сделай чтобы работало. )

Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile-процесс помогает наладить такой устойчивый процесс разработки.

(Если Клиент и инвестор не понимает что хочет, то выстрой им Agile-процесс. У них есть деньги, дай им прозрачность и уверенность что ты можешь сделать все их хотелки. Практики XP/Crystal/DSDM/DAD/Pragmatic programmer придадут тебе Силу. )

#agile

А чем Pulse Management отличается от Critical Chain project management?

Pulse management отвечает на 3 ключевых вопроса:
1. Делать или делать задачу которую придумал инженер в рамках текущего проекта?

2. Спасаем или не спасаем проект?

3. Усиливаем команду наймом сотрудников или пытаемся улучшить производительность текущей команды.

И на несколько дополнительных:
1. Когда закончим это проект?
2. Когда освободится сотрудник?
3. Как спасаем проект? (см. второе поколение Метода)


CCPM отвечает только на вопрос 2.

Agile-манифест. Принципы часть 4.

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

(Друг, не разменивай качество на скорость. Скорость убьет тебя на длинной дистанции. Встрой качество в процесс. Если Клиент не знает, что хочет то нам нужно обеспечить гибкую архитектуру чтобы быстро её менять. Для этого нужно 100% покрытие модульными тестами и придерживаться TDD, CI, CD)


Простота — искусство минимизации лишней работы — крайне необходима.

(Чем проще система, тем проще её поддерживать. А изменений будет много. Спроектируй сразу так чтобы было легко поддерживать. )

#agile

Agile-манифест. Принципы часть 5.

Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

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


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

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

== Итого ==

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

#agile

Разница в расчёте буферов для Agile-проекта.

Разница между Теорией ограничений (ТОС) и Бережливым производством -

Бережливое производство направлено на снижение потерь - то есть играть чтобы не проиграть. А решения ТОС направлены на то, чтобы выиграть.

Играть чтобы выиграть намного интересней чем играть чтобы "не проиграть". Это даёт силы и возможность получить больше чем есть сейчас.

То же самое касается разницы Мира прохода и Мира затрат. Цель бизнес-системы максимизировать Проход (играть чтобы выиграть), а не "резать косты" и снижать стоимость привлечения Клиента (играть чтобы не проиграть).

#ответы_на_вопросы

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

Концепция Дао предприятия помогает осознать "сколько на самом деле у нас точек внимания" и что с ними делать.

Для практической работы с треугольником есть правила: (продолжение следует)
#метод #метод_пульса