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

⚡️ Как решить запутанную проблему так, чтобы она не вернулась

Люди сопротивляются изменениям: «Мы 20 лет так работали». Каждый отдел оптимизирует свою работу — и создаёт проблемы следующему. Одни и те же пожары месяцами превращаются в хотфиксы. У вас 15 команд и десятки зависимостей — и непонятно, куда приложить усилия.

7 октября с 16:00 до 18:00 проведу открытый эфир о том, как решать проблемы с помощью системного мышления и AI.

Прямо на эфире выберем одного участника с реальной проблемой. Я проведу короткое интервью, а затем передадим историю команде AI-агентов.

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

Реальная проблема → системная модель → рычаг → изменение.

Участие бесплатное. Запись получат те, кто придёт на эфир.

📅 Добавьте эфир в свой календарь, чтобы не пропустить. Ссылку на Zoom пришлю за час до начала: https://calendar.app.google/aCqhcfzcxtVPSkFx6

⚡️ Кейс: кто теперь будет продавать мой продукт?

На консультации с одним из руководителей большой компании обсуждали переход к клиентоцентричной стратегии. И обнаружили характерный конфликт.

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

И у каждого владельца продукта появляется вполне понятный вопрос:

«А если сегменты перестанут продавать мой продукт? Будут собирать низковисящие фрукты, а в развитие новых продуктов никто не вложится?»

Джей Гэлбрейт, автор звездной модели оргдизайна, описывал процессы, которые помогают согласовывать работу продуктовых и клиентских подразделений. Один из них — согласование стратегий и планов продуктов и сегментов.

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

На картинке — пример такой договоренности. Продукт 1 в двух сегментах основной, а в третьем его продажи останавливают. Продукт 2 где-то растят, где-то продают в пакете. В Продукт 3 инвестируют для одного сегмента, запускают пилот для другого, а в третьем спроса нет.

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

Если интересно, какие еще процессы нужны клиенто-центричной организации, поставьте + в комментариях. Расскажу о них в следующих постах.

⚡️ Должности уходят. Теперь все — технические сотрудники

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 менторинг.
6. Приходить можно с любой рабочей задачей.

Пять мест уже заняты. Осталось одно. Хотите присоединиться — пишите @fancydev.

Что еще рассказать?

⚡️ Tiny Teams оптимизируют не то

В Альфа-Банке тестируют Tiny Teams: вместо классической продуктовой команды из 8–10 человек тот же объем разработки пытаются делать гораздо меньшим составом (2-3) с помощью AI.

Алексей Фетисов, директор по информационным технологиям Альфа-Банка:

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

И вот тут у меня вопрос: в правильную ли сторону двигается организация?

Если AI позволяет меньшим количеством людей делать больше, нам не обязательно уменьшать команду. Команда может остаться из 5–7 человек, но изменится ее состав.

В эти 5–7 человек можно собрать разработку, безопасность, риски, маркетинг, продажи и другие необходимые компетенции. Дать им AI-инструменты и строить команду вокруг end-to-end value stream, сокращая внешние зависимости, передачи и согласования.

И это возвращает нас к идее The New New Product Development Game из Harvard Business Review 1986 года: кросс-функциональная команда, которая вместе проходит весь путь создания продукта.

Tiny Teams продолжают оптимизировать разработку. Мне кажется, гораздо интереснее использовать AI, чтобы наконец собрать настоящую end-to-end продуктовую команду, превратив ее в enterprise-стартап с PnL.

Что думаете?

⚡️ Выпустить легко. Научиться сложнее

Наткнулся на очень сильный материал от ProKanban про типичную проблему AI.

AI радикально снижает стоимость создания софта. Команды могут выпускать гораздо больше фич за то же время. Сам по себе выпуск никому не нужен. Выпустить фичу легко. Научиться на результате — вот где настоящая работа.

Поэтому заканчивать Kanban-доску на выпуске становится совсем странно. Нам нужно понять, создало ли изменение ценность и чему мы научились. И вот что можно сделать: продолжить поток дальше выпуска — Released → Measuring → Learned.

Работа заканчивается, когда команда получила данные и проверила свои предположения. И здесь появляется новый объем незавершенной работы: сколько изменений мы выпустили, но еще не успели проверить их эффект.

Мне особенно нравится связка с Evidence-Based Management — управлением на основе свидетельств. Оно помогает смотреть на ценность, а Kanban делает цикл обучения видимой частью потока.

AI дает нам шикарную возможность перестроить этот поток. Узкое место переезжает дальше по системе — в измерение, проверку гипотез и validated learning.

На каком этапе заканчивается ваша Kanban-система?

⚡️ Темная кабина вместо дашбордов

В современных самолетах есть интересный принцип проектирования — dark cockpit. Пока все работает нормально, кабина визуально остается «темной». Никаких лишних сигналов. Если возникает отклонение, система сразу привлекает к нему внимание пилота.

Раньше было иначе: куча приборов и показателей, которые пилоту приходилось постоянно контролировать. В итоге много внимания уходило просто на проверку того, что все работает нормально.

И тут хороший контраст с тем, как мы часто проектируем управление в компаниях. Добавляем KPI, метрики, дашборды, отчеты — и заставляем лидеров постоянно смотреть на огромное количество информации.

В авиации пришли к обратному принципу: нормальная работа системы не должна требовать внимания. Система должна сама сделать отклонение очевидным и направить человека туда, где требуется решение.

По сути, это тот же принцип, что и andon в Lean. И еще один важный момент: система проектируется с учетом того, что люди ошибаются. Чек-листы и сигналы помогают поймать ошибку достаточно рано.

Чем меньше информационного шума, тем больше внимания остается на реальную проблему.

Статья про dark cockpit: Lean Enterprise Institute

Что показывают ваши дашборды?

⚡️ AI требует перепроектировать организацию

McKinsey выпустили свежее исследование про AI и операционную модель. Компании разделили на три уровня зрелости: доступ к AI-инструментам, автоматизация процессов и переизобретение — перепроектирование самой работы с учетом AI.

Таких компаний всего 13%. AI у них уже затрагивает роли, процессы и операционную модель. Почти половина лидеров из этой группы говорит о заметной ценности AI для бизнеса против 13% на первом уровне.

Особенно интересно, как меняется структура. Компании на уровне переизобретения чаще собирают кросс-функциональные команды с end-to-end ответственностью за создание ценности и меньшим количеством передач работы между функциями.

Форма зависит от стратегического фокуса: при продуктоцентричном команды строятся вокруг продукта, при клиентоцентричном — вокруг сегментов / индустрий / ролей, при операционно-центричном — вокруг сквозного бизнес-процесса.

Я писал об этом и разбирал в книге «Дизайн 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? Ставьте + в комментариях.

⚡️ Как, чему и зачем обучать руководителей высшего звена

Хотите успешных организационных изменений — начинайте с обучения руководителей высшего звена. Их ментальные модели определяют организационный дизайн. Ведь именно у этих людей ключи к организационным изменениям и власть.

Вчера прошел Agile Days. И мне присылают фотографию: на сцене Магнит рассказывает, что я обучал их топ-менеджмент. Теперь могу рассказать и я.

В прошлом году я провел серию тренингов для руководителей высшего звена и board−1 Магнита. На первых встречах — генеральный директор и его команда, представители разных форматов. И помню жаркие споры.

Например, каким должен быть стратегический фокус Магнита: операционно-продуктовым или клиентоцентричным? Что считать продуктом?

Вот темы, которые я считаю важными для топов:

1. Связь организационного дизайна, способностей и стратегии.
2. Системное мышление.
3. Теория очередей и бережливое мышление.
4. Широкое определение продукта.
5. Роль настоящего владельца продукта.
6. Взаимозаменяемые фичи-команды и другие гайдлайны по организационному дизайну из моей книги.

За последние десять лет, пожалуй, именно обучение топ-менеджмента удается мне лучше всего. После тренингов регулярно слышу: «Илья взрывает нам мозг».

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

Как вы взрываете мозг руководителям?

⚡️ Давайте знакомиться

Привет, я Илья Павличенко. Канал вырос, новых людей много — расскажу, кто я и чем занимаюсь.

Я эксперт по организационному дизайну и AI. Помогаю менеджерам и лидерам проектировать структуру, процессы и правила так, чтобы продукты выходили быстрее, а косты не росли. За плечами Росбанк, Альфа-Банк, Райффайзен, Открытие, ING, МТС Касса, Jusan Bank, Mighty Buildings.

Как я сюда пришёл
Прикладная математика. Несколько лет писал код, дорос до тимлида и понял, что меня больше тянет разбираться, как устроена работа вокруг кода. Перешёл на другую сторону Луны: Скрам-мастер, потом Agile-коуч в Luxoft.

В 2014-м вышел в свободное плавание. Первый в России Professional Scrum Trainer. В 2018-м сделал первый в России официальный кейс масштабируемого Скрама — МТС Касса: за полгода команда выросла с 28 до 60 разработчиков, Time-to-Market упал вдвое. Самый известный кейс — СБП, ускорение в четыре раза.

Индустрия значения не имеет: банки, финтех, логистика, FMCG, дома на 3D-принтерах. Системное мышление и теория очередей работают везде.

Сейчас пишу на вайбкодинге ПО для диагностики организаций, готовлю вторую версию методологии DAO и держу около двадцати AI-ассистентов под свои задачи.

А свежие промпты, скиллы, туториалы и другие AI-фишки складываю в отдельный канал «AI на работе».

Вне работы — мастер спорта по стритлифтингу и сапы всерьёз: зимой тоже, в костюме. Лучшие решения приходят после хорошей силовой. Ещё очень люблю живопись — импрессионистов и авангард.

Книги
«Creating Agile Organizations» — с Cesario Ramos. Как связать стратегию, структуру, процессы и HR-политики в одну систему.

«Дизайн Agile-организаций» — русская книга с инструментами: тепловые карты, области ценности, метрики адаптивности.

Статьи — на agile-organizations.ru и scrum.ru.

Самые популярные посты за полгода
→ Отказ от Спринтов не решает проблему
→ Команды нельзя нанять — только спроектировать
→ Кейс: 58% автономности, 0% поставки
→ Как оценить вклад сотрудника?
→ Скользящие цели: ловушка
→ Две логики AI
→ На выходных снова стал программистом
→ «Я плачу миллиард — а всё едет как черепаха»

Чаще всего ссылаюсь на: стратегический фокус, организационные способности, однопоточная работа, зависимости по Томпсону.

Чем помогаю
Обычно ко мне приходят с задачами: сократить Time-to-Market, пересобрать команды под новую стратегию, защитить оргдизайн перед руководством — и уходят с решением, которое можно внедрить.

→ Персональная консультация — разбираем ваш кейс один на один: где застревает поток, с чего начать. Уходите с планом. Написать @fancydev
→ DAO Практикум — менторинг в группе 4–6 человек. За 4–8 недель проектируете 3–5 вариантов оргдизайна своей компании и выбираете тот, что реально внедрить и защитить перед руководством.
→ Designing Adaptive Organizations — за два дня учитесь проектировать организацию целиком: от макродизайна и связанности на уровне портфеля до структуры команд.
→ Системное мышление — учитесь видеть, почему любая повторяющаяся проблема возвращается снова и снова, где в системе рычаг, который её меняет, и как показать это людям так, чтобы они поддержали изменения.
→ AI Практикум — учитесь закрывать типичные управленческие сценарии с помощью AI и собираете своих AI-ассистентов под свои задачи. То, что занимало дни, начинает занимать часы.
Для связи — @fancydev.

Что еще рассказать?

⚡️ Будущее без узких специализаций

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

В адаптивном организационном дизайне мы давно призывали уходить от узких специализаций внутри команд. Бизнес-аналитик, системный аналитик, фронтендер, бэкендер, тестировщик — каждый со своим кусочком работы и границами ответственности.

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

Появляется титул «продуктовый разработчик» для всей команды.

И AI делает такой переход реалистичным. Я сам сейчас с AI занимаюсь всем: маркетингом, продажами, монтажом видео — выполняю активности, которыми раньше не мог заниматься.

Настоящая мультифункциональность становится возможной. Искренне рад, что мы до этого дошли.

Как меняются ваши команды?

⚡️ Кейс: как вернуть топам реальность

Разбирали кейс AI-трансформации. Цели спущены сверху, к середине года их еще ужесточили, команды соревнуются между собой.

Раз в месяц — большое орг-демо, где все показывают, как здорово автоматизировали работу агентами.

Потом приходишь к команде и просишь показать подробнее: хочу перенести к себе. И выясняется, что решение работает при десятке дополнительных условий, о которых на демо не сказали. Хотя выглядело как готовый инструмент. Получаются такие потемкинские деревни AI-трансформации.

Мы нарисовали причинно-следственные циклы, и вылез интересный механизм: чем сильнее давление по целям, тем красивее становится картинка наверх. А чем красивее картинка, тем хуже руководство понимает реальное состояние дел и тем менее адекватные решения принимает.

Например, наверху считают, что здесь уже все реализовано и можно двигаться дальше. А на самом деле здесь еще конь не валялся.

В Scrum на Sprint Review показывают только то, что соответствует Definition of Done. Тогда инспекция имеет смысл: есть прозрачность — работает эмпирический контроль. Нет прозрачности — остается театр, и решения принимаются по картинке, которой в реальности нет.

Если в компании есть общие демо-дни, вывод тот же: у демо-дня должен быть свой DoD.

У меня есть товарищ, который когда-то вел проект именно так: каждую неделю удивлял заказчика новым функционалом и скоростью разработки. Заказчик был в восторге. Потом вскрылось, что под этим лежит техдолг размером с сам проект, и переделывать пришлось почти все.

И еще две вещи, без которых DoD для демо не заработает. Команды не сравнивают между собой. За внедрение не платят премию. Пока за цифру в отчете что-то дают или отнимают, цифра будет рисоваться.

У вас демо или потемкинская деревня?

⚡️ AI-агент сам придумал и продал продукт

Нэт Элиасон дал своему OpenClaw-агенту Felix $1,000 и задачу построить бизнес. Через три недели Felix заработал $14,718.

Самое интересное — откуда взялись первые деньги. Felix сделал Felix Playbook — PDF-гайд о том, как настроить собственного AI-агента, упаковал его и запустил в продажу. Только за первую неделю продукт принес около $3,500.

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

Чтобы это работало, вокруг модели пришлось построить отдельную систему. У Felix трехуровневая память: ежедневные записи, знания и правила поведения. Heartbeat возвращает его к незавершенным задачам, cron jobs запускают регулярную работу, а сложную разработку он может делегировать coding-агенту и потом контролировать результат.

Отдельно продуманы границы автономности. Telegram владельца — доверенный канал команд. Email и соцсети — источники информации. Для GitHub, Stripe, кошельков и деплоя используются отдельные аккаунты.

И вот это для меня самая интересная часть кейса: автономный AI-бизнес оказался задачей организационного дизайна. Нужно спроектировать память, полномочия, границы, механизмы контроля и взаимодействие между исполнителями.

Что в этом кейс самое интересное / крутое для вас?