Все из переводов слова "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

Скоро можно будет играть в игру "Я угадаю способы интеграции BIPULSE по одному логотипу"

Интересно, а кому-то нужно связывать все эти системы между собой напрямую без нашей умной системы?

#bipulse

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

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

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

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