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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А ведь если подумать - в современном мире практически нет бизнеса без ИТ-составляющей, а значит, менеджмент разработки ПО стал настолько значим, что часто подминает под себя все остальные процессы в компании.
А что у нас пока что мейнстрим в области разработки ПО? Пока еще 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)?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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