Возможности для новых проектов продолжают открываться, а это значит что и старые проекты нужно не упустить из виду. На очередной встрече посвященной историям внедрения Метода управления "Pulse Management" Евгений Айдаров расскажет какие метрики он применяет для снижения выявления угроз на этапе выполнения проекта.

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

Для получения ссылки для подключения необходима регистрация на событие по ссылке:
https://pulsemanagement.timepad.ru/event/1977162/

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

https://www.youtube.com/watch?v=OdlBQFSLbZo

Развитие различной *зации:

Электрификация - обеспечение всех электричеством
Индустриализация - усиление рабочих рук станками, которые управляются рабочими
Автоматизация - замена рабочих рук станками пол управлением рабочими.

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

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

Примеры:
* NetStock (vmss.pro) - цифровизация управления запасами и наличием от Жизнеспособная Система Управления Viable Management System

* BIPULSE - цифровизация проектного управления.

* Системы управления на сборочном конвейере в автомобилестроении. Все ручные операции определяются алгоритмом нужно уложиться за норматив.

Вопрос: Какой смысл в определении угроз в Уставе проекта.

Ответ: Ответ на вопрос "Что может убить проект" на этапе определения Цели проекта и формирования Устава проекта обеспечивает одинаковое понимание всеми ключевыми участниками проекта главных условий при которых проект может провалиться. Поэтому важно чтобы все основные заинтересованные стороны участвовали в мероприятии по запуску проекта.
#метод.

Вопрос: Что делать если в процессе выполнения проекта выявились другие угрозы в отличии от тех которые мы определили в Уставе проекта? Нужно ли пересматривать устав?

Ответ: Если у вас появились новые угрозы, но они не приводят к изменению Цели проекта или изменению ключевых характеристик результата проекта, то Устав не нужно менять.

У вас может поменяться План достижения Цели или содержание работ, но способ реагирования на такие изменения должен быть определен заранее для избежания ситуации "-А-А-а-а-а всё пропало, что делать шеф?"

Мёрфи придёт гарантировано, даже если вы выявите все угрозы. Есть типовой способ обработки ситуации (https://pulsemanagement.org/rules-deceisions-by-buffer/) и есть ваш способ,но тогда пишите План управления изменениями. (см "Свод знаний по управлению проектом") .

#метод

Вопрос: зачем определять и фиксировать угрозы в уставе проекта?

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

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

#метод

О "Продуктовой разработке"

Нету мифической "продуктовой разработки". Есть Жизненный цикл Продукта, который хорошо известен производственникам под именем "Жизненный цикл изделия (жизненный цикл продукции) - Product Lifecycle "

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

Таким образом, "продуктовая разработка" это много-проектная среда, где нужно выполнять обязательства по обеспечению Эксплуатации Изделия и одновременно с этим создавать новое Изделие. И это если мы ещё не говорим про проекты внедрения Продукта Заказчикам.

#метод

Вопрос: Являются ли Agile подходы методами Управления проектами

Ответ: не совсем

Ребятки, основатели движения ASDM, были инженерами и не поднимались на уровень определения цели проекта и его смысла. В большей части случаев они из "внутреннего ИТ" или как консалтеры ( читай внешний ИТ-подрядчик) помогали.


https://scrumguides.org/scrum-guide.html#purpose-of-the-scrum-guide
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

https://www.agile-process.org/
The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.

https://www.extremeprogramming.org/
Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

https://www.researchgate.net/publication/234820806_Crystal_clear_a_human-powered_methodology_for_small_teams
Crystal Clear - A Human-Powered Methodology For Small Teams, including The Seven Properties of Effective Software Projects

https://www.agilebusiness.org/page/whatisdsdm
DSDM is an Agile method that focuses on the full project lifecycle, DSDM (formally known as Dynamic System Development Method) was created in 1994, after project managers using RAD (Rapid Application Development) sought more governance and discipline to this new iterative way of working.

The RUP Is a Process Framework (уже RIP, прямой источник не нашел)

То есть все популярные в России реализации Agile (ASDM) это процессные "методы" кроме DSDM.

#agile #метод

Вопрос: Что делать когда при внедрении новых подходов типа Scrum сотрудники встречают это сопротивлением и превращают в карго-культ.

Ответ:
Если типовые мероприятия назвать о другому - получится Квартет по Крылову.
Для правильного внедрения нужно понимать цели каждого мероприятия, а если меняются Цели то поменяется и структура , через последовательные вопросы можно привести к необходимости всех мероприятий без сопротивления.

Сопротивление есть потому что "проблемы не существует" (первый слой сопротивления). Для участников, которым вы "продаёте" новый метод. У них нет проблемы с поставок, с процессами, с качеством. И методы которые вы предлагаете "не решают нашу проблему" (второй слой сопротивления).

Однако для каждого мероприятия есть скрытые предпосылки необходимости. И их нужно учитывать. Если предпосылка не выполняется, то нужен ли вам Скрам или это мероприятие?

Детали: Scrum patterns https://scrumbook.org/
https://sites.google.com/a/scrumplop.org/published-patterns/value-stream/sprint-planning

Детали: 6 (9) слоев сопротивления, Основные решения Теории ограничений, Словарь TOCICO

О роли качества в ИТ-проектах.

Метод (Pulse Management) определяет что качество должно быть превосходным или максимально превосходным. Однако повышение качества это инвестиции. Как определить когда нужно начинать инвестировать в качество?

Одним из популярных в последнее время подхода является: "Давай сделаем кое-как выгрузим в рынок , протестируем гипотезу." потому что "Так завещал Аgile"

Однако, у приверженцев такого подхода потом не хватает смелости выбросить этот прототип.

Как результат:
1. Не выполняется правило XP (eXtreme Programming) "Прототип на выброс"
2. Не выполняется ценность XP "Смелость" - нужна смелость чтобы выбросить сделанное.
3. Прототип на самом деле не настоящий Прототип который за 2 для делается.
4. Архитектура в прототипе не адаптирована под изменения.

Дальше это идёт как снежный ком обрастая дефектами, хотя нужно остановиться, и пересмотреть всю систему.

Из личной практики: Я руководствуюсь правилом: поднимаем автоматические модульные тесты если больше 3 человеко-недель объема работы.

При этом во времени это выглядит так:

1 неделя - модель/прототип
2 неделя - отладка с реальными данными
3 неделя - определение новых сценариев
4. неделя - пора писать тесты и переходить к полному циклу, а то начинает отваливаться ранее написанное.

Если на проекте 2 инженера, то контрольное время сокращается. А больше 2 инженеров на прототипе не нужно.

#метод #agile

Практика применения алгоритма планирования и инструментов ТОС из первых уст. В заметке ниже:

В воскресенье обсуждали с коллегами этап планирования проектов и дерево предпосылок.

Во время обсуждения, нам вспомнилось одно практическое наблюдение: если при планировании проекта, вы слышите фразу "Да тут всё понятно, что тут обсуждать!", то это признак того, что надо насторожиться, и глубже копнуть в этот вопрос.

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

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

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

Картинка к предыдущей заметке

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

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

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

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

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

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

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

Спустя несколько лет Начальник уходил на пенсию. По дороге к праздничному столу, накрытому в честь его ухода, он обнаружил, что Программист спит у терминала. Он программировал всю ночь.
==
Источник: https://www.karasik.eu.org/dao.html

Задание на выходные: посмотрите мультфильм "Пёс в сапогах"
https://premier.one/show/pes-v-sapogah

и ответьте на вопросы на картинке.

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

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

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

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

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

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

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


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

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

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

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

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

https://pulsemanagement.org/

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