Незримый рост

Тяжело отпускать. Потому что:

👎 хочешь сделать сам
👎 потому что у тебя получается
👎 потому что уверен, что хорошо сможешь только ты
👎 потому что другие не смогут также хорошо как ты
👎 потому что ты умеешь, наконец

...величайшее заблуждение руководителя😂

На прошлой неделе произошло ужасно прекрасное событие скрам-мастер в личке сказала мне на одной из командных встреч, что меня много и не мешало бы помолчать (без пассивной агрессии)😉 Даша, спасибо, за озарение🙏

Наверно, это лучший показатель роста сотрудника, когда он останавливает руководителя и доводит встречу до нужного команде результата...

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

В начале моего пути как РП стояла задача овладеть хард скиллами (aka PMBoK, PRINCE2). На следующем этапе - овладеть софт скиллами (коммуникации, лидерство, фасилитация и др.). Новым уровнем пару лет назад стало желание понять ценности каких компаний мне близки и какими проектами я хочу/не хочу заниматься потому что это идёт в разрез с моими ценностями.

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

Описанное выше - это только база, а есть не менее важные вещи:

👍 уметь выстраивать нетворкинг
👍 уметь в сторрителлинг
👍 критицизм
👍 эмпатия
👍 гибкость
👍 растить лидеров, а не последователей (спасибо @scrumbatya и @anyapavliuchenko за книгу "Turn the ship around")

Для себя понял, что быстрый (не путать с легким😂) путь научиться доверию - это чтобы те, с кем ты работаешь учились тому, что плохо или вовсе не знаешь ты...в таком случае у тебя не остаётся выбора как довериться человеку и всячески саппортить его успеху (но не мешать!).

Вдохновляющим примером для меня является адмирал Риковер - "отец" атомного флота, США, которому приписывают фразу..."Если подчинённый всегда соглашается с начальником, то он бесполезная часть организации".

Имел удовольствие попрактиковаться с коучами скрам-трека Настей Бутовой-Никишиной и Серёжей Липчанским.
Всё это "под соусом" золотого бейджа от ScrumTrek. Но мне был интересен не бейдж.
Люблю решать сложные кейсы и должен признать, что процесс выстроен достаточно интересным образом. Сначала надо пройти тест, потом написать эссе по 2м кейсам с командами (кейсы максимально ситуативные - примерно как встречал на сдаче PMI-ACP).

После успешного выполнения - практическое интервью с 2мя коучами на 4 темы:
📌 Продемонстрировать опыт успешной работы с командой
📌 Продемонстрировать опыт успешной трансформации компании
📌 Умение в коучинг/менторинг
📌 Умение результативно работать с большой аудиторией

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

Когда Серёга вжился в роль неуступчивого вредного PO, конфликтующего с командой в кейсе с коучингом пришлось попотеть)) Вспомнил свои самые сложные кейсы с реальных ретроспектив. Думаю, что в реальной жизни удалось бы решить проблему но не за 3 минуты как на тестировании и не факт, что коучинговым способом😉 благо на это у СМа ещё 7 шапок😉

Однозначно советую попытать свои силы с разными экспертами, чтобы всесторонне оценивать свои скрам-мастерские силы.

Ну, а я осветил себе дальнейший путь для обучения - надо больше погружаться в коучинг.

​​Часть корабля - часть команды!

На прошлой неделе наша команда провела двухдневный командообразующий тренинг для руководителей одной из компаний.

Самое любимое, что ещё до тренинга изначально всё пошло не по плану🤪

🤦‍♂️ поменялась цель. К нам пришли с классическим запросом: "внедрите нам аджайл и покажите как оценивать проекты в попугаях"
🤦‍♂️ произошел форс-мажор, который вынудил перенести тренинг на неделю
🤦‍♂️ такие мелочи как ручки, которые не пишут и стикеры, которые не клеят уже даже не считаю за проблемы, это сопутствующие потери🤓

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

В этот раз тренинг было решено провести в сеттинге экипажа викингов на Драккаре.
За своё путешествие команде было предложено пройти испытания на:

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

Отметил интересные моменты:

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

⚓️ в упражнении про коммуникации когда надо было ответить на вопрос: "Мне ЛУЧШЕ всего работается когда…" добрая половина участников в своём повествовании заменила слово лучше на "ПРОЩЕ/УДОБНЕЕ". Лучше - это про то, что побуждает двигаться вверх, окрыляет, мотивирует, а проще/удобнее - это что-то с душком демотивации - лишь бы от меня отстали и не трогали☹️ Любопытно, как люди в процессе упражнения неосознанно подменяли эти понятия.

Яркие фразы, которые запомнились с тренинга:

💥 Деньги - это коэффициент свободы
💥 Я люблю умничать, а если за это ещё и платят хорошие деньги, то это вдвойне круто!😉
💥 ОС бесполезная трата времени, если ничего с ней дальше не делать
💥 Под обратной связью некоторые подразумевают тотальное уничтожение личных границ, ну что поделаешь, будем надеяться, что когда-нибудь они все умрут🤣
💥 Важно правильно подбирать слова. "Помощь" и "поддержка" - разные штуки. Поддержка - это про психолога/инструктора по вождению. Помощь - это про то, что сделают за тебя.

В качестве полезного для себя "унёс с тренинга в рюкзачке" книгу на почитать:
📚 "Компас эмоций. Как разобраться в своих чувствах", Илсе Санд

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

@Cat_with_your_camera, спасибо за проделанную работу до, во время и после тренинга! Это было круто!🔥👏🤝

#полезное in English

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

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

📌 Интересный взгляд на роли, когда случается несправедливость: жертва, вредитель, лидер или тот, кто вступается. В том числе описаны паттерны поведения как следует поступать той или иной роли.

📌 Культура обучения через ошибки:
🔹Рассматривать инциденты как возможности
🔹Поощрять обмен знаниями
🔹Рефлексировать

📌 Как уволить чайка-менеджеров😂. А если честно, то селфчек как понять, что ты сам "не там" и что с этим дальше делать, если вдруг ты один из них?

#непропроекты Эмоциональное ностальжи от книги к ИИ

Пишу это лично соприкоснувшись со скайнет чатом ЖоПыТи😂. Возможно кто-то из олдфагов поймает себя на мысли, что тоже касались этих вещей.
 
⛩ 1991 - Книга "Энциклопедия профессора Фортрана" - получил первые знания о ПК.
 
⛩ 1992 - Сыграл в первую игру - гонки Grand Prix Circuit на ламповом 386м с кнопкой TURBO для "разгона процессора"😉
 
⛩ 1993 - написал свою первую программу на Turbo Basic. Результат был гораздо приятнее процесса, что предопределило быть проджектом, а не усидчивым разработчиком или продактом😊 В следующий раз с TB я столкнусь 16 лет спустя в центральном командном пункте ВМФ, только над системным блоком будeт висеть не плакат с выдержками из книг по программированию, а топор с надписью "уничтожать в первую очередь" - не шутка если что🤯
 
⛩ 1994 - Warcraft/Doom не могу разделить эти игры. Они перевернули мой детский мозг. Стратегия в итоге победила, потому что в Doom было по-просту страшно играть в 6 лет, даже если очень хотелось😂
 
⛩ 1997 - Photoshop 4.0. Это сейчас редактирование фотографии на телефоне так же просто, как отправить сообщение в телеге, а тогда возможность отсканировать на сканере черно-белое семейное фото и раскрасить в цвет казалось магией сродни сегодняшним картинкам нарисованным искусственным интеллектом.

⛩ 1999 - HoMM3. Будь проклят тот день, когда я сел за баранку этого пылесоса попробовал сыграть в Герои меча и магии 3 в первый раз😂. Не зная, что надо нажать кнопку "следующий день" закрыл игру как самую бесполезную в мире. Зато позже, когда распробовал - для меня это самая долгоиграющая и прокачивающая оперативную память мозга до сих пор (кстати, на тему развития объема нашей рабочей памяти мозга, можно посмотреть вебинар Ивана).
 
⛩ 2002 - собрал первый собственный ПК. Поразило то, что в одном устройстве могут быть: ПК, "видеомагнитофон", "музыкальный центр", обработка видео с VHS-камеры, можно писать музыку через аудиокарту с MIDI-клавиатуры Это казалось пределом того, что вообще когда либо смогут технологии😂 P.s. есть кто помнит ламповый Winamp😉?
 
⛩ 2007 - "точка невозврата"😊 Узнал, что можно получить сертификат Microsoft, если пройти обучение и сдать сертифицированный экзамен. Для курсанта военной системы казалось нереальной фантастикой и предопределило, что теперь ПК должен стать профессией, а не игрой.
 
⛩ 2017 - познакомился с управлением проектами в разработке ПО и Agile (спасибо Антону и ребятам той команды).
 
⛩ 2023 - опробовал chatGPT. Теперь уже профессии будущего не просто не за горами, а прямо "на ходу" можно начинать учиться - промпт инженер, детектив отпечатков ИИ-интеллекта в тексте, копирайтер у ИИ и т.д.
 
Каждый раз - это неподдельная эмоции от соприкосновения с чем-то, что открывает для тебя мир по-новому.
 
Когда писал задумался как забавно, что чем взрослее становишься, тем всё большие перерывы, когда какие-то события могут тебя поразить, но хорошая новость: по-прежнему могут!🙏🔥
 
А как твою жизнь 🫵 перевернули информационные технологии? Размышляли, что может появиться в будущем в сфере ИТ?

#полезное in English

📌 пособие для развивающихся лидеров о том, как можно разрешать сложные ситуации используя структуру: ("Вероятно", "Только", "Может быть", "Возможно"). Примерил как бы я разобрал пару своих недавних и сложных кейсов - оказалось действительно можно посмотреть на ситуации под другим углом используя этот метод.

📌 И снова про метрики😉 В статье описаны 3 метрики качества: внешнее, внутреннее и качество процессов. Понравилось, подчёркивание автора, что важно измерять внешнее качество (то, как пользователи воспринимают продукт), хотя это как правило сложно и частенько на это забивают. А зря, ведь именно здесь "зарыта собака" спрятана ключевая оценка ценности продукта!

📌 Очень плохие компании измеряют Velocity каждого отдельно взятого разработчика команды, плохие компании измеряют Velocity команды. Хорошие компании дают право самим командам измерять и управлять Velocity своей команды. Статья для чего на самом деле нужно измерять Velocity. Не ново, но содержательно.

📌 Что часто представляет продакт когда речь идёт о видении продукта? - Roadmap на год вперёд в Jira, MS Project, Wrike, Excel (нужное подчеркнуть)? А между тем - это прежде всего про пользовательский опыт и мечту. Текст с примерами того, как выстроить видение для продактов и владельцев продуктов

SAFe'вые вопросы

Истёк 4й месяц как запустили SAFe в компании и заканчивается 3й Program Increment.
 
Возможно есть среди подписчиков те, кто задаются схожими вопросами на старте масштабирования поэтому решил поделиться. Во многом с ответами мне помогли разобраться эксперты SAFe: Сергей Рогачёв, Алексей Ионов и плотный нетворкинг на Agile Days '23. Но важно, чтобы ответы искались отталкиваясь от контекста твоей организации.
 
❓ Сколько уровней SAFe нужно внедрять? Все? Один? (мы стартовали до уровня "Solution" включительно, но сейчас он видится 5м колесом в телеге)
🤲 Начинать можно с любого числа уровней и выстраивать следующие по мере готовности менеджмента.

❓ RTE (Release Train Engineer) - это больше эдакий Grand Scrum Master или Руководитель проекта?
🤲 RTE ближе к РП, чем к SM, а ещё вернее ближе к Delivery Manager (недавно, кстати, у Лёши Пименова вышло видео с интервью от первого лица работающего в этой роли). Почему так? Потому что SM отвечает за процесс работы кросс-функциональной команды. В этом смысле SM не очень сочетается с ролью RTE, т.к. состав ART может меняться походу движения в SAFe, поэтому достаточно сложно выстраивать процесс, когда команда непостоянна на дистанции и у неё может меняться фокус в направлении своего движения.

❓ Обязательно ли нужно внедрять enablers как элементы системы, если логика enablers заложена в других элементах: тасках, спайках, арх задачах и т.д?
🤲 Самый спорный ответ, но тем не менее. Enablers нужны для того, чтобы на всех уровнях бизнеса не объяснять ему как раз детали всех сопутствующих типов задач, а послать в тот самый САЙТ. В итоге всё зависит от того, а насколько эджайловая у вас организация? - Уровень maturity наших стейков таков, что они в теме разрабатываемых элементов, поэтому пока отказались от энейблеров.

❓ Кто должен приходить на System Demo: Business Owners или ТОПы? И как завлечь ТОПов, если их участие очень дорогое, да и не сильно хотят участвовать (при этом нам это нужно, т.к. пересекаются зоны их управления и необходимо работать с конфликтом интересов)?
🤲 Можно начинать с ключевых стейкхолдеров, коими являются BO и потом постепенно привлекать заинтересованных ТОПов, но не всех разом. Можно сделать несколько System Demo по бизнес-направлениям (например: продажи, закупки, бэкофис и т.д.)

❓ Может ли Business Owner быть ИТ-бизнес-партнёром (эдаким Grand PO)?
🤲 Может, но у него должна быть мотивация (по-простому: получать бонус от того, что он участвует в развитии своего бизнес-направления). Если BO выполняет функцию передающего в команды звена того, что хочет ключевой стейкхолдер или ТОП, то фактически к нему приходят не с проблемой, а с решением, что сильно сужает его возможности в реальный вклад развития бизнеса со стороны ИТ команды.

Весело едем дальше🚅

​​#непропроекты работа на конфе
 
Люди, которые на конференциях не только слушают доклады существуют!
Предлагаю чек-лист как действую сам с первой конференции (ITSMf в 2011) и помогаю другим коллегам эффективно работать с профильными конференциями.
 
☑️ определить зачем тебе участвовать?
🏃не бывал ранее
🏃компания платит, что ж мне отказываться?😏
🏃виски-пати
🏃нетворкинг
🏃потребность узнать что-то новое
🏃решить проблемы, с которым сталкиваешься в работе

☑️ если едет команда - сделать общий чат в телеге, где нужно обсуждать дальнейшие пункты. Мы обычно делаем файлик в облаке для общей работы с ним до/во время/после конфы (пример в аттаче)

☑️ узнать кто спикеры, какие будут темы, и главное: какие проблемы, возникающие в твоей деятельности могут быть закрыты благодаря посещению конференции

☑️ если мероприятие проходит в формате параллельных активностей, то заранее сформировать уточнённый список докладов/воркшопов на которые хотите сходить (на самом мероприятии на это часто не остаётся времени)

☑️ подготовить какие вопросы и с кем из спикеров/участников ты хочешь проработать

☑️ иметь "план Б", если что-то пойдёт не так, а всегда идёт🙏! (например, на последней конфе не приехало 2 спикера, с которыми планировал обсудить LeSS, а один интересующий доклад просто сняли с ростера)

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

☑️ применить полученные знания внутри компании через план "кто - с кем - когда - ожидаемый результат"

☑️ профит!

А какая была ваша первая профильная конференция🛫? Было интересно/полезно? Делитесь в комментариях🙏

И снова про T-shape и доверие

Классный пример работы T-shape команды показала недавно Metallica на шоу Goward Stern.
Ребята рассказывают пример того, как создавался их самый известный риф для "Enter Sandman"🎧.

Как Кирку Хэммету (🎸) в 3 ночи пришла в голову идея риффа, а Ларс (🥁) предложил: "а ты можешь добавить сюда ещё это и вот это?" Забавно, что ребята даже дали название тому, что они придумали: "3 повторения с хвостом".

Ларс не умеет играть на гитаре, но он сказал Хэтфилду (🎸): "сделай аранжировку того, что придумал Кирк, но в другой тональности!

Хэт говорит: "что я бы этого не сделал, я бы даже не додумался до такого, потому что я не делал такого элемента игры в принципе!" Но при этом он ответил Ларсу: "Хм, я никогда это не делал, но дай мне 1 день, я немного поработаю над задачей и вернусь с проверкой твоей гипотезы".

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

Когда погружаешься в деятельность другого и это никак не повлияет на ваши взаимоотношения - это и есть свобода в доверии. И таких вещей много: как помогать, подсказывать друг другу, когда ты сам не сильно в теме вопроса.

Как часто мы слышим вопрос (особенно начинающих команд) как я могу оценивать разработку я же тестировщик??? Как я могу оценивать аналитику я же разработчик??? Когда у вас есть единая цель - создать классный продукт, когда все вовлечены и УВЛЕЧЕНЫ этой идеей, то не будет стоять вопрос "как я могу?" - будет вопрос - "а что я могу сделать чтобы тебе помочь?"

❗️ P.s. а для тех, кому нужно обличить субъективные показатели доверия в math-friendly делюсь статьёй, которой поделились сегодня со мной☺️ Интересно как оказывается можно вывести уравнение доверия.

​​#пятничныйюмор или нет🤔😂

Наконец-то решена извечная проблема фасилитаторов на онлайн-встречах по поводу "хочу/не хочу включать камеру!"😂 Не знаю как насчёт другого софта для видеовстреч, но в MS Teams добавили функцию аватаров, которые можно активировать не включая камеру! При этом аватары достаточно реалистично подстраиваются под то, что говорит человек. Отличный компромисс для тех, кто не готов включать камеру.

+ 1 новый айсбрейкер для тех, кто пробует эту фичу впервые👍

Геймифицируй

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

Его проект заключается в том, чтобы считать ключевые показатели и "важнейший KPI".
Ключевые показатели достаточно базовые для тех, кто знаком с проектным менеджментом от PMI:
🕐 SPI (Schedule Perfomance Index) - насколько мы в сроках проекта
💲 CPI (Cost Perfomance Index) - насколько мы попадаем в бюджет
👨‍💻 Useful Time - насколько утилизируется время непосредственно на работу с тасками, а не встречи, youtube, бла-бла и прочий waste.

💎 Важнейшим KPI он определил - количество инноваций, которые будут реализованы и востребованы конечными пользователями (да, в составе команды в том числе продакт, который делит успешность запуска потенциальных инноваций наравне с командой разработки)

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

В процессе изучения попалась занимательная статья про долг по Velocity (раньше даже не сталкивался с таким термином, не Velocity конечно😁, а долгом по нему). Пусть статья "продающая", но она стимулирует подумать о таких интересных показателях как:

📌 Годовой оклад команды (надеюсь, считают все, кто задумывается об эффективности работы команды)

📌 Opportunity Cost Ratio - ценность, которая производится сотрудником на единицу оклада, которая должна быть больше, чтобы оправдать найм (а это уже интереснее)

📌 Накладные расходы на долг по Velocity (% времени, который можно было бы потратить с долга по Velocity на создание новых фич, которые несут ценность)

У кого-то был опыт геймификации процессов в компании? Поделитесь опытом, если так.

#полезное in English

Крутая статья от Романа Пихлера про Product Delivery и Scrum.

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

⭐️ вдохновляющим видением продукта для команды
⭐️ утверждённой продуктовой стратегией
⭐️ ориентированным на достижение продуктовой цели дорожной картой
⭐️ показателями успешности продукта
⭐️ бизнес-моделью как твой продукт может быть потенциально монетизирован

И раз уж мы говорим про развитие продукта в догонку ещё одна статья с наводящими вопросы как сформировать дорожную карту. Ты не продакт с богатым опытом? У тебя инхаус разработка? Как не превратиться в того, кто просто работает как заводик по перевариванию решений, который приносит бизнес?

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

#полезное in English

1. Крутейшая статья про то, что деньги - самая лучшая форма обратной связи!💸🗣
Как часто команда считает во сколько она обходится компании? Имхо, извечный вопрос: "а нам стоит делать фичи для бизнеса или заняться рефакторингом и сделать архитектурные задачи?" во многом будет восприниматься командой в другом ракурсе, если участники не только оценят субъективные факторы влияния на продукт, но и то во сколько обойдётся реализовать архитектурное решение или сколько компания не досчитается, если в продукте своевременно не появится новая фича.

2. Не менее увлекательная статья про то, как представить вашу деливери команду не в качестве заводика по производству фичей, а как райский сад, куда вашим клиентом стало бы интересно ходить. Сразу вспомнилось насколько сильно оказывает воздействие мышление людей с недавнего тренинга, когда люди "ЛУЧШЕ" заменяли на "проще"/"удобнее". Мышление имеет значение! И вряд ли получится создать команду, которая вдохновенно будет заниматься развитием своего продукта, если это будет команда разработки, которая думает лишь о количестве сторипойнтов и выполненных целях спринта, а не о том, как сделать так, чтобы целевой аудитории нравилось заходить в продукт🤩

3. Не новьё, но повторение - мать учения про путь к психологической безопасности:
👌 проявлять самим и позволять другим проявлять уязвимость
👌 принимать неудачи, но делать уроки из произошедшего
👌 активно слушать
👌 рассматривать конфликт как путь к сотрудничеству

#AgilePartnership

EnterAgility 1-2 июля проведут свои последние тренинги Professional Scrum Master I / Professional Scrum Master II 😊

EnterAgility обучили больше 100 агентов изменений, успейте и вы присоединиться к тренингам, которые позволят вам получить и освежить знания по Scrum и получить престижные международные сертификаты от Scrum.org, которые подтвердят ваши знания!

А по промокоду PRACTITIONER вы получите скидку 3000 рублей!

PSM I: enteragility.ru/psm_1
PSM 2: enteragility.ru/psm_2

​​Есть ли проджект менеджмент после Agile?🤔

Погружал сегодня нового РП в Agile Project Management. Интересно наблюдать как эксперт, работавший исключительно с предиктивными проектами, пытается разобраться как управлять проектом при помощи гибких подходов.
 
Самое первое, что бросается в глаза: человек "ищет привычное" - точку опоры👀. Сторипойнты пытается сразу понять как перевести в часы, а диаграмму сгорания примерить в подобие диаграммы Ганта. Словом мы стараемся ухватиться за привычное, чтобы хоть как-то чувствовать уверенность или усилить понимание🙏. Но конечно самое сложное - это поменять мышление. Собственно не случайно Agile обзывают философией, а не методологией. Недостаточно взять и натянуть имеющиеся инструменты в Scrum, Kanban, Crystal Clear и т.д. чтобы заработало. Требуется ПОВЕРИТЬ (не путать с карго-культом😁). Перестроить себя. Особенно это сложно для людей, пришедших из command & control организаций. Да ещё и в нашем случае компания продуктовая, что создаёт дополнительный челлендж для менеджера проектов ведь приходится балансировать между проектом и продуктом, PM и PO и т.д.
Но дорогу осилит идущий😊
 
Для меня в своё время стартовой ступенью шифта в Agile Project Management стало переосмысление проектного треугольника. В "классике" он состоит из рамок проекта, сроков и бюджета.
Проектный же треугольник в Agile - это ЦЕННОСТЬ, качество и ограничения. Ключевым становится максимизация ценности проекта с достаточным качеством, при этом мы по прежнему работаем с рамками, сроками и бюджетом (в ограничениях).
 
Хохмой дня стала моя попытка максимально жизненным примером объяснить смысл сторипойнтов😂. Думал пример с разными сценариями (сложности, объёма и рисков) сбора урожая на банановой 🍌🍌🍌 плантации привести в шутку, а оказалось, что человеку именно на таком примере наилучшим образом стало понятно как работать с относительной оценкой. Так что не надо "вот этих вот ваших" написать интеграцию с апишкой или запилить кнопку на фронте за 3SP. Чем материальней пример тем понятнее🌎
 
В очередной раз убеждаюсь, что при создании атмосферы доверия в командной работе, казалось бы из глупой идеи (или шутки) можно получить пользу🔥

#AgilePartnership

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

❗️ И сразу в догонку отвечаю на появляющиеся вопросы о том, что начал монетизировать канал. Нет и еще раз нет, канал по-прежнему не монетизируется и не делает платных реклам. Публикую партнёрские ссылки про обучение и работу только по собственному желанию и возможности продвигать сообществу полезные ресурсы.

​​Смена цели на встрече не проблема😉

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

В этот раз решили использовать известную технику (6 шляп мышления Эдварда де Боно), но нестандартным образом. Зачастую её используют как взгляд с разных сторон на все условия для принятия решения, но мы адаптировали её для того, чтобы устроить брейншторминг новых идей.

Как всегда по ходу сессии вскрывались интересные моменты:
👒 Белая шляпа (где только факты) посыпалась откровенной критика идей и когда фасилитатор об этом подсвечивал слова просто подменялись, но их суть оставалась😂 Зато участники научились адаптироваться😉
- "Надо перечеркнуть всё вышесказанное и признать, что мы не занимаемся бизнесом"
- "Мы не в бизнесе как факт" :)

⛑ Красная шляпа (эмоции):
- "Ну, во-первых у нас не так всё плохо, как в первом раунде"
- "Ты что плачешь?"😅

🎩 Черная шляпа (критика):
- "Разрываюсь, как будто на плечах слева (на стадии продаж) сидит чёртик, а справа (на стадии реализации) ангелочек"
- "Ну, да! Продали, а потом надо делать, а денег уже нет"🤷‍♂️

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

🟣 верифицировать результат внутри компании, включая перестройку процессов, т.к. ребята задваивают работу в программах только потому что надо кому-то другому предъявить показатели (закон Гудхарта в действии)
🟣 монетизировать свой продукт для клиентов

Остальное стало "удобрением" для формирования дорожной карты по достижению этих 2 целей.

🪖 Зеленая шляпа (креатив):
Реальная генерация идей началась только спустя отведенные (как для других шляп) 10 минут, но это тот самый случай, когда не жалко использовать резерв времени.

А ещё разящим отличием от генерации идей IT командами (например, на ретро) стала лютая вовлечённость участников в улучшение процесса и генерацию идей. Ребята думают как заработать деньги компании, а не "работу работать". Как ни странно, но это тоже про адаптивность. Некоторые руководители предлагают убрать agile, забить на ценностную составляющую в пользовательских историях и пусть просто работает конвейер по переработке задач. Таким образом гасится минимальная вовлеченность в то, для чего вообще ИТ-команды делают новые фичи.

Вторым полезным моментом мероприятия стало сближение с бизнесом и его ожиданиями от IT команд.
Звучали фразы:
☝🏻"Быстрее делайте задачи, а не занимайтесь стратегией"
☝🏻"Раньше, чем через полгода всё равно от этих айтишников не дождешься новых фичей в наших продуктах"

Вот такой коленкор. Полезно быть не близко к клиенту, а в гуще процессов клиентов, когда он вообще не говорит про ИТ, а говорит только про бизнес. Отрезвляющий опыт.

В своё время, благодаря @ADeryushkin заинтересовался темой мотивации команд в Agile среде.

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

В высоком качестве 👆🏻