= О работе =

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

* Не так страшны первых 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/

#подкаст

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