Данные в ДейSTвии

Всем привет! Если кому то актуальна тема управления изменениями, то буду рад помочь вам с этим на своём авторском тренинге Lean Change Management 👆 Тренинг практико-ориентированный. На вашем кейсе разберем: - видение изменения, - периметр измений - составим бэклог изменений для проверки гипотез применимости, актуальности и совпадения с культурой компании - научимся оценивать уровен сопротивления - разработаем план обхода сопротивления, через приживление новых небольших привычек и создания готовности к изменениям - научимся выявляться лидеров мнений, экспертных лидеров и других персон, важных для изменений - отработаем продажу изменений заказчику через его картину мира Буду рад всех видеть! Ближайший тренинг в конце апреля. Ссылка выше 👆

Почему одни изменения приживаются, а другие умирают в презентации? Часто проблема не в людях. И даже не в пресловутом «сопротивлении». Проблема в том, что изменениями пытаются управлять как механизмом: линейно, сверху вниз, по заранее нарисованной схеме. Хотя организация — это не станок. Это сложная адаптивная система. Отсюда главный вопрос: что, если сопротивление — не помеха, а полезный сигнал? Сигнал о том, что само изменение плохо спроектировано или внедряется не тем способом. В новой статье разбираем именно это: • Почему так много трансформаций проваливаются не на этапе идеи, а на этапе столкновения с реальностью; • Где классические модели (вроде ADKAR и 8 шагов Коттера) помогают, а где начинают упрощать слишком живую систему; • Почему иногда лучше работают не директивы, а итерации, обратная связь и агентность команд; • И почему вместо одного маршрута для всех иногда важнее задать границы изменений, а не строить колонну. Внутри — пять подходов к change management, их логика, ограничения и контексты, где каждый из них уместен. 👉 Читать статью целиком в блоге Сохраняйте пост или пересылайте коллеге, который всё ещё думает, что change management — это просто хороший план коммуникаций. Еще подробнее говорим об этом на тренинге Lean Change Agent (23-24 апреля, места пока есть;)

Всем привет! Нашлось немного свободного времени, так что я навайбокодид небольшое обновление на игру https://kanbangame.ru/ Суть изменений: для читабельности, теперь разные события подсвечиваются разным цветом и иконками - так что не спутаете и не пропустите. А то многие жаловались, что события выглядят однообразно, и их часто пропускают мимо. Приятной игры! 👍

Всем привет! Знаю, что задержался с обещанными скринкастом, новыми функциями игры и статьями 🤷‍♂️, но жизнь внезапно подкинула проблем, которые надо срочно решать 🛠 Прошу вас проявить терпение и понимание 🙏 Надеюсь, что на этой неделе я справлюсь со всем, что на меня навалилось, и продолжу публикации Всем добра! 🙌

Новая серия ПрожекторСэмаАльтмана кому-то мощно попала в нерв 😂😂😂

Дорогие женщины! Спасибо вам, что вы есть! Ради вас мы - мужчины - готовы покоять вершины, добывать букеты 8 марта, работать до упаду, строить дома, добиваться успехов. И на все это вдохновляете нас вы! С праздником! Будьте счастливы! И вдохновляйте нас дальше! 🎉🎉🎉💃💃💃🍾🍾🍾🥂🥂🥂

Всем привет! Как и обещал, готовлю скринкаст про то, как я с помощью ИИ +R +Process Mining делал археологию рабочих процессов в JIRA Но вот вопрос : куда это видео лучше выложить для вашего удобства? Телега тормозит, Ютуб под Тремя Буквами... 🤷‍♂ Поэтому пройдите пожалуйста опрос ниже, чтобы я понял как лучше действовать?

Простите 😂😂😂 Это точно не формат канала, но мне так смешно, что я хочу куда-то сохранить на память 😂😂😂😂 Вальтер Шелленберг....😂😂 полосатый... Де Тревилю!! 😂😂😂 Который за зайцем... чтоб фотографию...😂😂😂 Нет я не могу 😂😂😂😁😁😁😆😆😆

Если смотреть "Простоквашино" с закрытыми глазами, вы услышите, как Вальтер Шелленберг выговаривает графу де Тревилю за то, что тот купил кеды вместо валенок.

Простите 😂😂😂 Это точно не формат канала, но мне так смешно, что я хочу куда-то сохранить на память 😂😂😂😂 Вальтер Шелленберг....😂😂 полосатый... Де Тревилю!! 😂😂😂 Который за зайцем... чтоб фотографию...😂😂😂 Нет я не могу 😂😂😂😁😁😁😆😆😆

В прошлом ПрожектораСэмаАльтмана мы подводили итоги 2025 года и обсуждали, как разработчики кодят вайб-кодом быстрее, чем продакты успевают генерировать идеи. В новой, разговорной серии ПрожектораСэмаАльтмана мы разбираем, как перестать наступать на цифровые грабли в попытках корпоратов оседлать ИИ, и сделать из него ракету. В этом выпуске обсуждаем: ➡️ Почему нельзя "просто раздать всем ChatGPT" и получить эффект ➡️ Какие 3 шага нужно пройти до внедрения ИИ на уровне компании ➡️ Почему данные в вашей Jira скорее всего не подходят для обучени ИИ, и что с этим делать ➡️Корпоративный феодализм, как препятствие к ИИ-трансформации ➡️ИИ-продукты из воздуха: Реальный кейс о том, как банк может заработать на недвижимости, не привлекая риэлтеров ➡️Где реально находится бутылочное горлышко которое надо ускорять с помощью ИИ? Говорим свободно, с юмором, в меру собственного понимания происходящего. А в комментариях ждем от вас идеи и темы для следующих разборов! Смотреть новый выпуск тут: https://www.youtube.com/watch?v=QIijsYe-av0

🛠 Первый апдейт подъехал! Чейнджлог kanbangame.ru от 3 марта Ребята, спасибо всем, кто тестил игру, кидал баги в YandexForm и набрасывал идеи под прошлым постом! Вы — лучшая QA-команда 🔥 Я не стал откладывать в долгий ящик и уже выкатил свежий патч, который тюнит некоторые механики Что изменилось: 1) 🚨 Прощай, амнезия на дедлайны! Для карточки F1 (Fixed Date 1) добавил заботливые напоминалки на 11, 14 и 16 дни. Теперь не получится сказать «ой, я забыл про штраф». Большое спасибо @ILarchenko за отличную наводку! 🙌 2) 📈 Прокачали CFD (Cumulative Flow Diagram) Во-первых, успокоил странно скачущий в дни релизов график! Дело оказалось в задвоении задач в колонке Ready To Deploy в дни релизов 🤷‍♂️ Fixed Спасибо @sergeykolokolov за зоркий глаз! 👁 Во-вторых, вывел легенду по статусам. Теперь график можно нормально читать, а не гадать по цветам. 3)🖱 «А как заставить их работать?!» Добавил в Правила наглядный скриншот как перетаскивать ресурсы на карточки. Теперь сразу понятно, что иконки сотрудников нужно буквально брать за шкирку (drag-and-drop) и тащить на карточки. Спасибо анонимному герою из Яндекс.Форм, который честно признался, что с ходу механика непонятна! Вы спасли нервы будущим игрокам. 🦸‍♂️ 🎮 Играть тут: https://kanbangame.ru/ PS Следите за анонсами обновлений - иначе пропустите новые механики 😁

🤖 Как я навайбкодил бесплатный симулятор работы по Kanban — kanbangame.ru Я давно использую симулятор kanbanboardgame.com (основанный на GetKanban v2) на своих тренингах по Канбан-методу. К сожалению, с недавних пор он стал доступен только под VPN 🤷‍♂️. Использовать его стало практически невозможно 🙈 Я решил эту проблему радикально, и сделал свой аналог с блекджеком и ... некоторыми улучшениями 😁 🛠 Как это было создано: За 4 часа я навайбкодил рабочий прототип в Cursor, а следующие две недели ушли на сверку логики, экономики и корректировку механик. Визуал пока базовый, например, иконки ресурсов сильно упрощены. Главной целью было воссоздать логику и механики, а красоту можно накрутить и позже. 🎮 Где играть: Сам симулятор: kanbangame.ru - доступен совершенно бесплатно. ⚙️ Что я изменил по сравнению с оригиналом: 🔹 Настраиваемая экономика: на старте теперь можно выбрать экономическую модель игры — подписочная или с фиксированной стоимостью карточек. 🔹 Буфер перед релизом: добавил колонку Ready To Deploy как зримый накопитель готовых задач. Мне кажется, этого не хватало в оригинальной игре. 🔹 Понятный эффект Intangible-задач: при релизе зеленых карточек всплывающее окно теперь четко описывает эффекты ускорения. В оригинале механика их работы объяснялась очень общо. 🔹 Новая аналитика: добавил полноценный графики Lead Time Distribution и точечный график Lead Time Scatterplot. В оригинальной игре первого графика вообще нет, а второй выглядит на мой взгляд странно Приглашаю подписчиков использовать игру для развития навыков управления потоком задач и анализа метрик! 🐞 О найденных багах, пожеланиях и комментариях пишите, пожалуйста, сюда (не надо в личку) 👇Вопросы, благодарности, пожелания к механикам - пишите в комментариях👇

Ура! 🎉🎉🎉Пост с рассказом про использование Process Mining + ИИ набрал 50 лайков! Значит, на днях я запишу скринкаст, как я делал аналитику большого массива данных, заставив ИИ реализовать все что мне нужно, и получить итоговый отчет Не перекеключайте канал 😁

Вижу после поста в kanban_talks в канал пришли новые подписчики ✋ Давайте я вас сориентирую, куда вы попали, и что вы тут можете найти 🙌 Итак: это авторский канал Василия Савунова, эксперта в Data Driven Management, Канбан-практика, ИИ-эксперта и Agile-коуча. Пишу я не регулярно, и в основном это лонгриды про менеджмент на основе данных, про то, как прогнозировать сроки с вероятностью 85-90%, а так же про ИИ - и как его использовать для прогнозирования и не только С чего вам лучше начать читать этот канал: 👉 Customer Lead Time, System Lead Time, Cycle Time, First Touch Time - как во всем этом разобраться?! 👉 Как в Excel построить частотную диаграмму времени выполнения? 👉 Инструкция - как анализировать диаграмму времени выполнения задач? 👉 Инструкция - как использовать Cumulative Flow Diagram? 👉 Как спрогнозировать время выполнения 1000 задач в бэклоге? 👉 Вебинар Flight Levels: Как спроектировать систему управления всеми уровнями Про статистику и метрики: 👉 Описательная статистика для менеджера: Часть 1, Часть 2 (Часть 3 еще пишется) 👉 Кандидатский минимум анализа Канбан-метрик 👉 Вебинар "Метрики для дашборда руководителя" Про ИИ: 👉 Продюсирую видео-проект "ПрожекторСэмаАльтмана" 👉 Вебинар "5 ловушек ИИ для менеджера" 👉 Лонгрид "JIRA-археология с помощью ИИ и Process Mining" Так же периодическия провожу практикумы по анализу метрик - примерно раз в квартал И выступаю на конференциях с интересными докладами, например: 👉 Как руководителю управлять командой, на основе метрик? - доклад на TeamLead Conf 2023 Я открыт в общению, и вопросам, так что не стесняйтесь, спрашивайте в коммментариях - обязательно отвечу

[Продолжение предыдущего поста. Часть 3] 🍿 💡 Развязка: свежесть ≠ количество Я вспомнил золотое правило классиков Канбан-метода ( Трой Мадженнис, Даниэль Ваканти) при анализе метрик рабочего процесса:

«Свежесть данных важнее их количества» (c) умные люди

Если у нас на руках «простыня» данных за 5 лет, не стоит радоваться. В IT-разработке 5 лет — это целая эпоха. За это время могло измениться всё: 🎭 Состав команды (кто-то выгорел, кто-то пришел); 👔 Менеджмент (новые метлы по-новому метут); 🌍 Предметная область; 🏗 Стек технологий; ...и еще вагон нюансов. Любое из этих изменений меняет «физику» процесса. 🌪 А значит, статистика за 5 лет показывает не то, что происходит сейчас, а «среднюю температуру по больнице» с учетом всех кризисов и реформ прошлого. Я уточнил у заказчика хронологию событий. И бинго! 🎯 Выяснилось, что в этом проекте за 5 лет сменилось три состава команд и два менеджера. Каждый «оптимизировал» процесс под себя. Когда я запустил алгоритм Probabilistic Activity Tagging отдельно по годам, хаос превратился в стройную историю: 📜 Эпоха 2020-2022 Точкой Принятия Обязателств явно был статус «Analysis» (вероятность 65%) ⚡️ Эпоха 2023 – н.в. ТПО сдвинулась на "In progress" ( вероятность 73% ) Даты смены ТПО четко совпадали приходом новых менеджеров 🤷‍♂️ 🏁 Итог Мы договорились с заказчиком убрать «хвост» старых данных и анализировать только последние 2 года (период стабильности). Это дало чистые метрики, четкое разделение Upstream/Downstream и адекватные данные для аудита. 💼 В чем профит для вас? Если вы рулите армадой из 10–50 команд, вы наверняка смотрите в дашборды с метриками CLT, ULT, DLT. Но чтобы эти буквы имели смысл, нужно знать три координаты: 🐣 Точка создания (Open) 💀 Точка закрытия (Done) 💍 Точка принятия обязательств (ТПО) А дальше — чистая математика: 🧮Customer LT=Done-Open 🧮Upstream LT=ТПО-Open 🧮Downstream LT=Done-ТПО В каждой команде «своя атмосфера», и эти точки могут гулять по разным статусам. И тут на сцену выходят эвристики, о которых я писал выше 🚀 С их помощью можно автоматически отследить, когда ТПО (или другая точка) вдруг «поехала» в сторону. 📡 Это сигнал - процесс изменился, метрики врут, пора идти к команде с вопросами. И вам даже не нужно было присутствовать на дейликах, чтобы это узнать. P.S. Весь код для анализа (R + эвристики) я писал с помощью LLM 🤖🤝🧔 Если это пост наберет 50 лайков 👍, я напишу статью или запишу скринкаст, где покажу, как использовать LLM, чтобы создавать такие аналитические инструменты, даже если вы не программист.

[Продолжение предыдущего поста. Часть 2] 👆 🧩 Алгоритм 2. Probabilistic Activity Tagging (Эвристический скоринг) Дальше нужно было найти ту самую точку принятия обязательств (ТПО) 🎯 Я разметил очевидные статусы (Буферы, Открытие, Закрытие), чтобы отделить их от зоны активной работы. Но этого мало. Нужно было понять, какой из Work-статусов — тот самый (ТПО). Для этого я сделал две вещи: 1) я определения ТПО взял несколько паттернов Lifecycle Transition из Process Mining и дополнил своими - из рабочего опыта; 2) ввел скоринговую систему - алгоритм проходил по истории каждой задачи и начислял (или отнимал) баллы за наличие определенных паттернов. Всего я использовал 7 паттернов, чтобы исключить случайности. Вот самые интересные: 🚦 Фазовый сдвиг (Buffer → Work) Самый сильный сигнал (+ баллы). Если пассивный статус-буфер (например, Ready to Develop или Backlog) сменяется активным Work-статусом — это с высокой вероятностью и есть момент взятия обязательства. 🚫 Запрет на продолжение (Work → Work) Защита от ошибки (- баллы). Если предыдущий статус уже был рабочим, то текущий точно не может быть точкой старта. Это помогает не принять середину работы (например, Code Review) за её начало. 👶 Фильтр «Слишком рано» Аномалия (- баллы). Если Work-статус является самым первым в цепочке, то это какая-то аномалия или дисфункция. В рабочем workflow настоящий Commitment Point обычно находится посреди процесса. ...и так далее по остальным паттернам. 📊 Что в итоге? На выходе я получил список статусов с баллами, которые для наглядности перевел в проценты вероятности. И тут алгоритм выдал парадокс 🤯 В одном из ключевых проектов два статуса набрали абсолютно одинаковый вес: ⚖️ Analysis — 41% ⚖️ In Progress — 41% (остальные проценты размазались тонким слоем по другим статусам) Как же так? Алгоритм сломался, и не может определиться? 🤷‍♂️ О том, как я распутал этот узел и нашел единственно верную ТПО — в финальном посте 👇 [продолжение в следующем посте]

🗿 JIRA-археология с помощью Process Mining ⛏️ Кратко: 27 000 строк логов 📜, 5 лет хаотичных процессов 🌪, конец года ❄️ и Process Mining⛏️ Сеттинг: Огромное подразделение разработки Data-продуктов в одной огромной компании 🏢 20+ внутренних заказчиков, 10 направлений разработки. 😤 Бизнес жалуется: «Мы не понимаем, когда Data-подразделения сделают задачи! Их обещания по срокам не сбываются! Мы не знаем как нам выполнять обещания, которые мы даем нашему руководству». 🛡 Департамент Data-продуктов оправдывается: «У нас все сложно, контекст меняется часто, а бизнес постоянно меняет приоритеты! Проектов больше чем людей!» 🆘 Запрос классический, но болезненный: «Помогите нам разобраться, кто прав, расскажите как нам сделать работу прогнозируемой». На дворе декабрь ❄️, конец года, у всех горят дедлайны 🔥. Доступ к людям ограничен, «посидеть и поговорить» с представителем каждого из 10 проектов нереально! 🚫 У меня на руках — выгрузка из трекера: 27 000 задач за 5 лет 💾 🕵️‍♂️ Проблема: Вавилонская башня в Excel Открываю файл лога статусов и вижу: 1️⃣ 30 разных статусов, из который часть используется в одних проектах, часть в других. Часть вообще не используется. 2️⃣ 4 статуса, означающих закрытие задач 🏁 3️⃣ 5 статусов означающих на открытие задачи 🚦 4️⃣ 7 статусов-буферов 🛋 🤯🤯🤯🤯🤯 Но главная проблема: десяток промежуточных Work-статусов, среди которых спрятана точка принятия обязательств (ТПО)📍! А без знания точки принятия обязательств не возможно понять границу между ⬆️Upstream (выбор и подготовка задач) и ⬇️Downstream (разработка). Анализировать вручную 27 тысяч строк — это месяца два работы 🐢 Напомню - декабрь, все в мыле 🧼, времени поговорить ни у кого нет. А тем более разобрать 10 разных проектов. 🤖 Решение: эвристики Process Mining Я решил не гадать, а использовать два алгоритма Process Mining, адаптированные под Kanban. С помощью ИИ-шки написал код на языке R и прогнал данные. Алгоритм 1. Trace Variant Analysis (Анализ вариантов процесса) Для начала я взял каждую задачу и по последовательности дат в логе, восстановил её реальный путь по статусам. Получилась таблица из двух полей:

🆔 ID задачи, 🔀 Workflow ( последовательность статусов )

Посчитал частоту повторения одних и тех же workflow - получил таблицу частотности workflow 📊 Например вот так: —————————————————————————————— N | Workflow | Частота —————————————————————————————— 1 | Open -> Ready To Develop -> In Progress -> Done | 1234 2 | Open -> In Progress -> Done | 976 3 | Open -> Analysis -> In Progress -> Close | 650 И тд Очевидно самый частый workflow, который включает в себя статус открытия, промежуточные статусы и статус закрытия - скорее всего и есть основной 🏆 😱 Сюрприз: Оказалось, что примерно 20-30% задач в каждом проекте имеют путь "Open -> Closed". Это «шум», мусорные задачи или массовые чистки бэклога. Они искажали статистику, поэтому я их отфильтровал. [продолжение в следующем посте] 👇