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 - это не про менеджмент, а про лидерство?

#AgilePartnership

🚨 🗣 Эй, руководители проектов вы тут?) Кто давно задумывается о росте в горизонталь и вертикаль?)

Вчера пообщался с коллегой, которая ищет сильного менеджера, который сможет зачемпионить крутой проект/процесс/стартап в ТОПовой компании💪

Немного про вакансию:
✨ Менджер по развитию бизнеса
✨ Avito. AVITO!!!!
✨ Стартапное направление
✨ Отрасль Sales + IT
✨ Москва/Спб

🤲 Более детально ознакомиться с вакансией можно по ссылке.
📨 Для желающих присылайте свои CV Кате @ekaterina_peterson🙏

Рекомендую от души. Пошёл бы с удовольствием сам, но моё ❤️ уже занято😉

И снова про наши любимые оценки.

Опустим ситуации, где команда зрелая и умеет в прогнозирование загрузки своей работы (отличает 3 от 5😁)

Рассмотрим 3 ситуации:

🔶 "Не умею"

Начать рассказ не с принципов оценки, а зачем собственно это нужно команде? Когда команда поймёт бенефиты для своей работы, то вопрос "зачем это делать?" отвалится за ненадобностью.
Но учить тоже нужно, потому что неправильно заложенные параметры на старте приводят к тому, что "а у меня 1SP=1 часу", притом что остальная часть команды оценивает в относительной величине.

🔸 "Не хочу"

Не надо пытаться продать, что это нужно президенту, CEO или тёте Маше. Не прокатит. В этом случае надо понять а есть ли вообще проблема с оценкой у команды - может действительно пытаемся натянуть в их процесс нечто инородное? Да, есть команды способные оценивать свои объёмы только лишь числом задач, но это опять про зрелость. Если потребность есть, то читай п.1 ("зачем"), но истолковывай немного иначе. Объясни команде, что если мы будем продолжать делать как делаем, то не получим: "указываем плюшку". Ощущение потери чего-либо работает лучше, чем приобретение когда мы объясняем в п.1 про зачем. Нюанс в том, что у первой команды есть запрос, но нет понимания. А у второй нет запроса и есть сопротивление.

🔸 Мы привыкли оценивать "так"

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

Если ты в роли PO зачем тебе оценка? Тебе нужен прогноз для роудмапа? Так и спроси об этом команду, пусть они сообразят как предоставить информацию, чтобы можно было сформировать роудмап. В конце концов это и их продукт тоже - вовлекайте (модели ADKAR и Коттера в помощь)

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

//Но на самом деле нет)

Сегодня работаю с нашей командой в Питере на Team Lead Conf🔥🔥🔥. Если ты тут, то приходи к нам на стенд, чтобы пообщаться со мной и ребятами на тему крутых кейсов про изменения и не только))). А ещё подписывайся на канал МТС True Product Transformation, чтобы ещё больше узнать о цифровой трансформации в экосистеме МТС!

Подготовка к конференции ч.2

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

☑️ через нас с коллегами за 2 дня прошло порядка 800 человек. Это похоже на спид-дэйтинг😂 Тем, кто нравится (профессионально) уделяешь больше времени. Но в среднем каждому по 5-7 минут.

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

☑️ самый интересный момент заключался в том, что наши кейсы приходила огромная вариативность ролей (РП, Тимлид, CTO, QA, Бригадиры iOS, собственники бизнеса - кого только не было). И с каждой новой ролью задание играло новыми красками. Мне это напомнило сдачу PMI-ACP - там было важно отслеживать с чьей позиции ты решаешь задачу (Agile Coach, CDTO, Dev, stakeholder и т.д.) С каждой позиции могут быть абсолютно разные решения одной и той же задачи.

☑️ крайне важна слаженная работа команды. Когда ты как слушатель у тебя есть возможность выбрать доклад, выбрать с кем нетворкать или выбрать пойти просто полежать на бинбэге и почилить. Когда ты на стенде - ты должен быть доступен 99,9%, поэтому без поддержки коллег не обойтись, когда нужно отлучиться или помочь друг другу, когда нескончаемый поток людей.

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

☑️ за 18 часов работы на конфе до нас дошёл всего 1 агент изменений😂 но тем было интереснее как смотрят на нашу работу другие роли и как могут (пусть даже в теоретических кейсах) справляться с возникающими трудностями в процессах

👆Вывод: это отличная возможность для экстраверта понять каково быть интровертом😂

​​#непропроекты

Категоризация помогает

Я использую различные способы управления собственными задачами и проектами: Jira, Confluence, Trello, Notion, задачник Outlook, а иногда и их комбинацию, но по опыту больше 2 таск-листов очень сложно удержать в фокусе внимания. Но давно и неизменно использую возможность визуализации в Outlook в календаре. Оказалось, что для многих такой способ - открытие, поэтому делюсь.

Для чего это делаю я:

⭐️ у меня создан ряд категорий (например: "встречи с C-level", "встречи с командами", "встречи 1-1 с подчинёнными", "планирования" и т.д). Один взгляд в начале рабочего дня на цвета позволяет понять на что ты будешь сфокусирован сегодня

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

⭐️ по результатам 1-3 месяцев я делаю срез задач по своим управленческим навыкам: планирование, выполнение, делегирование, контроль. Цветовая гамма для меня позволяет в разы удобнее оценить примерную загрузку в часах, которая была за период.

P.s.+ лайфхак от коллеги - cпасибо @pturchenko. Если вам приходится много взаимодействовать с бизнесом, с командами, с подчинёнными на 1-1 то имеет смысл выстроить цикл встреч в своей работе по принципу pull in => pull out. Например, в понедельник-вторник: ставите цикличные встречи с CEO, CDTO. В среду: обрабатываете ОС и генерите задачи, которые образовались из этого общения, а в четверг-пятницу: встречи с командами и 1-1 с участниками своего отдела, чтобы довести обратную связь и делегировать задачи. Помогает эффективно расходовать временной ресурс и избегать повторений.

Развиваясь не забывайте делать это с шуткой по жизни!😉
Всем добра❤️, а у канала сегодня выходной😂