Наблюдения за животными наводит на некоторые мысли. Особенно если это умные питомцы. Поведение декоративных крыс хороший пример поведения социальных групп. Но я не про "Вселенную-25". У меня тут другой пример: выдача вкусняшки двум разным крыскам.

Активная позиция:
- Хочешь вкусняшку?
- Да, давай! Таак, я её сейчас аккуратно возьму. (Аккуратно слизывает языком). Няма, няма. Может еще есть?

Проактивная позиция:
- Хочешь вкусняшку?
- Да! Давай сюда! Давай Мне, Куда пошел? (тянет лапу и хватает палец) Ближе пододвинь, мне не достать. А всё достал! Теперь можешь идти. Стой! А еще есть? Еще давай!

А какое поведение вы наблюдали в командах и группах?

16 марта в 20-00 МСК Онлайн-встреча посвященная Методу управления проектным бизнесом Pulse Management. На встрече вы узнаете историю практического опыта применения метрик Метода, открытия и озарения.

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

Регистрация на встречу:
https://pulsemanagement.timepad.ru/event/1959781/

Коллеги. В связи с участившимися случаями неожиданных блокировок аккаунтов в популярных сервисах Mailchimp, Slack, Wrike рекомендую провести планёрку с одним вопросом "Что может убить ваш бизнес?"

И составьте план реагирования на угрозы.
Из типовых угроз сейчас:
1. Данные компании на зарубежных серверах.
2. Используются зарубежные сервисы в бизнес-процессах компании.

ps: SaaS BIPULSE расположен на российских серверах.

Об основах Метода Управления проектным бизнесом

В последнее время, рассказывая про Метод, я замечаю что на самом деле Метод и его правила - это управление в стиле "коучинг". Потому, что в нём все мероприятия построены по структуре:

1. Покажите метрики
2. Задавайте вопросы
3. Запишите ответы

Это согласуется со стратегией ведения переговоров:
1. Кто задаёт вопросы - тот управляет переговорами.
2. Аргументация к фактам один из самых сильных методов доказательства Тезиса на уровне логики. (Другие методы слабее или это уже манипуляция)

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

Всемогущий Scrum Master?

Часто на человека с ролью Scrum Master навешивают еще кучу зон ответственности. Однако, не может быть во всех направлениях сразу. Занимаясь процессами нельзя требовать поставки результата в в роли Руководителя Проектов, это находится в конфликте "сделай правильно и сделай быстро". Также, как пытаются Продакта заставить управлять командой. Переключаясь в организацию процессов он теряет фокус на Целях их выявлении и определении.

Картинка из Метода "Pulse Management".
#метод #метод_пульса #scrum

Догма ли Скрам-гайд?

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

Если говорить о Методе Пульса, то тут ситуация иная. Метод не универсальный механизм, хотя его ключевые инструменты: Цель, Ритм, Правила, Качество могут подходить к любой целенаправленной активности. Вопрос только в способе реализации этих инструментов.

Если вы действительно хотите прийти к Цели вовремя, то вы должны регулярно сверяться с картой, для этого нужен Ритм. Чтобы не спорить о способе достижения Цели у вас должны быть Правила. И нужно делать всё с максимальным качеством, чтобы не пришлось переделывать.

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

Внесение изменений и адаптация Метода к среде выполняется за счёт логических формулировок "Если _________(условие)________ то предпосылка ____(указать предпосылку)_______ будет неверной, поэтому мы применяем ______(новое правило)____________"

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

Возможности для новых проектов продолжают открываться, а это значит что и старые проекты нужно не упустить из виду. На очередной встрече посвященной историям внедрения Метода управления "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.

http://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.

http://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 http://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

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

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

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

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

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

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

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