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

⚡️ Хорошее решение может проиграть На выходных прочитал Thinking in Bets Энни Дьюк. И там есть мысль, которую многим лидерам и продуктовым командам полезно прибить к стене: «Хорошим решение делает не хороший результат. Хорошее решение — это результат хорошего процесса, и этот процесс должен включать попытку как можно точнее представить собственное состояние знания». Мы любим судить задним числом. Хороший результат — значит, решили правильно. Плохой — значит, ошиблись. Это слишком упрощённая логика. В сложной среде хороший результат может быть удачей. Плохой — следствием вполне разумного решения. Будущее неопределённо, информации всегда не хватает. Отсюда для меня главный вывод: Качество решений зависит от качества процесса, в котором мы обновляем своё представление о реальности. И здесь вспоминается старый добрый Скрам. Эмпирический контроль — его центральная концепция. Инспекция проверяет наши предположения реальностью, адаптация меняет следующие решения. Если новые данные не меняют решений, эмпиризма нет. Хороший процесс не гарантирует хороший результат. Он повышает шанс принять следующее решение лучше. Как у вас с хорошими решениями?

⚡️ Максимальная скорость ограничена структурой Недавно мне задали хороший вопрос: что быстрее — кросс-функциональная команда или три функциональные группы: аналитики, разработчики и тестировщики, работающие в общей Kanban-системе? Представим, что каждая функциональная группа установила минимальный WIP-лимит — один. Одна задача у аналитиков, одна у разработчиков, одна у тестировщиков. Минимальный WIP всей системы уже равен трем. Это ограничение создает сама структура. Кросс-функциональная команда может пойти дальше: одна задача на всю команду, однопоточная работа (ссылка), сворминг или моббинг. Тогда WIP системы может быть равен единице, а это максимальная скорость. Есть и второй эффект. Анализ, разработка и тестирование постоянно требуют уточнений и исправлений — это взаимные зависимости по Томпсону (пояснение здесь). В кросс-функциональной команде такие циклы могут закрываться почти мгновенно. В функциональной структуре каждый возврат пересекает границы команд и требует дополнительной координации. Процесс можно улучшать очень долго. Но максимальная потенциальная скорость ограничена структурой. При прочих равных кросс-функциональная команда получает структурное преимущество. Поделитись вашими структурными ограничениями, которые бесят?

⚡️ Команды в AI-native организации На днях созвонился с коллегой, которая проектирует подразделение на 50–70 человек. Мы перенесли операционные зависимости между командами в DSM (Design Structure Matrix) и запустили алгоритм оптимизации. Сразу проявились два плотных кластера — кандидаты на будущие организационные единицы. Функции, которые постоянно зависят друг от друга, имеет смысл держать вместе, снижая координацию через границы команд и подразделений. Для AI-native организации это особенно важно. AI в разы ускоряет отдельные задачи. Но если результат проходит через пять команд, согласования и очереди, организация быстрее не становится. Локальное ускорение упирается в стоимость координации. Поэтому мало внедрить AI в существующую структуру. Нужно сокращать внешние зависимости и собирать тесно связанные функции внутри автономных команд и юнитов. Тогда AI ускоряет весь поток создания ценности, а не отдельные операции. Еще в 1960-х Джеймс Томпсон описал взаимные, последовательные и общие операционные зависимости. DSM делает их видимыми и помогает спроектировать будущую структуру организации. Как вы проектируете команды?

⚡️ ChatGPT — океан, NotebookLM — лаборатория Недавно проводил воркшоп по NotebookLM. Родилась метафора. Если ChatGPT, Claude или Gemini — это океан, то NotebookLM — лаборатория. Когда цена ошибки высока, хорошего ответа мало. Важно понимать, на каких источниках он основан. NotebookLM работает только с тем, что вы ему дали: книгами, статьями, интервью, исследованиями или внутренними документами. Он показывает, откуда взят каждый вывод. Поэтому такой подход особенно полезен в медицине, юриспруденции, финансах, исследованиях и консалтинге, где важно быстро проверить обоснованность выводов. Я использую NotebookLM для проверки результатов других LLM. Например, Claude помогает подготовить отчет по организационной диагностике. Затем я загружаю в NotebookLM интервью, документы и сам отчет и прошу проверить, подтверждаются ли выводы материалами. За несколько минут находятся места, где модель слишком смело интерпретировала данные. Еще один полезный сценарий — собственная база знаний. Загружаете книги, статьи, материалы курса или исследования и получаете AI, который отвечает только в рамках этой библиотеки. P.S. Если вы в России и NotebookLM работает нестабильно даже через VPN, поможет настройка DNS: xbox-dns.ru Если пользуетесь NotebookLM — поделитесь полезными сценариями. Возможно, мы соберем отличную коллекцию идей.

⚡️ Книга, которая меняет угол зрения Обычно я не рекомендую книгу, пока не дочитаю ее до конца. Но здесь уже через несколько десятков страниц стало понятно: читать стоит. По ходу чтения выписал для себя около двадцати рефреймов. Вот пять, которые сразу забрал в работу. • Вместо погони за целями — строить систему, которая сама приводит к результату. • Вместо управления временем — управлять своей энергией. • Вместо поиска идеальной идеи — сначала выдать десятки плохих. • Вместо ожидания, что каждый эксперимент окажется успешным, — считать нормой, если срабатывает один из десяти. • Вместо попытки стать лучшим в одном навыке — собрать сильную комбинацию взаимодополняющих навыков. Люблю книги, после которых меняется не объем знаний, а угол зрения. Reframe Your Brain — как раз такая. Если работаете с продуктами, организационным дизайном, развитием команд или просто любите сильный non-fiction — смело рекомендую. Какая книга изменила ваше мышление последней?

⚡️ Общие сервисы живут иначе Вчера консультировал руководителя маркетинга. Она говорит: «Команда сильная, но всё движется медленно». Открываем доску. В работе — десятки задач. Такое я регулярно вижу в платформах, рисках, HR, лигал и других общих сервисах. К ним проходят запросы от всей организации, и они страдают от расфокуса. В результате сервис становится менее предсказуемым для своих внутренних заказчиков. Как этого добиться? Например, через явное ограничение незавершенной работы (WIP). На такой контекст хорошо ложится Kanban, потому что он стабилизирует поток, создает фокус и делает работу более предсказуемой. Несколько лет назад мы с Алексеем Пикулевым проектировали такую систему для функции рисков одного крупного банка. На фотографии — одна из тех рабочих сессий. Если узнали свою ситуацию — попробуйте найти место, где поток перегружен, и ограничьте незавершённую работу. Этого достаточно, чтобы поток ускорился и стал более предсказуемым. Где вам стоит ограничить WIP?

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

⚡️ Спроектируйте организацию, которая выпускает продукты в 2–3 раза быстрее Практически во всех моих консалтинговых проектах результатом становилось кратное сокращение Time-to-Market. Росбанк, СБП, МТС Касса и другие компании — перепроектирование организации каждый раз позволяло радикально ускорить поставку ценности. Именно поэтому я решил собрать эту методологию, инструменты и многолетнюю практику в новой программе DAO PRO · AI-native. Если вы CEO, CTO, COO, руководитель PMO, руководитель трансформации, Agile-коуч или отвечаете за развитие компании или юнита, возможно, сейчас перед вами стоит одна из таких задач. - Сократить Time-to-Market и сделать разработку более предсказуемой. - Разработать организационный дизайн под новую стратегию компании. - Защитить организационный дизайн перед руководством и получить поддержку изменений. - Провести диагностику организации и понять, что именно ограничивает скорость изменений. DAO PRO · AI-native — профессиональная проектная программа по проектированию скоростных организаций. Если вы еще не знакомы с методологией DAO, это не проблема. Для новых участников программа начнется с двухдневного интенсивного погружения в методологию проектирования скоростных организаций. За последние годы сама методология сильно выросла. И, пожалуй, именно эта часть меня сейчас больше всего драйвит. Около 40% того, что мы будем использовать в DAO PRO, пока вообще не описано ни в одной из моих книг. Это новые инструменты, новые модели и новые способы применения уже известных подходов, которые появились в результате многолетней консалтинговой практики. Программа длится 4–8 недель. Мы будем встречаться раз в неделю, а между встречами работать над организационным дизайном вашей компании или юнита. Вы разработаете 3–5 вариантов организационного дизайна, сравните их по скорости, стоимости, предсказуемости и ограничениям вашего контекста и выберете решение, которое действительно можно внедрить. Среди них будет и радикальный вариант, способный кратно сократить Time-to-Market. Мы будем использовать специально разработанное программное обеспечение для организационной диагностики и проектирования, а AI станет полноценной частью работы над вашим проектом. По итогам программы вы получите завершенный проект организационного дизайна и профессиональный статус DAO PRO. Первый поток планирую запустить в августе–сентябре. Это будет небольшая пилотная группа до 8 участников. Хочу поработать с каждым максимально глубоко, поэтому количество мест ограничено. Если хотите попасть в первый поток — записывайтесь в лист ожидания. 👉 Ссылка

⚡️ Отказ от Спринтов не решает проблему Давно хотел написать этот пост. Финальной точкой стала статья Нильса Пфлегинга. Нильса я очень уважаю, книги его читал с большим удовольствием. Но здесь, кажется, мы по-разному понимаем, что такое Спринт. Часто встречаю призывы отказаться от Спринтов и перейти в «настоящий поток». И каждый раз ловлю себя на мысли, что спор идет совсем не о том. Я много лет подряд рассказываю про one-piece flow. Если вы давно знаете меня, то знаете, что я всегда выступал за максимально маленький размер работы, быстрый поток и отсутствие очередей. Самый известный пример — кейс СБП c 4х кратным ускорением. Команды работали практически без внутренних очередей. По сути, оставалась одна внешняя очередь — Бэклог Продукта. Поток был настолько быстрым, что Канбан был просто не нужен. Именно поэтому меня удивляют призывы отказаться от Спринтов. Скрам вообще не говорит, как вам организовать поток работы. Хотите выкатывать изменения десять раз в день — отлично. Хотите делать Continuous Delivery — пожалуйста. Хотите работать по одной задаче за раз — тоже прекрасно. В Руководстве по Скраму говорится, что Спринт — это контейнер для всех остальных событий. Смысл этих событий очень простой: регулярно остановиться и проверить, приближаемся ли мы к Продуктовой цели (Product Goal). Посмотреть на результаты, обсудить обратную связь, скорректировать Бэклог Продукта и решить, что делать дальше. Вот для чего нужен Спринт. Спринт — механизм эмпирического контроля. А поток — это способ организовать выполнение работы. Это две разные вещи, которые прекрасно сочетаются друг с другом. Когда я слышу призывы отказаться от Спринтов ради потока, мне кажется, что люди спорят не со Спринтами. Они спорят с батчингом. И батчинг действительно стоит убирать. А вот регулярную инспекцию и адаптацию я бы точно оставил. Что думаете?

⚡ Как оценить вклад сотрудника? Как понять, кто из сотрудников сработал лучше? И какая команда показала лучший результат? Никак. Любой результат — это сочетание усилий людей и условий, в которых они работают. Процессы, архитектура, зависимости, качество решений, доступные инструменты, помощь коллег, случайности — всё это влияет на итог. «Невозможно измерить индивидуальную результативность. Вы измеряете лишь совокупный эффект системы и усилий человека. Разделить их невозможно.» Эдвард Деминг. А вы что оцениваете — людей или систему?

📚Книги для агентов изменений Участвую сейчас в одном из проектов организационной трансформации и поймал себя на мысли: а какие книги действительно лежат у меня на рабочем столе и к которым я регулярно возвращаюсь? Для меня это всего две книги. И символично, что обе написаны людьми, которых я знаю уже много лет и глубоко уважаю как практиков. 📘 Первая - книга моего друга Ильи Павличенко «Дизайн Agile-организации». Для меня это настоящий справочник по организационному дизайну. Когда возникает вопрос, как перестроить структуру, роли, процессы, взаимодействие команд или систему управления, - очень часто открываю именно ее. Огромное количество практических гайдов, инструментов и идей, которые помогают не просто обсуждать изменения, а проектировать их. 📗 Вторая - «Карта гипотез (вторая книга)» Александра Бындю. Любая трансформация начинается с большого количества предположений. Что именно менять? Где настоящая проблема? Какие изменения дадут эффект, а какие окажутся пустой тратой времени? Эта книга помогает структурировать гипотезы, определить стратегию изменений и двигаться не на интуиции, а через осознанные эксперименты. Любопытно, что эти две книги отлично дополняют друг друга. Одна отвечает на вопрос «Как проектировать организацию?», другая - «Что именно стоит менять в первую очередь и как проверить, что мы движемся в правильном направлении?» Если вы занимаетесь организационными изменениями, Agile-трансформациями или развитием компаний, искренне рекомендую обе книги. Для меня они уже давно стали настольными. А какие книги вы считаете обязательными для агента изменений? Поделитесь своими рекомендациями в комментариях.

⚡️ Нужна стратегия — иду на тренировку Не знаю, как это работает и что именно происходит с точки зрения биохимии. Но уже много лет замечаю одну вещь. После хорошей силовой тренировки я весь день летаю словно на крыльях. Отличное настроение, куча энергии, и именно в таком состоянии почему-то приходят самые хорошие мысли. Так получилось и на днях. Тренировка вышла настолько удачной, что я обновил свою персональную стратегию. Хотя предыдущую версию написал всего две недели назад. И принял несколько важных решений. Поймал себя на мысли, что полезно знать про себя такие вещи. Для меня это тренировка. Похоже, именно в этом состоянии лучше всего получается думать стратегически. А что помогает вам поймать такое состояние?

⚡️ На выходных снова стал программистом С пятницы по воскресенье меня затянул Claude. Настолько, что две ночи подряд почти не спал. В ночь с субботы на воскресенье лег только в три — просто потому, что хотелось закончить еще один кусок. Я наконец сделал то, до чего годами не доходили руки — начал писать инструмент для организационной диагностики. Когда работаешь с большими организациями, постоянно повторяешь одни и те же действия: картируешь поток, строишь тепловые карты, анализируешь компоненты и зависимости, чтобы понять, где командам не хватает автономности и где на самом деле нужно менять систему. Теперь эту работу я постепенно автоматизирую. И за эти три дня я неожиданно вспомнил, что всегда любил в программировании. Когда я был разработчиком, мне никогда не нравилось писать код. Мне нравилось думать об архитектуре, видеть систему целиком. Теперь код в основном пишет Claude. А мне остается то, что всегда приносило удовольствие. Первый модуль уже готов. Есть личный кабинет, можно создавать тепловые карты, сохранять их и анализировать. Дальше хочу добавить функциональный анализ, анализ операционных зависимостей и еще несколько диагностических модулей. Но главное открытие оказалось другим. Навыки разработчика никуда не делись. Я по-прежнему думаю через архитектуру. Помню SOLID, YAGNI, XP, TDD. Поэтому Claude не просто генерировал код. Он писал так, как я от него требовал: с TDD, автотестами, архитектурными ограничениями и субагентами с разными ролями. Я просто в восторге. И, кажется, понял одну вещь. AI не столько заменяет людей, сколько начинает возвращать им профессии, от которых они когда-то ушли. Потому что постепенно забирает самые рутинные и нелюбимые части работы, а человеку оставляет то, ради чего он когда-то вообще пришел в эту профессию. У вас было что-то похожее?

⚡️ Как измерить организационное обучение «Организация учится тогда, когда меняет свои последующие решения на основании обратной связи». — Джон Стерман Мне нравится это определение. И обучение можно измерить. Одна из лучших метрик обучения организации — количество изменений в Бэклоге Продукта после Обзора Спринта. Ведь именно там материализуется обратная связь: в изменившихся приоритетах, новых идеях и решениях отказаться от старых. Но прикол в том, что у большинства команд Обзор Спринта это просто Демо, после которого не происходит изменение содержимого Бэклога Продукта. Команды просто двигаются по заранее намеченному плану, а Демо это отчетная вечеринка. Поэтому организационное обучение не происходит. А ваша организация учится, на самом деле?

⚡️ Gamma оказалась быстрее Codex Последние недели почти все презентации делаю в двух инструментах: Codex и Gamma. И пришел к выводу, что они решают разные задачи. Если нужно глубоко подумать над структурой, логикой или содержанием — я остаюсь в Codex. Но это скорее "черный ящик": отправил запрос, подождал, получил результат. Что происходило внутри — не очень понятно. Когда структура уже есть, почти всегда перехожу в Gamma. Она ощущается совсем по-другому. Ты работаешь не с ответом модели, а с презентацией. Карточки перестраиваются прямо на глазах, можно мгновенно менять структуру, оформление, добавлять или удалять разделы. Скорость работы ощущается совершенно иначе. Из того, что особенно понравилось: • 20+ AI-моделей для текста, дизайна и изображений; • Word, PDF или ссылка за 60 сек. превращаются в готовую презентацию; • есть аналитика просмотров: видно, кто открыл презентацию, сколько времени провел на каждом слайде и где перестал смотреть; • веб-формат вместо тяжелых файлов — отправил ссылку и всё работает на любом устройстве; Есть только один совет, который сэкономит вам деньги. Отключайте генерацию изображений. Иначе токены заканчиваются очень быстро. Я прошу Gamma использовать простые заглушки, а все финальные изображения делаю отдельно в ChatGPT в своем стиле. Получается и дешевле, и визуально гораздо аккуратнее. Сделал презентацию с обзором возможностей Gamma. 👉 https://gamma.app/docs/5-Gamma--sotfm82d8w60o6f Что используете — Codex, Gamma или что-то еще?

⚡️ Сначала меняется система На выходных проводили небольшой Coach Camp с друзьями. Поймал себя на мысли, как изменились наши разговоры за последний год. Раньше почти все обсуждения были про оргдизайн. Сейчас почти любая тема приходит к AI. Разбирали пример одной большой компании. У нее Discovery идет квартал, потом еще квартал занимает Delivery. При этом компания готовится внедрять AI. Сегодня Discovery, прототип и первую обратную связь можно получить за несколько дней. Если при этом Discovery по-прежнему занимает квартал, AI не поможет. Люди действительно начинают работать быстрее. Но эффективность потока от этого автоматически не растет. Самый большой эффект AI, как мне кажется, получают организации, которые готовы перепроектировать процессы: перейти к меньшим рабочим пакетам, сократить cycle time и повысить эффективность потока. Подробнее об этом писал в книге "Дизайн Agile-организаций". Проблема в том, что такой реинжиниринг почти неизбежно затрагивает роли, ответственность, структуру принятия решений и привычные способы работы. А здесь вступает в силу законы Лармана: организации неявно оптимизированы так, чтобы сохранять существующий статус-кво, существующее распределение власти и существующие организационные структуры. Да, AI способен многократно усилить. Но максимальный эффект, скорее всего, получат только те, кто готов саму систему. Что вы думаете?

⚡️ Пять часов искать не там Вчера почти пять часов бился над отчетом по организационной диагностике. Переписывал промпты, менял связки Codex, NotebookLM и ChatGPT, но проблема оказалась не в настройках. Я пытался заставить инструменты делать работу, для которой они не подходят. Тогда я вернулся к проектированию самого процесса и разложил его по шагам. Для каждого шага выбрал режим из модели A4 (детали здесь) — Automate, AI Only, Assist или Avoid — и подобрал инструмент, который лучше всего справляется именно с этой частью работы. NotebookLM (с 16 июля Gemini Notebook) оказался сильным в работе с доказательной базой: искать подтверждения, сравнивать интервью, находить противоречия и проверять готовый диагноз. Поэтому он особенно полезен там, где цена ошибки высока: в исследованиях, юриспруденции, медицине и аудите. Интерпретацию, причинные связи и сам организационный диагноз лучше собирать в связке эксперта и Codex. Для презентации я использовал Gamma. Главный вывод: выигрывает эксперт, который понимает сильные стороны каждого инструмента и подключает их на разных этапах процесса. Умение собрать из AI работающую систему становится отдельной профессиональной компетенцией. Как вы распределяете роли между AI-инструментами?

⚡️ Как приоритизировать AI‑инициативы Полезно разложить все AI‑идеи на простую карту из четырёх квадрантов. По одной оси — фокус на клиенте или на сотруднике. По другой — ориентация на рост или на снижение затрат. Возьмём IKEA. Кейсы про рекомендации, ценообразование и «агентную» коммерцию попадают в зону «клиент + рост» с акцентом на новую выручку и качество опыта. Еще рост в клиентском квадранте: покупатель сканирует комнату через 3D/LiDAR, выбирает стиль и бюджет, система предлагает несколько вариантов обстановки в 3D, которые можно донастроить под себя. Кейсы про оптимизацию цепочки поставок, доставку до клиента и работу бэк‑офиса — в квадранты про эффективность и сокращение издержек. Когда карта инициатив заполнена, следующий шаг — вспомнить стратегический фокус по Вирсеме: операционная эффективность, лидерство по продукту или близость к клиенту. Под этот фокус выбираются одна–две ключевые способности (capabilities) на рост и одна–две вторичные на эффективность, которые вы готовы усиливать AI в ближайшие 90 дней. Инициативы из карты получают приоритет только если усиливают эти способности; остальные временно уходят в «паркинг». Так появляется управляемый портфель: связка со стратегией и ограниченное число способностей, которые вы реально прокачиваете. А как вы приоритизируете AI‑инициативы?

⚡️ Как определять кластеры команд** Работал с почтово-логистической компанией, где в продуктовой разработке около 300 человек. Один из первых вопросов при проектировании продуктовой организации — как определить кластеры команд? Начали со стратегии. Доминирующим оказался клиентоцентричный фокус. Но это не означает, что все кластеры команд должны строиться вокруг клиентских сегментов. Для крупных организаций такой модели почти никогда не бывает достаточно. Мы сознательно спроектировали гибридную структуру кластеров команд. Кластеры команд вокруг рынков и клиентских сегментов (доминирующий фокус): - Международная доставка. - Внутрироссийская доставка. - Корпоративные клиенты. Кластеры команд вокруг операций: - Оформление и исполнение отправлений. - Работа отделений. Кластеры команд вокруг продуктов и инноваций: - Тарифы и расчеты. - Новые цифровые сервисы. Именно выглядят крупные организации. Стратегический фокус определяет доминирующую логику построения кластеров команд, но редко бывает единственной. Проблема не в гибридности. Если вы можете объяснить, почему один кластер команд построен вокруг рынка или сегмента, другой — вокруг процесса, а третий — вокруг продукта или платформы, значит структура поддерживает стратегию. По какой логике сегодня определены кластеры команд в вашей компании?

⚡️ У эксперта должны быть AI-ассистенты На выходных я собрал AI-ассистента для работы с материалами организационных исследований. В него можно загрузить интервью, заметки с Gemba, результаты Value Stream Mapping, SWOT, материалы воркшопов и другие исследовательские артефакты. Решил проверить его на реальной работе. Загрузил материалы исследований, которые проводил в крупных компаниях в прошлом году. Подготовка материала, на которую раньше уходило несколько дней, в этот раз заняла около часа. AI-ассистент быстро собрал наблюдения из разных источников, выделил повторяющиеся паттерны и разложил материал по уровням системного айсберга. При этом он не интерпретирует результаты и не предлагает рекомендации. Это остается работой эксперта. Пока собирал ассистента, понял одну вещь. Общих знаний языковой модели для такой задачи оказалось недостаточно. Пришлось буквально разложить по полочкам собственный способ анализа: что относится к каждому уровню системного айсберга, по каким признакам их различать и где ассистент должен остановиться. Получается интересное разделение ролей. AI отлично справляется с обработкой больших массивов информации и поиском паттернов. Но качественная диагностика по-прежнему требует доменной экспертизы. Сейчас у меня уже около двадцати таких AI-ассистентов. Каждый ускоряет отдельную часть моей работы, но ни один не заменяет экспертизу. Если вам интересно, чтобы я про них рассказал, напишите в комментариях. Какого AI-ассистента вам сегодня не хватает?