Результаты исследования 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.iss.one/ivan_abashkin), тут следует задавать вопросы:
- А почему ты считаешь, что достижение цели МОЖЕТ занять СТОЛЬКО МАЛО времени?
- А почему ты считаешь, что достижение цели МОЖЕТ занять СТОЛЬКО МНОГО времени?

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

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

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

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

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

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

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

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

#ит #ответы_на_вопросы #разработка_по

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

О том, какие вопросы задавать читайте в новой статье Ивана Абашкина: https://t.iss.one/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

Разбирая словарь TOCICO:
==
task safety - The difference between a task time estimate and the mean task time (the 50% task time estimate).
Usage: Many times a task estimate is twice or more the mean task time; this is the origin of the suggestion to cut estimated task times in half before using them in the critical chain schedule until resources and resource managers start giving challenging but achievable durations (i.e., approximately 50% task time estimates).

Caution: Some tasks have a static or fixed time and cannot be reduced significantly.

See:50% task time estimate, touch time.

== (перевод Яндекса)

безопасность выполнения задачи (task safety) - разница между оценкой времени выполнения задачи и средним временем выполнения задачи (оценка времени выполнения задачи на 50%).

Использование: Часто оценка задачи вдвое или более превышает среднее время выполнения задачи; отсюда и предложение сократить расчетное время выполнения задачи вдвое, прежде чем использовать их в расписании критической цепочки, пока ресурсы и менеджеры ресурсов не начнут давать сложные, но достижимые сроки (т.е. примерно 50% оценок времени выполнения задачи).

Внимание: Некоторые задачи имеют статическое или фиксированное время и не могут быть значительно сокращены.

Смотрите: оценка времени выполнения задачи на 50%, время касания.

==

Тут явно прописанные условия почему нужно резать оценку в 2 раза и нужно ли её резать.

Однако, проблема в том, что все читают книжку "Критическая цепь" и не читают примечания.

1. В словаре явно указано "Часто оценка задачи..." - то есть не всегда, и
2. "Внимание: Некоторые задачи имеют ...." - даже предостережение есть.

Игнорирование предостережения приводит к печальным результатам:
1. Проигнорировали "ЧАСТО" - инженеры дали оптимистичную оценку, мы её зарезали в два раза а потом "Ой, нам CCPM не подходит, приходится очень быстро-быстро работать".

2. Проигнорировали предупреждение , и начинается "Изделие изготавливается 24 часа, куда я оценку буду резать? Нам не подходит!"

Поэтому в Методе я явно указал что берем "оптимистичную" и "пессимистичную" оценку длительности работы. Оптимистичная всегда будет без резервов, которые нам нужно убрать в буфер проекта. А если длительность работы стандартизирована то обе оценки будут равны.

#метод #ccpm #TOCICO

Управление воронкой продаж для сервисного (проектного) бизнеса


Исходя из посылки для сервисного бизнеса (проекты на заказ):
1. Мы завершаем проекты точно вовремя (применили Метод)
2. Нам нужно всегда загружать ресурсы
3. Нам нужно не перегружать ресурсы
4. Обычно длительность проектов примерно одинаковая, проекты с короткой длительностью имеют низкую маржу , длинные проекты слишком заморочные для людей, поэтому копания выбирает для себя комфортную среднюю длительность и интересность проектов.

Нам необходимо привлекать столько лидов чтобы контрактовать их точно вовремя.
5. При отлаженной системе продаж, входящий лид становится Клиентом за конечное время.
6. Не каждый лид становится клиентом. есть конверсия. (2-3-10-30%)

7. Мы знаем через сколько времени освободится рабочий центр.

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

Но сколько лидов сейчас загружать в воронку?

1. Лиды - заполняют буфер перед перед производством. (запуск проектов)
2. Какой размер буфера?

Надежное время контрактования = надежное время пополнения = среднее время контрактования делить на конверсию = 3 мес / 0.20
Скорость продаж = тут нету, поэтому берем количество рабочих центров для проектов

Размер буфера для лидов = Надежное время контрактования * РЦ

Например:
Есть 4 рабочих центра
Время контрактования - 3 мес.
Конверсия: 10%
Средний проект = 3 мес. (длительность тоже нужно учесть)

Значит нам нужно в воронке: 4 * 3 / 10% = 120 лидов в пике. по 30 на каждый РЦ. в условиях когда дата завершения проекта приближается к дате контрактования

Если дата завершения дальше срока контрактования, то уровень буфера лидов нужен меньше. (или больше? я еще не подумал об этом)

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


#метод #ббк

Закон Конвея

Много Agile-экспертов при аргументации преобразования компании любят ссылаться на Закон Конея. «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации», с той точки зрения что "Чтобы создавать новое вам нужно поменять организационную структуру, а сразу всё будет хорошо". Вот у вас отделы, а нужно выделить людей в проекты.

Но мне это напоминает Квартет басни Крылова. И вот почему:

Закон Конвея описывает "что вижу, то пишу" и не учитывая историческую перспективу.

Сначала, при росте сложности при создании системы компания начинает делиться на подразделения выделяя экспертизы. В этом проявляется необходимость снижения локальной сложности и уменьшения количества коммуникаций (см. "идеальный размер команды" 7+-2)
Затем, имя опыт в отрасли компания тиражирует полученные результаты опыт создавая похожие системы и развивая имеющиеся.

Таком образом для работы над существующими системами НЕ ТРЕБУЕТСЯ изменения организационной структуры, потому что архитектура системы/изделия диктует организационный дизайн и наоборот имеющаяся структура компании определяет разбивку на зоны ответственности.

Беготня от "функциональных колодцев" имеет последствия в виде утраты экспертизы, в результате чего получается настолько "гибкая" структура продуктов, что бизнесу проще похоронить продукт, чем его поддерживать. При размытии точек экспертизы каждый конечный исполнитель будет иметь меньшую экспертизу чем если бы о был в отделе. Защита в виде регулярных встреч сможет удержать деградацию, но не надолго в стратегической перспективе. Также при устранении "колодцев" появляется эффект дублирования функций, потому что единые корпоративные стандарты становятся изолированными внутри проектов, и каждый инженер начинает перепридумывать реализации потому что:
1. "лень искать",
2. "так интересней".
3. "не у кого спросить"
4. "мне некогда искать в этой вики, мне результат нужно выдавать."


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

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

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

И возвращаясь к началу ответьте на несколько вопросов:
1. А точно ли нужно в вашей организации менять орг структуру?
2. Какую конкретную проблему это решит?
3. Можно ли эту проблему решить иначе?
3. Какие плюсы и минусы обоих решений?

#agile

В субботу Буду выступать на конференции ISDEF - 21-я осенняя конференция про развитие глобального бизнеса на софте. https://conf.isdef.org/ .
В воскресение буду в Москве, можно встретиться, подпишу книгу (у кого есть 🙂 или просто так.

Пишите @sbase.

OKR - а по русски "Цели и ключевые показатели", это совсем не Система Сбалансированных Показателей (ССП , а иже BSC), а на самом деле это Проектно-портфельное управление. Где Проекты - это те самые квартальные цели.

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

ps: про цели и результаты в маркетинге следующей заметкой.

Цели и ключевые результаты в маркетинге.

Для разработки продуктов алгоритм работает: Цель, План, погнали в "темпе вальса". Но иногда бывает иначе.

Могут быть ситуации, когда нельзя определить конкретные действия по достижению Цели, но бывает в продажах и маркетинге. Ибо цель звучит как "Повысить продажи на 20%". А вот способ повышения этих +20% никто не знает. тогда начинаются метания "О боже, как я могу повысить продажи? Давай попробуем так? А может так? Не.. давай эдак.".

Продвинутые мастера в таких случаях говорят: Эээ, брат, это у тебя зона неопределенности Киневину, поэтому тебе нужно HADI циклы делать, и Sсrum применять". И тогда вместо того чтобы сесть и подумать "Как мы можем достигнуть цели кратчайшим путём?" Начинается беготня по кругу , ой в смысле по Скраму. Где эффект главным образом проявляется за счёт ежденевного контроля (ежедневный Скрам), а не системной работы.

Но думать - это сложно, наш мозг устроен так что он пытается улизнуть и не делать трудную задачу думания. На картинке ниже модель работы с экспериментами "Ралли" которую вы применять НЕ будете, ибо думать это сложно. Чтобы выставить машинку на доску нужно ответить на три вопроса:
1. Кому продаем?
2. Что на самое деле продаем?
3. Какой слой сопротивления мы улучшаем этим экспериментом?

А затем нам нужно правильно поставить сам экперимент.

Интересны подробности? Поставьте плюс, сделаю вебинар.

Модель управления с экспериментами "Ралли" которую вы применять НЕ будете.

Новости. Мы выпустили большое обновление системы бизнес-аналитики и поддержки принятия решений для улучшенного управления проектами BIPULSE. Версия 7.9.199 (Июнь-сентябрь)

Самое главное:

+ Теперь можно адаптировать под свою сферу применения. Доступные адаптации: ИТ-проект (Agile), Объекты строительства, Проекты организационного развития и другие.

+ Улучшен интерфейс, убрали ненужное подсветили нужное.

+ Ускорена работа с расписанием. Теперь оперативное расписание для 20.000 работ можем рассчитать за 5-10 секунд.

+ Добавлена интеграция с Azure DevOps (ex TFS, Team Foundation Server), как всегда двунаправленная.

Ключевые изменения версии 7.9:

+ Появился установочный пакет для развертывания на свой Linux сервер с СУБД PostgreSQL

+ Мы закончили миграцию на платформу KPHP - Все модули работают в штатном режиме. Система стала быстрее работать в 3 раза.

Оставайтесь в фокусе, держите руку на Пульсе бизнеса!
Закажите демонстрацию.

#bipulse