Обсуждения пост

В общем, каким-то странным макаром у исходного поста с PDF руководством по Запуску работ по Канбан-методу отвалились комментарии 🤷‍♂️

ПОЭТОМУ давайте обсуждать тут, под этим постом 👇

Вообще история и суть этого руководства интересна.

🛢Начать с того, что Sandvik Group - это вообще-то нефтянка.
А Sandvik IT - это лишь IT-подразделение этой нефтянки. Тем не менее, интересно, что автор решили выпустить такое практическое и полезное руководство. Какие цели они при этом преследовали мне не известно, но вышло хорошо 🤷‍♂️

😢 Изначально авторы планировали что у этого руководства будет продолжение, но по факту никакого продолжения не случилось. ЧТо печально, на мой взгляд.

⏲️ Важно отметить, что руководство было написано в тот период, когда существовал совместный бренд Lean Kanban University, и поэтому в руководстве вершиной развития Канбан-системы называется Lean-подход.
🤷‍♂️Но судьба распорядилась так, что Kanban University отпочковался от Lean Kanban Universty, где-то в 2015-2019гг, и начал двигать свое видение Канбан-метода.
В тексте руководства раскиданы всякие реверансы к Lean, и не надо этому удивляться, а просто принять во внимание временной контекст , когда это все было написано.

😂 Чтоб вы понимали, в этом руководстве главными Канбан-метриками указаны Cumulative Flow Diagram и Control Chart (дада! контрольная диаграмма, что бы под этим не подразумевалось).
А Lead Time Distribution Chart (LTD) указана как "другая диаграмма ... которая становится все более популярной в Канбан-сообществе" 😂😂
Сейчас-то без LTD мы никуда - а в то время это только начинало быть популярным.

👍 Что в этом руководстве безусловно хорошо, на мой взгляд, так это то, что оно сразу и четко обозначает цель Запуска - это стабилизация и опрозрачивание состояния команды до уровня некоего "Базового Состояния" (baseline) с которого уже можно двигаться в сторону непрерывных и устойчивых улучшений.

🌟 И далее дается перечень действий ПОСЛЕ Запуска, которые призваны эту стабилизацию и опрозрачивание поддержать и придать импульс к дальнейшим улучшениям.
То есть это не "просто провести STATIK" и уйти в горизонт. Это полноценный Запуск с последующим сопровождением.

👏 Еще меня очень порадовало, что в самом начале руководства дан призыв - пообщаться с Менеджером команды, чтобы опрозрачить его цели, и выровняться в ожиданиях от перехода на Канбан-метод.
‼️Более того, в руководстве есть точка, в которой Коуч (к которому обращено это руководство), должен спросить САМ СЕБЯ - а стоит ли тебе вообще идти по пути Запуска с этой командой? решит ли это их проблемы и продвинет ли к их цели?

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

👉 Накидывайте в комменты, что еще интересного найдете в этом руководстве для себя. Или чего не нашли в нем, а стило бы этому там быть.

📘 Так, глядишь, и современное руководство по Запуску работ по Канбан-методу сделаем. Необходимость сделать это, по-моему назрела.

А вы предыдущий пост с PDF-руководством комментировать можете? А то я чего не вижу тако возможности и пытаюсь понять - это у меня глюк в телеге, или реально там комменты закрыты?

Всем привет! 👋

На прошлой неделе мы с вами обсуждали, что нужно для запуска работ по Канбан-методу. И это обсуждение было не просто так! Часто, отвечая на этот вопрос, я слышу: "Да просто проведите им STATIK, и все!"... но мой опыт говорит, что этого, к сожалению, недостаточно.

👉 Есть куча необходимых действий ДО STATIK (например, выровнять ожидания ЛПРов и менеджмента) и после STATIK (поддержка, доделка того, что не успели, и так далее). И порой, от этих шагов зависит успех всего предприятия. Да и сам STATIK — не панацея, и редко идет так как задумано! 🤷‍♂️ Участники часто не обладают нужными данными, не всегда понимают суть изменений и целей своей, а уж установить WIP-лимиты на первой сессии STATIK — часто похожа на попытку научить кота играть на пианино. 🐱🎹

Короче говоря, "просто провести STATIK" — это худшая рекомендация 👎, которую можно дать для старта работы по Канбан-методу в команде. Тут нужен полноценная сессия Запуска: с обучением, подготовкой менеджмента, выравниванием ожиданий и, конечно, созданием Канбан-доски. Не забываем про поддержку после запуска!

🤷‍♂️Но вот беда — хороших материалов о том, как провести такую сессию, почти нет. На русском так вообще нет. Каждый делает по-своему, полагаясь на интуицию и опыт (и иногда на удачу). А если вы хотите все это организовать в своей команде, то, скорее всего, вам придется действовать методом проб и ошибок. 🔨Что несколько напрягает, по-моему.

🎉 Но я облечу вашу задачу!
Во время отпуска я перевел отличное руководство — "Kanban Kick-Start Field Guide" от Sandvik IT (IT-подразделение Sandvik Group). 💡

📔 Это практичное руководство охватывает все минимально необходимые действия до, во время и после Запуска работ по Канбан-методу. Конечно, оно было написано в 2013 году, и моменты связанные с организацией работы удаленных команд сейчас выглядят наивно, но как план действий — это отличный документ! В нем даже есть роль Flow Manager, что в свете последних изменений от KU, выглядит как рекомендация, опередившая свое время, но очень актуальна сейчас. 🔄

🛋В общем, читайте, изучайте, спрашивайте.
Перевод 80 страниц текста превратился в 130, но я уверен, что это вас не остановит! 😉
Оригинал руководства на английском доступен по этой ссылке

Лайк, share, repost — добро пожаловать! 🚀

Обсуждаем тут

Канал "Данные в действии"

Дело в вашем мнении: собрали ТОП-10 докладов и ТОП-3 воркшопов по оценкам и комментариям участников

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

Собрали список топовых докладов и воркшопов, основываясь на оценках и комментариях участников прошедшей конференции AgileDays’25 в рамках двух дней.

🔗Все итоги — во вложении.

Ну ничего себе! Мой доклад занял 2е место по оценкам на Agile Days!
Даже Асхата обогнал! Вот это поворот 😱

Вы тут давеча обсуждали мой доклад на Agile Days, в котором я развеивал мифы о менеджменете. Но в управлении продуктами мифов по-моему не меньше, а ещё больше.
Всякий суслик мнит себя продактом, хотя task от user story отличить не может. А уж про продуктовые метрики и цели вообще не стоит говорить.

И как раз под эту тему
⭐22 и 25 апреля пройдет наша большая продуктовая конференция ProductConf - https://productconf.ru. Мы собрали крутых спикеров — будут кейсы, практики, подходы, которые реально помогают развивать продукты и команды. Думаю, многим из вас будет интересно и полезно — и для роста, и просто чтобы вдохновиться.

Конференция пройдет онлайн и офлайн (в Москве).
Поэтому можно подключиться из любой точки, или прийти лично — я тоже буду там!

И у меня для вас есть промокод на 20% скидку — SAVUNOVPC

Короче, приходите. Буду там, помашу вам рукой, обниму, если не убежите.
А если не придёте — я всё равно вас люблю, просто чуть меньше 😆❤️

Попросил ChatGPT резюмировать итоги обсуждения "Что надо сделать, чтобы команда начала работать по Канбан" из прошлого поста.

По-моему, получилось весьма интересно 😊

### Чек‑лист запуска работ по Канбан‑методу в команде

0. Пролог: «Не стреляйте, я только спрашиваю»

Разбираемся в контексте: зачем вообще создана команда, чего от нее ждут, что болит, сколько денег 💸 / людей 👥 / ИБ‑ограничений 🛑 у нас есть и все остальное что важно знать перед началом.

1. Получить у спонсора/ЛПРа подпись кровью 🖊

Находим и приручаем спонсора‑ЛПР, продав ему идею. НО НИ В КОЕМ СЛУЧАЕ не говорим слова "Канбан" 🚫, "поток" 🌊, "WIP-лимиты" 🔒 и так далее. Это пугает неокрепшие умы ЛПР-спонсоров 🧠💀.

2. Обучение команды 📚

Ликбез 📖, общее обучение 🧑‍🏫, и обязательно игра 🎮 GetKanban — чтобы все поняли механику до того, как станет больно . Лакируем и закрепляем канбан-мемчиками в рабочем чате.

3. "STATIK‑ритуал" 🔮

Формулируем цель сервиса 🎯, рисуем поток работ на доске, вводим классы обслуживания 🏷 и WIP‑лимиты ⛔️, договариваемся о нужных каденциях — полная классика STATIK. Надеемся, что этого хватит для старта 🚀.

4. Закрепляем политику входа задач и пожарный сигнал

Приучаем все к принципу: «Нет на доске — нет в работе». Чётко описываем, что такое «срочно» ⚡️ и кто имеет право кричать «горим!» 🔥. И что мы после этого крика делаем 🤷‍♂️.

5. Дергаем большой красный рубильник 🚨

С понедельника вытягиваем задачи по Канбан-системе слева-направо строго в рамках WIP-лимитов 📈. Готовимся к нытью и непониманию в команде 🤦‍♂️, но радуем всех тем, что выбрасываем скрам‑ритуалы на свалку 🗑 (или музей) .

6. KMM‑апгрейды по чуть‑чуть

Раз в неделю добавляем новую практику из плаката KMM ‒ маленькими порциями, чтобы команда не сбежала 🏃‍♀️ и не догадалась, что "у нас Канбан" 🤫.

7. Данные и PR 📊

Собираем метрики (lead time, throughput, WIP Aging ), рисуем графики 📈 и показываем их всем, чтобы сохранить доверие 💪 и бюджет 💵.

Канал "Данные в действии"

В преддверии нового материала по Канбан-методу, который будет посвящён плану запуска работы по Канбану, решил запустить опрос, чтобы понять, как оно на самом деле у вас происходит?

Напишите в комментариях, что вы ОБЫЧНО делаете, чтобы команда РЕАЛЬНО начала работать по Канбан?

Мне кажется, это очень холиварный вопрос.
Уверен, что многие ответят "провести STATIK", только вот реальная практика показывает, что это недостаточно, и нужны ещё усилия, чтобы практики Канбана стали привычными.

А какие именно усилия? Как вы думаете?

🙈 Как вы думаете, это нормально, когда во время перевода 80-страничное руководство разбухает до 120-150 страниц?

Думал, по-быстрому в отпуске перевести руководство по запуску работы по Канбан-методу ... и уже 3й день не могу завершить это благое дело 🤷‍♂️

Наконец-то найдено объяснение 130-му дню зимы
😂😂😂

👉Вот PDF доклада на Agile Days в котором я попробовал поставить под сомнение очевидность общеизвестной практики менеджмента, и через это показать необходимость доказательного подхода к выбору инструментов менеджмента.

Канал "Данные в действии"

😇Часто вижу религиозную веру в то, что какая-то практика, приём или инструмент менеджмента представляется менеджером как аксиома, не требующая доказательств.
😡Это жутко бесит всех вокруг и приносит много вреда как самому человеку, так и окружающим.
👉Поэтому я решил сделать доклад на тему возможности доказательного подхода в менеджменете (PDF в следующем сообщении)

Ух... Выступил...

Перелет 4 часа, 1.5 часа на паспортном контроле, ночью последние штрихи к презентации, 4 часа сна...

Но! Show Must Go On!
Как бы плохо я себя не чувствовал, но выход на сцену это триггер - улыбка, энергия, подача. Потом можно свалится, уползти в нору и отдышаться. Но раз ты на сцене - соответствуй!

PS Презентацию позже выложу в канал

Кстати, сегодня в 13:00 выступаю на Agile Days с необычным докладом.
Тема навеяна холиварным постом в котором мы с вами рассуждали, а возможен ли "доказательный менеджмент"? По аналогии с доказательной медициной.

Надеюсь, вызову взрыв башки у слушателей 😂

Торжественное открытие состоялось, мы начинаем второй офлайн-день самой джазовой конференции AgileDays’25: погнали!⚡️

[продолжение предыдущего поста]

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

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

👉Если все это учесть, то становится понятно, почему вопросы менеджмента разработки ПО стали в итоге решать сами программисты. У них больше всего болело, они понимали как все реально устроено, а уволить их безболезненно не получалось, так что приходилось к ним прислушиваться.

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

🤷‍♂️В результате работы мысли этих программистов, получилось те системы менеджмента разработки ПО, которые мы имеем сейчас - Scrum, SAFe, LeSS, Scrum Of Scrums и др

🤔 Удивительно тогда другое - почему системы менеджмента, созданные программистами, зачастую вызывают сопротивление самих программистов? Ведь большинство современных подходов к разработке ПО так или иначе говорят о необходимости хорошей коммуникации - навык, которые многим программистам совсем не присущ, и развивать который они не хотят 🤷‍♂️

😊Иронично, на мой взгляд еще и то, что в ходе борьбы за выживание разных Agile-подходов, победил Scrum, где роль классического менеджера вообще вынесена за пределы процесса 😂😂
Предполагается что "самоуправляемая" Scrum-команда будет "сама себе менеджер" 🤷‍♂️ Может быть и есть где-то менеджер уровнем выше команд, но в Scrum Guide его не видно (хотя и не запрещено добавить).
Учитывая, что и SAFe и LeSS так или иначе базируются на Scrum, то эта идея отсутствия классического менеджера масштабируется и на крупные масштабы разработки - 100, 500, 1000 человек.

🤷‍♂️ Не удивительно, что в этих условиях, сам менеджмент компании тоже не слишком доволен предлагаемой системой управления: где понятные метрики? где попадание в дедлайн? как можно управлять, в условиях "самоуправляемой" команды? ничего не понятно, но кто-то же должен ответить в случае провала? А с кого спрашивать? Кого штрафовать или увольнять? Всю Scrum-команду? Как-то не персонализировано и дорого.

🤔 Но и бизнес, как мне кажется, по большей части, тоже не слишком доволен результатами Agile-процессов. По крайней мере я это вижу в РФ. Потому что Scrum-based процесс принуждает к выделению целых продуктовых групп под конкретные продуктовые направления. А это означает, что нужно включить пылесос, и начать собирать с рынка всех специалистов для укомплектования таких продуктвых групп. Фонд оплаты труда разбухает, а есть ли сопоставимая отдача от этих продуктовых групп? Тут все очень по-разному 🤷‍♂️ Но гарантий, конечно, никто не даст.

🤯 Может быть, действительно, корень текущих проблем управления разработкой ПО именно в том, что за дело взялись программисты?

👉 Я давно замечал - если программисты берутся за дизайн интерфейсов, то получается интерфейс в котором может разобраться только программист, а всем остальным неудобно

👉 Если программист берется за написание инструкции по пользованию ПО, то... либо он ее не допишет (потому что проще программировать, чем объяснить как работает), либо напишет так, что обычному человеку понять будет очень трудно.

👉 А если берется налаживать процессы менеджмента....

😂 Давайте вы сами продолжите мысль - что тогда случится? 😂a>

Очень интересную мысль коллега принес с обучения Сколково

Вся эволюция современной системы менеджмента — это то как айтишники решали свои проблемы

А ведь если подумать - в современном мире практически нет бизнеса без ИТ-составляющей, а значит, менеджмент разработки ПО стал настолько значим, что часто подминает под себя все остальные процессы в компании.
А что у нас пока что мейнстрим в области разработки ПО? Пока еще Agile. Значит и все процессы в компании начинают испытывать давление в сторону Agile 🤷‍♂️ А кто придумал Agile? Программисты!
Не верите?

Я как-то изучал список приглашенных на ту знаменательную встречу 2001 года в Сноуберде, штат Техас, на которой родился Agile Manifesto - все они работали программистами!

👉 Kent Beck - Smalltalk-программист, создатель XP
👉 Mike Beedle - программист
👉 Arie van Bennekum - COBOL-программист)
👉 Alistair Cockburn - прикладной ООП-разработчик, создатель методологии Crystal
👉 Ward Cunningham - программист, разработчик первой Wiki-системы
👉 Martin Fowler - ООП-программист, автор книг по шаблонам ООП и рефакторингу кода
👉 James Grenning - программист C/C++ , начинавший писать с начала 70-х годов XX века
👉 Jim Highsmith - программист, начинал с работы в NASA, писал ПО для ракет
👉 Andrew Hunt - прикладной программист, писал софт для телекома, банков, медицины
👉 Ron Jeffries - программист, написал свою первую программу в 1961 для Стратегического авиационного командования США
👉 Jon Kern - программист C++, Java, писал код для систем моделирования авиационных тренажёров, и моделирования работы двигателей
👉 Brian Marick - начинал как программист, затем начал специализироваться на менеджменте тестирования ПО
👉 Robert C. Martin - начинал как C++ программист на мейнфреймах
👉 Stephen J. Mellor - в 1970-х работал в CERN программистом на языке BCPL​, разрабатывая систему управления ускорителями
👉 Ken Schwaber - программист, а затем руководитель проектов по разработке ПО
👉 Jeff Sutherland - занимался разработкой объектно-ориентированных систем​
👉 Dave Thomas - программист, активный популяризатор языка Ruby

Более того:
👉 Создатель SAFe, Дин Леффингвелл - тоже начинал как программист.
👉 Создатель LeSS, Крейг Ларман - программист.

🤔 Удивительно правда?

❓ У меня сразу родилось куча вопросов:
❓ Как так получилось, что программистам пришлось взять решение проблемы менеджмента разработки ПО в свои руки?!

❓ Где-то в другой предметной области можно найти такие примеры, когда работники сами взяли в свои руки решение проблемы менеджмента своего труда? Или это уникальный случай?

❓ Значит ли это, что у менеджеров не было проблем с менеджментом разработки ПО, раз они не придумали ничего лучше "каскадного подхода" (Winstone Royce)?

🔎 Погуглил чутка, и понял, что все это случилось, похоже, от безысходности 🤷‍♂️
На момент появления профессии программиста, в мире не существовало (да и сейчас по-моему не существует), ничего похожего на "менеджмент интеллектуального труда". И не было менеджеров, которые бы понимали, как этим управлять.

👨‍🔬Да, есть интеллектуальный труд ученых. Но в научных проектах опора делается на нормы, которые выработают сами ученые и на их самоорганизацию в ходе проекта. То есть, что тогда, что сейчас менеджмент научных разработок довольно слабо структурирован, и какого-то единого, общепринятого подхода вроде как нет 🤷‍♂️ Так что повторить не получится.

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

[продолжение в следующем посте]

✋Друзья, признаюсь честно: собирался просто кинуть вам парочку смешных картинок, чтобы вы не забыли о моем существовании 😏. Но потом понял, что это было бы нечестно по отношению к вам. За этот месяц у меня произошло столько всего, чем хочется поделиться, и возможно вам будет интересно заглянуть в мое закулисье 🎭

🤦‍♂️Во-первых, я начал одновременно писать две книги (про 📘Канбан и про 📕 удалёнку). Получается трудно, и больше похоже на пословицу про гонку за двумя зайцами 😂 Чувствую, что если буду продолжать бежать за обоими, то в итоге могу получить по морде и от первого, и от второго 🐇🐇😅. Но остановиться не могу - хочется достичь своих целей.

✌️Во-вторых, я погрузился в аудит рабочих процессов большого ритейлера. Представьте себе интервью с 26 людьми - и каждый из них видит только часть общей картины, по-своему её описывает, что-то не договаривает, что-то преувеличивает, где-то путается, а где-то выдумывает. И день за днем я это слушаю, и буквально начинаю себя чувствовать Джонни-Мнемоником 🤯: в голове десяток версий одной и той же реальности, а мне из них нужно склеить одну, более-менее правдоподобную. Когда в день по 5–6 интервью, то под конец дня в голове гул и туман, невольно хочется закутаться в простыню и уползти в неизвестном направлении… Но где-то день на третий, когда мозг «пропитался» информацией, вдруг начинаешь видеть паттерны и взаимосвязи, и неожиданно понимаешь, как выглядит вся картинка — и увиденное пугает, захватывает и мотивирует продолжать разбираться дальше!

☝️Затем настал черёд анализа данных из трекера задач. Звучит просто… пока не увидишь, насколько данные могут быть неполными, противоречивыми, лживыми, кривыми и запутанными. Мне приходится устраивать настоящее детективное расследование: где-то добыть недостающие цифры, где-то сопоставить одни цифры с другими, где-то на собственном опыте сложить паззл из статусов задач. И вот когда, казалось бы, все проясняется, наступает момент разочарования: данные подтверждают, что у клиента всё идёт долго, сложно, и обрадовать его мне нечем 🥲.
Но! Все это делается ради того, чтобы указать клиенту на путь к пониманию внутреннего хаоса. Оказывается, даже в хаосе есть закономерности, и это вселяет в клиента робкую надежду, и жгучий интерес. И с этого начинается путь к улучшениям.

👨‍🏫 Параллельно я продолжал обучать людей Канбан-методу. Онлайн-тренинги «Основы Канбан-систем» и «Масштабирование Канбан-систем» для меня, как любимые книги: я их писал, переписывал, вычеркивал лишнее, радовался прозрениям учеников и страдал над сложными кейсами. В общем скучать не приходится. Тем более что онлайн-тренинг в Zoom — это как кино одного актера 🎭: я 16 часов в кадре, стараюсь зарядить всех своей энергией, объясняю, спрашиваю, отвечаю, подбадриваю. И когда начинаю чувствовать, что постепенно группа становится моим со-ведущим, а не пассивными слушателями, то понимаю, что кино захватило внимание зрителей, а мне удалось нанести им непоправимую пользу. Это тяжело, но непередаваемо прекрасно 🎉!

🚀И это ещё не всё: за последний месяц я выступил на конференции Инфостарт, пережил очередной виток ремонта в доме (лучше не спрашивайте 🏠🙃), учил скрам-мастеров… В общем, жизнь кипела и вертелась как в калейдоскопе.

👉И все это время я постоянно себе напоминал: «Надо написать статью про метрики распределения, и новую PDF-инструкцию, и марафон по анализу метрик провести…».
Но - сэ ля ви - плотность событий такова, что раньше середины апреля я вряд ли что-то из этого смогу сделать.

Так что вопрос: дождётесь ли вы меня или переключитесь на смехуечки и котиков?🐱 Мне кажется, я уже знаю ответ… 😂
И это не упрёк: никто не может конкурировать со смехуечками и котиками 😂 😂 😂! Но если вы всё же останетесь тут, то я буду рад вдвойне.

🗓 В апреле я вернусь с новой порцией «годноты». А пока что желаю вам приятных расследований и как можно больше интересных прозрений. Пишите в комментариях, как вы справляетесь с плотным графиком, кто кого догоняет (вы зайцев или они вас?), и где берёте силы на кино одного актера :) ?

Жду ваших ответов и душевно обнимаю!
Ваш Василий ✌️

🚀Говорим про стратегию — теряем опору

Вчера закончил проводить очередной тренинг «Масштабирование Канбан-систем»

🤔 И вот интересное наблюдение: в начале всё вроде бы идёт как по маслу: участники бодро осваивают Upstream Kanban, выстраивают End2End Value Stream, обсуждают организацию командного и координационного уровня Flight Levels (привет, Клаус) и разбирают KPPM Теодоры Божевой. Но достаточно переключиться с организационных разговоров о процессах, каденциях и wip-лимитах на обсуждение стратегического уровня Flight Levels и стратегии в целом — как у людей сразу «сносит крышу»🤯

🥶 Буквально вчера, во время финальных полутора-двух часов, группа внезапно погрустнела: «Тяжело, непонятно, космос какой-то…»

🤷‍♂️ А речь всего-то шла о стратегическом уровне Flight Levels и важности стратегии (да, нужно, чтобы она вообще была), о каскадировании этой стратегии вниз и о понимании бизнес-модели компании. И в продолжение - про дерево метрик, которое связывает продукты, инициативы и ключевые показатели в единую красивую математическую модель, позволяющую понять как наши действия повлияют на конкретные рычаги экономики бизнес-модели.

👨‍🚀 И вот тут участников будто выбрасывает на орбиту без скафандра.
😱 Земля под ногами пропала, а вокруг — непонятные формулы матмодели и страшные слова про бизнес-метрики и стратегию.

🤦‍♂️ Ну как так? Почему мы так чётко понимаем процессную часть и при этом теряемся, когда разговор поворачивает к языку бизнеса? Разве то «как считаем деньги» так уж радикально сложнее того «как мы организуем работу»?

🤔 А может, дело не в сложности темы, а в том, что этот уровень видения ломает привычную оптику? Вот берёшь привычный уровень задач - «мы оптимизируем процессы!», и вдруг понимаешь: для того, чтобы нанести непоправимую пользу мало процессов, нужно ещё в продукт, стратегию и экономику посмотреть, а это явно другой масштаб видения и осмысления. Совсем не привычный, и требующий иного взгляда на вещи.

❓ Что думаете? Где здесь истинная причина этого «культурного шока» между позицией «мы про процессы» и позицией «мы про бизнес»?

✏️Напишите в комментариях ваши версии
❤️Очень интересно услышать

Когда-то 23 февраля был днем Красной армии, потом – всех военных, а теперь это про людей, которые умеют брать ответственность, даже когда тяжело. Защита – это не всегда про оружие. Это про врача, который не уходит с дежурства, про пожарного, который бросается в огонь, про инженера, который не спит ночами, чтобы техника не подвела. Это про всех, кто в нужный момент говорит: «Я разберусь», – и действительно разбирается.

Этот праздник не про громкие слова, а про тех, на ком все держится. С Днем защитника Отечества!

Подписаться на канал📱

23 февраля.
День ответственного человека. Мужчины.

С праздником, мужики!

Согласен с определением ниже👇
https://t.me/data_driven_management/359

✋Привет!
🤔Размышлял тут на тему того, как сделать практикум по анализу Канбан-метрик на основе ваших данных, а не на основе какого-то абстрактного кейса или синтетических данных?

👉 И появилась идея (излагаю ниже) . Давайте вы ее почитаете и скажете ваше мнение, что нужно ещё предусмотреть и как улучшить, ладно?

💡Идея.
А что если мы устроим практикум-марафон на 3-4 недели, в котором каждый участвует индивидуально, использует свои данные, но задание и учебные материалы для всех одинаковые, и есть общее пространство (чат или доска Миро), где можно видеть результаты других участников, поделится своими и получить совет? Каждые 3 дня мы концентрируемся на конкретной метрике, я формулирую задание,, как построить эту метрику, как разбирать ее и анализировать, в помощь вам будут инструкции, статьи и помощь зала.
Ну и добавим какие нить ачивки с призом для интереса.

Детально, пошагово, я вижу это так (длинно и нудно) :
1️⃣ вы записываетесь на марафон, и получаете в личку ссылку на чат этого марафона.

2️⃣ я объясняю в каком виде надо подготовить данные и вы выгружаете свои данные в свой личный Google Spreadsheet (тут уж сами как-нибудь) - эти данные никто не видит, только вы!

3️⃣ каждые 3 дня я в чат марафона делаю пост с инструкцией : что надо сделать с вашими данными в Google Spreadsheet, как визуализировать, на что посмотреть, какие вопросы себе задать, и куда записать ответы.

4️⃣ Скриншоты результатов вашей работы и выводы которые вы из них сделали, вы постите на лист Миро. Я смотрю, кто сделал, а кто нет, и фиксирую. Если вижу явные ошибки - разбираю и говорю как исправить.

5️⃣ параллельно с этим в режиме конкурса, вы смотрите на результаты работы других людей и дополняете их своими выводами, идеями куда ещё посмотреть и другой пользой. И в обязательном порядке подписываетесь. Авторы результатов должны будет отметить те ответы, которые для него оказались наиболее полезными, и я это фиксирую в рейтинге "лучший эксперт марафона". Тот кто по итогам марафона получит больше всего отметок "было полезно" получает возможность бесплатно отучиться на любом моем тренинге в течении года, либо передать это право другому человеку.

6️⃣ если кто-то 3 раза подряд не делаете задание и не постит результаты, то из чата вылетает, чтобы оставались только те, кто реально готов работать.

🏃‍♂️‍➡️Заданий будет не меньше 8-9, то есть марафон на 3-4 недели получается.

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

❓Что думаете? Готовы в таком участвовать?

👉Напишите в комментарии, какие риски вы видите? И что бы вы ещё предложили предусмотреть и дополнить?

Чутка статистического юмора вам в ленту 😂

Данные в действии

Класс!

Наглядное представление, как работают wip лимиты и каково значение управления потоком в скорости производства системы :)

А вот и PDF с инструкцией про Lead Time Scatterplot, которую я сделал по итогам последнего практикума

Пользуйтесь за здоровье

Она хорошо пойдет в догонку к тем инструкциям что уже были выпущены ранее:
- PDF про анализ Lead Time Distribution
- PDF про анализ Cumulative Flow Diagram
А так же к инструкциям:
- как построить Lead Time Distribution в Excel
- как построить Cumulative Flow Diagram в Excel

Данные в действии

По итогам последнего практикума, я понял, что остро не хватает простого материала-инструкции по анализу Lead Time Scatterplot

Так что я сел и сделал.

Ниже раскадровка в виде инфокарточек, а PDF-ку приложу следующим сообщением

Данные в действии

Похоже кто-то решил пофлиртовать с AI-персоной :))

Но он не поддался. 😂😂 Облико морале!

Мне кажется, или на втором скрине кто-то флиртует с AI-персоной? 😂😂😂

Но тот не поддался. Russo AI-persono obliko morale 😂😂

Спасибо вам ребята! Частично компенсирую расходы на AI-персону.

А в будущем, если получится сделать целевые сборы перед практикумом, то можно для него более крутой тариф AI-персоны взять, который сам умеет данные из файла анализировать и выводы делать. Тогда и анализ быстрее пойдёт и выводы могут быть более крутые на выходе

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

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

Хспди... Если бы вы знали, как я переживал когда готовился! 🙈

Тренингового опыта-то у меня много, но тут:

1) Никто никогда ничего такого не проводил в России - я по крайней мере не нашел. Как говорится "аналогофнет". То есть подсмотреть не у кого 🤷‍♂️ , как делать

2) Куча данных, которые можно крутить по всякому. Я уже ближе к дате проведения буквально бил себя по рукам, чтобы не делать новых срезов и визуализаций.
Там и CFD можно было немного иначе показать, и по квартальным задачам построить LTD и Scatterplot, и много чего еще можно было сделать. Постоянно мучало ощущение что недостаточно я сдела🙈

3) Тайминг. Понятно что дольше 2х часов вы после работы, да еще в пятницу, не высидите. Но любой тренер вам скажет - 2 часа это минимум на любую серьезную активность. А контента-то явно больше чем на 2 часа! А еще хорошо бы что-то объяснить, чтобы всем все понятно было.... куда это все впихнуть? Пришлось ужимать. НО вроде бы основное успели

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

5) Когда я увидел 53 регистрации, я очень, ОЧЕНЬ удивился. Но рассчитал что 60% которые придут точно - это 35 человек.
Вам любой тренер скажет, что 35 человек - это почти предел людей которым тренер может управлять и синхронно учить. Мы обычно группы больше 30 участников в принципе не берем - потому что это предел за которым наступает хаос, как ни старайся

А когда за 10 минут до начала я увидел, что на опрос ответило 70 человек 👻👻😱😱...
То мне реально поплохело... потому что количество рабочих мест я сделал из расчета на 40 человек...

И тем не менее - мы справились!
У меня самая умная, самая отзывчивая и классная аудитория канала!
Люблю вас! ❤️❤️❤️
/пошел отпаивать себя чаем/

Ничего себе! По опросу вроде бы ожидалось 35 человек, а тут вон какой аншлаг! 😱

Очень рад такому энтузиазму. Хотя команды в Zoom по 8 человек, это наверно боль

Лист Miro для практикума (read only)
https://miro.com/app/board/uXjVLiHUuF4=/?share_link_id=435275796748

Пускаю в Zoom

Через 2 минуты начинаем практикум. Ссылка для подключения выше

Через 10 минут начинаем практикум.
Жду вас по этой ссылке

ID конференции 863 1185 5755
Код доступа 457674

https://us02web.zoom.us/j/86311855755?pwd=RzqeBrNNvXh2e49gnaSeUS5y7H496M.1

Для тех, кто забыл, или не записался с Timepad.

Орг детали про практикум:
1) Начало в 18:30
2) Работаем до 20:30
3) Будем работать в Zoom, Miro, Google Spreadsheet
4) Будет работа в КОМАНДАХ, так что придется общаться
5) Это ПРАКТИКУМ, а не лекция!
‼️6) Придется много писать на стикерах, так что с телефона участвовать не получится!!!!‼️
Подключайтесь с ноутбуков или десктопов

Компоную Miro лист для практикума. Пытаюсь понять, на сколько команд готовить рабочие места?

Давайте посчитаемся - сейчас создам опрос, ответьте пожалуйста.

Ребята, кто собирается придти на практикум, КОТОРЫЙ ЗАВТРА!!!

Пожалуйста проверьте что:
1) У вас доступен Zoom
2) У вас доступен Google Spreadsheet
3) У вас доступен Miro

ОСОБЕННО если вы планируете подключаться С РАБОТЫ!!!
Потому что бывали случаи, когда из-под корпоративной сети недоступно что-то из этого

Если чего-то из этого у вас недоступно - полноценно участвовать не сможете 🤷‍♂️

Так вот в чем дело! 😂😂😂

😱Воу, воу! Ну вы даете!

56 регистраций!
Если придет хотя бы половина это будет весьма масштабно 😂😂

❤️Очень рад такому интересу с вашей стороны.
🙈Правда опасаюсь завышенных ожиданий

👻Давайте я вас немного попугаю👻👻👻, чтобы вы осознанно шли на это мероприятие, понимая риски:
1) Это будет ПЕРВЫЙ РАЗ! 1️⃣
То есть, несмотря на всю подготовку с моей стороны, наверняка будут какие-то косяки🤦‍♂️, накладки❌, неточности и прочее 🤷‍♂️

2) Этого НИКТО и НИКОГДА не проводил ничего подобного! 🙈
То есть, это ЭКСПЕРИМЕНТ 🧪!
И вы будете первопроходцами 🐭, набивающими первые шишки 🥥, обретающие бесценный опыт на свою ж...

3) Предмет практикума - СКУЧНЕЙШИЕ ЦИФРЫ🥱, графики📈, диаграммы📈 и прочее.
Никакой развлекухи! Все по звериному серьезно👨‍🔬.

4) Придется ДУМАТЬ! 🤯
И много🤯🤯🤯.
Это практикум, а не лекция.
Надо будет делать упражнения, и прикладывать усилия, чтобы сделать правильные выводы.

❓Ну что, все еще хотите участвовать?

🤗Тогда WELCOME в эту пятницу!

🔥 Как обычно проводят субботний вечер?
— Кто-то отдыхает 🍹
— Кто-то залипает в Netflix 🎬
— А я… методом "найти-заменить" убираю "мусор" из исходных данных! 😎

💾 Подготовка данных для практикума — это когда ты думаешь, что будешь анализировать сложные метрики, и графики, а на деле:
✅ Чистишь таблицу от служебных колонок
✅ Исправляешь криво вбитые даты
✅ По 100 раз перепроверяешь формулы и графики
✅ Находишь и исправляешь все дубликаты
✅ Ищешь, какие слова могут выдать отрасль клиента 😬
✅ Расшифровываешь аббревиатуры (ШК? ПФ? БП? Теперь всё понятно)

💡 Кульминация: В какой-то момент я понял, что самое сложное - не очистка данных, а лингвистическое расследование - как сделать так, чтобы набор данных не намекал на область деятельности клиента, данные которого я взял за основу учебного кейса? 😂

🚀 Практикум по Канбан-метрикам — в следующую пятницу, 7го февраля. Учебные данные почти готовы, осталось только совместно с вами их проанализировать.

👀 А как ты проводишь субботний вечер?

Многие из вас наверняка слышали, что Agile Alliance влился в PMI. Сами они заявляют, что всё останется так же, как было, только теперь с помощью PMI. Вчера по этому поводу у них была большая встреча. Надеялся написать вам что-то интересное по её итогам, но, к сожалению, подключиться не получилось. Да и Бог с ним.

⚡ Хоть этой новости уже три недели, всё же хочется поделиться размышлениями о том, что она может означать. Сразу скажу, что за PMI я плотно не слежу (хотя стандарт для проектных офисов жду по старой памяти), поэтому буду рассуждать исключительно со своей стороны.

🔥 Признак кризиса Agile Alliance как организации
Время сейчас сложное: кризисы, нестабильность — думаю, всё понятно. Хотя структура Agile Alliance старая и уважаемая, но бизнес есть бизнес. Скорее всего, мы увидим обновление гибкой линейки продуктов в PMI. Напомню, что они уже покупали Disciplined Agile, и сертификации по нему есть на сайте, но продавались они плохо. Настолько, что DA задвинули куда-то подальше: на сайте с ходу не найдёшь. Видимо, одна из задач этого союза — освежить линейку продуктов. Пока только PMI ACP (аналог PMP для Agile) осталась на главной странице сертификаций.

⚙️ Признак коммодизации Agile
Это может означать, что PMI признал Agile обязательной компетенцией для всех проектных менеджеров. Однако здесь встаёт вопрос: зачем им Agile Alliance, если у них уже был Disciplined Agile? Видимо, они не смогли сохранить и развить компетенции по Agile у себя внутри. Это моё субъективное мнение, основанное на изучении некоторых курсов, материалов и вопросов по Agile в PMP.

✨ Я не настроен негативно, скорее скептично
Несмотря на вышеописанное, у меня есть определённые надежды, и они не беспочвенны:
- Agile Practice Guide, приложение к 6-й редакции PMBoK, был очень хорошим. Его создавали как раз ребята из Альянса. Это показывает, что у PMI и Agile Alliance есть успешный опыт совместной работы.

- Я искренне считаю, что в 2025 году быть проджект-менеджером и не владеть Scrum, Kanban и гибким подходом в целом — это не дело. Такой союз может способствовать популяризации гибких подходов, что, в свою очередь, может привести к созданию качественных гибридных методик и их применению за пределами IT. Например, мы любим обсуждать такие кейсы на Agile Days. Более того, этот союз может, пусть даже косвенно, поспособствовать легализации гибких подходов в госсекторе. Знаю точно, что за PMI там следят даже сейчас.

📖 Вопрос с Agile в PMBoK 7
Мне могут возразить: "Но ведь Agile уже вписан в 7-й PMBoK". Да, это так. Но то, как его вписали, только подтверждает, что союз PMI с Agile Alliance был крайне необходим.

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

✋Друзья!
👉Специально для тех кто в Питере, на следующей неделе будет интереснейшее оффлайн-событие!
🎆Наконец-то можно встретиться вживую, и пообщаться в кругу единомышленников. А так же послушать умные доклады, и задать животрепещущие вопросы.

😊Организатор - Максим Фролов, администратор канала российского Канбан-сообщества kanban_talks, матерый Delivery Manager, и руководитель с опытом работы в Тинькофф, HeadHunter и других крупных компаниях нашей страны.

👉Всех зову на Delivery Meetup SPB №9!

🙃Когда - 6 февраля (четверг), с 19:00 до 21:00, а потом - афтерпати
🙃Где - СПБ, Музей Леста, площадь Карла Фаберже, 8В

Прийти послушать вживую - https://delivery-community-spb.timepad.ru/event/3184456/
Трансляция будет, регистрация не нужна!

Кто и о чем будет рассказывать:

1. “Как победить звериный оскал капитализма с помощью обратной связи"
Ирина Матвеева, управляющий партнер Escalate, HR & CX эксперт, лидер сообщества IT HR, коуч
- как переубедить стейкхолдера изменить позицию;
- как поверить, что твои люди – лучшие, хотят и могут;
- как с помощью обратной связи дать людям самоорганизоваться и взять ответственность за результат на себя.

2. "Путь DevOps команды в сервисную парадигму"
Алекс Цыбульник, Аккредитованный Тренер Канбан Стандарт, Автор и ведущий Kanban podcast, продюсер конференций Flowdays, Agile среда в ПСБ
- в чем отличия DevOps команды от продуктовой на примере визуализации производственного процесса;
- как команда оказалась в завале и как с этим помогли справиться канбан-практики;
- какую роль сыграли классы обслуживания в работе с ожиданиями заказчиков.

3. “Айтишники дуреют от этой прикормки: инженерная культура, 101”
Секретный спикер
- что это и кому может быть интересно и полезно;
- почему в delivery без инженерной культуры грустно;
- как уложиться в сроки, бюджет и качество, и получить за это "ура" всей команды;
- почему многочисленные курсы без понимания культуры не сделают из вас действительного цельного специалиста.

Подписывайтесь на канал @delivery_community_spb
Регистрируйтесь на митап 🙂
https://delivery-community-spb.timepad.ru/event/3184456/

1C-ники отзовитесь!

Ребята я готовлю доклад для конференции 1С-ников, и хочу воспользоваться мудростью группы, чтобы сделать его максимально близким для аудитории. Доклад будет посвящен статистике работы с инцидентами.

Сам я в прошлом web-разработчик, и у меня знаний по 1С совсем нет 🤷‍♂️
А мне нужно понять, какие факапы или инциденты характерны именно для 1С- разработки? Что там такого есть, и как это обычно называется в среде 1С-разработчиков?

Накидайте пожалуйста в комменты - какие факапы и инциденты наиболее часто происходят при разработке на 1С?

📚 Относительно недавно я заполучил в свои руки книгу "Kanban Maturity Model". Было это непросто, потому что книга доступна только в печатном виде.

🤔Я со скепсисом отношусь к самой модели KMM, но не мог пройти мимо главы "Understanding Lead Time" в приложении это книги. Начав ее переводить, я понял, что мне надо записывать то, что я прочитал, потому что глава написано не простым языком, и если не записать то, что написано в начале, можно не понять что там в конце.

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

🤷‍♂️И как-то так само собой получилось изложение этой главы на русском языке, которым я хочу поделиться с вами.

👉О чем этот текст?
📈Вы знаете, что с помощью Lead Time Distribution Chart можно прогнозировать Lead Time с вероятностью 80-90%. Я про это даже целую PDF'у сделал.

🚨Однако есть проблема: не во всех случаях, этому прогнозу можно доверять. Это сильно зависит от характера распределения Lead Time Distribution Chart. Есть распределения которые обеспечивают хорошую надежность прогноза, а есть такие распределения, по которым лучше прогнозов не делать вообще, потому что полученные прогноз будет очень ненадежен. И вот об этом - данная глава, изложение которой я вам предоставляю.

‼️ВАЖНЫЕ ДИСКЛЕЙМЕРЫ!
1️⃣ Это не дословный перевод, а вольный пересказ с дополнениями и сносками.
2️⃣ В исходном тексте есть спорные моменты, поэтому я написал предисловие, которое вам лучше почитать, а то в какой-то момент чтения у вас могут появиться непонятки.

❤️❤️❤️Хочу выразить огромную благодарность Максиму Фролову @britishpop, Диме Челышеву @Glinco, и Артуру Темирову @atemirov за вычитку, критику и вовремя заданные вопросы по тексту. Ребята, без вас ничего не получилось бы! Спасибо вам огромное! ❤️❤️❤️

Я не решился выложить эту простыню на vc, но предоставляю вам ссылку на Google Doc
Вопросы, комментарии, корректировки, предложения - пишите в комментарии к этому посту

👉 Приятного чтения
——————————————
Данные в действии