Стратегия, AI и организационный дизайн

⚡️ Закон Акоффа, который сносит башку У Рассела Акоффа есть простая и очень неприятная для менеджмента мысль: если оптимизировать систему целиком, эффективность отдельных ее частей неизбежно где-то упадет. И наоборот: если делать максимально эффективной каждую часть по отдельности, целое будет страдать. Хотите, чтобы каждый человек в команде был постоянно загружен? Получите неэффективную команду. Хотите эффективную продуктовую группу? Отдельные команды иногда будут простаивать. Хотите эффективную организацию? Какие-то департаменты неизбежно будут выглядеть неэффективными по своим локальным метрикам. Но организации обычно делают ровно обратное. Они оптимизируют загрузку людей, эффективность команд, KPI функций и производительность департаментов по отдельности. А потом удивляются, почему целое работает медленно. Недавно я писал про это в контексте AI: отдельные люди и команды ускоряются, а компания целиком — нет. Та же логика есть в Scrum-паттерне Greatest Value: локальная оптимизация частей ухудшает результат целого. С какими забавными проявлениями закона Акоффа вы встречались?

⚡️ Сегодняшний эфир придется перенести Коллеги, сегодня в 16:00 планировал провести эфир про решение запутанных проблем с помощью системного мышления и AI. Но сейчас понимаю, что не смогу провести его в том формате и качестве, которое задумал — с живой работой AI-агентов и разбором реального кейса. Поэтому решил не делать урезанную версию и перенести эфир. Новую дату сообщу отдельно. Извините, если уже запланировали время — и спасибо за понимание.

⚡️ Системные диаграммы как повод для разговора Закончился еще один поток по системному мышлению. И вот такая обратная связь от участников. Для меня здесь особенно важна одна мысль: системная диаграмма — это инструмент для диалога. Она помогает вытащить сложную проблему на стол, посмотреть на нее вместе и нормально поспорить о том, что на самом деле происходит в системе. При этом системные диаграммы сразу работают в двух направлениях: помогают искать рычаги в системе и становятся инструментом изменений — через общее понимание и договоренности. Рад, что участники начали применять это прямо на своих рабочих задачах. Если хотите попробовать такой подход, вот мой публичный тренинг Professional Systems Thinker. Где вам нужен диалог?

⚡️ Как решить запутанную проблему так, чтобы она не вернулась Люди сопротивляются изменениям: «Мы 20 лет так работали». Каждый отдел оптимизирует свою работу — и создаёт проблемы следующему. Одни и те же пожары месяцами превращаются в хотфиксы. У вас 15 команд и десятки зависимостей — и непонятно, куда приложить усилия. 7 октября с 16:00 до 18:00 проведу открытый эфир о том, как решать проблемы с помощью системного мышления и AI. Прямо на эфире выберем одного участника с реальной проблемой. Я проведу короткое интервью, а затем передадим историю команде AI-агентов. Агенты построят разные системные гипотезы и будут спорить между собой. AI-критик сравнит их с исходной историей, после чего мы построим итоговую системную модель и найдём рычаги изменений. Реальная проблема → системная модель → рычаг → изменение. Участие бесплатное. Запись получат те, кто придёт на эфир. 📅 Добавьте эфир в свой календарь, чтобы не пропустить. Ссылку на Zoom пришлю за час до начала: https://calendar.app.google/aCqhcfzcxtVPSkFx6

⚡️ Мои 100 килограммов Есть хорошая фраза:

«Я никогда не проигрываю. Я либо побеждаю, либо учусь».

Я занимаюсь стритлифтингом. И есть одна цифра, которая уже второй год мне не дается — 100 кг допвеса на брусьях. Вчера снова пошел на сотку. Не получилось. Конечно, обидно. Но попытка хорошая, и я чувствую, что стал ближе к сотке. Сегодня не победил. Значит, поучился. И попробую еще раз. Честно... что у вас не получается?

⚡️ Кейс: кто теперь будет продавать мой продукт? На консультации с одним из руководителей большой компании обсуждали переход к клиентоцентричной стратегии. И обнаружили характерный конфликт. Раньше компания была продуктоцентричной: полуавтономные дивизионы, владельцы продуктов, у каждого свой P&L. Теперь компания собирает продукты в пакеты и комплексные решения, адаптирует их под клиентов. Ответственность за P&L переходит к клиентским сегментам. И у владельца продукта появляется вполне понятный вопрос: «А если сегменты перестанут продавать мой продукт? Будут собирать низковисящие фрукты, а в развитие новых продуктов никто не вложится?» Джей Гэлбрейт, автор звездной модели оргдизайна, описывал процессы, которые помогают согласовывать работу продуктовых и клиентских подразделений. Один из них — согласование стратегий и планов продуктов и сегментов. Для этого используется матрица: по строкам — продукты, по столбцам — клиентские сегменты. На пересечении руководители договариваются, какую роль продукт играет в конкретном сегменте и каких результатов ожидают. На картинке — пример такой договоренности. Продукт 1 в двух сегментах основной, а в третьем его продажи останавливают. Продукт 2 где-то растят, где-то продают в пакете. В Продукт 3 инвестируют для одного сегмента, запускают пилот для другого, а в третьем спроса нет. За каждой ячейкой стоят решения: ожидаемая выручка и маржа, рост клиентской базы, инвестиции или вклад продукта в экономику всего пакета. Так продуктовые и сегментные руководители согласовывают взаимные обязательства. Становится видно, где сегмент рассчитывает на развитие продукта и где продукт рассчитывает на продажи со стороны сегмента. Спорные места обсуждают вместе с топ-менеджментом. Если интересно, какие еще процессы нужны клиенто-центричной организации, поставьте + в комментариях. Расскажу о них в следующих постах.

⚡️ Как увидеть зависимости, пересобрать команды и продать изменения Если одна фича регулярно требует две-три команды, у вас может быть проблема не с координацией. Возможно, сами команды собраны так, что зависимость встроена в структуру. В новом видео показываю связку из двух инструментов. Матрица зависимостей помогает увидеть устойчивые кластеры команд, которые снова и снова вынуждены работать вместе. Но самое важное — такую картину можно показать менеджменту и продать необходимость изменений. У меня есть реальный пример: project manager два года жил с зависимостями, которые топ-менеджмент не видел. После визуализации и презентации нужные ресурсы выделили на следующий день. Дальше две развилки. Если структуру менять нельзя — матрица зависимостей покажет, где нужно настраивать координацию. Если можно — подключаем Heat Map. Она помогает понять, какие функции и архитектурные компоненты стоит втянуть внутрь новых команд, чтобы повысить автономность. В итоге связка помогает пройти весь путь: увидеть проблему, сделать ее видимой для других и спроектировать новую композицию команд. Таймкоды: 00:00 — Зачем нужны матрица зависимостей и Heat Map 01:19 — Как увидеть устойчивые кластеры и сигнал плохой композиции команд 03:04 — Кластеризация и как визуализация помогает продать изменение 04:32 — Две стратегии: устранить зависимости или управлять ими 06:09 — Heat Map: что втянуть внутрь автономных команд 07:23 — Текущее и целевое состояние, цена автономности 08:47 — Когда нужна специализация по бизнес-доменам 09:27 — Как использовать связку инструментов на практике 10:41 — Масштабирование на департаменты и юридические лица Какие зависимости вы бы убрали?

⚡️ Должности уходят. Теперь все — технические сотрудники The New York Times пишет: в AI-компаниях (OpenAI, Anthropic) исследователи, старшие инженеры и руководители продуктов все чаще используют одно название — технический сотрудник. В декабре 2025 года его указывали в LinkedIn 39% сотрудников Anthropic, 31% OpenAI и 26% xAI. Я этот тренд поддерживаю двумя руками. Всегда выступал против иерархии внутри продуктовых команд. Мы собираем людей, чтобы создавать новое и решать комплексные проблемы. Для этого нужны отношения «взрослый — взрослый». А иерархия подталкивает к отношениям «взрослый — ребенок». Вспоминаю звонок, на котором представлял своего друга другим Скрам-мастерам. Они еще не знали, что он станет их руководителем. И я видел, как изменились их лица, мимика, позы, когда они об этом узнали. Человек тот же. Но отношения уже другие. Равенство при этом не означает одинаковую зарплату. Оплата по навыкам вполне может работать: один человек получает миллион долларов в год, другой — 50 тысяч. При этом никто из них не выше другого по статусу внутри команды. В комплексной среде с высокой изменчивостью нам нужно, чтобы люди соперничали идеями. Чтобы с сильной мыслью мог выступить любой. Когда появляются статусные шильдики, становится проще ждать решения старшего и отдавать ему ответственность. Чем больше поводов чувствовать себя ребенком, тем меньше взрослого поведения. В Скраме эта идея давно заложена: внутри команды нет иерархий, а у людей, создающих Инкремент, общее название — Developers. Конечно, одного переименования мало. Но сам отказ от статусных титулов мне очень близок. Ваше мнение?

⚡️ DAO Pro стало «Сообществом сильных людей». Есть одно место. Около месяца назад я тихо запустил DAO Pro. Идея была простой: программа на 4–6 недель для тех, кому нужно спроектировать организационный дизайн (настроить процессы, определить зоны ответственности и полномочия, изменить HR-политики, AI-трансформация). Собрались корпоративная и публичная группы. С корпоративной все пошло по плану. А публичная сломала мои предположения. Люди иногда пропускают встречи из-за работы и отпусков. Задачи меняются прямо по ходу программы. При этом отлично сработала взаимная ответственность, разные контексты, групповой и p2p менторинг и доступ к моим материалам, доскам, тренингам и воркшопам. Поэтому DAO PRO становится «Сообществом сильных людей» и каждый поток устроен так: 1. До 6 человек. 2. Работаем 3 мес. 3. Два часа каждую неделю. 4. Запись каждой встречи. 5. Групповой и p2p менторинг. Приходить можно с любой рабочей задачей. Пять мест уже заняты. Осталось одно. Хотите присоединиться — пишите @fancydev. Что еще рассказать?

⚡️ Открытый эфир про AVSM Друзья, 1 октября с 14:00 до 15:00 проведу открытый эфир про Advanced Value Stream Mapping (AVSM) — воркшоп для работы с потоком создания ценности. Разберем, как с помощью AVSM разобрать поток от идеи до конечной точки, увидеть потери скорости, определить рычаги изменений и получить поддержку на изменения. Записи не будет, поэтому приходите. Ссылка: https://us06web.zoom.us/j/81333961569 Что еще стоит разобрать?

⚡️ Tiny Teams оптимизируют не то В Альфа-Банке тестируют Tiny Teams: вместо классической продуктовой команды из 10–12 человек тот же объем разработки пытаются делать гораздо меньшим составом с помощью AI. Алексей Фетисов, директор по информационным технологиям Альфа-Банка:

«Продукт и AI-инженер с системой агентов могут пройти тот же объем за день или быстрее. Узкое место теперь — решения, согласования и смежные процессы»

И вот тут у меня вопрос: в правильную ли сторону двигается организация? Если AI позволяет меньшим количеством людей делать больше, нам не обязательно уменьшать команду. Команда может остаться из 8–10 человек, но изменится ее состав. В эти 8–10 человек можно собрать разработку, безопасность, риски, маркетинг, продажи и другие необходимые компетенции. Дать им AI-инструменты и строить команду вокруг end-to-end value stream, сокращая внешние зависимости, передачи и согласования. И это возвращает нас к идее The New New Product Development Game из Harvard Business Review 1986 года: кросс-функциональная команда, которая вместе проходит весь путь создания продукта. Tiny Teams продолжают оптимизировать разработку. Мне кажется, гораздо интереснее использовать AI, чтобы наконец собрать настоящую end-to-end продуктовую команду, превратив ее в enterprise-стартап с PnL. Что думаете?

⚡️ Лучшие материалы недели про AI, оргдизайн и системное мышление 1. Steve Blank: AI Killed the MVP — Long Live the IUP⁠ AI сделал создание продукта настолько дешевым, что MVP больше почти ничего не доказывает. Blank предлагает новый термин — Initial Untested Product. Bottleneck теперь не построить продукт, а понять, что стоит строить. 2. HBS: США и Китай участвуют в разных AI-гонках⁠ США оптимизируют frontier models, Китай — массовое проникновение AI в экономику. Если цель — производительность всей системы, лучшая модель вполне может оказаться локальной оптимизацией. 3. McKinsey: Technology Trends Outlook 2026⁠ Инвестиции в agentic software development могут вырасти примерно в ×12,8 за год, в AI infrastructure — ×5,3. Но многие технологии всё ещё на стадии пилотов: капитал и технологии ускоряются быстрее организаций. 4. John Cutler: AI and the Loss of Positive Friction⁠ AI убирает трение между исследованием, решением и реализацией. Но именно это трение часто заставляло людей думать. Убирая waste, можно убрать и полезное мышление. 5. ProKanban: Beyond the AI-Powered Feature Factory⁠ AI позволяет выпускать больше features, но не гарантирует value. Авторы продолжают Kanban после Done: Released → Measuring → Learned. Непроверенная гипотеза — тоже WIP. 6. Scrum.org: Scrum-команда из AI-агентов⁠ В проекте Raptors собрали Scrum Team из AI-агентов. Эксперимент показывает, насколько важны явные governance, decision rights и feedback loops при работе агентов. А что нашли вы?

⚡️ Выпустить легко. Научиться сложнее Наткнулся на очень сильный материал от ProKanban про типичную проблему AI. AI радикально снижает стоимость создания софта. Команды могут выпускать гораздо больше фич за то же время. Сам по себе выпуск никому не нужен. Выпустить фичу теперь легко. Научиться на результате — вот где настоящая работа. Поэтому заканчивать Kanban-доску на выпуске становится совсем странно. Нам нужно понять, создало ли изменение ценность и чему мы научились. И вот что можно сделать: продолжить поток дальше выпуска — Released → Measuring → Learned. Работа заканчивается, когда команда получила данные и проверила свои предположения. И здесь появляется новый объем незавершенной работы: сколько изменений мы выпустили, но еще не успели проверить их эффект. Мне особенно нравится связка с Evidence-Based Management — управлением на основе свидетельств. Оно помогает смотреть на ценность, а Kanban делает цикл обучения видимой частью потока. AI дает нам шикарную возможность перестроить этот поток. Узкое место переезжает дальше по системе — в измерение, проверку гипотез и validated learning. На каком этапе заканчивается ваша Kanban-система?

⚡️ 13 инструментов диагностики организации За последние год собралось много инструментов организационной диагностики. Они помогают увидеть, где организация теряет скорость и адаптивность и что именно можно менять. Сейчас это особенно важно: AI быстро меняет то, как устроена работа, и организациям приходится быстрее учиться и перестраиваться. Поэтому я записал видео и коротко прошёлся по всем 13 инструментам. Такой формат пробую впервые — не знаю, зайдёт вам или нет. Посмотрите и напишите, какой инструмент вам понравился больше всего. 00:00 — Введение: кому и зачем нужны 13 инструментов диагностики 00:50 — Интервью (1) 02:03 — Тепловая карта (2) 05:23 — DSM-матрица (3) 08:29 — Функциональный анализ (4) 09:20 — Матрица критичности и неопределённости (5) 10:52 — Матрица зависимости (6) 12:32 — Value Stream Mapping (7) 14:31 — Feature-Team Adoption Map (8) 16:17 — Org Topology, организационная топология (9) 18:14 — Сетевая диаграмма оргдизайна (10) 19:54 — Причинно-следственные связи, CLD (11) 20:34 — PST: Professional System Thinker 20:55 — Айсберг системного мышления (12) 21:38 — Причинно-следственная карта (13) 23:19 — DAO Практикум 24:03 — DAO: Designing Adaptive Organizations

⚡️ Темная кабина вместо дашбордов В современных самолетах есть интересный принцип проектирования — dark cockpit. Пока все работает нормально, кабина визуально остается «темной». Никаких лишних сигналов. Если возникает отклонение, система сразу привлекает к нему внимание пилота. Раньше было иначе: куча приборов и показателей, которые пилоту приходилось постоянно контролировать. В итоге много внимания уходило просто на проверку того, что все работает нормально. И тут хороший контраст с тем, как мы часто проектируем управление в компаниях. Добавляем KPI, метрики, дашборды, отчеты — и заставляем лидеров постоянно смотреть на огромное количество информации. В авиации пришли к обратному принципу: нормальная работа системы не должна требовать внимания. Система должна сама сделать отклонение очевидным и направить человека туда, где требуется решение. По сути, это тот же принцип, что и andon в Lean. И еще один важный момент: система проектируется с учетом того, что люди ошибаются. Чек-листы и сигналы помогают поймать ошибку достаточно рано. Чем меньше информационного шума, тем больше внимания остается на реальную проблему. Статья про dark cockpit: Lean Enterprise Institute Что показывают ваши дашборды?

⚡️ AI требует перепроектировать организацию McKinsey выпустили свежее исследование про AI и операционную модель. Компании разделили на три уровня зрелости: доступ к AI-инструментам, автоматизация процессов и переизобретение — перепроектирование самой работы с учетом AI. Таких компаний всего 13%. AI у них уже затрагивает роли, процессы и операционную модель. Почти половина лидеров из этой группы говорит о заметной ценности AI для бизнеса против 13% на первом уровне. Особенно интересно, как меняется структура. Компании на уровне переизобретения чаще собирают кросс-функциональные команды с end-to-end ответственностью за создание ценности и меньшим количеством передач работы между функциями. Форма зависит от стратегического фокуса: при продуктоцентричном команды строятся вокруг продукта, при клиентоцентричном — вокруг customer journey, при операционно-центричном — вокруг сквозного бизнес-процесса. Я писал об этом и разбирал в книге «Дизайн Agile-организаций». И вот для меня главная мысль. Хотите получить реальную ценность от AI — придется перепроектировать организацию. AI ускоряет отдельные задачи, но зависимости между подразделениями никуда не исчезают. Все равно нужны end-to-end команды и полуавтономные подразделения с минимумом внешних зависимостей. Иначе получите локальные автоматизации внутри старой структуры. Так что от Agile, Scrum и организационного дизайна с приходом AI мы никуда не денемся. Исследование McKinsey прикладываю. Что об этом думаете?

⚡️ AVSM: как найти потери скорости, определить рычаги и продать изменения На днях созванивались с одним project-менеджером. Он проектирует процессы для двух департаментов, в каждом из которых несколько команд. Задача — сделать поток работы более предсказуемым. Он рассказал мне задачу и хотел обсудить, как провести Value Stream Mapping. Я послушал и понял: обычного VSM здесь не хватит. Ему нужен Advanced Value Stream Mapping, AVSM. Это моя методология end-to-end workshop, которую я постепенно собрал вокруг VSM. В ней мы разбираем поток, операционные зависимости, семь видов потерь Toyota, метрики, разные типы задач и параллельные ветки. Но главная фишка AVSM — в сквозной фасилитации. Люди сами проходят весь путь: находят потери скорости, определяют рычаги изменений и фактически продают эти изменения сами себе. Поэтому на выходе появляется не только список проблем, но и мандат на изменения. Мы проговорили про это 40 минут, а потом я записал подробный разбор для участников DAO Практикума. К сожалению, выложить его сюда не могу из-за чувствительной информации, которую мы обсуждали. Но могу провести открытый часовой эфир и впервые целиком разобрать AVSM: механику, фасилитацию и тонкости проведения такого воркшопа. Готовы узнать про AVSM? Ставьте + в комментариях.