Опубликовано видео с прошлогоднего РИТ++
Рассказываю о методе.

Как часто у вас возникает дилемма между "Нужно утилизировать ресурс" и "Нужно достигнуть текущие цели максимально быстро?"

https://tinyurl.com/y6xl7j8s

#метод 27

— Планирование содержания спринта ==

При определении содержания спринта необходимо учитывать доступную мощность команды и дополнительные факторы.

Факторы влияющие на планирование

1. Мощность команды - весь объем работы который может выполнить команда за спринт. Мощность команды вычисляется на основе прошлого опыта (исторических данных) или экспертной оценкой.
2. Резерв мощности для задач не влияющих напрямую Реализацию функционала поставки, но влияющих на снижение стоимости поддержки Продукта.
3. Резерв мощности на неожиданные задачи
4. Резерв мощности на неопределённость содержания в случае если задачи в спринте не имеют типовых решений и требуются исследования.
Правила планирования спринта
1. Все задачи спринте одной команды должны касаться одного проекта.
2. Команда должна иметь возможность гарантированно успеть выполнить все взятые на спринт обязательства по поставке коммерчески ценного результата.
3. Команда должна иметь возможность выполнять работы по техническому совершенствованию Продукта.
4. Команда должна иметь понятную цель на спринт.

Алгоритм планирования содержания спринта:

1. Определите, максимальную мощность команды на основании 2-3 завершённых спринтов.
2. Определите, какой резерв нужен для незапланированных задач и рисков. В среднем это 20-30% мощности команды.
3. Определите, какой резерв нужен для выполнения технологических задач. Этот резерв может составлять от 10 до 80% максимальной мощности в зависимости от технологической зрелости команды.
4. Определите ключевую цель спринта.
5. На остаток мощности команды - доступную мощность команды, выберите приоритетные задачи имеющие ценность для бизнеса, результат выполнения которых вы хотели бы получить по завершению спринта и соответствующие цели спринта.
6. Определите правила вытягивания задач из нераспределенных.

Коллеги, BIPULSE стал еще доступнее. Программа вошла в Реестр российского ПО
https://reestr.minsvyaz.ru/reestr/162655/?sphrase_id=230199

Эшелонирование проектов.

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

В описание Метода "Pulse Management" крако указано про наличие ресурса-ограничения и эшелонирование.

Но покажу на примере:

* Проект "А" имеет критическую цепь длительностью 100 дней, стандартный буфер цепи 50 дней. Итого, полная пессимистичная длительность проекта (с буфером) составит 150 дней. В этом проекте есть ресурс-ограничение - Р , который, задействован в последней задаче (для простоты).

* Проект "Б" имеет критическую цепь длительностью 10 дней. И "Р" в нём начинает первую задачу. Это очень короткий, но очень важный проект. А так как он короткий, то мы должны его сделать точно во время.

Мы точно знаем, что "Р" не закончит работу на проекте "А" точно на 100-й день, это значит что сообщать кому-то, что мы начнем проект Б на 101 день - будет заведомым провалом, так как ресурс "Р" будет недоступен на 100-й день. Но мы точно не знаем когда на самом деле освободится "Р".

Поэтому, мы должны сдвинуть начало проекта "Б" на размер буфера проекта "А" - 50 дней , чтобы начать проект на 150 день с вероятностью 90%.
Сдвиг проекта "Б" обозначим как "буфер доступности ресурса" , Мы можем отслеживать расход этого буфера на основании потребления буфера проекта "Б", или на основании плановой загрузки ресурса "Р" . А если мы его разметим на 3 зоны по "светофору" то мы сможем начать беспокоиться вовремя чтобы не поставить под угрозу выполнение проекта Б.

также см. пункт 9. методички
https://pulsemanagement.org/rules-schedule/

В основе Метода "Pulse Management" лежит Теория Ограничений, она прошита не только как реализация Метода Критической Цепи для проектов с изменяющимся содержанием но и в мероприятиях Метода.

Дательней о применимости ТОС в Agile подходах и Scrum , которые совместимы с Методом я я написал в заметке: https://www.facebook.com/alexey.vasilyev.773/posts/2639248306316305

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

О том как достигать профессиональных целей и выстраивать карьеру читайте в нашей новой заметке.

https://www.facebook.com/pulsemanagement.org/posts/3071441799640839

Мы выпустили новый модуль в BIPULSE - Финансовое планирование

Как работать с модулем рассказали в видео-инструкции
https://youtu.be/HUB7zVbWMFg

Сегодня мы будем проводить вебинар об управлении проектами в BIPULSE с примнением принципов Проектной Ассоциации.

BIPULSE - управление проектами на основе национальных Принципов
Сегодня в 19:00 МСК пройдет вебинар Проектной Ассоциации. Успейте зарегистрироваться и принять участие!
https://projects.management/view-event.html?EventID=W25z11z2020T1900#Morning=1

BIPULSE интегрируется с Bitrix24 по REST API и обеспечивает уровень управления проектами с надежным планированием и контролем поверх существующих задач.

По информации партнеров Bitrix24 с 1 января 2021 года меняются условия для бесплатных тарифов. REST API становится доступным только на коммерческих тарифах.

Если Вы планируете использовать этот режим интеграции с BIPULSE планируйте расходы.

Напоминаем, что в BIPULSE есть интеграции с разными системами https://bipulse.ru/integrations в двунаправленном режиме. Это обеспечивает старт с применением ресурсного планирования и Метода Критической Цепи (CCPM) на имеющихся данных.


https://www.facebook.com/bipulsetool/posts/3634023073351081

#bipulse

За счёт чего Метод Критической Цепи (CCPM) работает в ИТ-проектах.

Чистый CCPM работает за счёт:
1. Более точный план, за счет планирования от конца и применения Дерева перехода. Мы уже на старте проекта знаем с какими трудностями столкнёмся. Можно сказать что применяется "диверсионный анализ" если говорить в терминах ТРИЗ

2. Оптимистичные оценки при оценке длительности задач. Э.Голдратт предлагал резать оценки на 2, ибо вероятность 50%, но для ИТ -проектов это не годится, инженеры оптимисты.

3. Регулярный контроль расхода буфера критической цепи и поиск решения как вернуть проект в зелёную зону.

В чистом CCPM многое осталось за скобками, скрытые предусловия и скрытые предпосылки. Метод "Pulse Management" (http://pulsemanagement.org) делает их явными и учитывает.

Коллеги, в 2018 году я проводил исследование кейсах о внедрения Метода Критической Цепи (Critical Chain Project Management, CCPM) в России и странах СНГ. И нашел буквально 13 компаний. Из них половина - из сферы строительства, 2-3 пробовали как эксперимент и только одна из ИТ.
Я буду благодарен, если вы поможете мне собрать более полную информацию по состоянию на 2021 год. Обещаю поделиться результатами.

Для участия в исследовании, заполните форму: https://forms.gle/TaVGqrv3eZbd8A4H6 или можем в частном порядке пообщаться. Если Ваш кейс уже публичный, то буду благодарен за ссылку в комментариях.

Что делать, если команда столкнулась с проектом, при разработке которого. возникает бесконечное количество неожиданных дополнительных задач, которые тоже нужно сделать, чтобы завершить проект.

Не бывает бесконечного роста количества задач без причины.
Есть две ключевых причины роста объёма:
1. "Мы не подумали"
2. Дефекты

(третья: "Мы не знаем куда идем" редко бывает)
Но алгоритм обработки такой ситуации один:

1. Остановить текущий проект.

2. Провести большую ретроспективу, выявить причины роста объемов работ.

3. Запустить новый проект, для этого:

3.1 Определить цель проекта (Заполнить Устав проекта: https://pulsemanagement.org/rules-project-charter/)

3.2 Выполнить планирование остатка работы от конца https://pulsemanagement.org/rules-create-plan/

3.3. Договориться о правилах включения новых задач в объем проекта.

3.4. Договориться о правилах работы при которых будет производительность по решению задач будет максимальная из возможной (приближение к точности планирования 70%)

3.5 Определить сроки проекта, сделать резерв для буфера времени проекта (буфер критической цепи).

4. Регулярно проверять метрики: скорость решения, точность планирования, расход буфера.

5. Делать с максимальным качеством

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

Известны ли сроки в ИТ-проектах в отличии от строительства?

Сроки у ИТ-проектов известны всегда. Просто иногда их не сообщают или с ними не согласны. Сроков не бывает только в одном случае: у Компании ОЧЕНЬ много денег и её позиция больше похожа на венчурный фонд - что-то из начинаний должно заработать.

А какие же сроки бывают?
1. Сроки по госконтрактам - неважно как хорошо вы оцениваете объем работ и есть ли у вас ресурсы, вы обязаны выполнить проект в контрактные сроки.

2. Сроки по проектам внедрения - даже если у вас "Продуктовая компания" и вам не повезло делать продукт в Б2Б секторе, при нарушении сроков внедрения вы рискуете потерять рынок и уменьшаете годовой доход.

3. Срок, который собственник готов ждать пока ИТ-отдел сделает нужные изменения чтобы он смог зарабатывать больше. Не справляетесь? Добро пожаловать на рынок труда. Зачем нужен ИТ-отдел который только тратит деньги?

Таким образом как ни крути, сроки у проектов есть. И чем лучше вы в них попадаете тем более надежным партнёром вас будут считать.

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

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

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

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

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

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