Scrum Mastery Club
Kanalga Telegram’da o‘tish
Мы предлагаем уникальные программы для профессионального развития и поддержку безопасного сообщества. Наша цель - чтобы каждый из участников мог вместе с единомышленниками расти быстрее, чем в одиночку.
Ko'proq ko'rsatish1 080
Obunachilar
+124 soatlar
+77 kun
-130 kun
Ma'lumotlar yuklanmoqda
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Oktabr '26Okt '26
Oktabr '26
+18
0 kanalda
Sentabr '26
+14
2 kanalda
Get PRO
Avgust '26
+28
1 kanalda
Get PRO
Iyul '26
+41
1 kanalda
Get PRO
Iyun '26
+35
0 kanalda
Get PRO
May '26
+31
1 kanalda
Get PRO
Aprel '26
+26
1 kanalda
Get PRO
Mart '26
+25
1 kanalda
Get PRO
Fevral '26
+27
1 kanalda
Get PRO
Yanvar '26
+17
0 kanalda
Get PRO
Dekabr '25
+25
0 kanalda
Get PRO
Noyabr '25
+25
1 kanalda
Get PRO
Oktabr '25
+26
0 kanalda
Get PRO
Sentabr '25
+22
0 kanalda
Get PRO
Avgust '25
+27
0 kanalda
Get PRO
Iyul '25
+20
1 kanalda
Get PRO
Iyun '25
+30
1 kanalda
Get PRO
May '25
+48
1 kanalda
Get PRO
Aprel '25
+36
0 kanalda
Get PRO
Mart '25
+31
1 kanalda
Get PRO
Fevral '25
+34
1 kanalda
Get PRO
Yanvar '25
+43
1 kanalda
Get PRO
Dekabr '24
+40
1 kanalda
Get PRO
Noyabr '24
+40
2 kanalda
Get PRO
Oktabr '24
+42
1 kanalda
Get PRO
Sentabr '24
+33
1 kanalda
Get PRO
Avgust '24
+62
2 kanalda
Get PRO
Iyul '24
+43
1 kanalda
Get PRO
Iyun '24
+39
0 kanalda
Get PRO
May '24
+31
0 kanalda
Get PRO
Aprel '24
+30
1 kanalda
Get PRO
Mart '24
+42
0 kanalda
Get PRO
Fevral '24
+69
0 kanalda
Get PRO
Yanvar '24
+63
0 kanalda
Get PRO
Dekabr '23
+60
0 kanalda
Get PRO
Noyabr '23
+41
0 kanalda
Get PRO
Oktabr '23
+59
0 kanalda
Get PRO
Sentabr '23
+529
0 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 18 Oktabr | +2 | |||
| 17 Oktabr | +1 | |||
| 16 Oktabr | +1 | |||
| 15 Oktabr | +6 | |||
| 14 Oktabr | 0 | |||
| 13 Oktabr | +1 | |||
| 12 Oktabr | 0 | |||
| 11 Oktabr | +1 | |||
| 10 Oktabr | 0 | |||
| 09 Oktabr | 0 | |||
| 08 Oktabr | +1 | |||
| 07 Oktabr | 0 | |||
| 06 Oktabr | +1 | |||
| 05 Oktabr | +1 | |||
| 04 Oktabr | 0 | |||
| 03 Oktabr | +1 | |||
| 02 Oktabr | +1 | |||
| 01 Oktabr | +1 |
Kanal postlari
ИИ ускоряет работу. Но почему бизнес не становится быстрее?
Сегодня ИИ может за минуты подготовить аналитику, написать код, обработать документы или предложить решение. (Сам проверял это вчера проектируя новую странице нашего сайта).
Но что происходит дальше, если вы работаете в организации?
Результат ждет проверки. Решение - согласования. Задача - следующего участника процесса.
Мы ускоряем отдельные операции, но сама организация продолжает работать по старым правилам.
Возможно, главный вопрос уже не в том, как внедрить ИИ. А в том, как перепроектировать организацию с его появлением.
Именно этому посвящен новый цикл клуба Scrum-Mastery.
«Архитектура организации с ИИ»
С 22 октября мы проведем пять практических встреч (я их назвал эти встречи - “лаборатории”), в которых будем разбираться:
- Как меняются потоки создания ценности.
- Как распределять работу между людьми и ИИ-агентами.
- Как измерять реальный эффект.
- Как менять управление, не теряя доверие команды.
- Как спроектировать новую операционную модель.
Как обычно, это не лекционный курс об инструментах ИИ. Это совместная практическая работа для Scrum-мастеров, Agile-коучей, руководителей и консультантов.
Старт: 22 октября.
По четвергам, 19:00–21:00 МСК.
Участие в клубе - 5 900 ₽ в месяц.
В новом цикле - пять практических встреч.
Программа и вступление:
https://scrum-mastery.ru
Присоединяйтесь. Будем исследовать, как меняется сама архитектура организаций.
| 2 |  Красивая Карта гипотез может быть совершенно бесполезной
Вы определили цель. Выбрали метрики. Нашли субъектов. Описали их боли и желания. Сформулировали гипотезы.
Соединили все стрелочками. Получилась красивая, логичная карта.
Но означает ли это, что у вас есть работающая стратегия?
Совсем не обязательно.
За время работы с Картой гипотез я убедился: самые опасные ошибки - не те, которые сразу бросаются в глаза. А те, которые скрываются за внешне правильной конструкцией.
Например:
🔸 Метрики улучшаются, а цель не достигается. Значит, мы измеряем не то, что действительно важно.
🔸 Субъекты определены, но их влияние переоценено. Мы пытаемся изменить поведение людей, от которых результат зависит лишь косвенно.
🔸 Боли и желания выглядят убедительно, но не проверены. Стратегия строится на наших предположениях о людях, а не на понимании их реальной мотивации.
🔸 Гипотезы на самом деле оказываются задачами. Мы знаем, что собираемся сделать, но не можем объяснить, почему это должно изменить поведение субъекта и повлиять на метрику.
И это только часть возможных ошибок.
Самое интересное начинается, когда мы проверяем не отдельные элементы, а всю логику стратегии.
Действительно ли выбранные субъекты способны повлиять на результат? Какие гипотезы критичны? Что нужно проверить в первую очередь? Где у нас просто красивые предположения?
Именно этим будем заниматься на программе «Карта гипотез. Практик 2».
Мы пойдем глубже, чем на первой ступени:
- разберем типовые и неочевидные ошибки в картах;
- научимся проверять связи между целями, метриками, субъектами и гипотезами;
- будем оценивать силу влияния субъектов;.
Практик 1 — научиться строить Карту гипотез.
Практик 2 — научиться видеть, насколько хороша построенная стратегия и что в ней нужно изменить.
📅 19, 21 и 23 октября, с 16:00 МСК.
Три дня углубленной практики.
🔗 Программа и регистрация
И напоследок один вопрос.
Вспомните последнюю стратегию, над которой вы работали. На чем основана ваша уверенность, что выбранные гипотезы действительно приведут к результату?
На проверенных связях и данных? Или на том, что все выглядит логично? | 47 |
| 3 |  💡А что, если Карту гипотез использовать для личной стратегии?
Мы привыкли работать с Картой гипотез в бизнесе: цели, метрики, субъекты, гипотезы. Но что, если применить тот же подход к личной стратегии?
Например, человек хочет сменить профессию, выйти на новый уровень дохода или запустить собственный проект.
Обычно работа начинается с целей и плана действий. Но есть проблема: наличие цели и списка задач еще не означает, что у человека есть стратегия.
Здесь Карта гипотез помогает задать другие вопросы:
- Какие изменения действительно приведут к желаемому результату?
- От каких людей и их поведения зависит успех?
- Какие предположения мы принимаем за факты?
- Какие гипотезы стоит проверить, прежде чем вкладывать время и ресурсы?
И что особенно интересно - это инструмент не только для себя, но и для работы с другими людьми.
Для коучей, консультантов, наставников и фасилитаторов, которые помогают клиентам принимать стратегические решения.
На программе «Карта гипотез. Практик 2» мы будем разбирать в том числе применение метода к личной стратегии. А еще - учиться находить ошибки в картах, проверять гипотезы и расставлять приоритеты.
🗓 Старт — 19 октября.
🔗 Программа и регистрация
А вы пробовали использовать инструменты бизнес-стратегии для решения личных задач - своих или клиентских? | 117 |
| 4 | Почему внедрение ИИ не делает организации эффективнее? Новые выводы Gartner об организационном дизайне
На прошлой неделе Gartner представил результаты нескольких исследований, которые, на мой взгляд, очень точно показывают одну из главных проблем современных трансформаций.
Мы научились достаточно быстро внедрять новые технологии, но гораздо медленнее меняем способы организации работы.
📊 Несколько интересных цифр из исследований Gartner:
- Почти 40% компаний превышают бюджеты на внедрение ИИ.
- Организации, которые не просто внедряют ИИ, а одновременно перепроектируют работу, более чем в два раза чаще превосходят свои цели по затратам.
- Компании, которые направляют полученный эффект на инновации, почти в четыре раза чаще превосходят цели по выручке.
- Только 38% HR- и IT-директоров имеют общее понимание того, как ИИ изменит организацию работы.
Последняя цифра мне кажется особенно показательной.
Проблема уже не столько в технологиях, сколько в организационном дизайне.
Представьте обычную продуктовую команду.
Разработчики начали активно использовать ИИ. Код пишется быстрее. Аналитики быстрее готовят требования. Тестировщики автоматизируют создание тестов.
Кажется, производительность должна вырасти.
Но при этом:
• Решения по-прежнему проходят через несколько уровней согласования.
• Задачи продолжают ждать друг друга.
• Команды зависят от внешних подразделений.
• Ответственность распределена между множеством ролей.
• Приоритеты регулярно меняются.
В результате отдельные операции ускоряются, но весь поток создания ценности может практически не измениться.
А иногда становится даже хуже: работы производится больше, а незавершенных задач и очередей становится ещё больше.
Мы автоматизируем существующую неэффективность вместо того, чтобы устранить её причины.
Если завтра ваша команда станет выполнять свои задачи в два раза быстрее благодаря ИИ, сможет ли ваша организация в два раза быстрее создавать ценность для клиента?
📚 Источники Gartner, 6–8 октября 2026:
HR Symposium/Xpo: Productivity Isn't the Prize
Only 38% of CHROs and CIOs Share an Understanding of AI's Impact
HR Symposium/Xpo: Management and Work Redesign | 101 |
| 5 |  💡 Мероприятие запланировано. Сайт готов. Программа опубликована. Реклама запущена. А почему участник должен прийти именно к вам?
Продолжаем готовить «Литейный интенсив 2027» через Карту гипотез. И хочу рассказать, почему мы выбрали такой подход.
Часто вижу, как подготовка конференции начинается с готового перечня работ: сделать сайт, собрать программу, пригласить спикеров, запустить рекламу во VK. У опытных организаторов есть отработанный процесс и это, конечно, полезно.
Но даже подробный план не отвечает на главный вопрос: за счет чего именно наша конференция станет ценной для тех, кого мы хотим привлечь?
В нашем проекте мы начали с целей, метрик и субъектов - людей, чьи решения влияют на результат. Потенциальных участников, руководителей, которые согласуют поездку,, стратегических партнеров, экспертов.
Уточнили, что считаем успехом. Проверили, как метрики подтверждают достижение цели. Сформулировали предположения о болях и желаниях этих людей (которые теперь их нужно проверять в интервью).
И уже на этой основе строим гипотезы.
Например, доклад попадает в программу не просто потому, что тема модная или спикер известный. За ним должна стоять причинная логика:
Если мы дадим потенциальному участнику возможность разобрать значимую для него производственную задачу на сопоставимых практических кейсах,
то он решит участвовать в конференции и инициирует согласование поездки,
потому что увидит возможность получить применимое решение задачи, за которую отвечает,
тогда это повлияет на количество проданных билетов.
Это пока предположение. Нам еще предстоит проверить, действительно ли задача важна, достаточно ли такого предложения и что мешает человеку принять решение.
А дальше появляются тактические задачи: найти подходящего эксперта, подготовить кейс, описать ценность разбора на сайте, донести ее до нужной аудитории.
❗️У каждой задачи появляется основание: какую гипотезу она проверяет или реализует, чье поведение должна изменить и на какую метрику повлиять.
То же самое с рекламой. «Запустить рекламу во VK» - действие. Чтобы оно имело смысл, нужно понять, к кому мы обращаемся, что для этого человека важно и почему наше предложение побудит его сделать следующий шаг.
Готовый процесс помогает организовать работу. Но купить «коробку» задач и рецептов, которая сама обеспечит успех конкретной конференции, не получится. Без понимания целей, людей и причинных связей можно выполнить весь план - и не получить нужного результата.
Поэтому мы двигаемся от смысла к действиям: цель и метрики → субъекты и их мотивация → гипотезы → задачи. А затем проверяем результат и пересматриваем свои предположения.
На следующей неделе будем разбирать саму технологию на курсе «Карта гипотез. Практик 1».
🗓 Старт - 12 октября, онлайн. Практическая работа — в Sociotech: будем учиться строить такие связи на своих проектах.
Программа и регистрация | 171 |
| 6 |  🗺 Через неделю начинаем новый поток по Карте гипотез. И немного меняем само обучение
12 октября стартует «Карта гипотез. Практик 1».
Сейчас готовим новый поток. И одно из важных изменений - вся практическая работа теперь проходит непосредственно в Sociotech.
Почему для нас это важно?
Когда начинаешь использовать Карту гипотез в реальной работе, довольно быстро понимаешь: ценность не в том, чтобы правильно расставить квадратики и стрелочки.
Нужно научиться думать через карту.
Формулировать. Связывать. Проверять логику. Возвращаться назад. Перестраивать. Видеть, где карта не складывается и почему.
Поэтому мне хочется, чтобы на тренинге участники работали не с учебной картинкой, а сразу с полноценным инструментом.
И здесь нам очень помогает
Sociotech.
В платформе можно собирать Карту гипотез, последовательно работать с ее элементами, возвращаться к формулировкам, перестраивать связи и постепенно доводить карту до рабочего состояния.
И это уже гораздо ближе к тому, как Карта гипотез используется в реальной работе.
📅 Практик 1 стартует 12 октября.
Три онлайн-занятия: понедельник / среда / пятница.
Программа и регистрация | 148 |
| 7 |  ИИ построил нам стратегию трансформации. Красивую. Логичную. И неправильную.
На прошлой встрече клуба Scrum-Mastery мы решили провести довольно интересный эксперимент.
У нас был реальный кейс организационной трансформации банка. До этого мы несколько недель разбирали его как консультанты: изучали стратегию, проводили интервью, смотрели процессы, анализировали организационную структуру и искали системные ограничения.
Материала накопилось много.
- Конфликт между бизнесом и ИТ.
- Двоевластие Product Owner и технического лидера.
- Проектное управление, конкурирующее с продуктовым.
- Низкая автономность команд.
- Разные KPI бизнеса и ИТ.
- Огромное количество зависимостей.
- Проблемы со сквозным Time-to-Market.
И мы решили сделать то, что сейчас очень хочется сделать практически каждому консультанту: а что, если все это просто отдать искусственному интеллекту и попросить его построить стратегию трансформации?
Загрузили результаты аудита в Sociotech. ИИ разобрал материалы, выделил факты, обработал SWOT и построил Карту гипотез.
На первый взгляд - отлично: есть цель, есть метрики, есть гипотезы, есть конкретные задачи. Можно брать и начинать трансформацию.
А потом мы стали разбирать карту руками. И обнаружили довольно серьезную проблему.
В стратегии практически исчезли люди, которые должны эту трансформацию осуществить. В Карте гипотез оказалось всего два субъекта. При этом там не оказалось одной из важнейших групп - руководителей подразделений, которым придется менять правила управления, делегировать полномочия, разрешать конфликты приоритетов и поддерживать новую модель работы. И практически потерялись участники самих команд, поведение которых тоже должно измениться.
Самое интересное - ИИ про них знал. В загруженных материалах были руководители, команды, PO, технические лидеры, Scrum Masters, PMO. Были описаны конфликты полномочий, проблемы автономности, разные KPI и даже конкретные управленческие противоречия.
То есть проблема оказалась не в недостатке данных.
ИИ прочитал данные. Но не построил из них полноценную логику изменений. И вот здесь эксперимент стал для меня действительно интересным.
Если мы говорим о стратегии через Карту гипотез, недостаточно написать: «Хотим сократить Time-to-Market». Нужно задать следующий вопрос: чье поведение должно измениться, чтобы эта метрика изменилась?
Руководитель должен начать принимать решения иначе. Product Owner - получить другие полномочия. Команда - иначе работать с приоритетами и зависимостями.
И только потом появляются гипотезы: Если мы изменим X, субъект Y начнет вести себя Z, потому что…, и это должно повлиять на конкретную метрику.
И, пожалуй, это один из самых полезных выводов нашего эксперимента:
AI не отменяет необходимость понимать инструмент, которым вы пользуетесь. Скорее наоборот. Чем лучше становится AI и чем убедительнее выглядят его ответы, тем важнее человеку понимать технологию достаточно хорошо, чтобы заметить ошибку.
Потому что плохой ответ ИИ заметить легко. Гораздо опаснее хорошо оформленный, логично звучащий и профессионально выглядящий ответ, в котором пропущена одна принципиальная часть системы.
Именно поэтому мы в клубе Scrum-Mastery не просто изучаем инструменты организационного дизайна и стратегии.
Потому что навык ближайших лет, похоже, будет заключаться не только в том, чтобы уметь спросить AI.
А в том, чтобы понимать предмет достаточно глубоко, чтобы не поверить ему там, где он красиво ошибся.
И как раз в октябре стартует новый поток обучения «Карта гипотез. Практик — Ступень 1».
Там мы учимся не просто рисовать карту, а строить эту причинную логику: цель → метрики → субъекты → их боли и потребности → изменение поведения → гипотезы → действия.
И, конечно, будем учиться использовать AI как помощника — но не отдавать ему стратегическое мышление целиком.
👉 https://scrum-mastery.ru/hypothesis_mapping | 239 |
| 8 |  🚀 От аудита к стратегии изменений: соберём план трансформации с помощью ИИ
Представьте: у вас есть результаты диагностики компании. Вы уже увидели проблемы, противоречия, организационные разрывы и точки роста.
Но что делать дальше?
Как превратить десятки наблюдений и рекомендаций в понятную стратегию трансформации? Завтра будем делать это вживую на очередной встрече ннашего клуба. Мы соединим сразу
несколько инструментов:
🔹 Проектирование To-Be - как из текущего хаоса собрать образ целевой организационной системы.
🔹 Карта Гипотез трансформации - как определить, что именно менять, какие гипотезы проверять и в какой последовательности действовать.
🔹 ИИ как помощник агента изменений - будем использовать Sociotech прямо в процессе, чтобы вместе с ИИ структурировать результаты аудита, формировать гипотезы и собирать стратегию.
И самое интересное - не будем работать на абстрактном примере, а возьмём результаты реального аудита и прямо на встрече пройдем путь:
Аудит → системные проблемы → To-Be → гипотезы → приоритеты → план изменений.
В результате у нас должна появиться не просто красивая схема, а рабочий черновик стратегии трансформации, который можно дальше обсуждать с заказчиком и превращать в реальные действия.
Для меня это одна из самых важных практик для современного агента изменений: не просто уметь диагностировать организацию, а уметь быстро превращать диагностику в стратегию действий.
А теперь к этому добавляется еще один инструмент - ИИ как партнер в работе над стратегией.
Завтра будем пробовать это руками. Мастер-класс для тех, кто занимается организационными изменениями, трансформациями, Agile и развитием бизнеса.
После встречи начнем собирать программу второго осеннего потока Scrum-Mastery на октябрь.
🌐 Scrum-Mastery | 158 |
| 9 |  Учителя бывают разные
Есть те, кто хорошо знает методологию и умеет о ней рассказывать.
А есть те, кто продолжает использовать ее сам - в реальной работе, с реальными задачами и ограничениями.
Мне кажется, для прикладного обучения это принципиальная разница.
Неделю назад начала работу группа, которая готовит конференцию «Литейный интенсив». И мы сразу пошли не в презентации, не в список мероприятий и не в распределение задач.
Мы начали строить стратегию конференции с помощью Карты гипотез.
Причем в этот раз в работу вовлечен весь программный комитет - все организаторы.
Это уже второй наш опыт использования Карты гипотез для подготовки конференции. Прошлой весной мы точно так же использовали ее при подготовке предыдущей конференции: сформировали стратегию, определили ключевые гипотезы и на их основе уже двигались к реализации.
И для меня это, пожалуй, один из лучших способов проверить любой инструмент: работает ли он там, где нет учебного примера и заранее известного правильного ответа?
Карта гипотез у нас постоянно проходит именно такую проверку - в проектах, командах, стратегических задачах, обучении и теперь снова в подготовке конференции.
Поэтому на наших тренингах мы не просто рассказываем, как устроена Карта гипотез.
Мы показываем, как с ней работать.
Разбираем реальные ситуации, создаем карты руками, ищем ошибки, спорим о гипотезах, учимся связывать стратегию с приоритетами и задачами.
А главное - после обучения у вас остается не просто знание технологии, а практика ее применения.
Ближайшие тренинги в октябре
✔️Карта гипотез — Уровень Практик, Ступень 1
12 октября · онлайн
➡️https://scrum-mastery.ru/hypothesis_mapping
✔️Карта гипотез — Уровень Практик, Ступень 2
19 октября · онлайн
➡️ https://scrum-mastery.ru/hypothesis_mapping_2
Все тренинги проходят на платформе Sociotech.
Если вам интересно не просто узнать про Карты гипотез, а научиться использовать их в своей реальной работе — приходите практиковаться вместе с нами. | 656 |
| 10 |  🎲 23 сентября - «Диагностика доверия в команде»
Можно ли диагностировать доверие в команде не с помощью длинной анкеты, а прямо в процессе взаимодействия?
23 сентября проведём специальную игру «Мастер Доверия» - «Диагностика доверия в команде».
Это будет не просто игровая сессия. Мы разберем, как через игру можно увидеть, что происходит с доверием в команде, и как превратить полученные наблюдения в материал для дальнейшей работы.
Что будет на встрече:
🧩 Погружаемся в методологию Разберем, как устроена диагностика доверия через игру: что именно мы наблюдаем и как работают игровые механики.
🎲 Играем в онлайн-версию «Мастера Доверия» Пройдем игровой сценарий, в котором участники сталкиваются с командными ситуациями, принимают решения, дают друг другу обратную связь и наблюдают, как меняется уровень доверия.
🔎 Разбираем опыт игры Посмотрим, что происходило с командой в процессе и какие сигналы доверия можно заметить непосредственно во взаимодействии участников.
💡 Смотрим примеры использования
Обсудим, где такой формат можно применять в работе: командная диагностика, ретроспективы, фасилитационные сессии, развитие команд и работа со сложными ситуациями.
Особенно приглашаю фасилитаторов, Agile Coach, Scrum Master, бизнес-тренеров, HR и всех, кто работает с командами.
Можно прийти просто как участник. А можно посмотреть на игру ещё и глазами фасилитатора - как устроен сценарий и что из него
можно забрать в собственную практику.
📅 23 сентября, 19:00 МСК 💻 Онлайн
👉 Подробности и регистрация: trustmastergame.ru/events | 148 |
| 11 | Всем привет! Если вы еще не пробовали наш калькулятор потерь от недоверия, самый раз протестировать. Обновили алгоритмы расчета.
🙂 Будем рады обратной связи!
https://trust-tax-calc--agiletechru.replit.app/ | 189 |
| 12 |  🔎 Продолжаем исследовать организацию
Сегодня на встрече закрытого клуба Scrum-Mastery продолжаем разбираться с тем, как диагностировать и проектировать организацию как систему.
Будем говорить про аксиоматическое проектирование и разберем его на реальном кейсе.
Не просто посмотрим на готовый анализ, а вместе:
- определим функциональные требования;
- разложим элементы организационной конструкции;
- построим матрицу функциональной связанности;
- попробуем найти в ней системные проблемы;
- и посмотрим, какие изменения можно спроектировать для будущего состояния.
То есть пройдем весь путь: собрать → проанализировать → спроектировать.
Если хотите присоединиться — напишите мне в личку, еще есть возможность попасть на сегодняшнюю встречу в 19:00.
Даже если давно собирались прийти — сегодня как раз хороший повод 🙂
Ну или записывайтесь в наш клуб: https://scrum-mastery.ru/ | 200 |
| 13 |  Организационный дизайн - это не оргструктура
Можно нарисовать новый орг чарт, перераспределить полномочия и создать продуктовые команды и через несколько месяцев обнаружить, что решения по-прежнему принимаются «по-старому», согласований стало больше, а сквозной результат не улучшился.
В новой статье разбираю, как смотреть на организацию как на систему, и зачем здесь может быть полезна логика аксиоматического проектирования.
Главный переворот: не структура → роли → процессы, а функции → требования → конструкция системы.
👉 Читать статью: «Аксиоматическое проектирование: почему оргструктура — это не весь организационный дизайн» | 171 |
| 14 |  🚀 Стартовал осенний сезон клуба: разбираем Модель Гелбрайта
Вчера мы провели первую встречу нового сезона «Архитекторы Потока». Без общих воды - сразу перешли к сути диагностики операционной модели на реальном кейсе.
Что обсудили на первой встрече:
1️⃣ Прошли по Модели Гелбрайта. Разобрали, как 5 элементов (Стратегия, Структура, Процессы, Награды, Люди) должны быть сбалансированы, и почему изменение одного без остальных неизбежно ведет систему в хаос.
2️⃣ Нашли главный системный разрыв. На примере кейса увидели, как бизнес мыслит категориями P&L, клиентов и скорости, а ИТ-блок — стабильностью, утилизацией ресурсов и проектными вехами. Это две разные вселенные, которые не стыкуются на уровне операционки.
3️⃣ Сменили фокус диагностики. Зафиксировали главное правило: мы ищем не «виноватых» или плохих людей, а ошибки в дизайне системы и паразитные связи между ролями.
Что было: попробовали сразу применили модель к реальным симптомам из аудита, чтобы самостоятельно найти корень проблемы в конкретном элементе модели.
Что дальше:
На следующей неделе (вторник, 8 сентября, 19:00 МСК) переходим ко второму модулю: Диагностика организационной связанности. Будем строить матрицу функциональной связанности и анализировать результы.
👇
Кто хочет присоединиться к следующему занятию - пишите в личные сообщения или приходите: https://scrum-mastery.ru
#ScrumMastery #АрхитекторыПотока #МодельГелбрайта #AgileДиагностика #OrganizationalDesign | 160 |
| 15 |  🧩 Сбой в системе: почему ИТ-процессы воюют с бизнес-стратегией
Завтра - 1 сентября, и мы официально запускаем новый практический сезон в закрытом бизнес-клубе Scrum-Mastery. Давайте разберем один из главных ментальных инструментов, с которого мы начнем наш сентябрь.
Когда T2M ключевых продуктов банка или компании составляет месяцы, а планы спринтов регулярно рушатся, менеджмент обычно ищет виновных: «программисты медленные», «бизнес не умеет писать ТЗ», «Скрам-мастера плохо фасилитируют».
Но в 95% случаев люди вообще не при чем. Причина — в разрыве операционной модели. Чтобы доказать это Топ-менеджменту и СЕО на языке жестких системных аргументов, мы будем использовать фундаментальный инструмент организационного инжиниринга - Модель организационного соответствия Джея Гелбрайта (Звезда Гелбрайта).
В чем суть Звезды Гелбрайта?
Гелбрайт доказал: успешная компания - это сбалансированная пятиконечная звезда, где все лучи синхронизированы между собой:
- Стратегия (Strategy): куда мы идем и какое наше рыночное преимущество.
- Структура (Structure): как нарезаны команды.
- Процессы (Processes): как движется информация и ценность .
- Награды/Мотивация (Rewards): за что людям платят бонусы и KPI.
- Люди/Компетенции (People): какими способностями обладают сотрудники.
🔴 Классический клин операционной модели («Inside-Out»):
Посмотрите, в какой ловушке сейчас находится большинство компаний на рынке:
- Стратегия требует: рыночная скорость, T2M за 14 дней и маневренность.
- Но Структура заперта в жестких компонентных командах, где фичи 60% времени гниют в очередях.
- Награды (KPI) Тимлидов и Скрам-мастеров завязаны на локальную «скорость закрытия тикетов».
Итог: лучи операционной модели противоречат друг с другом.
⏳ Завтра — старт. Последний шанс войти в контур изменений
Именно с Аудита организационного соответствия по модели Гелбрайта мы начнем первый живой воркшоп клуба в сентябре. Мы не будем читать лекций. Мы возьмем реальный кейс и разберем, как по шагам сопоставить стратегию бизнеса с текущей структурой, чтобы C-Level директора сами увидели необходимость реформ.
👉 Оформить абонемент и войти в клуб Scrum-Mastery прямо сейчас: https://scrum-mastery.ru
#ScrumMastery #OrgDesign #SystemicThinking #FlowEfficiency #GalbraithStar #InsideOut #Management #AgileCoaching | 148 |
| 16 | 🛑 Главный итог недели организационного инжиниринга
Всю неделю разбирали, почему привычный фокус на локальной скорости команд и оптимизации встреч больше не приносит бизнесу результатов. Если процессы спроектированы «изнутри наружу», компания тратит энергию на обслуживание внутренних очередей, полностью теряя сквозную скорость поставки ценности.
Если вы пропустили ключевые разборы или хотите перечитать материалы перед стартом практики, я собрал всю цепочку системных инсайтов в один путеводитель:
Пост 1. Аксиоматика Нама Су
Пост 2. Анатомия очередей: как с помощью HeatMap бэклога доказать, что команды утилизируют сами
себя
Пост 3. VSM «снаружи-внутрь»: как найти простои там, где Jira показывает 100% скорость?
Пост 4. Эффект кобры в IT
🚀 От теории - к жесткой практике: сентябрь в клубе Scrum-Mastery
Книжные подходы бессильны перед дефектами структуры.
Настоящий орг-дизайн начинается там, где абстрактные лозунги уступают место моделированию: когда вы берете карту взаимодействий, находите паразитные связи между отделами и своими руками собираете наилучшую комбинацию команды полного цикла.
Весь сентябрь в нашем закрытом клубе мы посвятим серии живых проектировочных воркшопов и мастер-классов. Мы будем учиться разговаривать с ИТ-директорами, CPO и СЕО на языке организационного инжиниринга.
Что мы сделаем вместе на сентябрьских занятиях клуба:
- Проведем аудит организационного соответствия по модели Гелбрайта. Начнем с фундамента - сопоставим рыночную стратегию бизнеса с текущей структурой, чтобы наглядно увидеть, где организационные дисбалансы блокируют коммерческий результат.
- Своими руками разметим HeatMap бэклога и построим сквозной VSM.
- Спроектируем целевую Decoupled-модель ИТ-платформы.
- Упакуем результаты анализа в бизнес-кейсы для C-Level.
Этот сентябрь - ваш первый уверенный шаг на пути трансформации из роли «модератора встреч» и администратора досок в статус глубокого организационного архитектора и стратегического консультанта для C-Level.
🎟️ Окно регистрации на сентябрьские мастер-классы открыто. Оформляйте абонемент, забирайте библиотеку инструментов и переводите свою карьеру в высшую лигу:
👉 Оформить абонемент и стать участником клуба Scrum-Mastery
#ScrumMastery #OrgDesign #SystemicThinking #FlowEfficiency #ValueStreamMapping #HeatMap #Management #AgileCoaching | 657 |
| 17 |  💡 Эффект кобры в IT: как KPI на скорость заставляет Тимлидов и Скрам-мастеров вредить бизнесу
Британская история знает шедевральный пример управленческого абсурда. В колониальной Индии расплодилось слишком много ядовитых змей. Губернатор ввел денежную награду за каждую принесенную голову кобры, ожидая, что популяция сойдет на нет.
Что сделало население? Индийцы начали массово разводить кобр в домашних условиях, чтобы стабильно зарабатывать на сдаче голов. Когда премии отменили, фермеры просто выпустили ставших ненужными змей на волю. В итоге популяция кобр выросла в несколько раз.
Локальное денежное поощрение метрики полностью уничтожило глобальную цель.
🐍 Как «разводят кобр» в компании прямо сейчас
Каждый раз, когда ИТ-дирекция привязывает премии Тимлидов и Скрам-мастеров к локальному KPI «Сократить IT Lead Time на 15%», включается тот самый индийский сценарий. Люди перестают думать о продукте и начинают играть в систему ради защиты своего кармана:
1️⃣ Саботаж сложных задач: Зачем команде брать тяжелую, стратегическую фичу от Product Owner'а, которая «поплывет» по срокам и убьет средний Lead Time? Тимлиды под любым предлогом выталкивают сложные задачи из спринтов. Команда фокусируется на примитивном «мусоре» (покрасить кнопки, поменять тексты), который закрывается за час и гарантирует премию. Графики скорости летят вверх, но бизнес-результат равен нулю.
2️⃣ Скрытие багов: баг в спринте - это остановка удар по KPI. Ошибки начинают замазываться быстрыми «костылями» прямо на продакшне в обход трекеров, чтобы не портить статистику. Качество кодовой базы деградирует мгновенно.
3️⃣ Ликвидация прозрачности: Скрам-мастер из независимого аудитора превращается в соучастника. Чтобы дашборд выдал руководству красивую цифру, СМ начинает вручную чистить тикеты, дробить задачи и перекрашивать баги в «новые фичи». Прозрачность процессов умирает первой.
Система всегда оптимизирует ту локальную метрику, к которой привязаны деньги, самым дешевым и циничным для себя способом.
Локальная оптимизация имеет нулевой экономический эффект для компании.
📅 Сентябрь в клубе Scrum-Mastery: перезапуск системы метрик
Весь сентябрь в нашем закрытом клубе мы посвятим суровому организационному инжинирингу. Хочется в том числе разобрать конкретные инженерные формулы: Flow Efficiency (эффективность потока) и Cost of Delay (стоимость задержки), которыми нужно заменить «скорость закрытия тикетов», чтобы вернуть командам продуктовый фокус.
Занимайте свое место в контуре изменений, пока открыто сентябрьское окно регистрации. Начинаем уже 1 сентября! Завтра опубликуем конечную программу встреч.
👉 Оформить абонемент и войти в клуб Scrum-Mastery: https://scrum-mastery.ru
#ScrumMastery #SystemicThinking #OrgDesign #FlowEfficiency #Management #AgileCoaching | 130 |
| 18 |  💡 VSM «снаружи-внутрь»: как найти простои там, где Jira показывает 100% скорость?
Большинство ИТ-руководителей свято верят своим дашбордам в Jira. На графиках всё идеально: velocity растет, спринты закрываются вовремя, внутренняя скорость разработки (иногда вы найдете термин - IT Lead Time) стремительно падает. ИТ-блок уверен, что работает со стопроцентной эффективностью.
Но у бизнеса паника - клиенты по-прежнему ждут банальную фичу месяцами, а компания упускает окна возможностей.
Почему возникает эта иллюзия? Потому что классические таск-трекеры измеряют процессы «изнутри наружу» (Inside-Out) - от статуса «В работе » до статуса «Готово» внутри производственного силоса. Система полностью слепа к тому, что происходит с задачей до и после написания кода.
Чтобы вскрыть этот обман и увидеть реальную картину, профессиональному агенту изменений нужен взгляд «снаружи внутрь» (Outside-In) и инструмент Value Stream Mapping (VSM) - картирование сквозного потока ценности глазами клиента. Картирование позволяет переключить фокус менеджмента с локальной оптимизации (заставить программистов быстрее нажимать на кнопки) на оптимизацию сквозного потока (убрать простои на стыках между отделами).
🤖 Кейс: Как ИИ-анализ взламывает слепые зоны процессов
В одном из последних проектов мы решили пойти дальше классического рисования стрелочек на флипчарте. Мы провели картирование не просто потока, а смоделировали сквозной путь ценности в Lucidchart и подключили встроенных ИИ-агентов для глубокого организационного анализа.
Вот какие жесткие цифры и аномалии вскрыл ИИ-анализ на карте потока:
- Парадокс Touch Time: чистая, полезная работа инженеров над кодом (Touch Time) занимает всего от 4 до 8 рабочих дней.
- Общий календарный срок (Lead Time) прохождения сквозного изменения составляет от 82 до 104 рабочих дней.
- Эффективности потока (Flow Efficiency): Эффективность конвейера составила всего 12–15%. Это значит, что более 85% времени задача просто «протухает» в очередях - в ожиданиях ответов от смежных колодцев и в циклах согласований.
Даже если разработчики ускорятся в два раза и начнут писать код за 2 дня вместо 4, сквозной Time-to-Market для клиента не изменится ни на час. Проблема лежит в ошибочном дизайне организационной связанности (Coupled Design).
🚀 Отработаем эту технологию на практике в клубе Scrum-Mastery
Теория без практики мертва. На ближайшем живом воркшопе нашего закрытого клуба мы разберем эту инженерную технологию до винтиков. Вы сможете прийти со своими кейсами и картами процессов.
Что мы сделаем вместе на занятии клуба:
1. Пошагово спроектируем сквозной VSM в Lucidchart
2. Разберем, как правильно настраивать промпты для ИИ-агентов
3. Упакуем результаты анализа в понятный b2b-язык для C-level
Доступ на проектировочную сессию и к библиотеке промптов открыт только для резидентов клуба. Занимайте свое место, забирайте готовые инструменты и переводите свою карьеру на уровень системного инжиниринга.
👇 Ссылка на оформление абонемента и вход в клуб Scrum-Mastery
👉 https://scrum-mastery.ru
#ScrumMastery #OrgDesign #ValueStreamMapping #FlowEfficiency #Lucidchart #AIinManagement #InsideOut #SystemicThinking #Management | 140 |
| 19 |  📝 Анатомия очередей: как с помощью HeatMap бэклога доказать, что команды утилизируют сами себя
Знакомая картина? ИТ-директор на комитетах требует расширения штата, заявляя о 100% выгорании и перегрузке своих сотрудников. Разработчики действительно в мыле, Jira трещит от тысяч закрытых тикетов, аналитики пишут тонны ТЗ. Но нужные рынку фичи не выходят месяцами.
Чтобы вскрыть этот парадокс, профессиональному агенту изменений нужен жесткий инструмент - HeatMap (тепловая карта) бэклога.
Как устроена «фабрика» ложной занятости?
Когда организация нарезает ИТ-структуру «изнутри наружу», например, плодит десятки изолированных компонентных команд (команда базы данных, команда интеграционной шины, команда АБС), она попадает в утилизационную ловушку.
Чтобы выпустить одну сквозную фичу для клиента, продуктовая команда вынуждена встать на поклон в 7–10 таких технологических колодцев. Каждая задача застревает во встречных очередях Change Requests (CR). И вот тут начинается самое интересное. Если выгрузить бэклог и раскрасить задачи в цвета тех компонентных команд, которые должны делать интеграции, мы увидим страшный HeatMap.
Что показывает HeatMap бэклога в реальности:
1️⃣ ИТ-отдел утилизирует сам себя: инженеры платформы загружены «с горкой», но 80% их энергии уходит на перекладывание задач из одного ИТ-силоса в другой, согласование внутренних интерфейсов и бесконечные созвоны по стыковке компонентов. Это ложная, паразитная утилизация.
2️⃣ Время «протухания» задач превышает время работы: чистая разработка фичи занимает 3 дня, но более 60% календарного времени жизненного цикла задачи — это чистый простой в очередях ожидания ответов от смежников.
3️⃣ Паралич квартального планирования: попытка расписать «головы» компонентных команд на 3 месяца вперед в динамичном бизнесе создает лишь иллюзию порядка. Как только одна команда сдвигает сроки на неделю, по принципу «эффекта домино» рушатся планы остальных колодцев, превращая бэклог в хаос.
Проблема не в лени программистов, а в том, что структура спроектирована под обслуживание ИТ-систем, а не под путь клиента. Нужно перестать делить "головы" на квартальных планированиях и пересобрать инженеров в кросс-функциональные домены.
🚀 Что мы будем делать на практикуме в клубе Scrum-Mastery?
Построение и защита HeatMap бэклога - это высший пилотаж организационного консалтинга, который мгновенно переводит агентов изменений из роли «модератора встреч» в статус стратегического партнера для C-Level.
На ближайшем потоке клуба мы вместе возьмем реальный обезличенный бэклог компании, находящейся в утилизационном тупике, и по шагам разметим его тепловую карту и вместе проанализируем.
🎟 Доступ к практикуму, шаблонам и видеозаписи открыт для всех резидентов клуба. Занимайте свое место в контуре изменений по ссылке:https://scrum-mastery.ru
👉 Оформить абонемент и войти в клуб Scrum-Mastery
#ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency #HeatMap #InsideOut | 117 |
| 20 |  💡 Аксиоматика Нама Су: как развязать организационные узлы и спроектировать автономную команду полного цикла
Бывало ли у вас так: вы собрали отличную команду, настроили процессы, РО горит идеей, но фичи все равно выходят раз в квартал? Вы заходите на ретроспективу, а разработчики разводят руками: «Мы все написали за два дня, но задача уже месяц висит на согласовании в безопасности, ждет ответа рисков и доработок от команды интеграционной шины».
Поздравляю, вы уперлись в «паразитный замок» организационной связанности. Когда команда делает руками только 30% задачи, а остальные 70% времени фича простаивает в очередях к смежникам — это не проблема плохих людей или плохой фасилитации. Это ошибка проектирования структуры. И лечится она не тренингами, а методологией аксиоматического проектирования MIT (теория Нама Су).
Три типа организационного дизайна: В каком лабиринте вы застряли?
Нама Су разделил архитектуру любых систем (включая оргструктуры) на три типа по уровню связанности элементов (Coupling):
1️⃣ Связанный дизайн (Coupled Design):
Это то, где сейчас живет 90% корпоративного рынка. Ситуация, когда для выполнения одной бизнес-задачи требуется одновременное, синхронное участие множества смежных компонентных команд, ИТ-комитетов и согласующих органов. Система блокирует сама себя. Шаг изменений тут равен не спринту, а кварталу - пока все колодцы не согласуют ресурсные планы.
2️⃣ Последовательный дизайн (Decoupled Design):
Зависимости между командами существуют, но они асинхронны и стандартизированы. Команда автономна, потому что все ключевые эксперты (бизнес, ИТ, Риски, ИБ) физически выведены из своих «функциональных колодцев» и на 100% времени выделены внутрь продуктовой группы. Смежники больше не пишут друг другу Change Requests - они собирают фичи на лету.
3️⃣ Независимый дизайн (Uncoupled Design):
Каждый юнит закрывает свою бизнес-потребность полностью самостоятельно. Изменение приоритетов одного процесса никак не аффектит другие.
Большинство агентов изменений пытаются разогнать команду, находящуюся в жестком Coupled-дизайне, с помощью локальных действий: сокращают дейли, меняют форматы ретро. Но законы физики оргдизайна неумолимы: локальная оптимизация в связанной системе дает нулевой эффект на выходе.
Чтобы сдвинуть сократить t2m, Скрам-мастер обязан действовать как архитектор: взять матрицу взаимодействия, найти связанные узлы, убрать паразитное вето смежников и помочь топ-менеджменту пересобрать «наилучшую комбинацию команды полного цикла».
На ближайшем потоке нашего клуба мы переходим от теории к суровому орг.проектированию. Мы будем учиться перестраивать системы «снаружи внутрь» - от клиента и бизнес-целей. И одно из первых занятий будет посвящено как раз практике аксимоматического проектирования. Что хотим сделать:
- Разберем живой, реальный кейс, который застрял в утилизационной ловушке.
- Своими руками построим Матрицу связанности и найдем точки разрывов.
- Спроектируем целевую Decoupled-структуру пилотного контура.
- Сформируем пошаговый тактический бэклог задач, который Скрам-мастер может внедрить в своей компании уже на следующий день.
Доступ на воркшоп открыт только для действующих участников клуба. Чтобы занять свое место на проектировочной сессии, забрать готовые шаблоны матриц и развернуть свою карьеру в сторону системного консалтинга - оформляйте абонемент по ссылке ниже.
👉 Оформить абонемент и стать участником клуба Scrum-Mastery
#ScrumMastery #AgileCoaching #SystemicThinking #OrgDesign #FlowEfficiency #AxiomaticDesign | 145 |
