​​Раз майлстоун, два майлстоун!🚧

Давно не выкладывал что-то практическое про проектное управление. "А их есть у меня".

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

Конечно надо учитывать свой контекст и приложенную мной таблицу можно и нужно обогащать особенностями вашего проекта, но если изначально в проекте стоит дедлайн то отталкиваясь от конечно точки "Go live" можно разумно заложить то количество времени, которое потребуется на каждом из этапов, чтобы понимать попадаете ли вы в сроки или требуется уже сейчас наращивать ресурс (inhouse|подрядчики) или резать скоуп. Жертвовать качеством не советую😏

Наш опыт показывает, что планирование таких ключевых точек позволяет достаточно эффективно управлять ходом проекта и вовремя тречить возникающие риски в части сроков.

Прикладываю сам шаблон

​​Про источник "вечной молодости" в работе
 
Что делать когда выгораешь от своей текущей деятельности (по причине приелась, а не финансовой неудовлетворенности, отсутствия возможности работы в коллективе и т.п.)😟
 
🟢 у меня был период месяцев 6, когда число "сухих" по нарративу и содержанию демо и отношение к команде было таким пресным (даже когда команда реально перфомила), что надо было сделать хоть что-то и я научился делать топовые презентации по результатам проектов для ТОПов. В какой-то момент я довёл мастерство до такого уровня, что когда в последствии кому-то в моём энтерпрайзе необходимо было сделать презы для конференций ко мне обращались за помощью в дизайне и ревьюинге. Так я прокачал скилл, когда выгорел от череды бездушных демонстраций проектов. А ещё бонусом приобрёл понимание, что не лучшие результаты проекта может вытащить крутейшая презентация, а восприятие даже самого лучшего проекта может прибить паршивая презентация а-ля "из 90х" стайл.
 
🟢 спустя 6 лет управления проектами с помощью каскадной модели мне настолько осточертел PMBOK, что я пришёл в Agile. Правда сначала узнал, что такое Jira, а потому уже что Jira - не Agile😅
 
🟢 последний год я стал активно проводить тренинги и консультировать бизнес вне ИТ потому что за 5 лет частично исчерпал себя (на текущий момент) в менторинге ИТшников.
 
🙌 Вывод: по мере работы уровень эмоционального заряда естественным образом снижается. Поэтому в начале ты с "полным баком" эмоций, а когда замечаешь, что пропадает страсть, не чувствуешь нужной энергии, то надо переключится на идею энтузиазма. Придумать в голове что-то непривычное, но в зоне достижимого, что способно стимулировать и придать энергию. Благодаря этому удаётся создавать и подпитывать ту энергию, которая должна быть внутри.

​​Ехал в поезде из МСК в СПБ 23 марта. Всю дорогу крутилась мысль. Про эволюционную прямую ответственности.

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

1️⃣ ОНО.
Евлампию 5 лет, бабушка бежит следом, он спотыкается и падает. Виноват пенёк, что появился тут на моём пути.

2️⃣ОНА/ОН
Евлампию 10 лет, бабушка уже не успевает за внучком, он спотыкается и падает. Виновата бабушка, что не придержала его, когда он побежал.

3️⃣ОНИ
Евлампию 25 лет, он бежит с цветами на свидание с любимой девушкой в знакомом парке, спотыкается и падает. Виновата администрация города, что так плохо ухаживает за парком, что тут пень посреди аллеи.

4️⃣Я!
Евлампию 50 лет и он бежит за маленьким сыном в родном парке, он (Евлампий) спотыкается и падает. Виноват Евлампий, потому что бежал невнимательно и сам виноват, что естественным образом встретился с препятствием.

5️⃣СУДЬБА
Евлампию 75, он счастливый старичок гуляет с палочкой в своём наполненном историей парке, спотыкается о тот самый пенёк и падает (без последствий для организма). Виновата судьба, которая сложила его жизнь так, что он вырос в том месте, где располагался парк в котором природа решила породить дерево, а потом от старости оно сломалось под собственным весом и остался только пень. Всё было предопределено.

Понятное дело, что возраст условный, потому что для кого-то "они" будут виноваты и в 50, а кто-то примет ответственность за собственное "я" уже в 6 лет. Уже не вспомню где видел статистику по дееспособному населению (вне привязки стран, менталитетов и культурных аспектов), но в возрасте 25-50 лет процент того, кого считает виноватым "во всех бедах" распределялся так.

Кто понял - тот понял.

Пояснение к опросу. Немного саморефлексии🙈 - кто меня лично знает пролистывайте сразу😂
Тут азы анализа жестов (несмотря на то, что красноречивее всего тут взгляд). Пальцы к губам - это разные категории значения: от принятия решения до скуки. А на фото это сигнал "я себя насильно затыкаю, чтобы тебя не перебить, хоть и страшно хочется". Это раз. А два - кроме моих, ничьих рук на столе нет. Можно оправдаться, что так было "удобнее", но на самом деле это сигнал-препятствие между участниками, я так показываю "я с тобой в корне не согласен".

p.s. дискуссия ведётся с крутейшим архитектором ИТ систем. Если интересно почитать/посмотреть про тайные техники влияния на ТОП-менеджмент, глубокий анализ различных систем и в целом как стать архитектором - ставьте тучу реакций, чтобы он завёл свой канал про дикий менеджмент😉😂

#AgilePartnership

Трудоустройство в IT-менеджменте за 1,5 месяца

EnterAgility 25 апреля запускают третий поток Карьерного Апгрейда для PM, Delivery и Scrum-мастеров и Agile-коучей — интенсивной карьерной программы, на которой помогут вам за 1,5 месяца устроиться на новую работу или решить любой другой карьерный запрос.

Решите свою карьерную задачу благодаря интенсивной работе с 8+ практикующими экспертами из отрасли — enteragility.ru/career_upgrade

По промокоду PRACTITIONER вы получите скидку в 15%!

Проинвестируйте в свое будущее и начните лето с новой работой! ❤️

​​Имею желание купить дом, но не имею возможности. Имею возможность купить козу, но не имею желания.

Проводили эксперимент с подведением итогов года по всем продуктам в компании (эдакое System Demo в эпоху до внедрения SAFe). После нескольких лет докладов с нескучным презентациями (как однажды выразился наш коллега на их тему - "воды столько - хоть дельфинов запускай"😂) решили изменить подход и провести gigaRetro в компании. Скрам мастера подготовили сценарий и понеслась…

Дальше случилось, то, что ожидалось - по сценарию инженеры (аналитики, тестировщики, разработчики) из разных команд рандомно встречаются в комнатах человек по 7 и… молчат. Нет, вы не подумайте мы не ошалевшие. Агенда была, вопросы, которые обсуждать в каждой комнате наводящие тоже были. Но в 10 из 12 комнат гробовое молчание.

Отсутствие доверия? Страх показаться глупым? Страх быть неверно истолкованными? Не знают что обсудить? - Пришлось раскачивать и создавать атмосферу доверия, чтобы разговор стартовал - фасилитаторы были полезны как никогда.

Посчитали, что стоимость встречи получилась ~50 000 за 1 час. Много это или мало? С точки зрения формирования доверия, знакомства друг с другом, обмена опытом и лучшими практиками - да вообще бесплатно.

Проблема ни в том, что ребята нет желания доносить свою точку зрения - они ПРОСТО НЕ ОБЩАЮТСЯ. По итогу вынесли несколько полезных инсайтов, например аналитики команды .Net позаимствовали практику написание юзер-кейсов у аналитиков команды 1С.

А вы считаете свой cost of meeting?

​​Канбан - он и в клинике канбан

На прошлой неделе сломал плечо - теперь я однорукий коуч😂 Опыт побудил меня сравнить качество обслуживания в различных клиниках и сопоставить его с работой в ИТ

1️⃣ Коммерческая клиника "Партнерство и Сервис"
Кто давно в канале знают, что мы с напарницей проводим тренинги, в том числе в сети коммерческих клиник, прививая сотрудникам клиники максимально клиентоориентированный подход, близкий нам самим. Важно не только качать hard skills в своих медицинских навыках, но и активно совершенствовать soft skills. Эмпатия и умение находить общий язык с пациентами - ключевые аспекты в медицине, как и взаимодействие со стейкхолдерами у ИТ - команд.

2️⃣ Травматология "Спешное обслуживание"
Попав в травматологию в два часа ночи, я был поражён оперативностью и эффективностью их работы. Всего за 15 минут мне сделали рентген, наложили гипс, дали заключение и вызвали скорую в больницу. Zero waste of time. Максимальное использование каждой минуты. Важно быть не только быстрыми, но и оставаться эффективными в стрессовых ситуациях, что актуально когда, например, несколько кросс-функциональных ИТ команд должны успеть зарелизиться в одно часовое окно.

3️⃣ Городская больница "Бюрократический лабиринт"
В этой клинике, хоть и не было долгих очередей, но процесс регистрации занял целых 30 минут, а забор анализов и ЭКГ - целых 3 часа. Заключительным аккордом стало общение с лечащим врачом, который, прежде чем озвучить диагноз, предложил мне заполнить гору бумажек и нецензурно наорал. Так что и в медицине и в ИТ, процессы и инструменты с лёгкостью могут перекрывать важность взаимодействия между людьми.

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

P.s. сижу жду ЭКГ. 3 часа ночи. Рядом дверь с надписью "Пациенты в критическом состоянии"🤯. Оттуда оры и крики - как в Resident Evil. Через минут 10 мимо оттуда выкатывают и прокатывают мимо меня на каталке абсолютно здорового, но бесконечно пьяного товарища, конечности которого привязаны к каталке 4 узлами и 2 медбрата со словами "Валера хорош уже выступать а то стукнем щас" увозят его на прокапывание физраствором. К слову его привезли после меня. Видимо, кто больше орёт - тому и сервис. Вот такой вот инцидент-менеджмент😉

PMBOK часто мешает адаптивности Agile, но кое-где может обогатить
 
Уже 2й год внедрили и используем метод освоенного объёма на проектах. Отлично работает как на кастомных проектах, так и внутри развивающихся продуктов. Всё ещё часто люди путают продукт и проект. Напомню, что проект - это не только про скоуп и сроки, но и про контроль за бюджетом. Мы пришли к управлению бюджетом с помощью этого нехитрого метода ввиду того, что поздно пить боржоми, когда проект провалился. Нужен был проактивный, а не реактивный подход. Когда можно работать с ожиданиями стейкхолдеров в разрезе недель, а не месяцев с момента старта проекта. Спасибо @alexandraizusina Саше, нашему PM и RTE, которая довела шаблон до удобства использования на любом самом лютом проекте💪🙏
 
Простыми словами - это метод анализа всего объёма на проекте по отношению к плану и стоимости его выполнения. Благодаря ему можно оперативно анализировать отклонения от изначального плана и на основании обратной связи принимать управленческие решения.
 
Короче, чтобы не глядеть в бюджет своего проекта как коза в афишу - юзайте😉

​​Про обратную связь

Давать обратную связь команде, руководителю, на 1-1 с сотрудником нужно обязательно. Это один из ключевых способов скорректироваться и прийти к улучшениям. Про подходы к обратной связи в форматах COIN, "сэндвичей" и прочих говорено немало. Примеров мало. Вот реальная история из жизни Довлатова как НЕ надо давать позитивную обратную связь. Хотя событие было в крайней степени этого достойно.

"Лет десять назад я спас утопающего. Вытащил его на берег Черного моря. Жили мы тогда в университетском спортивном лагере. Ко мне подошел тренер и говорит: "Я о тебе, Довлатов, скажу на вечерней линейке".
Я обрадовался. Мне нравилась гимнастка по имени Люда. И не было повода с ней заговорить. Вдруг такая удача. Стоим мы на вечерней линейке. Тренер говорит:
"Довлатов. шаг вперед! "
Я выхожу. Все на меня смотрят. И Люда в том числе. А тренер продолжает:
"Обратите внимание! Живот выпирает, шея неразвитая, плавает, как утюг, а товарища спас!.. "
После этого я на Люду и смотреть боялся."

Не будьте как тренер😉

​​Какую культуру вы могли бы построить?

Давно не выкладывал практических упражнений.
Что там с ледоколами и энерджайзерами для ретро или стратсессий?😉

Представьте, что вы отправляетесь в путешествие, и у вас есть возможность взять с собой до 5 бумажных книг. Это могут быть ваши любимые произведения или просто случайные книги, которые давно привлекали ваше внимание: "желанные к прочтению". Можно как художественные так и нон-фикшн литература. Какие книги вы бы выбрали? 📚

После того как участники зафиксировали на стикерах перечень книг даём задание:

Та-дам! Во время вашего отдыха на пляже происходит глобальная катастрофа. Большая часть человеческой цивилизации и её истории исчезает. Вы и ваши книги становитесь одними из немногих выживших. Именно по этим книгам потомки будут восстанавливать культуру погибшей "Атлантиды". Конечно, вы не могли предвидеть это, укладывая свои вещи, но теперь надо воссоздать цивилизацию🤔 А дальше повествование кто что выстроил из своих "книжных" стройматериалов?😁

​​Искал намедни в компанию Delivery Process Owner. Не взяли, но то уже другая история. Почему такое название роли тоже отдельная песня, но для понимания у нас это Delivery Lead с обвесом из оргизменений.

Пересмотрел больше 20 кандидатов. Хочу рассказать о портрете кандидата, если раздумываете занять роль Delivery Manager, Release Train Engineer и иже с ними кто вместе с вами в поисках?

🔸 Опыт работы 7+ лет
🔸 Отличное понимание Software Delivery Life Cycle
🔸 За плечами опыт работы руководителями проектного офиса, релиз менеджера и некоторые даже имели опыт CEO
🔸 Опыт People Management присутствовал у большинства (у кого-то это ПМы, к кого-то скрам-мастера, но инструментарий управленца прослеживался)
🔸 Понимание (не путать со знанием) моделей Koттера и ADKAR
🔸 Ожидаемая зарплата варьировалась, но в среднем по больнице запрос 400+ на руки

Ещё пара штрихов:
🔻 Лучше уметь решать практические кейсы, чем идеально знать теорию - очевидно же, да?! Но не всем.
🔻 Люди и взаимодействие ВАЖНЕЕ процессов и инструментов. Но это не означает, что процессы и инструменты не нужны вовсе. У некоторых кандидатов была настолько зашкаливающая эмпатия, что не представлялось а как они вообще вступают в конфликт с тимлидами/руководителями/ТОПами когда требуется менять процесс.

P.s. Самое идеальное собеседование было начато самопрезентацией 4,5 минуты. Не шучу! Чувак за 4,5 минуты рассказал о крайнем опыте и я уже было дело подумал, что пора сворачиваться, но тут (как на некоторых докладах в конференциях самая мякотка начинается в вопросах) пошло общение на 55 минут о деталях кейсов и практических примеров разрешения гаммы производственных вопросов в деливери разработки. Я получил истинное удовольствие от интервьюирования человека, что не часто встречается на собеседованиях. Тот случай когда ты не просто ищешь кандидата, но и можешь научиться чему-то новому. Так что встречают по времени самопрезентации, а провожают по глубине понимания профессиональных навыков и опыта😉 Не бойтесь быть лаконичным. Краткость - сестра таланта)

​​За тёмным порталом ценности

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

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

Это всё прекрасно работает:
💸 Когда у компании овермного денег на то, чтобы идти первейшим (не всегда лучшим) путём
🔮 Когда владелец продукта не визионер, а = тимлид/передаст полученных задач от бизнеса в команду
🔬 Когда Business Owners (если говорить про SAFe) имея самые разные возможности в арсенале: изменить бизнес-процессы, поменять оргструктуру или даже поток создания ценности следуют проторённым путём и автоматизируют всё, что автоматизируется.

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

Всегда найдётся место улучшениям

🏎 Шумахер в начале 90х настоял, чтобы ему установили в болид 3!!! спидометра.
Над ним все посмеивались ведь в то время гонщики королевских гонок использовали для контроля скорости только тахометр.

В итоге он использовал центральный спидометр для реальной скорости. Левый - для предыдущей минимальной скорости прохождения поворота. Правый - для предыдущей максимальной скорости прохождения поворота. Тем самым он управлял данными в 2-х измерениях с опережающими и реальными показателями и мог контролировать и нащупывать точку предела при торможении и разгоне авто на каждом из поворотов каждый круг.

Выводы:
🔻 найти улучшения можно даже когда уже годами в индустрии всё работает хорошо
🔻 не бойтесь быть новаторами
🔻 гипотезы можно и нужно проверять
🔻 одного индикатора может быть недостаточно для того, чтобы понимать достаточно ли мы эффективны
🔻 добейтесь как можно более быстрого эффекта и команда поверит в полезность action points, а за ней могут потянуться и другие
🔻 работа с опережающими показателями сложна, но даст выдающиеся результаты при грамотном использовании (ведь запаздывающие используют все, а у вас будет преимущество)

Спринт не тот каким кажется🌚

Зафакапили очередной спринт и начинаем 20 минут на ретро спорить, что задача X должна была быть аж в 13 сторипойнтов, а мы оценили в 5 и в этом вся наша проблема. Надо тестировщику Паше оценки правильные ставить! А лучше, чтобы PO Вася оценку да по максимальной шкале - сразу в 21! А ещё лучше, чтобы эти щеглы из бизнеса могли бы и потерпеть! Мы ж тут для них качественную фичу всей командой стараемся сделать!

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

Порой у команд уходит бОльшая часть энергии на то, чтобы работать с возникшими ошибками (читай за спор в переоценке элемента бэклога), вместо того, чтобы достичь технического мастерства. Посчитайте как часто мы инспектируем на ретро то, что не получилось относительно возможностей осуществлять эксперименты, рисковать, достигать совершенства. Другими словами работаем с запаздывающими показателями вместо того, чтобы работать с опережающими (подробнее об этом можно почитать у Стивена Кови в книге "Как достичь цели. Четыре дисциплины исполнения" и пример в моём предыдущем посте). Даже теорема Пифагора имеет около 300 вариантов решений, поэтому команда не должна крутиться только вокруг проблем спринта. Безусловно решать возникающие проблемы нужно, но не зацикливаться только на них. Тогда команда сможет смотреть видеть дальше проблемы оценки задачи X. Но конечно это всё возможно при определённом уровне зрелости. И в этом одна из задач агентов изменений, чтобы создавать команде условия для такого роста. На эти размышления натолкнуло когда перечитал книгу "Turn the ship around".

"Немного руля вдали от скал гораздо лучше, чем много руля вблизи скал"

В чем эффективность агента изменений

Системный администратор и скрам-мастер не нужны когда всё хорошо. Как только плохо они сразу же виноваты и резко нужны.

Вспоминаю как директор постоянно спрашивал: Как померять твою эффективность? За что мы платим тебе деньги? (кстати, один из популярных вопросов на собеседовании на скрам-мастера).

И ты придумываешь себе тучи метрик, чтобы продемонстрировать свою эффективность. А метрика лишь одна:
незрелая команда => расти, незрелый PO => расти, организация нуждается в коучинге => расти, организация нуждается в scaling => расти

Как только зрелость на любом из уровней вырастет в norming-perfoming по условному Такману - как правило зрелость участников позволит самим эффективно делать эмпирические выводы о своей деятельности. Дальше агент изменений всё. Остаётся выбор или высасывать себе задачи по изменениям из пальца или искать новые вызовы.

P.s. есть ещё одна похожая роль - директор по цифровой трансформации. Как говорил один знакомый CDTO: "моя задача в том, чтобы пока все наши конкуренты поднимаются по ступенькам на 1й этаж, мы поднялись на лифте на 3й с помощью цифровизации процессов. Эффективность моей работы будет заключаться в том, что я должен уйти через 3 года". Случается, что при этом за целый год не рождается ни стратегии ни хотя бы ступеньки, хотя человек уходит, да😂

Кстати, картинка от Игоря Ларченко почти в тему поста😂

Возможно, именно поэтому Agile Leadership - это не про менеджмент, а про лидерство?