= Снижение неопределенности в проекте =

Я уже рассказывал про две оценки , и Иван нашел дополнительное применение двух оценок. Однако хочется свести всё в один алгоритм:

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

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

2. Для каждой найденной такой цели задайте вопросы:

2.1 Что может поставить под Угрозу достижение этой цели (тут Угроза - может случиться, а может и нет)
2.2 Какие Цели нужно достигнуть для снижения каждой угрозы?

2.3 Что мешает достигнуть цель за оптимистичное время? (тут явное Препятствие, оно уже есть)
2.4 Какую цель нужно достигнуть для преодоления этого препятствия?

2.5 Что мешает уменьшить разброс оценок? (тут явное Препятствие, если разброс большой, то есть обоснование для этого, а значит мы выявляем источник высокой неопределенности)
2.6 Какую цель нужно достигнуть для преодоления этого препятствия?


3. После ответов на вопросы 2.2, 2.4, 2.6 выполните планирование найденных цепей по алгоритму планирования проекта.

4. Выполните оценку времени необходимого для достижения каждой новой промежуточной цели

5. Уточните оценки времени необходимого для достижения целей для которых выполнили такую проработку.

6. Ответьте на вопросы:

6.1 В свете новых фактов, потратим ли мы меньше времени на достижение цели (в цепи) если будем делать все работы по снижению вероятности угрозы чем было указано в пессимистичной оценке?

6.2 Если ответ "нет" - уберите промежуточные цели из плана работ, цепь будет защищаться адаптивным буфером и он может быть значительно больше чем стандартный. Если "да" то оставьте промежуточные цели в плане работ.

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

= О работе =

Работа растягивается и сжимается, в зависимости от того, как вы её работаете. Опытные руководители помнят, что:

* Не так страшны первых 90% работы, как вторые 9% работы.

* Первых 90% работы требуют 10% времени, а оставшиеся 10% работы требуют 90% времени.

Поэтому неважно сколько работы вы уже поработали, и сколько процентов завершили, важно ежедневно уточнять: Когда закончишь? А почему не сейчас?

#метод #ccpm

Это раньше я рассказывал "Ищите отклонения для выявления угроз". Но если все оценки вывести на график, то сразу будет видно где может быть скрытая угроза.
#метод

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


Чтобы понять почему адаптивные подходы получили популярность нужно понять историческую перспективу. Какая была ситуация на 1995-1996 год (даты выпуска XP, Scrum)? Что в корне изменилось?

И самое важно: О Чем на самом деле говорил Винстон Ройс в докладе 1970 года?

И если посмотреть на эту картину в целом, то выясняется что:
1. в 1970 году время от идеи до результата - неделя минимум, потому что цепочка такая: идея - алгоримизация - кодирование - набивка перфокарты/ленты - ОЧЕРЕДЬ в вычислительный центр - выполнение программы - результат.

Это все ДОЛГО! И стоимость ошибки ДОРОГАЯ! Поэтому мысль такая: пишите БОЛЬШЕ документов чтобы БЫСТРЕЕ делать программное обеспечение.

2. За время пути собака смогла подрасти, с 1990 уже распространены микроЭВМ и время от идеи до результата - 1-2 часа худшем случае. Это значит что нам НЕ НУЖНА вся документация чтобы быстрее создавать программное обеспечение.

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

4. Когда разработчики создают ПО, часто информация к ним приходит в искаженном виде. Потому что "пиши больше документов", а эти документы пишут Аналитики, который ПРИДУМЫВАЮТ что нужно Клиенту, потому что Клиент сам не знает что хочет, и оперирует терминами и решениями которые ИЗВЕСТНЫ ему. А Аналитики выступают в роли "переводчиков" исходя из предпосылки что "Клиент точно знает что хочет" - а это не так.
В результате при накоплении такого опыта появилось понимание что проблема недопоонимания системная.

5. В американском мире Контракты жесткие. Это значит что Клиент хочет получить за свои деньги то что ему представили в ТЗ. НО когда он получает то что в ТЗ ,но это не то (потому что п.4), он расстраивается и начинаются разборки кто, что не то сделал.

Исходя из этой перспективы и появляются подходы:
1. Мы не знаем точно Цели Клиента - давай адаптировать постоянно.
2. Чтобы Адаптировать постоянно - "путешествуй налегке", меньше документов. И нужны "тесты первыми" чтобы ничего не падало при изменениях.
3. Если Клиент не знает сам цель - давай посадим его рядом и сделаем рамочный контракт с оплатой командой (тут стоим упомянуть что почти все авторы подходов работали во внутреннем ИТ больших не-ИТ компаний)
4. Стоит постоянно напоминать Разработчику что важно не его совершенствование, а работающий софт.

Ну а следствия этих изменений появляются в виде поддерживающих практик, принципов, ценностей.

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

В описании решения CCPM в TOC Handbook есть два правила: "начинать работы по готовности работы-предшественника" и "начинать работы как можно позже", как они стыкуются между собой?

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

Фокусируйся и завершай - если раньше начнем, то потеряем фокус. Однако я бы этого относил только к проектам НИОКР, где это важно.

Для планирования питающих цепей есть дилемма: начинать раньше или начинать позже. Технически, если у нас СЛИШКОМ большой запас времени до точки слияния, превышающий питающий буфер, то начинать надо ПОЗЖЕ, чтобы удержать ФОКУС.

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

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

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

Поддержка принятия решений инженеров в диалоге:

- Так нельзя сделать!
- Точно?
- Точно! Так нельзя сделать!
- А если подумать?
- Думал! Так точно нельзя сделать!
- А если еще подумать?
- Ну.. ну если вот так, и вот так... Ну так можно сделать.

У нас вышла статья про про нашего мальчика BIPULSE, о том чем ты полгода занимались

"Как мы облачный PHP-сервис завернули в коробку — с защитой, лицензией, и при этом ускорились"

Мы привыкли к облакам и сервисам по подписке (что называется сложным словом SaaS) . Заливаешь данные, строишь календарики — и не задумываешься, на чьих там они серверах хранятся. Удобно? Да. Безопасно? Ну, так… Обычно мы на это забиваем. Или не задумываемся. Или задумываемся, но всё равно забиваем.

https://vc.ru/services/526585-kak-my-oblachnyy-php-servis-zavernuli-v-korobku-s-zashchitoy-licenziey-i-pri-etom-uskorilis

#bipulse

И следом сразу продолжение, техническая часть о том, что сейчас "под капотом" BIPULSE

https://habr.com/ru/post/686496/

#bipulse

https://youtu.be/hGVh7IHwJwg

Выложен доклад 2019 года для Форума независимых разработчиков программного обеспечения ISDEF

Выложен доклад 2020 года для Форума независимых разработчиков программного обеспечения ISDEF.

https://youtu.be/Eq5D5QEN-fM

По следам доклада на конференции ISDEF 2022. "Как занять место под солнцем".

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

При подготовке доклада меня спросили, "Ну хорошо, а делать-то что надо?". И пришлось разложить в последовательность шагов (кто внимательный увидит здесь ТОС-подход).

Алгоритм улучшения предложения ценности для Партнёров и Клиентов когда продаём инфраструктурные решения.

1. Что Клиент использует ЕЩЁ с своей деятельности?

2. Как встроиться в производственный процесс Клиента?

3. Подумай о Клиенте шире, Какую боль и страдание мы ему доставляем (будем доставлять) своим существованием когда встроимся, как отдельный Продукт?

4. Что даст наш Продукт партнёру (целевой системе в которую мы встраиваемся)? (Чем мы его усилим, чтобы он продавал нас в комплекте)

5. Что нужно партнёру ОТ НАС (от нашей системы)? (Что нужно передать внешней системе чтобы пользователь бесшовно перешел в каш модуль)

6. API - примеры, сниппеты для быстрой встройки в партнёрские решения.

--
Алгоритм простой, мы при внедрении BIPULSE проходим по этим шагам. А вот ссылки на доклад пока не могу дать, в публичный доступ еще не выложили :(

#bipulse

= Буфер =

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

Ситуация:

У нас при внедрении 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/

#подкаст