Подкаст 39. Как быстро получить состояние всех проектов портфеля

https://t.me/bipulse_podcast/108

Технический комментарий:
Это совсем свежая запись, буквально прошлой недели. Кто нас регулярно слушает, как вам новый звук?

(До завершения первого сезона осталось 3 выпуска ;)

#подкаст

Обновляю словарь терминов ТОС. убираю следы конвертации, вычитываю комментарии.

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

Похоже придётся обновлять ДСТ Внедрения Метода.
#теория_ограничений #tocico

Опубликовали руководство пользователя BIPULSE в виде веб-страниц с поиском.

https://bipulse.ru/app/manual/

Вот почему, у всех нормальные руководства, с описанием "какие кнопки нажимать", а у нас методичка опять получилась?

(с) "Управление проектным бизнесом" https://t.me/bipulse

Филип Маррис картинку к заметке в запрещёном LinkedIn показал .

Примерно так выглядит график буфера для Agile-проектов.

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

#теория_ограничений

Готовлю статью про Управление проектами Методом Критической цепи, а то мы как "сапожник без сапог", BIPULSE реализует "Управление проектами критической цепи" (CCPM), но... у нас на сайте нет ничего про сам Метод.

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

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

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

Если кратко, то следим за руками:
1. С конца 1980-х года Япония и страны Юго-Восточной Азии запускают программы переноса технологий и повышают своё товарное присутствие на рынках США.

2. Это создаёт угрозу потери технологического лидерства США. А на любую угрозу нужно как-то реагировать. С 1988 до 1991 выпускается много статей на эту тему.

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

4. Появляется много НИОКР (а как иначе совершенствовать технологии), но они не вакууме выполняются, а на фоне растущей конкуренции из Азии. При этом к концу 80-х ЭВМ стали дешевле, то есть возрастает роль программного обеспечения

6. И тут к концу 80-х выясняется что текущие способы управления НЕ РАБОТАЮТ в условиях такого внешнего давления и сложившейся юридической практики. Есть статистика проваленных проектов, и обсуждения и профильных кругах о проблемах.

7. И с конца 80-х начинается активный пересмотр всего управления предприятием и проектного управления в частности. Выпускается много книг и дискуссий о том "Как лучше управлять проектами" , с озвучиваем что PERT и CPM придуманные в 50-х для проектов строительства не помогают делать проекты надежней (как серийное производство)

8. И ба-бах! В период с 1995 до 1998 выходят множество книг про новые способы управления (тот же Agile software development), и Голдратт не просто так выпустил книгу "Критическая цепь" в 1997 году. Это время было такое на поиск серебряной пули.

Занимательная история, однако.

BIPULSE вошёл в рейтинг Российских систем управления ИТ-проектами от Компьютерры!

https://www.computerra.ru/314009/rejting-rossijskih-sistem-upravleniya-it-proektami-2025/

BIPULSE набрал 124 балла и занял 4 место.
АвтоГант набрал 8 баллов и занял 13 место.

4 место для системы которая не совсем про Software Development Live Cycle (SDLC) - очень хороший результат!

#новости #bipulse

TOCICO анонсировали, что выпустили материалы прошлогодней конференции Critical Chain всех членов.

==
ATTENTION TOCICO MEMBERS! We have just released the Critical Chain 2024 video recordings for all TOCICO members.
==

Выложили запись доклада на IT GLOBAL MEETUP 17

Взгляд маркетинга на разработку: что бесит, почему так, и как с этим жить

https://youtu.be/Q9bP6TErRcI

#видео

Подкаст 40. Конвейер проектов - как выполнять проекты не задумываясь

https://t.me/bipulse_podcast/109

Продолжение темы 39 с анализом проектов. Пара "Check-Act" цикла PCDA

#подкаст

Wolfram Müller в запрещенном LinkedIn пишет про Agile и я с ним согласен:

Если бы я мог дать молодым руководителям лишь один совет, он был бы таким: «Читайте всего Голдратта!»

Все знают Парето – это всё прекрасно, и это хорошее начало.

Но Парето подходит к проблеме так же, как и все остальные! Вы повсюду ищете способы улучшений, и лишь 20% из них оказываются действительно эффективными. Прекрасно!

Но Голдратт вводит в игру ограничение.

Если вы фокусируетесь на нём, то можете достичь большего минимальными мерами — часто достаточно изменить всего одно правило — чем всеми остальными мерами вместе взятыми. 1% усилий для 99% эффекта!

Лишь один пример: у нас был клиент, который продавал примерно на 30% больше оборудования [чем мог произвести/обслужить]. Ограничением тогда был отдел электротехнического проектирования — безнадёжно перегруженный!

Нам всего лишь нужно было спросить: «Что помогло бы вам повысить выпуск продукции на 50%?»

Ответ последовал незамедлительно: «Если бы кабели были расходным материалом!»

Это и было решение! Существовало правило: «Всё, что дороже $5, должно проходить через отдел закупок, а чтобы отдел закупок это приобрёл, это должно пройти согласование в электротехническом отделе!» Опять старое правило из мира, ориентированного только на затраты 🤢

Изменение правила заняло всего пять минут – затем кабели стали расходным материалом, и техник мог просто взять ещё один кабель, и всё – не беспокоя отдел электротехнического проектирования! 😃

Сорок минут анализа ситуации в «узком месте» привели к увеличению пропускной способности на 30% при тех же затратах!

Оптимизации в «узком месте» часто дают эффект рычага 1:99 или даже больше!

У кого ещё есть подобные примеры? Оптимизации на ограничении! Пожалуйста, комментируйте!

P.S. Мне посчастливилось наткнуться на это добрых 20 лет назад. Это помогло мне утроить производительность по проектам для 1000 разработчиков программного обеспечения – можете представить, какое это было удовольствие и карьерный
рывок!

До встречи, Вольфрам – с нетерпением жду ваших примеров.

P.P.S. Agile часто такой... в духе Парето.

обновл: (прим.: нейропревод, спс Ивану Абашкину)

Когда нельзя но очень хочется, то можно!

А можно ли BIPULSE использовать бесплатно? Можно! Но есть условия.

Как использовать BIPULSE бесплатно

Если вы приходите на Встречи Клуба, и активно участвуете, то у вас есть преимущества при внедрении BIPULSE себе в компанию.

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

Есть решение!

Если позволяет политика ИБ (и передаваемые к нам в облако данные не гостайна), можете использовать BIPULSE в облаке до запуска коробочной версии совершенно бесплатно!

#bipulse

Записали сегодня и Иваном последний 42 выпуск подкаста "Разговоры о проектном бизнесе".

Первый сезон на этом завершён. Теперь буду писать Книгу. Отмазок не осталось.

Подкаст 41. Ретроспектива проекта: Зачем? Как? Для кого?


https://t.me/bipulse_podcast/112

Очень сложная была запись, немного психоделичная.

#подкаст

Подскаст 42. Как внедрить Метод управления проектным бизнесом.

https://t.me/bipulse_podcast/113

Последний выпуск первого сезона. Теперь буду писать вторую книгу.

#подкаст

Я недавно закончил читать книгу "Правила Потока для управления проектами по Голдратту"
https://t.me/proprocess_ru/6290

Это было сложно потому, что всегда возвращался к Методу и вопросам
- А правильно ли я понимаю Критическую Цепь?
- А как Правила влияют на Метод?
- Нужно ли что-то менять в Методе, для лучшего соответствия Цепи?
и другие.

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

Теперь о книге, с подачи Михаила Селезнёва (@mseleznev), который меня сподвиг на анализ....

Основные озарения:

1. В целом это хорошая иллюстрация проекта внедрения.
Книга идёт в режиме пошагового внедрения, примерно по схеме о которой я говорил в 42 выпуске подкаста.

Раньше я рекомендовал внедрение Метода "снизу":
- с учёта текущей работы и спринтов,
сейчас я больше склоняюсь к внедрению "сверху", то что есть в Дереве стратегии и тактики CCPM:
- Сначала запускаем Ритм анализа состояния проектов с ТЕМ ЧТО ЕСТЬ.

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


2. В отличии о других книг по ТОС, эта книга БАЗИРУЕТСЯ на ОПЫТЕ читателя, то есть он должен УЖЕ знать про управление проектами. В идеале, наверное должен быть знаком с предыдущей книгой серии бизнес-романов "Критическая цепь".

Потому, что вся книга построена на решении конфликтов "я сейчас так..., а должен так....".

Полный цикл по CCPM такой:
а) Критическая Цепь
б) Лоуренс Лич
в) Правила Потока...

И... Тут важно понимание, что CCPM - надо сравнивать не с "PMBoK", а с "PMBoK + управление программами проектов и портфелями".
Это очень большая разница. Книга "Правила потока..." она про программно-портфельное управление проектами.

3. Некоторые правила типа "Полная комплектация", у меня в Методе описаны более чётко: "Проектируй в стол" (Правила непрерывного проектирования).

Так как Метод - про проекты НИОКР, то в таких проектах просто физически никогда не будет полной (100%) комплектации.
Однако, перед каким-то КУСКОМ работы мы ОБЯЗАНЫ выполнить ДЕТАЛЬНУЮ проработку решения на 1-2 месяца работы.
Это полностью соотносится с техниками Экстремального программирования:
- Метафора системы (грубый план)
- Архитектурный шип (Architecture Spike) - детальное проектирование части системы.


4. Неожиданной была рекомендация: размер задач 1-4 недели.

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

То, есть:
* для 2-х летнего проекта -- задача = 1 мес, это значит 1/24 (4.5%)
* или 1/8 = 12.5%
Это очень крупноблочная разбивка.

Обоснование для этого: Слишком много контроля для менеджеров проектов слишком сильно нагружает их. (стр 137)
В книге приводится пример: СБОРОЧНЫХ проектов промышленных роботов (стр 137). То есть это контекст "ПРОИЗВОДСТВО под заказ".

Поэтому, я считаю что рекомендация Книги по укреплению точек контроля справедлива ТОЛЬКО для СБОРОЧНЫХ проектов, когда у вас ОЧЕНЬ много сборочных единиц. И мое общение с Клиентами из производственных компаний, когда мы внедряем BIPULSE для управления производством, действительно показывает РАЗНИЦУ между ERP и ИСУП:
- в ERP детализация ДОЛЖНА быть до каждого винтика, однако
- в ИСУП достаточно декомпозиции на крупноблочные сборочные единицы.

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

Люди не способны что-то планировать на горизонте дольше недели.

#ccpm

(продолжение https://t.me/bipulse/641)

Следствие этого правила: если применить рекомендацию Книги "Как есть" сэкономив на начальном планировании, то мы не сможем ЕЖЕНЕДЕЛЬНО контролировать отклонения проекта еженедельно, так как у вас НЕ БУДЕТ ПРАВДИВЫХ данных. Если для ВАШЕЙ среды это НОРМАЛЬНО, то вопросов нет, иначе используйте другой способ контроля.

Схема CCPM+Agile (как к Методе, CCPM с крупными задачами сверху и мелкая нарезка задач выполняющаяся по Agile снизу) - более работоспособная. Так как информация о прогнозе на основе СКОРОСТИ выполнения работ ДАЁТ ответ на вопрос "когда закончишь". Однако, для лучшей АВТОМАТИЗАЦИИ управления (и снижения нагрузки на руководителя) нарезку задач ЛУЧШЕ выстраивать в Цепь.

Некоторые следствия из этого, для ПРАВИЛЬНОГО применения эшелонирования проектов по ресурсу-ограничению (CCPM):

а) Для проектов НИОКР высокой неопределённости при построения план-графика необходимо планировать НЕ на конкретные ресурсы (людей или навыки), а на отделы. Это даст необходимый уровень управления с размерами задач 5-10 дней, и при этом информационная система не захлебнётся при выравнивании ресурсов.

б) Необходимо управлять МОЩНОСТЬЮ отделов, а не наймом конкретных специалистов. Отделы делятся на Сектора (команды) дешевле затягивать проекты в команды, чем собирать команду под проект. Каждый Отдел может выполнять ТОЛЬКО 2-3-4 проекта в параллель в зависимости от числа проектных команд (секторов).

Это полностью соответствует правилу Метода: Минимально 2 человека на тематике, лучше 3. Если будет 5-7 человек - то идеально. Люди ДОЛЖНЫ чувствовать поддержку коллеги и не находиться один-на-один с проектом.

Итоги

1. Книга хорошая, но это "обновление и уточнение ранее сказанного"
2. Это инструкция по внедрению CCPM
3. С некоторыми рекомендациями я не согласен.
4. Мы поставим в план развития BIPULSE поддержку многоуровневых планов.

#ccpm

Кратко о конференциях про управление проектами:

---
мы не заинтересованы в методологических докладах и теории,

(с) «Проектные офисы: успешные стратегии и тактики»
---

То есть на такой конференции НИКОГДА не будет "Как правильно" , всегда будет "Как мы неправильно делали и огребли".

Начинаю хотеть сделать свою конференцию, где будут выступать где ЗНАЮЩИЕ люди (консультанты или эксперты) рассказывают "Как правильно". Кейсы - это хорошо, когда подкреплены теорией.


Почему именно Консультанты

Консультанты просто видят больше.

Средний РП за год может 1-2 проекта вести в 1 компании.
Консультант видит 10 компаний в год. Со всеми их проблемами и некоторых дотягивает до решений.

Если мы говорим, не о крупняке котоырй хватается перед другими "а мы еще так можем",
то средний бизнес не хочет или не может рассказывать об успехах, "зачем учить конкурентов?".
А Консультант может рассказать, у него много историй и есть обобщающий опыт.

* * *

Любой кейс Консультанта это демонстрация теории.

Личная Я уже заколёбся подавать доклады

1.
- у вас есть что-то новое чего нигде не написано?
- вот моя книга, там написано.
- ну это нам не годится.

2.
- вендорский доклад не интересно. Есть теоретический.
- не.. Теория нам не надо..

А потом на конфе:
- У нас просрочка 1млн долларов в день стоит
- Так может CCPM применять?
- Не.. Это нам не подходит.
- ???


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

Я взбешён.
Ещё один отказ доклада получу и точно конфу буду делать.

* * *
А нельзя или иначе?

Мне каежтся я прихожу к точке, когда иначе нельзя. Вот смотрите:


- Метод управления проектным бизнесом я упаковал
- Книгу я написал
- Подкаст мы закончили писать (42 выпуска, примерно 60 часов)
- Информационно-методический комплекс BIPULSE я спроектировал и он работает.
- Кейсы развёртывания Метода у меня есть с результатами. (это кроме мировых по CCPM)
- Тренинги корпоративные провожу
- Тренинги в одном питерском учебном центре (Цифровизация, УП, УП ИТ, ИТ-директор, бизнес-аналитик) я веду.
- Петербургский Клуб Руководителей ИТ-проектов я координирую, и даже нахожу (и мне помогают) организаторов митапов и докладчиков (с 2015 года почти без перерыва проводим ежемесячные встречи).


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

А то НИ ОДНА компания мне на выставке не смогла мне честно казать "Мы отгружаем всегда вовремя или раньше", все отвечали "Ну.. как у всех". И это печалит меня.

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