Управление без паники

Карго-культ и Scrum: Почему правила не всегда спасают Я тут вспомнил одну историю из Альфы пример как правильная концепция Shu Ha Ri может превратиться в карго культ Часто в Agile и Scrum упоминают концепцию Shu Ha Ri Shu (яп. 守) — первая ступень, где нужно точно следовать указаниям учителя, годами тренироваться, чтобы создать основу. Ha (яп. 破) — вторая ступень, когда ученик начинает адаптировать и изменять правила, создавая свои подходы. Многие спешат к этому этапу, переоценивая себя. Ri (яп. 離) — третья ступень, когда ученик освобождается от правил, действуя интуитивно, основываясь на глубоких принципах. На этапе Shu команды должны следовать Scrum Guide. В Scrum Guide говорится, что все технические решения принимает команда. Звучит справедливо, правда? Но… В моем случае команда состояла в основном из джунов, и только один сеньор имел опыт промышленной разработки, сопоставимый с средним возрастом разработчиков. Пример: когда пришло время выбрать базу данных, сеньор сразу предложил решение. Однако Scrum Master заявил: "Это всего лишь твое мнение, команда должна выбрать сама!" Что в итоге? Четыре часа пустых разговоров о базах данных. Выбрали PostgreSQL, как и говорил сеньор с самого начала. Но важнее всего, что после этого общение с ним стало напряженным: он считал Scrum фигней и транслировал это при каждом удобном случае + при всей команде его мнение было обесценено. Почему так произошло? Потому что букву правил поставили выше сути. Карго культ в действие Что важно запомнить: 1. Контекст решает всё. Даже самые правильные принципы могут выйти боком, если не учитывать реальность. 2. Правильное делегирование: Задачи должны соответствовать реальным знаниям и навыкам тех, кто их выполняет, а не вашему желанию делегировать результат =) Кто сталкивался с таким?

Четыре график, 30 минут и 0 встреч: готовый инструмент для поиска точек роста любой команды Возможно, сейчас будет сложновато. Но умение работать с данными, строить графики и читать их - must have skill, если вы хотите развиваться как руководитель или, в крайнем случае, Delivery Manager=) Умение в data driven decision сильное конкурентное преимущество, которым все еще обладают далеко не все. Придя в новую команду мне потребовалось 30 минут, чтобы прийти на первые встречи уже с фактурой! За эти 30 минут я: - построил и изучил графики команды - сформировал набор гипотезы - предположил, какие конкретные действия надо предпринять для улучшения процессов - сформировал доказательства аргументов, которые я буду проводить команде о необходимости запуска изменений На практике я не раз наблюдал как для подобных результатов руководителям требовались недели, а иногда и месяцы. В конце статьи оставлю инструкцию как можно научиться так же быстро находить точки улучшений ваших процессов и быть профессионально-убедительным при общение с командой и руководством Разберем несколько графиков: График Cycle Time Histogram: 1. Длинный хвост -> большой разброс времени выполнения 2. Только ~33% задач делается быстрее 14 дней, а это целый спринт 3. Присутствуют моды на 1, 5, 14, 24, 62 дни Гипотезы 1. Команда работает непредсказуемо и/или на графике разные типы рабочих элементов 2. Спринты формируются странно, скорее всего в них просто «напихивают» какой-то объем задач, а не формируют исходя из цели 3. Вероятно, от спринтов надо отказаться, так как большая часть все-равно переезжает в следующий спринт 4. Есть разные источники задержек и их надо исследовать 5. Задачи, в основном, закрываются к конце неделе Делитесь вашими выводами в комментариях - что вы еще заметили? График Throughput Chart: Небольшая вариативность - последние 4 спринта за две неделе делают, примерно, 40-45 задач Гипотезы 1. можно предположить, что задачи примерно одинакового размера 2. можно предположить, что процессы в команде стабильные, не хорошие, а именно стабильные График Aging Chart: Два проблемных статуса ToDo и Ready for UAT(user acceptance testing) Гипотезы 1. У команды нет ТПО (точки принятия обязательств) 2. ToDo и Ready for UAT без вип лимитов 3. Чтобы сократить LT (lead time) фокусируемся на этих статусах, но в первую очередь на Ready for UAT, так как он ближе к концу График CFD (накопительная диаграмма потока) 1. Количество задач стабильно во всех статусах 2. В Ready to MR, после 21.10 резко сократилось кол-во задач, вероятно были изменения 3. У команды в целом стабильное количество входящий задач и мощность выпуска Гипотезы 1. В команде, в целом, стабильные процессы 2. Надо сокращать Cycle time Ready for UAT и ToDo Какие изменения требуется провести? 1. Меняем формат дейликов на фокус на завершение задач 2. Определяем ТПО и вводим вип лимит 3. Ставим вип лимит на Ready for UAT 4. Проводим СТАТИК, но это надо делать почти всегда, как минимум лайт версию Как и обещал, в конце статьи о том, как же формировать аналогичные гипотезы также быстро - инструкции в 3 шага не будет=) Но я готов делиться опытом, инструментами и готовить гайды. Помогите мне поднять мотивацию с колен и не растерять энтузиазм. Как мне помочь: 1. Лайк, репост, подписка Сейчас я готовлю гайд по экспресс-анализу метрик, пересылайте этот пост коллегам, польза для вас - самая главная мотивация вести канал 2. Если ваш запрос не готов ждать - буду рад помочь лично - можно написать мне и договориться о сессии менторинга - разберем ситуацию, построим/разберем графики, разработаем план действий. Можно в личку, но лучше тут . Для подписчиков всегда специальная цена ❤️

Сейчас заметил за собой один момент, над которым надо активно работать: Don't be the smartest guy in the room. Когда ты эксперт (или думаешь, что им являешься), легко начать думать: «Да тут и так всё понятно», или «Что нового мне могут рассказать?» Однако, важно вовремя остановить такие мысли. Настоящая экспертность проявляется в способности оставаться любопытным и открытым к контексту и людям, даже если кажется, что ты всё понял за пять минут или за два дня. С другой стороны, стоит избегать изобретения велосипеда каждый раз. Большинство ситуаций можно привести к известным типовым моделям и использовать проверенные планы. Важно затем адаптировать эти решения вместе с командой под конкретный контекст. Один из ключевых принципов звучит так: Уважайте текущие роли и процессы. Ведь вы не всегда знаете, в ответ на какие вызовы они были созданы.

Новый старт: Что можно узнать в первый день работы Delivery Lead? На целый год забыл про Дзен - буду догонять, актуальный контент в тг На этой неделе я начал свою работу в новой компании на позиции Delivery Lead. Что можно узнать за один день и какие выводы сделать? На самом деле достаточно много, если знать куда смотреть и иметь определенный уровень насмотренности. В этом отлично помогает гайд Что удалось сделать в первый день: - Познакомился с СТО и лидом одной из команд. - Ознакомился с процессами работы: RFC, Solution, Epic, Task. - Посмотрел, как декомпозируют задачи. - Изучил метрики RFC и командные метрики. - Запланировал встречи 1-1 с другими участниками команды. Основные наблюдения Проблемы и задачи в компаниях часто повторяются. Понадобилось всего пару часов изучения досок и метрик, чтобы наметить простой план улучшений. Вот, на что я обратил внимание: - Какие задачи движутся по доске команды и как они связаны с верхнеуровневыми сущностями. - Как задачи переходят через этапы на доске и где они чаще всего зависают. - Метрики. Рекомендую отличный плагин для Jira для быстрого анализа метрик: Jira Metrics Plugin. От ребят из hh (если не ошибаюсь) - Артефакты команд. Проблемы, которые сразу бросились в глаза - Медиана LT составляет 26 дней при длине спринта в 14 дней, и только 33% задач укладываются в спринт. Возникает вопрос: «Зачем тогда спринт?» - Дейлики проходят в формате отчётов по людям: «Что я делал вчера?» - Ретроспективы проводятся раз в квартал, и выводятся странные action points. - Команды очень сильно связаны на уровне кода. Фича требует последовательной работы нескольких команд Общий вывод Если подняться на уровень всей организации, стало заметно главное: - С одной стороны, есть запрос на изменения. Понимают, что текущая ситуация не идеальна и представляют, чего хотят достичь. Но отсутствуют промежуточные цели, которые могли бы помочь двигаться к основной цели. - Нет стратегии управления изменениями на уровне компании (по крайней мере, в виде артефакта). Существуют только локальные задачи на уровне команд. На этой неделе я запланировал встречи с ключевыми участниками и командой, чтобы проверить свои гипотезы и откалибровать план. p.s пинганите в комментариях, напишу дизайн(вопросы), которые подготовил для 1-1

Выступление на конференции МСП.РФ: Инсайты о гибких навыках и искусственном интеллекте Что если мессенджеры — привычные нам инструменты — работают против нас? Неожиданно, правда? На конференции МСП.РФ я выступил с докладом о том, как улучшить коммуникацию в рабочих чатах. Я разобрал несколько привычных, но неочевидных ловушек общения и дал рекомендации. В этом и следующем постах я поделюсь ключевыми моментами своего выступления, от «гибких навыков» до применения искусственного интеллекта в работе. Начнем с одной из самых спорных тем — общения через мессенджеры. «Гибкие навыки» в мессенджере: подводные камни и как их избежать Голосовые сообщения — ловушка для всех нас На первый взгляд, это удобно: нажал кнопку, сказал и отправил. Но голосовые сообщения таят в себе скрытые сложности: - Поиск информации — становится почти невозможным. Текстовые сообщения куда проще пролистать глазами, найти нужный момент. С голосовыми же приходится тратить время на многократное прослушивание. - Проблемы с фиксацией задач — важные детали можно упустить, и сложнее отследить выполнение задач. - Неточность восприятия — в отличие от текста, где всегда можно уточнить, в голосовом формате нередко возникают недопонимания. - Время на прослушивание — аудиоформат требует больше времени, чем короткое текстовое сообщение. Это особенно затрудняет работу, когда информации много. Неопределённые задачи — путь к неразберихе Бывает, что в мессенджерах задачи формулируются размыто, и вот к чему это ведет: - Неясные цели — коллеги просто не понимают, что именно от них требуется, что может вызвать задержки. - Траты времени на уточнения — приходится переспросить, а это съедает время обеих сторон. - Снижение ответственности — если указания нечёткие, сложно понять, кто за что отвечает. Результат? Задача может остаться без внимания. - Смещение фокуса — неопределенность может выбить команду из рабочей колеи и нарушить приоритеты. Множественные темы в одном сообщении — запутывают Когда в одном сообщении несколько тем, это сильно усложняет коммуникацию: - Сложность восприятия — получатель теряется, не зная, что важно. - Риск упустить ключевые моменты — информация может просто затеряться среди других тем. - Сложности с обратной связью — ответ на одно из обсуждаемых вопросов может затенить остальные. - Непрозрачный прогресс — когда задачи не разделены, усложняется их отслеживание. Как надо? В мессенджерах старайтесь: - Избегать голосовых сообщений. Оставьте их для общения с друзьями. - Сразу переходить к сути, чтобы собеседник мог прочитать и ответить по мере возможности. - Уважать личное время — используйте мессенджеры в рабочие часы. Обсуждение с ведущим: за и против голосовых сообщений На этапе вопросов и ответов случилась дискуссия с ведущим. Он любит использовать голосовые, так как много времени проводит за рулем и это удобно для него. Но такие случаи — исключение. Что думаете? Какие «гибкие навыки» добавили бы вы? На что наложили бы ваше личное вето?

⚡ Помните: изменения — это командная работа, и с правильной стратегией они могут быть успешными! Каждый из этих факторов будем подробно разбирать p.s на мой взгляд умение управлять изменениями на базовом уровне это необходимый навык для любого руководителя

Опубликовано фото

Получился не самый плохой понедельник 1. Подготовил статью на завтра, небольшой тизер : Быть своим: 3 шага к успеху для нового руководителя 2. Поштормил над аудиторией, тематикой контента и площадками. Первый драфт готов, буду его улучшать 3. Составил контент план на месяц. Получилось плотно, но это вызов все успеть Продолжаю думать над вопросами площадок и привлечения аудитории. Есть тг как основная площадка и есть дзен, инста, линкидин, откуда хочется привлекать новых подписчиков Пока в голове выглядит так Тг - основной контент( в основном обучающий или полезный) + личные заметки ( как эта ) - В дзен кросспостинг - В инсту анонсы, рилсы и краткие выжимки / карточки - В ютуб записи конференций и шортсы - В линкид обучающий контен - В vc вероятно аналогично линкидину Дайте вашу ОС в комментариях , как вам такое разделение ?