Проектный бизнес - как, что, зачем
163 subscribers
56 photos
3 files
58 links
Мы помогаем выполнять проекты вовремя. Практики, Методики, Анонсы.
http://bipulse.ru

Обсуждение в чате @proprocess_ru
Вопросы ведущему: Алексей Васильев @sbase
Download Telegram
Тем кто управляет проектами по разработке программного обеспечения следует читать не только труды по управлению, но по самой разработке. Вы не овладеете совершенством написания программного кода, но сможете определять когда нужно говорить "этого достаточно", чтобы не было как в причте:

== 5.2 Дао программирования

Начальник спросил Программиста, сколько времени ему потребуется, чтобы завершить программу, над которой он работает. ''Она будет закончена завтра'', немедленно ответил Программист.

''Мне кажется что вы несколько оторваны от действительности'', сказал Начальник, ''все же, сколько это займет?''.

Программист на миг задумался. ''У меня есть несколько идей, которые я хотел бы вставить в программу. Это займет по меньшей мере две недели'', сказал он наконец.

''Даже такой срок не кажется мне достаточно реалистичным'', настаивал Начальник. ''Я буду доволен, если вы просто сообщите мне, когда программа будет готова''.

Программист согласился.

Спустя несколько лет Начальник уходил на пенсию. По дороге к праздничному столу, накрытому в честь его ухода, он обнаружил, что Программист спит у терминала. Он программировал всю ночь.
==
Источник: http://www.karasik.eu.org/dao.html
Задание на выходные: посмотрите мультфильм "Пёс в сапогах"
https://premier.one/show/pes-v-sapogah

и ответьте на вопросы на картинке.
Если вы читали книгу о Методе управления проектным бизнесом, то наверное помните, что у нас есть два Ритма (пульса) : ритм контроля выполнение проекта, и ритм улучшений.

Эти ритмы соответствуют вершинам треугольника Дао предприятия:
- ритм улучшений - вершина "Процессы и правила" - мероприятия Ретроспективы спринта

- ритм контроля - вершина "Целей" - "планёрки" и "летучки".

Однако есть вопрос: А что с остальными вершинами Дао предприятия?

Есть ли Ритм у Технологий?
Есть ли ритм у Качества?
Если они есть, то какие они?

#метод #метод_пульса
Обсуждая с Иваном Абашкиным (https://t.me/ivan_abashkin) аспекты применения POOGI относительно диалектики, я могу теперь ответить на два вышеназванных вопроса:

= Ритм технологий =

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

Однако ссылка на это Ритм есть в главе "Правила непрерывного
проектирования".

Ритм проектирования Изделия, а именно "ПРИНЯТИЕ РЕШЕНИЙ о том КАК ДЕЛАТЬ" должен иметь свою периодичность - это период пересмотра и анализа предлагаемых решений относительно архитектуры Изделия. Если ритм не задать, то есть риск уйти в паралич анализа. И Ритм помогает сфокусироваться и сделать процесс управляемым.

Инструменты ритма:

Подготовка:
1. Мыслительный процесс ТОС "Дерево перехода" в отношении целевых функций системы но с другими вопросами:
а) Какой нужен целевой результат?
б) Что мешает получить целевой результат?
в) Какая должна быть характеристика системы для преодоления этого препятствия?


Мероприятие ритма:

последовательный анализ решения командой проекта с применением инструментов:

а) Мыслительный процесс ТОС "Дерево будущей реальности"
б). Алгоритм "Снижение архитектурных рисков" https://vimeo.com/240325104

#метод #метод_пульса
Я начал ссылаться на Метод управления проектным бизнесом "Pulse Management" однако в чате закреплена только ссылка на печатную книгу (за деньги). Но на самом деле, эта книга есть и в бесплатной авторской редакции на сайте Метода:

https://pulsemanagement.org/

#метод #метод_пульса
Проектный бизнес - как, что, зачем pinned «Вышла печатная книга о Методе управления проектным бизнесом. Теперь её можно заказать. https://ridero.ru/books/upravlenie_proektnym_biznesom/ В чем отличия от версии 1.11 выложенной на сайте PulseManagement: а) Это печатная книга б) Она с бумажными страницами…»
Проектный бизнес - как, что, зачем pinned «Я начал ссылаться на Метод управления проектным бизнесом "Pulse Management" однако в чате закреплена только ссылка на печатную книгу (за деньги). Но на самом деле, эта книга есть и в бесплатной авторской редакции на сайте Метода: https://pulsemanagement.org/…»
Проектный бизнес - как, что, зачем
Коллеги, в 2018 году я проводил исследование кейсах о внедрения Метода Критической Цепи (Critical Chain Project Management, CCPM) в России и странах СНГ. И нашел буквально 13 компаний. Из них половина - из сферы строительства, 2-3 пробовали как эксперимент…
2021 - Исследование о внедрении CCPM.pdf
228.3 KB
Результаты исследования 2021 года.

Было всего 7 ответов. Интересные выводы: несмотря на полученный положительный эффект, только 30% (2/7) компаний продолжили применение CCPM.

Препятствия к применению:
- трудности синхронизация задач между командами и компаниями
- срыв сроков не по нашей вине
- "нам еще рано"
- слишком высокое давление на команду (50% оценка задач).

#ccpm
= Ритм качества =

Вершина качества связана со всеми другими вершинами, и за неё отвечает инструмент Метода "Качество" .

Частота этого ритма определяется исключительно скоростью изменения организации и скоростью выпуска новых изделий на рынок. Для некоторых это 3 месяца, а для других год.

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

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

Такая сессия должна охватывать:
а) Анализ изменений внешней среды
б) Анализ трендов изменений внешней среды
в) Анализ положения компании в рынке
г) Проектирование будущего положения компании в рынке.
д) Анализ текущих процессов и правил относительно будущего положения компании и выявление нежелательных явлений и препятствий которые не позволяют достигнуть цели.
Запись семинара 29 марта 2012 года о применении CCPM в строительстве.

Открытый семинар: Леонид Казинец (Председатель совета директоров и основатель корпорации «Баркли»)
"Почему в России так строят? Чего не хватает для управления проектами? Современные теории управления бизнес-процессами в строительстве: концепции Just in Time, Lean manufacturing, практика Kaizen"

https://www.youtube.com/watch?v=roolQKH8-fc&feature=youtu.be

#ccpm
Из недавней дискуссии об аспектах планирования и выявления Угроз.

В Методе управления проектным бизнесом "Pulse Management" есть скрытая посылка которая следует из границ применения:

1. Метод применим для ИТ-проектов и НИОКР.

Это значит, что (срытая посылка):

2. Большая часть работ в проектах ИТ и НИОКР имеет примерно одинаковую длительность.

Следствие посылки 2:

3. Отклонения в оценках длительности работ (значительно) выбивающиеся из средних диапазонов значений содержат угрозы.

4. Следствие из п. 3: нам не нужно выявлять угрозы для КАЖДОЙ цели в плане проекта, нам нужно их выявлять ТОЛЬКО для тех целей оценка длительности достижения которых выбивается из средних значений.

Однако, пункт 4 верен ТОЛЬКО при выполнении посылки 2.

Возникает вопрос: А что делать с такими целями которые не имеют большого разброса, но разница между оценками стабильно в 2 раза? Если мы будем учитывать их в адаптивном буфере, то буфер проекта будет равен длительности проекта, что что же не хорошо.

С подачи Ивана Абашкина (https://t.me/ivan_abashkin), тут следует задавать вопросы:
- А почему ты считаешь, что достижение цели МОЖЕТ занять СТОЛЬКО МАЛО времени?
- А почему ты считаешь, что достижение цели МОЖЕТ занять СТОЛЬКО МНОГО времени?

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

#метод #метод_пульса
При найме разработчиков программного обеспечения в ИТ-проектах действует неявное правило:

----------------
Необходимый стаж для достижения уровня "Архитектор по разработке программного обеспечения" обратно пропорционален времени компиляции исходного кода (времени сборки).
----------------

То есть в языках программирования в которых время сборки программы долгое, таких как C++, C#, Java до архитектора дорастают быстрее. по сравнению с теми языками программирования где "результат мгновенный".

Причина этого в том, что разработчик (ПО) не хочет ждать пока программа соберется и он сможет проверить свою идею, поэтому большую часть проверок и доказательств он выполняет в голове, на листе бумаги или в wiki-документе. Таким образом он чаще работает с абстракциями и может моделировать поведение системы усилием мысли.

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

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

#ит #ответы_на_вопросы #разработка_по
Когда есть большой разброс в оценках длительности работ в наукоёмких и сложных проектах, то это повод задавать вопросы. Но какие вопросы нужно задавать? Если задать неправильный вопрос, то получишь неправильный ответ. Но если задать правильный вопрос, то можно и кружкой в голову получить.

О том, какие вопросы задавать читайте в новой статье Ивана Абашкина: https://t.me/ivan_abashkin/39

#метод_пульса #метод
в PMBoK есть термин "Project Charter" который в русский язык перевели как "Устав проекта", однако

"Уста́в — свод правил, регулирующих организацию и порядок деятельности в какой-либо определённой сфере отношений или какого-либо государственного органа, организаций, предприятия, учреждения и так далее." (С) википедия

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

#метод #метод_пульса #pmbok
Все из переводов слова "Charter" это разные формы обозначения "право на что либо", однако это не то, что реально нужно для ответа на вопросы "мы всё еще идём к этой цели или нет?", "Это точно нужно делать для этой цели или нет?"

Прорабатывая Метод управления проектным бизнесом (Pulse Management) (далее "Метод") я пытался найти лучшее обозначение документа Цели проекта. А ведь мы говорим именно об этом.

И... пока не смог найти. В Методе есть инструмент Холст Цели проекта, но это конкретная визуальная форма. Всё тоже самое можно сделать и в виде списка.

Но, как лучше должен называться по-русски документ определяющий Цель проекта и его границы ?

Договор проекта? Соглашение о проекта? - ну как-то не очень, это юридическая форма документа.

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

Карточка проекта? - это к информационным системам больше.

Карта проекта? - Это уже больше к планированию.

Цель проекта? - не содержит смысла документа.

Соглашение о Цели проекта? - хм.. исходя из способа формирования Холста Цели проекта определяемого Методом, наверное это наиболее приближенное обозначение результата мыслительного процесса "Определение Цели проекта".


Теория ограничений называет все построения логических цепочек и их проверки - мыслительные процессы. С этой точки зрения в Методе тоже есть мыслительные процессы и самый важный их них это: Мыслительный процесс "Определение Цели проекта" - а процесс это потому, что Цель проекта в контракте И Техническом задании это не совсем то что нужно на самом деле. И о ней нужно договориться. О границах проекта нужно договориться. О ресурсах нужно договориться. И самое важное, что Цель проекта нужно проверить на логичность всех утверждений. (об этом читайте в разделе "Вести с передовой" на сайте Метода). Поэтому результат всех договоренностей и проверок логично зафиксировать в "Соглашении о Цели проекта" - это "документ" и он носит неформальный оттенок о том что все участники проекта одинаково понимают Цель проекта и свою роль в нём.

ps: да, это второе поколение Метода. Включу в Книгу.

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

Метод управления проектным бизнесом (и информационная система управления управления проектами BIPULSE) имеет инструменты анализа качества процесса выполнения работы. А именно: скорость роста объема работы и количество добавленной работы.

Если новая работа в проект добавляется, значит объем увеличивается, значит сроки проекта могут увеличиваться.

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

(продолжение)

Что это может быть за работа?

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

Или, у вас в ИТ-продукте появился дефект, значит нужно создать задачу на исправление дефекта.

Однако для анализа процесса есть проблема: Как отличить декомпозицию пакета работ от новой и добавленной работы?

Простое решение: Всю дополнительную работу необходимо маркировать метками:
* дополнительная работа - любая работа которая появилась неожиданно
* дефект (для ИТ-проектов) - работа, которая появилась в результате обнаружения дефекта.

Дефекты в этом случае будут иметь обе метки и "дополнительная работа" и "дефект".

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

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

#метод #метод_пульса #bipulse
Цифровизация управления

Я часто провожу тренинги у партнёров в ЦНТИ Прогресс в рамках курса по цифровизации, цифровой трансформации и тд.

На них часто приходят производственники с основной задачей "Нам сказали что нужно всё перевести в цифру". Но является ли это той самой "Цифровизацией" которая должна по идее является сдвигом парадигмы по сравнению с предыдущей "Автоматизация" ?

Я считаю что нет. Простая автоматизация рутины - то всё еще автоматизация. Добавление новых умных станков - это автоматизация. И вот почему: если посмотреть все крупные сдвиги через призму изменений то вот что получится:

1. Электрификация - электричество в каждый дом, повышение качества жизни рабочих. ГОЭРЛО - 1920-1930
2. Индустриализация - 1929-1941 усиление рук рабочих, рабочий теперь может быть сильнее и продуктивнее когда он работает на станке.
3. Автоматизация - 1960-1990 - замена рук рабочих на роботов, ПЭВМ - автоматизирует работу офисных работников, ИТР.

и теперь Цифровизация - это замена чего на что? Последнее звено в производственной цепи - это принятие решений.

Цифровизация - это исключение управленца из цепи принятия решений, а значит это переход в режим управления "подчинение алгоритму".

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

Поиски такого алгоритма нашли в концепциях ERP, MRP, MRP2 и другие, но на наиболее прорывным в этом решения Теории Ограничений (ТОС), а именно простые метрики и индикаторы отвечающие на вопросы "когда", "что" и "сколько":

- упрощенный барабан-буфер-канат. Управление буфером заказа - когда запускать заказ в производство.
- буфер запасов в цепях поставок - когда и сколько закупать
- буфер проекта - когда спасать проект
- виртуальный барабан проектов - когда запускать новый проект и что обещать
- Проход - какой заказ или проект стартовать
- Проход проекта изменений - dT(осн)/dt - какой проект изменений начинать для производственной компании

и другие, простые показатели. И их даже можно считать в Экселе если у вас всего 3-5 объектов управления. Но если больше, то добро пожаловать в "Цифровизацию", тут уже без ИТ-решения не обойтись и ПРИДЁТСЯ подчиняться алгоритмам заложенным в информационные системы.

Для проектов, простой ИСУП не подойдет, нужен ИСУП который умеет решение ТОС для проектов. Также и других сфер. Для цифровизации управления нужны ИТ-решения реализующие положения Теории Ограничений.

Что за решения:
Для проектов - BIPULSE
Для запасов и цепей поставок - NetStock
Для производства - NetOperations


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