В продолжение сегодняшнего поста вот такой фреймворк для анализа конфликтов и стратегии их разрешения предлагает SAFe 6.0.

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

Всем счастливого последнего дня в этом году!🎄

Желаю всем в новом 2025 найти или отчаянно следовать своей North Star⭐️

Оставайтесь адаптивными, но пусть следующие 365 дней дадут меньше поводов для экстренной адаптации🙏

Спасибо каждому, что читаете❤️
Это ценно. Увидимся в новом году😎

Проджекты, как вам новости начала года от PMI?

🔥Объединение с Agile Alliance
🔥Подготовка PMBOK v8 и фактически "возврат к истокам" 6й версии, т.к. 7я была сильно в отрыве от реальности. Помню когда сдал PMP подумал, что если бы готовился по 7й, а не 6й не сдал бы 100%.

Это нормально признавать свои ошибки, даже если ты PMI😉

P.s. детальнее про восьмёрку можно почитать у Вани Селиховкина и если зарегины в PMI непосредственно ТУТ

Счастливого Рождества😇

В волну нельзя промахнуться - камень всегда попадает в цель

Стою на посадке в аэропорту Стамбула. Подбегает женщина с ребёнком и просит помощи в общении со стюардами. Их транзитный самолёт задержался и они не успели на регистрацию на мой рейс в Сербию. Муж внизу получал чемоданы, но сдать уже не может, т.к. регистрация окончена, а с чемоданами не пускает таможня Стамбула. Следующим пунктом из Сербии у них автодорога и отель в горах Черногории, в котором на следующий вечер слетит бронь, если они не приедут.
Стюард предлагает варианты:
1) Сдать в забытый багаж авиакомпании Air Serbia, чтобы доставили завтрашним рейсом
2) Купить 4 чемодана ручной клади и переложить всё из 2 больших чемоданов, в 4 малых, но придётся выбросить большие

Что в итоге выбрала пара?
- Что выкинуть 2 чемодана по 200$ каждый - слишком дорого. Отчаяние. Долгие споры и ругательства с авиакомпанией, которая им сочувствовала, предлагала решения, но не могла нарушить принятые правила из соображений безопасности. Не улетели...Сомнительное решение с финансовой точки зрения.

Много лет назад в одном из проектов по монтажу узлов тепловой энергии я столкнулся с настоящим вызовом. У меня был табличка Excel, которая содержала 119 адресов города Ростова, Ярославской области. Каждая строка - "бесконечность"😵‍💫 Это полная детальная информация об условных диаметрах труб и запорный арматуре, указанных в проектно-сметной документации к конкретному адресу. Я собирал данные неделю, чтобы с помощью хитрых макросов далее по ней генерировались формы М-15 для приемо-передачи генподрядчику. Короче док был уничтожен. Безвозвратно. С ноутом. Передавать оборудование послезавтра. Отчаяние.
Купил ноут. Два дня и две ночи я работал, начиная с нуля, собирая информацию заново.

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

Чему я научился:

1) Нет пределов фантазии при составлении реестра рисков в проектах. Раньше я думал "ну такого же никогда не произойдёт - зачем это вообще вписывать?!"
2) не стоит гнушаться простой человеческой структурной моторики. Я распечатал список из 119 адресов и после полного круга (перенос данных, проверка данных, правильная отработка макроса, формирование печатных документов и печати) простыми человеческими галочками карандашом отмечал успешность каждого этапа. Поверьте, после 24-го часа монотонной работы такой подход куда эффективнее, чем вести рябящий в глазах электронный реестр🙂

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

При ведении бэклога целесообразно использовать подход с использованием акронима DEEP. Писал ТУТ об этом. Но если с Detailed, Estimated, Prioritized никогда не было проблем провести объяснение для начинающих владельцев продуктов, то Emergent - это какой-то "странный" зверь. И вот наткнулся на ПОСТ, где очень круто это разъясняется.

#полезное in English

🔸 FOCUS для целей спринта как INVEST для пользовательских историй

🔸 Интересный взгляд на то, как работать PO|CPO в B2B и общаться с клиентами о преимуществах, а не о функциях: "как этот продукт поможет вам" , а не "как этот продукт работает"
💬 "Мы можем легко впасть в режим лекций, «обучая» коллег мучительным подробностям о техническом долге, аспектах разработки и о том, как команды внедрения деплоят непрошедший QA код, когда они переходят к следующему одноразовому проекту"

🔸 Как грамотно работать с картой (матрицей стейкхолдеров) от Романа Пихлера
💬 "Следует сосредоточиться на заинтересованных сторонах, чей вклад и поддержка вам действительно нужны"

🔸 Крутая статья про разницу защитной позиции и отстаивания своих идей, если кто-то не понимает, что вы делаете
💬 -«Ты боишься, что тебя сбросят с лошади?»
-«Если ехать достаточно долго, рано или поздно тебя сбросят»

🔸 "Сокращение штата — это краткосрочное решение, которое игнорирует коренные проблемы. Корпоративная иллюзия."

Agile это не только про гибкий, но и про быстрый 

Когда процессы лучше чем Agile?

Чем больше людей объединены целью и горят продуктом тем вероятнее взлетит agile философия в проекте по его реализации. Но со временем рук начинает не хватать и мы берём в компанию разных людей: их мотивация может лежать в области денег, ради карьерных амбиций, ради власти, да даже наворовать идей и создать на этой основе что-то своё. Как только людей, которые присоединились позже становится больше, чем энтузиастов горящих целью случается переломный момент. Люди, которые не горят целью хорошо управляются морковкой спереди и сзади, танцами с бубном HR бизнес партнёров и экспертов по вовлеченности, но лучше всего работает формализация процессов. Не вовлеченный, не сосредоточенный на цели - работай по регламенту. Не хочешь работать по регламенту и менять майндсет - на выход. Это хорошо иллюстрировалось в прошлом когда Джобс работал над Лизой (захламлённой бюрократическими процессами вплоть до совета директоров) и ушёл в Макинтош (свобода творчества и объединённые целью небольшая группа людей). В итоге где сейчас Лиза и где Мак? 

Пример из современности Nasa и SpaceX. У Nasa 700 подрядчиков, более 2000 компаний. Всё медленно, долго, некачественно и бесконечные издержки. А Маск уже реализовал вертикальную посадку перезапускаемого модуля. 

Но быстро = дорого. Хочешь крутой продукт - инвестируй в людей, которые заражены единой целью. Хочешь дешевле - инвестируй в людей которые выстроят процесс, позволяющий из группы людей создать коллектив, хотя бы лежащий в направлении цели. 

К сожалению часто вижу попытки в компаниях натянуть Agile подходы на людей которые к этому никогда не будут готовы. НИКОГДА НЕ БУДУТ ГОТОВЫ! Right People Do The Right Things. Ну, не замотивируешь ты человека, который сам этого не хочет. Максимум простимулируешь, но временно. Надо начинать с "Right people".

Съездить в командировку - это посмотреть на работу своей организации в миниатюре

Здесь прекрасно всё:

🚂 оформление командировки (насколько простой и понятный процесс, сколько согласований, какие билеты, гостиницы, лимиты доступны и т.д)

🚖 как пользоваться "благами цивилизации" в виде такси (работают ли с аггрегаторами или может легко возместить челночные траты за частников)

💰как закрывать авансовый отчёт (в одной компании было в порядке вещей после успешных переговоров или подписания актов выполненных работ пойти заказать коньяку за обедом или вечером сауну, а в другой поднимали на вилы за то, что ты лишний раз воспользовался такси в служебных!!! целях)

🤯 как работает бухгалтерия и взаимоотношения с CEO (тут всё просто: доки делает сотрудник или бухгалтерия. Однажды мне пришлось собирать план командировки чуть ли не как на шенген)

Была одна история как я реализуя проекты за 2 дня проехал: Питер=>Вологда=>Рыбинск=>Ростов=>Жуковский=>Ростов=>Москва=>Питер. Перемещался на 3х транспортах: личный авто, поезд, автобус. Реестр рисков - пфф это азбука в сравнении с тем, чтобы заполнить все подотчетные главбуху почему такой странный маршрут😅
Хотя это была та же компания, когда мой коллега летал в Китай вместо Уфы так что тотальный контроль не залог успеха.

Короче, хочешь понять как устроен мир в компании скорее мчи на конференцию😉

А вы любите гонять в командировки? Были интересные случаи?

#полезное in English

1️⃣ Твоя память тебе врёт

🔸 В посте речь про самообман и искажение памяти, что люди склонны обманывать себя, особенно в отношении своих воспоминаний и убеждений. Мозг перерабатывает информацию, создавая более «доброжелательный» взгляд на реальность, что может привести к искажению восприятия прошлого.
🔸 Иллюзия контроля и психическое здоровье: Эволюционно мозг стремится поддерживать иллюзию непрерывности и контроля, что может быть полезно для психического здоровья, но также может привести к искажению восприятия реальности. Осознание собственных ошибок и заблуждений помогает улучшить ментальные модели и мыслительные процессы.
🔸 Ведение рукописного дневника: Рекомендуется фиксировать важные решения и убеждения в рукописном дневнике, так как это помогает избежать самообмана. Записи не подлежат изменению, что делает их более надежными для объективной оценки своих мыслей и действий.

2️⃣ Отсутствие доверия как препятствие к быстрому росту команд

🔸 В очередной раз о том, что очень трудно измерить - доверие, но то, что является непосредственным катализатором роста команды. Недостаток доверия как препятствие для эффективности: В процессе роста команды недоверие между участниками может стать основным препятствием для эффективного сотрудничества. Это недоверие может быть оправданным, если у членов команды нет достаточных данных о компетенциях друг друга или если они только начинают работать вместе.
🔸 Доверие и масштабирование сотрудничества: Доверие позволяет командам работать более эффективно, снижая необходимость в постоянной проверке и контроле. Когда члены команды доверяют друг другу, они могут делегировать задачи и работать автономно, что особенно важно в условиях высокой нагрузки и давления.
🔸 Влияние доверия на принятие решений: Низкий уровень доверия может привести к затягиванию процессов и необходимости более детального контроля, что увеличивает рабочую нагрузку для всех участников. Создание доверительных отношений в команде позволяет быстрее принимать решения и двигаться вперед, особенно когда вовлечено множество заинтересованных сторон.

3️⃣ Как мы решаем что создать

🔸 Интересный подход к созданию продукта. Заинтересовала карта нужд пользователей
🔸 Принципы => Карта => Приоритизация => Зоны ответственности => Минимальные трудозатраты на тестирование

4️⃣ Результат - это не то, что нам на самом деле кажется

🔸 О взгляде на результаты. Чем outputs отличается от outcomes, а если по-простому, что результатом является не то, что мы закончили разработку и залили на прод, а то, что функцией стали пользоваться конечные пользователи и надо фокусироваться именно на этом.

​​Посмотрел, что посты про мотивацию у меня в канале звучат 34 раза - это, вероятно, 3 место после Agile и проектов😏😉 Да, я счастлив, когда удаётся замотивировать человека, когда веду тренинги по мотивации и выравнивание этого аспекта позволяет сделать организацию лучше! Но что, если взглянуть на другую сторону медали? Не со стороны консультанта/руководителя/подчинённого, а со стороны всей системы организации на что посмотреть? Наткнулся на классный пост...

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

Если зуд не прошел, и мотивировать все-таки хочется, медленно выпейте стакан воды и выясните, прозрачны ли квалификационные надбавки; платите ли вы их за необходимые для компании компетенции и не получают ли их low-performers.

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

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

Ну уж если совсем хочется мотивировать всех подряд как Шариков и котов, расслабьтесь, перекреститесь и проверьте, правильно ли подобраны и обучены линейные менеджеры, и на своих ли они местах.

Если болезнь приобрела затяжной характер, помедитируйте, и спросите себя, а тем ли вы заняты на своем месте сами?"

Отрезвляет⭐️

​​Задавайте много вопросов

Если человек что-то не понимает это вовсе не означает, что он некомпетентный. Вполне возможно ему не хватает данных.

В праздники довелось одним днем съездить Белград - Сараево - Белград

Конечно я был наслышан о балканских приколах. Оба раза граница Сербии проходила без сучка. А вот на обратном пути из Боснии пограничник замучил вопросами: а почему вы ездили? а как прошла поездка? а что посещали? а как так всего на 1 день? а ещё планируете приехать? и т.д. Я привык, что такой опрос обычно на въезде, но на выезде?!))

Мне вспомнилось как в своё время защищал масштабирование в SAFe в компании перед CEO. Уходил в -цать раз пауз решений и ответов на вопросы CEO, который хотел понять до каждой ШЕ, чем внедрение фреймворка поможет улучшить QA или создать "скамейку запасных" для разработки, а сколько мы сэкономим наняв архитектора данных или High-load тестировщика.

Впрочем по итогу он признался, что эти всевозможные данные с него спросят собственники когда он попросит деньги на имплементацию фреймворка, так что логично, что ему надо обоснование на каждый вложенный цент. У каждого руководителя есть свой начальник. Даже у собственника есть "бизнес - великий американский Бог, очень грозный, который карает быстро и ужасно" (с) Джек Лондон.

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

У моего прошлого босса была классная стратегия когда его давили точной датой решения он отвечал, что я возьму паузу на 1-3-5 (опционально) дней и вернусь к вам с ответом. Это позволяло не подписать себя на нереальные сроки и хорошо всё взвесить. 

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

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

​​Как общаться с разработчиками

Начинающие (и продолжающие) скрам-мастера, пришедшие не из мира IT сталкиваются с проблемой а как разговаривать с разработчиком. Хуже, если ещё при этом ты начинаешь учить разработчика как управлять его задачами - это путь в никуда. Недавно общался с другом, который по совпадению работал CTO, а сейчас трудится Agile лидером и ему естественно не составляет труда перейти на общий язык с разрабом, когда это требуется. А если ты и строчки кода в жизни не писал? Как быть?

Надо помнить о 2 вещах:
1) Зачем ты входишь в этот разговор или даже конфликт? Какая цель преследуется?
2) Помоги человеку почувствовать собственную важность в процессе

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

Слово за слово, что хотим узнать сколько у "такой-то" модели толщина каркаса?
И полетело:
- Вы вообще знаете с кем разговариваете?
- Кто вам дал этот номер?
- Это я вам говорю сколько должно быть миллиметров, а не вы мне рассказывайте
- Да не смотрите, что в магазине на этикетке пишут, вы меня слушайте

Ну и тон of voice был уже практически форме крика. Оказалось, что это директор по производству, но не ставленный менеджер, а человек, который прошёл всю кухню руками от рядового сборщика, поэтому досконально разбирался в вопросе.

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

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

#полезное in English

1️⃣ Подходы про то, как уменьшать устаревающий бэклог.
История, что со временем бэклог превращается в мусорное ведро - стара как мир. Я видел только парочку владельцев продуктов, которые всегда держали его в надлежащем состоянии. У большинства задачи уходят корнями созданности в более, чем 3 года. В статье понравился описанный подход "про дракона"😁

2️⃣ Исследование как разработчики теряют 1 день в неделю из-за неэффективности менеджмента.
Как по-разному воспринимает менеджмент ИИ: для менеджмента видится, что это в разы увеличит эффективность написания кода, а для разработчиков - пока эффективность в написания кода от ИИ не настолько очевидна. Ну, и по классике ТОП 5 как менеджмент считает эффективность разработки (привет, проджект менеджмент😉):
- количество строчек кода
- частота релизов
- число сторипойнтов
- число отработанных часов
- изменения требующие исправления (CFR)
... и не слово про ценность и про техдолг, необходимый для скорости внедрения инноваций.

С всемирным днём рок-н-ролла всех! Agile Rocks!🎸🎤🎧

Перефразируя слова главного героя: "Всё имеет своё начало. Если у вас есть общие ценности и принципы, то не составит большого труда делать крутые инновационные проекты". Другое дело, что фундамент — это не только технические требования или бизнес-цели, но и понимание того, почему мы делаем то, что делаем. В Agile подходах важно не только адаптироваться к изменениям, но и регулярно возвращаться к основам: к ценностям команды, к целям проекта и к ожиданиям заинтересованных сторон. Это требует смелости — смелости взглянуть в лицо проблемам и признать, что иногда именно мы сами являемся источником затруднений.

p.s. Если кому интересно - данный фрагмент из сериала Винил (2016). Рекомендую.

​​На выходных выступил для студентов иностранного факультета магистратуры Высшей школы менеджмента СПбГУ — рассказывал про практические кейсы трансформаций в компаниях ⚙️

Очень порадовала вовлечённость ребят, количество вопросов и интерес к реальному опыту — это всегда крутой индикатор стремления к росту!

И вот что хочу посоветовать всем, тем, кто подписался и кто изучает Agile, трансформации и организационные изменения:

📚 Теория — важна. Но!
🔍 Контекст — критически важен.

В реальной компании никто не откроет Scrum Guide или сайт SAFe в момент конфликта, непонимания или сопротивления. Там будут живые люди:
👥 Со своими страхами, амбициями, интересами.
⚖️ Со своими зонами ответственности и зонами влияния.

Поэтому:
1️⃣ Учите инструменты — это база.
2️⃣ Пробуйте их применять в реальных кейсах — даже учебных.
3️⃣ Учитесь видеть людей, а не только роли и процессы.
4️⃣ Помните, что адаптация подхода под конкретную ситуацию — ключ к успеху.

Agile — не про шаблоны. Он про гибкость, эмпатию и постоянную настройку под "полевую" реальность.

Спасибо студентам ВШМ за тёплый приём и интересные вопросы — вдохновили!

А у ребят всё получится! Они толковые и вовлеченные на 100500%🔥 Пишите в личку @rudman87, кто подписался, если ещё будут вопросы, с удовольствием помогу ответить🙏