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

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

✌️Во-вторых, я погрузился в аудит рабочих процессов большого ритейлера. Представьте себе интервью с 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 в следующем сообщении)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Данные и PR 📊

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

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

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

На прошлой неделе мы с вами обсуждали, что нужно для запуска работ по Канбан-методу. И это обсуждение было не просто так! Часто, отвечая на этот вопрос, я слышу: "Да просто проведите им 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 — добро пожаловать! 🚀

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

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