= Буфер =

Применение буфера времени, или по простому "управленческого резерва" из практики.

Ситуация:

У нас при внедрении BIPULSE, есть методическое сопровождение внедрения. Главный методист - это автор этих строк. Методическое сопровождение внедрения это цикл видео-встреч каждую неделю с разбором методических вопросом "Как лучше применять Метод?" или "Как правильно применять ИСУП и Метод для получения результатов быстрее?". Мы эти встречи называем "трекинг", потому что это нечто среднее между бизнес-трекингом, коучнгом и консалтингом.
Обычно ритм (окна) под все встречи у нас 2 часа (в соответствии с моей же рекомендацией)

История:

Коммерческая трекинг-встреча занимает один час. Точнее должна занимать один час. Я думаю, что она должна занимать один час. Но, на практике, я редко когда заканчиваю встречу ровно в то время, когда я должен закончить. Встреча часто завершается на 5-10 минут позже.

Но тут внезапно так получилось, что в расписание встали две встречи встык. Вот буквально, одна завершается и следующая начинается. Ну это же просто , тут завершаешь, там начинаешь, верно?

Ну... я тоже так думал "это просто". Я продержался 5 недель. Я пытался завершать точно, но не получается. Хочется же на нанести больше "непоправимой пользы" (с). Из-за смещения времени завершения этого страдает следующая встреча, и сложно быстро переключить контекст. Но это коммерческая встреча, в отличии от других, тут важно начинать вовремя.

Поэтому как бы не хотелось "уплотнить график", пришлось признать, что нужен резерв времени между встречами всегда - БУФЕР! Для часовых встреч такой буфер минимум - 30 минут. (полчаса).
А вот, например, двух-часовую встречу проще завершить вовремя, так как все темы же разобраны.

Итого: буфер он и Африке - буфер (см. примечание), он годится не только для проектов, но и для регулярной деятельности и для организации рабочего времени.


(1) прим. Кeйс с прошлой конференции TOCICO Компания AeroSUD находится ЮАР и там применяют ТОС для запасов, проектов, логистики.

#метод

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

Тема:
- История Метода
- Применимость Метода. Для кого нужен и и зачем.

Автор и и ведущий Иван Абашкин
Отвечает на вопросы автор Метода - Алексей Васильев.

Слушать в YouTube
Слушать в Дзене
Слушать в Rutube
Слушать в VK и со стены

#подкаст

Новость: У BIPULSE появилась работающая сборка под AstraLinux и РедОС
#bipulse

Обновлён перевод словаря TOCICO в виде сайта https://bipulse.ru/app/dictionary/

* Все связи между терминами выправлены. Некоторых терминов в словаре нет, хотя ссылки на них есть. но в оригинале также.
* Все статьи терминов выложены на GitHub и совместимы с разметкой для Obsidian
* Английская версия остается немного битой и без картинок, ибо это автоматический разбор.
* Написание некоторых терминов изменено или разбито на два термина, типа "желтая зона (буфера)", для обеспечения связей.
* Ключи статей могут терять кавычки, докузавр иначе не может

Так как мы завершили обсуждение и перевод словаря TOCICO, то если вы использовали словарь в виде документа в GoogleDocs, то больше не используйте, документ больше не будет источником для сайта. Доступ на редактирование закрыл. Версия в GitHub свежее, версия на сайте позволяет пройти документ "насквозь" и поиск быстрый есть.

ВАЖНО

1. Представленный перевод не догма
2. Если хочется добавить или дополнить, добавить метки для работы с терминами в конкретной области знаний ТОС, или проставить ссылки на хендбук, то это приветствуется.
3. Для изменения или дополнения статей следует использовать версию статей на GitHub

Лицензия на это перевод (составное произведение): Apache 2 - то есть при правках этого произведения нужно вернуть правки источнику. Остальное без ограничений.

В переводе и уточнение смысла терминов этой версии перевода принимали участие, за что им огромная благодарность:
Алексей Васильев - автор этой версии
Иван Абашкин - за вопросы про производственные цепочки
Андрей Пчелинцев - за копание вглубь терминов
Дмитрий Пантелеев - за ответы по особенностям логистических решений ТОС и способа реализации их в решении NetStock
Евгений Айдаров - за вопросы о применении решений ТОС в ИТ-проектах.

От отдельная благодарность Дмитрию Егорову за консультации на практикумах и ответы на глупые вопросы!

Оставайтесь в фокусе, держите руку на Пульсе!

#TOCICO

Точка интеграции проекта как виртуальный барабан при эшелонировании проектов

из словаря TOCICO:
"эшелонирование (staggering) - В управлении многопроектными проектами критической цепи процесс выпуска (впуска) проектов в работу на основе доступности и возможностей или емкости барабана или виртуального барабана."

"виртуальный барабан (virtual drum) - в многопроектном управлении проектами критической цепи средство разнесения проектов, не предполагающее выравнивания нагрузки на ресурс."

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

"точка интеграции (integration point) - в управлении проектами критической цепи - задача, в которой сходятся основные пути в проекте.
... точка интеграции МОЖЕТ быть выбрана в качестве виртуального барабана."

Если мы будем смотреть на компанию внимательно, то наша цель это ИЗБЕЖАТЬ перегрузки ресурсов. А значит, по хорошему, мы должны выбрать в качестве виртуального барана ресурс. Однако системы управления проектами в большей части не могут выравнивать проекты по ресурсам, поэтому применение точки интеграции в качестве виртуального барабана - события запускающего следующий проект оправдано.

Так, например, в некоторых мегапроектах для определения события старта следующего этапа (проекта) используется "кросс-проектная веха". То есть, событие имеющее одну и ту же дату в разных файлах MS Project.

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

С другой стороны, при начале работ по Методу Критической цепи лучше это делать вручную, это даст понимание алгоритмов и ожиданий от информационной системы.

Итого:
1. Начинаем с ручного эшелонирования проектов явно указываем по какому событию связываем проекты.
2. Если ИСУП умеет эшелонировать проекты по ресурсам используем эту возможность.

#ccpm

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

Тема:
- Модель предприятия. (Пирамидка и фрактал)
- Потоки принятия решений.


Автор и и ведущий Иван Абашкин
Отвечает на вопросы автор Метода - Алексей Васильев.

Прочитать подробней про Метод управления проектным бизнесом https://pulsemanagement.org/

Слушать в Дзене
Слушать в Rutube
Слушать в VK
Слушать в YouTube
#подкаст

В выпуске 2 есть ответы на вопросы:

1. Как метод и ТОС предлагают работать с беклогом задач, когда нет конечных требований, а работа уже начата? из серии мы сами еще не знаем, что хотим но давайте делать и посмотрим, что получится. Эдакий Scrum, где по ходу движения за несколько итераций получается уже желаемое.

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

3. Как быть когда у команды есть несколько классов обслуживания для задач? например, команда должна готовить новый проект и осуществлять поддержку предыдущего проекта. Лучше использовать усиленный буфер или считать, что команда тратит не по 8 рабочих часов, а по 4, например.

#подкаст

= Как приоритизировать изменения в ИТ-продукте =

Если у вас ИТ-продукт и стоит постоянная проблема выбора "какую функцию реализовать", то рекомендую использовать следующий набор Правил:

1. Хорошая информационная система должна помогать принимать управленческие решения. То, есть информационная система должна отвечать на вопросы.

2. Если информационная система не помогает принимать решения, то это система учета. В таких системах есть полезная составляющая, однако идеальная система учёта это когда учёт есть, а системы нет.

3. Любую функцию (новую характеристику) оцениваем через вопросы:
3.1. Зачем нужна эта функция или новая характеристика? Какую проблему она решает? (ДЛЯ ТОГО ЧТОБЫ .............. )
3.2. На какой вопрос МОЕГО КЛИЕНТА отвечает эта функция или новая характеристика?
3.3. Сколько денег МОЙ КЛИЕНТ сможет заработать, если воспользуется ответом на этот вопрос?
3.4 Сколько денег МОЙ КЛИЕНТ сэкономит, если я получит ответ на этот вопрос быстро с применением новой функции (характеристики продукта)?

Если хоть на один из вопросов пункта 3 у вас нет ответа, то НЕ ДЕЛАЙТЕ функцию. Остальные функции приоритизируйте по ожидаемой прибыли КЛИЕНТА, так как большую часть изменений в существующем ИТ-продукте можно сделать за фиксированное время. Хорошая команда может за 2 недели такого наворотить....


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

Ps: рецепт появился благодаря дискуссии с Юлианой Кузнецовой @NoWind_GetOnTheOars

Время - это единственный ресурс который нельзя пополнить.

Деньги можно взять в банке.
Ресурсы - можно купить.
И только потраченное время нельзя вернуть.

#метод

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

Тема:
- Принципы и ценности Метода (их нет)
- Предпосылки применимости Метода.

Автор и и ведущий Иван Абашкин
Отвечает на вопросы автор Метода - Алексей Васильев.

Слушать в Дзене
Слушать в Rutube
Слушать в VK
Слушать в YouTube

Прочитать подробней про Метод управления проектным бизнесом https://pulsemanagement.org/

#подкаст

Коллеги прислали.

= Опять про Agile =

1. Метода Waterfall - не существует и никогда не было.

2. Винстон Ройс в 1970 году показал решение которое позволяло БЫСТРЕЕ выходить программному обеспечению в эксплуатацию. Пиши БОЛЬШЕ документов чтобы быстрее выпускать проекты. Потому, что на тот момент от идеи до внедрения было минимум 5 рабочих дней.

3. "За время пути собака смогла подрасти" , ЭВМ стали быстрее и цикл обратной связи ускорился, уже не нужно было создавать больше документов для быстрого выпуска.

4. Клиент никогда НЕ ЗНАЕТ РЕШЕНИЯ но приходит с ним. это ГИПОТЕЗА! Однако все так увлечены созданием ПО что не обращают на это внимания.

5. Особенности культуры США (юристы и индивидуалим) совместно с п.4 к 1995 году показали что это контрпродуктивно.


Поэтому инженеры на местах придумали Agile-подходы, которые помогают решать СИМПТОМЫ и следствия от п5 + п2., за счёт п3, но не помогают решить п.4. Потому что это на уровне принятия решений, а не у инженеров.

Никому верить нельзя...

Индекс и скорость потери денег

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

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

Для «реального ИТ» все задержки проекта — потери дельты прибыли компании за каждый день просрочки ИТ-проекта. Все непроизводственные задержки запуска ИТ-проекта, связанные с согласованием запуска, это тоже потери.

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

Показатель MLI: Каждый день просрочки — один потерянный проект, или упущенная прибыль за результат проекта. Применимость: ИТ для реального бизнеса (позиция заказчика)

Показатель MLR: Каждый день просрочки — теряем столько же денег сколько должны были заработать в день.
Применимость (сфера): услуги. (позиция поставщика услуг)

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

Почему столько слайдов вдруг?

Завершил осеннюю серию тренингов (курсов) Директор ИТ, Директор цифровой трансформации, Управление проектами цифровизации, Бизнес-аналитик и обоснование проектов. Которые веду в ЦНТИ Прогресс (Санкт-Петербург)

Участники курсов - это в основном представители реального производственного бизнеса. В таких бизнесах , как только мы удаляемся от производственного конвейера на один шаг оказывается, что там проект на проекте и проектом погоняет. Это и организационные изменения, и внедрение ИТ-систем и модернизация производства.

Основная проблема: КАК внедрять изменения? Как делать то, что надо делать? Как НЕ ДЕЛАТЬ то что не надо делать?

Поэтому на этих курсах у меня становится всё больше Теории Ограничений и применение "Метода управления проектным бизнесом" нежели абстрактного Скрама.

Также, после новых новшеств BIPULSE в части адаптации решения У-ББК для управления поручениями, и Метод стал охватывать почти все ключевые решения ББК Теории ограничений:

* Адаптация CCPM для проектов с высокой неопределенностью.
* Буфер заказа - для управления поручениями.
* Буфер перед ограничением (производством) - управление временем аналитика
* Запланированная загрузка - принятие решения когда брать новый проект в работу.

Это всё привело к необходимости пересмотреть набор слайдов к курсам.

Оставайтесь в фокусе! Держите руку на Пульсе!

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

Онлайн-встреча посвященная Методу управления проектным бизнесом Pulse Management. На встрече вы узнаете новые решения Метода, открытия и озарения.


Поручения — неотъемлемая часть бизнеса. Как бы не паковали всю работу в проекты с задачами для которых срок решения определяется критической цепью и всегда двигается, иногда (или часто) нужны задачи которые ВАЖНО сделать ДО СРОКА. Если их сделать позже, то будут убытки.

Собственник выдавая поручения хочет, чтобы что-то было сделано к конкретной дате. А если это не проект, то значит это простая задача. Но как же управлять такими задачами?

Об этом и других аспектах и будет идти речь на встрече. Готовьте вопросы о вашем применении Метода, и трудностях.

Событие бесплатное, регистрация по ссылке:
https://pulsemanagement.timepad.ru/event/2267084/

Камера и микрофон очень желательные!!

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

Тема:
Продолжаем детально разбирать предпосылки лежащие в основе Метода, а именно:

1) Выполнение обязательств вовремя и в полном объёме это коммерческое преимущество.
2) Ресурсы компании ограничены.
3) Содержание проекта никогда точно не известно и закон Мёрфи работает.
4) У нас всегда многопроектная среда и расфокусировка приводит к потере времени.
5) Люди хорошие.

Вопросы:
- Если ограничение у нас находится на команде разработки, то ТОС рекомендует обеспечить работой команду 24/7. Как избежать выгорания команды в этом случае?
- Когда мало опыта по каким критериям можно себя проверить, что правильно создал Дерево текущий реальности? Это без ментора вообще возможно?

Автор и и ведущий Иван Абашкин
Отвечает на вопросы автор Метода - Алексей Васильев.

Слушать в Дзене
Слушать в Rutube
Слушать в VK
Слушать в YouTube

Подробней про Метод управления проектным бизнесом https://pulsemanagement.org/

#подкаст

Коллеги, меня наконец-то допинали, поэтому у меня наконец-то появилась определённость по запуску открытого интенсивного онлайн-курса. Это второй запуск курса, который был в конце 2021 года.

"Основы Теории ограничений и управление проектами вовремя и в рамках бюджета"
4 недели по 2 занятия в неделю по 2 часа.

Стартуем числа 10-11 февраля, заканчиваем в начале марта.

---
Курс построен вокруг реальных ситуаций участников и представляет собой интенсив, направленный на отработку навыков в игровой и реальной среде. За счёт детального разбора домашних работ участники получат не только новые знания, но и консультации "как действовать" в реальных условиях.
---

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

Высокие материи я вытащил из него, а то там еще на один курс набралось. Но возможно удаться рассказать что-то в рамках онлайн-встреч Клуба, если нам получится запустить их в виде "20 минут доклад, потом разбор ситуаций"

Стоимость еще не знаю.

= Достаточно ли Скрама для руководителя проектов =

Исходя из цели Скрама: "создавать ценность с помощью адаптивных решений комплексных проблем." (рус. перевод)

И автоперевода "complex problems" - сложные проблемы. (ага, не "комплексные")

А также условий среды в которой:
- Цель руководителя проекта - обеспечить достижение цели проекта
- Интересы руководителя проекта - попасть в ожидания заинтересованных сторон (по срокам, качеству, стоимости).

Где Цель проекта может быть:
- Понятна и определена
- Непонятна и нужно исследование.

Только для ситуации когда "У нас есть проблема, и мы не знаем как её решать" Скрам может достаточен. Так как Если цель меняется, и нужно постоянное экспериментирование то принципы и ценности Скрама будет работать.

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

#ответы_на_вопросы #agile_цинизм #agile

Оказывается в ТРИЗ есть развитие и попытка выйти за рамки "я знаю как" в состояние "я не знаю как, но будем разбираться".

Штука называется "Технология Эффективных Решений" - ТЭР.

Из полного описания нашел только эту:
https://triz-summit.ru/confer/tds-2006/203452/203533/

Потому что "очень действенное и поэтому ДСП"

Еще в статье нашел интересное:

==
7. Чем объяснить "застой" в развитии ТРИЗ?

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

Принцип создания ТРИЗ Г.С.Альтшуллером был выбран точно и правильно: исследование массивов готового патентного материала с целью выяснения закономерностей развития систем, и определения общих принципов решения трудных задач.
...
Сегодня же проблема исследований состоит в том, что переходя в надсистему ТЭР, исследователи ТРИЗ полностью теряют почву под ногами: т.к. у них исчезает привычная "питательная среда": готовый информационный материал для исследования в виде патентного фонда, литературных записей, и т.д.
==

Запись встречи. Часть 1. Упрощенный барабан буфер канат и управление поручениями

https://youtu.be/gNewSq246Jc

1. Аспекты решения Барабан-буфер-канат
2. Управление поручениями

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