Стратегия, AI и организационный дизайн
前往频道在 Telegram
🧠Стратегия, AI и организационный дизайн 📊Продуктовая разработка. 💪Стритлифтинг. Книга "Дизайн Agile-организаций" www.piter.com/product/dizayn-agile-organizatsiy www.agile-organizations.ru Для связи - @fancydev
显示更多2 044
订阅者
+4724 小时
+677 天
+18930 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
七月 '26
七月 '26
+105
在1个频道中
六月 '26
+275
在0个频道中
Get PRO
五月 '26
+253
在4个频道中
Get PRO
四月 '26
+231
在5个频道中
Get PRO
三月 '26
+253
在15个频道中
Get PRO
二月 '26
+191
在1个频道中
Get PRO
一月 '26
+51
在4个频道中
Get PRO
十二月 '25
+30
在1个频道中
Get PRO
十一月 '25
+58
在2个频道中
Get PRO
十月 '25
+124
在1个频道中
Get PRO
九月 '25
+80
在2个频道中
Get PRO
八月 '25
+85
在3个频道中
Get PRO
七月 '25
+58
在4个频道中
Get PRO
六月 '25
+70
在2个频道中
Get PRO
五月 '25
+58
在1个频道中
Get PRO
四月 '25
+152
在6个频道中
Get PRO
三月 '25
+89
在3个频道中
Get PRO
二月 '25
+272
在9个频道中
Get PRO
一月 '250
在3个频道中
Get PRO
十二月 '24
+1
在1个频道中
Get PRO
十一月 '24
+2
在0个频道中
Get PRO
十月 '24
+8
在0个频道中
Get PRO
九月 '24
+205
在1个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 11 七月 | +1 | |||
| 10 七月 | +49 | |||
| 09 七月 | +1 | |||
| 08 七月 | +9 | |||
| 07 七月 | +28 | |||
| 06 七月 | +3 | |||
| 05 七月 | +1 | |||
| 04 七月 | +1 | |||
| 03 七月 | +5 | |||
| 02 七月 | +3 | |||
| 01 七月 | +4 |
频道帖子
⚡️ A4 для проектирования AI-процессов
У одного моего коллеги PST-тренера есть интересная рамка A3, которая помогает командам договориться, где AI можно использовать, где его нужно контролировать, а где лучше вообще не подпускать к работе. Я бы расширил её до A4, потому что в реальных процессах “автоматизация” часто означает две разные вещи: AI выполняет шаг под контролем человека или AI работает полностью автономно в низкорисковом контуре.
A4 помогает разложить любой процесс по шагам — на уровне команды, продукта или всей организации — и решить, какую роль AI должен играть в каждом шаге. Это не про “написать запрос получше”, а про проектирование процесса: где нужен человек, где AI может помочь, где можно передать выполнение, а где допустима полная автономия.
1. Avoid — только человек. AI не участвует, если ошибка может ударить по доверию, отношениям, безопасности или репутации. Примеры: обратная связь, конфликтная коммуникация, чувствительные письма, обсуждение людей, решения с юридическим риском.
2. Assist — AI помогает. AI делает черновик, ищет закономерности, расширяет набор вариантов. Человек оценивает и принимает решение. Примеры: подготовка ретро, варианты критериев приёмки, анализ обратной связи, черновик сообщения для заинтересованных людей, идеи для экспериментов.
3. Automate — AI выполняет. AI ведёт шаг процесса по заданным правилам. У человека остаются проверка, правила остановки и ответственность за результат. Примеры: краткое содержание встреч, извлечение договорённостей и следующих шагов, регулярный отчёт о статусе, первичная обработка заметок из исследований.
4. AI Only — автономный AI. AI работает без ручной проверки каждого результата. Это подходит только для повторяемых, низкорисковых задач с понятными границами. Примеры: проверка формата данных, поиск дубликатов, присвоение технических меток, распределение типовых запросов по категориям.
Для меня ценность A4 в том, что он переводит разговор из “используем AI или нет?” в более точный вопрос: какую степень участия AI мы разрешаем на этом шаге процесса? А уже в следующем посте можно разобрать, как применять A4 к реальному процессу: разложить его по шагам, выбрать режим для каждого шага и описать ограничения.
Как бы вы использовали A4 в своей команде?
| 2 | ⚡️ Почему одни цели вдохновляют, а другие нет
Недавнее исследование о том, как руководители формируют надежду в организациях, предложило простую и полезную рамку.
Когда мы обсуждаем цели, разговор обычно сводится к одному вопросу: насколько они должны быть амбициозными?
Но есть вопрос важнее. Верят ли люди, что организация действительно способна этой цели достичь?
Представьте матрицу с двумя осями.
По вертикали — уровень амбиций.
По горизонтали — способности организации: насколько люди верят, что организация действительно способна достичь этой цели.
Получается четыре типа целей.
Слева — цели, в которые команда не верит. Именно здесь рождаются красивые презентации, громкие обещания и последующий цинизм. Не потому, что цель слишком смелая. А потому, что люди не видят у организации возможностей ее реализовать.
Справа — цели, которые воспринимаются как достижимые.
Если нужны прорывные изменения — новый продукт, выход на новый рынок, масштабная AI-трансформация, — выбирайте высокие амбиции.
Если организация перегружена, доверие к изменениям подорвано или важно закрепить уже достигнутые результаты, вполне нормально выбрать более умеренные цели и двигаться последовательно.
Получается, вопрос не в только в том, насколько амбициозна цель. А соответствуют ли амбиции реальным способностям организации.
Компании часто пытаются изменить формулировку цели, хотя гораздо важнее изменить саму организацию, чтобы люди действительно поверили: эту цель можно достичь.
Если посмотреть на ваши последние 3–5 целей, в каком квадранте они окажутся? | 348 |
| 3 | ⚡️ Скорость обратной связи определяет цель
В организациях ставят самые разные цели.
Одни описывают выполненную работу (Output), другие — изменения в поведении пользователей (Outcome), третьи — бизнес-результаты (Impact).
На картинке — моя рабочая эвристика. Она помогает выбрать, какой тип целей обычно уместен на разных горизонтах планирования.
Но это именно эвристика для коммерческих продуктовых организаций, а не универсальное правило.
Один из самых важных факторов здесь — скорость получения надежной обратной связи.
Если гипотезу можно проверить за несколько дней, Outcome вполне может стать целью спринта. Если обратная связь приходит месяцами, то даже квартальный горизонт может оставаться уровнем Output. А в некоторых контекстах — например, при работе по госконтракту — даже при быстрой обратной связи цели могут оставаться Output, потому что именно такой результат принимает и оплачивает заказчик.
Поэтому универсальной рекомендации здесь нет. Один и тот же горизонт планирования в разных организациях может предполагать разные типы целей.
Каких целей у вас больше: Output, Outcome или Impact? | 408 |
| 4 | ⚡️ Момент корпоративной трезвости AI
Посмотрел разбор MIT Project NANDA про корпоративные GenAI-внедрения. Цифра неприятная: только около 5% пилотов дают быстрый рост выручки или измеримый эффект для P&L.
Вот что мне показалось главным.
Большинство пилотов застревает. Красивое демо собрать не сложно. Сложнее довести его до результата в бизнесе: с данными, процессами и людьми, которые реально будут этим пользоваться.
Деньги уходят не туда. Больше половины бюджетов уходит в продажи и маркетинг. А самый заметный возврат MIT видит в автоматизации бэк-офиса: админка, операционка, снижение внешних затрат.
Партнёрства работают лучше, чем стройка внутри. Решения от специализированных поставщиков срабатывают чаще, чем попытка сделать всё своими силами.
AI должны вести линейные руководители. Люди, которые знают процессы, боль, ограничения и ежедневную работу команд.
AI усиливает то, что уже есть. Очереди, разрывы между командами, плохие данные, медленные решения. Всё это никуда не исчезает и становится заметнее.
Мой главный вывод: организационный дизайн становится главным фактором успеха AI-внедрения.
Если нет полуавтономных продуктовых групп, фиче-команд с быстрыми циклами обучения, практик борьбы с WIP и бережливого мышления, гибких HR-политик, AI не спасает. Он показывает, где система слаба.
А вы что думаете? | 426 |
| 5 | ⚡️ Когда хороший инструмент становится плохим
На прошлой неделе я проводил трёхдневный тренинг по LeSS (модели, основанной на взаимозаменяемых кросс-функциональных командах). Среди участников была ребята, которые недавно стали работать по SAFe.
По ходу тренинга мы определили стратегический фокус компании. Стратегия — продуктовое лидерство.
Если вы строите продуктовое лидерство, вам нужны высокая адаптивность и минимальный Time-to-Market. А большие очереди, высокий Work in Progress и специализированные команды неизбежно снижают скорость изменений. SAFe в данном случае не лучший выбор. При этом для компаний с другим стратегическим фокусом — например, операционным лидерством или клиентоцентричностью — он вполне может быть подходящим решением.
Организационный дизайн нельзя выбирать в отрыве от стратегии. Сначала нужно понять, какую стратегию реализует компания. Затем определить, какие организационные способности необходимо развить. И только после этого выбирать организационный дизайн.
Эта идея лежит в основе книги «Дизайн Agile-организаций».
Почему LeSS и SAFe по-разному влияют на адаптивность, я разбирал здесь.
С чего начинаете вы? | 435 |
| 6 | ⚡️ Команды нельзя нанять — только спроектировать
В 90-х провели знаменитый эксперимент с курицами. В одном курятнике оставили обычных несушек. В другом собрали только самых продуктивных. Через несколько поколений обычный курятник процветал, а в "команде суперзвезд" большинство куриц погибло — самые сильные заклевали остальных.
Эта история хорошо показывает, что недостаточно собрать лучших людей. Метаанализ 31 исследования с участием 1390 медицинских команд показал: команды с высоким уровнем сотрудничества почти в три раза чаще добиваются лучших результатов.
«Производительность системы зависит не от того, насколько хорошо работают ее части по отдельности, а от того, насколько хорошо они работают вместе». — Рассел Акофф
Команда не возникает сама собой. По определению Катценбаха и Смита, ее отличают общая цель, общий способ работы и взаимная ответственность за результат. Именно она заставляет людей помогать друг другу, делиться знаниями и вместе отвечать за успех.
Это и есть задача организационного дизайна — создать такие условия, в которых невозможно быть успешным отдельно от своей команды. Общая цель, прозрачность, быстрые циклы обратной связи и коллективная ответственность делают сотрудничество самым выгодным способом работы.
Сильные организации не строят вокруг суперзвезд. Они проектируют систему, в которой обычные люди становятся выдающимися командами.
Что мешает вашей команде стать настоящей командой? | 1 015 |
| 7 | ⚡️ Коллаборация важнее в эпоху AI
AI уже перестал быть узким местом в разработке. Код появляется быстрее, чем когда-либо. Но многие команды не стали выпускать ценность быстрее на рынок — они просто создают больше незавершенной работы (WIP).
Коллаборация становится важнее, чем была раньше. Если вы хотите, чтобы AI действительно ускорял команду, я бы обратил внимание на четыре практики.
1. Ограничьте WIP не только в разработке. Лимиты нужны и на PBR, и на уточнении требований, и на тестировании. Чем меньше неподтвержденных гипотез проходит дальше по потоку, тем меньше очередей возникает позже.
2. Не пускайте в спринт сырые задачи. Если гипотеза плохо проработана до начала работы, AI лишь быстрее превращает неопределенность в код. А исправлять это приходится всей команде.
3. Используйте swarming вместо массового параллелизма. Если каждый разработчик вместе со своим AI-агентом пилит собственную фичу, WIP стремительно раздувается. Swarming, парное и mob-программирование помогают команде быстрее завершать начатое.
4. Измеряйте скорость завершения, а не скорость старта. AI должен увеличивать скорость завершения работы, а не скорость ее начала. Именно это влияет на время поставки ценности, а не количество одновременно открытых задач.
Кажется, что AI снимает ограничения с разработки. На практике он просто переносит узкое место дальше по потоку. Поэтому управление WIP сегодня становится еще важнее, чем раньше.
А как вы ограничиваете WIP? | 459 |
| 8 | ⚡️ 10 рычагов изменения культуры
Иногда компании «меняют культуру», начиная с ценностей, плакатов и программ, вместо изменения системы работы. Но культура — повторяющееся поведение, закреплённое структурами, процессами, метриками и правилами.
Вот 10 рычагов, через которые на самом деле формируется и меняется культура:
1. Политики найма и критерии отбора.
2. Организационная структура и кто принимает решения.
3. Управление результативностью и KPI.
4. Вознаграждение и система стимулов.
5. Процессы принятия решений лидерами и командами.
6. Обучение и развитие руководителей и ключевых людей.
7. Процедуры работы с клиентами и партнёрами.
8. Пространство и неформальные связи.
9. Личное поведение лидеров и разбор конфликтов.
10. Внутренние коммуникации и истории.
Именно эта «середина» определяет, превратится ли стратегия в поведение или останется презентацией. Культуру невозможно навязать речами — её можно только собрать через последовательное выравнивание этих элементов с тем, как вы хотите, чтобы работала организация.
Какой рычаг сейчас самый критичный для вас? | 496 |
| 9 | ⚡️ Плейбук AI‑трансформации
Эндрю Ын — один из создателей Coursera и бывший руководитель Google Brain и Chief Scientist Baidu. На основе этого опыта он разработал плейбук AI‑трансформации, который я прикладываю в PDF.
Плейбук описывает пять шагов.
1. Запустить пилоты.
Стартовые AI‑проекты должны быть реализуемыми и достаточно заметными, с результатом в горизонте до года. Успешные пилоты создают внутренний спрос на новые AI‑инициативы.
2. Собрать AI‑команду.
Долгосрочное преимущество даёт централизованный внутренний AI‑юнит, который серийно запускает проекты и развивает платформу. Для этого всё чаще вводят роль CAIO или размещают команду под технологическими C‑level‑ролями.
3. Обучить ключевые роли.
Ын предлагает три уровня обучения: для топ‑менеджмента, лидеров направлений и инженерных ролей. Комбинация курируемых онлайн‑курсов и очных сессий по модели «перевёрнутого класса» помогает связать AI с практикой бизнеса.
4. Сформировать AI‑стратегию.
Стратегию формируют после первых шагов, когда понятно, где AI создаёт наибольшую ценность и опираясь на стратегический фокус.
5. Наладить коммуникации.
Нужны понятный тезис ценности AI, прозрачные планы и работа со страхами и ожиданиями разных стейкхолдеров. Сильный AI‑нарратив поддерживает доверие инвесторов, облегчает диалог с регуляторами, помогает привлекать талант и снижать внутреннее сопротивление.
Ключевая мысль плейбука
«Компания + нейросетки» сама по себе не делает бизнес AI‑компанией. Нужна пересборка процессов, ролей и структуры так, чтобы AI был встроен в повседневные решения и поток ценности, а не жил отдельным экспериментальным треком
Насколько ваш подход близок к этим пяти шагам? 🙂↔️ | 582 |
| 10 | AI-Transformation-Playbook.pdf | 480 |
| 11 | ⚡️ Management fads и гомеостаз организаций
У большинства «больших идей» в менеджменте — Six Sigma, бережливое мышление, Agile, Kanban — одна и та же траектория. Сначала хайп: сильные кейсы, обучение, сертификаты, вакансии, ощущение, что «теперь так будет у всех».
А потом включается более глубокая сила — гомеостаз организаций. Большинство компаний устроены так, чтобы не трогать существующую структуру власти, ролей и карьерных лестниц. Любая практика, которая действительно работает, требует менять оргдизайн, границы команд, ответственность, мотивацию — а это дорого, рискованно и политически больно.
Ровно об этом говорят законы Лармана: организации оптимизированы на сохранение статус‑кво, поэтому любое серьёзное изменение либо размывается до смены терминологии, либо объявляется «слишком теоретичным и непрактичным».
Крейг Ларман однажды сказал мне об этом очень просто: «Илья, всё это пройдёт. Были жёлтые трусы, будут зелёные трусы — и эти тоже пройдут». Волна за волной сменяют друг друга модные подходы, но поведение системы остаётся прежним.
На примере Agile это видно предельно ясно. Форма обновилась, а базовые управленческие принципы остались старыми — разрыв ожиданий и результатов накапливается, хайп схлопывается, и рынок движется к следующей «зелёной паре трусов».
А как вы переживаете эти волны? | 515 |
| 12 | ⚡️ Почему AI‑ассистенты не ускоряют поставку
Разработчики с AI‑ассистентами действительно пишут код быстрее, и DORA это подтверждает. Но время сквозной поставки и пропускная способность почти не меняются.
У многих команд эффективность потока 15–40%: из 60 дней пути идеи до релиза активная работа занимает около 12, остальные 48 — ожидание ревью, интеграции, окружений, зависимых команд и финального «да». В больших организациях это легко превращается в 8–12% эффективности, и ускорения касаются только тонкого слоя над массивом простоя.
Дон Рейнертсен формулирует просто: «В продуктовой разработке самые большие потери вызывают не инженеры, а работа, сидящая в очередях». Поэтому эффект от AI‑ассистов определяется не «скоростью кода», а качеством платформы, прозрачностью потоков и выравниванием команд.
Видели такое? | 612 |
| 13 | ⚡️ «Я плачу миллиард — а всё едет как черепаха»
Несколько лет назад ко мне пришёл собственник компании и говорит:
«Я каждый месяц плачу на R&D и айтишников почти миллиард, а продукт двигается как черепаха. Для меня это чёрный ящик.»
Первое, что мы сделали, — маппинг потока создания ценности: от идеи до выхода на рынок. Мы разложили этот поток на шаги и для каждого собрали три метрики: идеальное время работы (process time), реальное календарное время (cycle time) и процент возвратов назад по цепочке. Оказалось, что сами айтишники делают своё примерно за месяц и по метрикам выглядят нормально — это не была точка приложения усилий.
Главная дыра нашлась на этапе идеации и валидации гипотез: бизнес и R&D гоняли задачи туда‑сюда, решения пересматривались, согласования копились, и только здесь терялось до полугода календарного времени. Мы вообще не стали трогать айтишников, а перестроили взаимодействие бизнеса и R&D на этом участке — и общий срок поставки сократился в два раза за счёт изменения системы, а не за счёт героизма.
Если вас тоже бесит, что вы тратите огромные бюджеты, а скорость поставки не устраивает, напишите мне в личку в Telegram или в комментариях к этому посту. На бесплатной консультации мы разберёмся, где искать «узкие горлышки», наметим подход к диагностике потока создания ценности и посмотрим, чем я могу вам помочь в вашей ситуации.
Где у вас сейчас застревает поток? | 626 |
| 14 | ⚡️ Как рождаются инновации
Если положить рядом классические работы — все они приходят к одной мысли: инновация — это не вспышка гениальности, а организационная конструкция.
Регби вместо эстафеты
В 1986 году Такеучи и Нонака разобрали, как Honda, Canon, Fuji-Xerox и 3M делают продукты быстрее остальных (саммари статьи). Вместо эстафеты «маркетинг → R&D → производство» — кросс-функциональная команда, в которую с самого начала входят маркетинг, R&D, дизайн, производство и продажи. Амбициозная цель, автономия, мультиобучение и пересекающиеся фазы разработки.
Цитата топ-менеджера Honda:
«Это как поместить людей на второй этаж здания, убрать лестницу и попросить их найти способ спуститься. Креативность появляется тогда, когда вы ставите команду в экстремальные условия и даёте, казалось бы, невыполнимую цель».
Кросс-функциональность — это не IT-команда
Речь не про айтишную ячейку «аналитик + разработчик + тестировщик». В оригинальных исследованиях кросс-функциональная команда — это все ключевые организационные функции, нужные для выпуска продукта, собранные в одну группу без внешних зависимостей.
В Canon в команду нового копира входили: инженер-конструктор, технолог, маркетолог, планировщик производства, специалист по качеству, сотрудник поддержки, закупщик, логист, тестировщик и упаковщик.
Похожий рецепт встречается и в кризисных кейсах: собирают команду из 15 человек — разработчиков ПО, продуктовых менеджеров, людей из рисков, финансиста и юристов. Сажают в общую комнату, ставят амбициозную цель, убирают остальные задачи и оставляют в покое.
Это мини-компания внутри компании — инженерия, закупки, юристы, финансы в одной комнате. Без писем в соседнее подразделение и очередей на согласование.
Команды тяжеловесов
Уилрайт и Кларк в 1992 году дали этому имя — heavyweight teams: полный набор организационных функций внутри (инженеры, маркетинг, продажи, закупки, финансы, качество, поддержка), фултайм, сильный лидер, ответственность за продукт целиком. По данным Honda, HP и Canon — сроки на 30–50% короче, переделок меньше, конфликты между функциями почти исчезают.
Автономное подразделение
Кристенсен и Овердорф объясняют, почему даже компании с деньгами и сильными людьми буксуют. Старые процессы и ценности отлично справляются с поддерживающими инновациями и отторгают прорывные. Лекарство — команда тяжеловесов внутри, отдельное автономное подразделение или покупка компании, которую не интегрируют.
Что общего
Рецепт прорывной инновации стабилен последние 40 лет: берём команду со всеми ключевыми функциями внутри — инженерия, маркетинг, продажи, дизайн, производство, финансы, юристы, закупки. Ставим амбициозную цель, освобождаем от других задач и от логики максимальной утилизации, защищаем от старых процессов и ценностей основного бизнеса.
Главный сдвиг — перестать измерять, насколько все заняты, и начать измерять, с какой скоростью идея превращается в ценность для клиента.
А у вас как с инновациями? | 561 |
| 15 | ⚡️ Capability‑heatmap для инвестиционных решений
Capability‑heatmap помогает увидеть, какие способности бизнеса критично усиливать именно сейчас и какой след это оставит на всей организации: на скорости инноваций, операционных расходах, масштабируемости. Вместо того чтобы спорить о каждом проекте по отдельности, руководство принимает решения, исходя из тепловой карты: где несколько стратегически важных способностей одновременно слабо работают и негибки, значит, туда потребуется заметно больше инвестиций, а где capability уже стабильно достигает нужных целей, туда вкладываться дальше не имеет смысла.
Полезно пройти простой цикл: сначала описать текущие ключевые способности, затем оценить их ценность, качество исполнения и риск, после чего определить будущие capabilities, которые понадобятся стратегии — например, управление продуктами на базе AI, быстрая экспериментальная разработка, встроенная персонализация решений. Сопоставляя на одной карте текущие и будущие способности, топ‑команда получает конкретный план инвестиций: какие capabilities создавать с нуля, какие догонять, а какие оставить как есть.
Мини‑чек‑лист для вас:
- Опишите ключевые бизнес‑способности (capabilities).
- Оцените их ценность, исполнение и риск.
- Определите будущие способности (включая AI‑related).
- Наложите на карту текущие инвестиции и скорректируйте приоритеты.
Детальнее карты способностей мы разбираем на тренинге Designing Agile Organizations: scrum.ru/cod.
А как вы определяете куда инвестировать? | 552 |
| 16 | ⚡️ Две логики AI
Сейчас бизнес выбирает две принципиально разные траектории. Oracle, Meta и многие другие сокращают десятки тысяч людей, чтобы вложиться в AI. Логика: технология должна заменить человека.
Есть другой подход. IKEA запустила AI-чатбота, который забрал на себя 47% всех обращений. Затем они посмотрели на оставшиеся 53%. А там — не про «где мой заказ».
Людям нужна помощь с домом. Советы по пространству. Идеи, как сделать лучше. И IKEA не сократила людей. Они переучили их в консультантов по интерьеру. Те же сотрудники. Другая ценность.
Результат — €1,3 млрд дополнительной выручки за год.
Одни спрашивают: как сэкономить с помощью AI? Другие — что теперь могут делать люди, когда AI забрал рутину? Один рынок. Два выбора. Два результата.
AI не принимает решения за вас. Это управленческий выбор.
А вы куда идете? | 776 |
| 17 | ⚡️16 архетипов команд для диагностики
При диагностике юнитов использую карту архетипов команд, основанную на FTAM (Feature Team Adoption Map). По горизонтали — полнота навыков, по вертикали — широта области работы: от задач до всего продукта.
Важно: ни один архетип сам по себе не “плохой”. Вопрос только в том, насколько он согласован с вашей стратегией и текущими задачами.
Часто всплывают 7 архетипов:
Y1 — функциональная команда с фокусом на задачах. Работа ведётся на уровне задач, продуктовый контекст снаружи.
Y2 — неполные команды с фокусом на задачах. Узкие специализации и заметные зависимости при работе с задачами.
A2 — неполные команды с фокусом на фичах. Команды группируются вокруг фич, но часть зависимостей остаётся.
A3 — e2e‑команда с фокусом на фичи. Узкоспециализированные кросс-функциональные команды.
B2 — неполные команды с фокусом на область продукта. Зависимости остаются.
B3 — взаимозаменяемые кросс-функциональные команды с фокусом на области продукта.
C3 — взаимозаменяемые Agile-команды с фокусом на целый продукт. Отсутствие внутренних заборов по потоку ценности.
Эта карта — способ обсудить, насколько текущие архетипы команд соответствуют стратегии юнита и в какую сторону движение даст больше эффекта: вправо (к большей полноте навыков), вверх (к более широкому продуктово‑клиентскому фокусу) или по обеим осям сразу.
Где на матрице ваши команды? | 612 |
| 18 | ⚡️ Ловушка: почему AI не даёт +25% EBITDA
Генеративный AI уже в повестке советов директоров, но у большинства компаний он дает ограниченный эффект в P&L.
Типичный сценарий: AI ставят как еще один SaaS, запускают пилоты и ассистенты, подкрашивают существующий продукт и автоматизируют старые процессы как есть. В результате растет скорость отдельных людей и подразделений, но не производительность компании. Это и есть описанная в HBR «micro‑productivity trap».
У тех, у кого AI работает, оптика другая: не «как улучшить задачу», а «как переизобрести бизнес в мире, где люди + агенты — новая производственная функция». Они сначала решают, где будет лежать ценность и в чем хотят выигрывать (стратегический фокус), а потом перерисовывают 3–5 ключевых потоков ценности с AI в центре.
В кейсах Bain и Lowe’s такой подход дал +10–25% к EBITDA и более чем двукратный рост конверсии там, где клиенты реально взаимодействуют с AI‑ассистентом.
Ключевой организационный вывод: пока AI остаётся «темой для IT/цифрового подразделения», компания остается в ловушке микро‑продуктивности. Как только AI‑трансформация становится предметом владения борда и CEO, с бизнес‑целями и пересборкой value chain, появляются шансы на +10–25% к EBITDA.
А как у вас — локальные оптимизации или пересборка ключевых потоков ценности? | 708 |
| 19 | ⚡️ Agile‑хайп как management fad: почему волна схлопнулась
Лет 5–8 назад казалось, что Agile навсегда стал нормой: вакансии, сертификаты, тренинги, «Scrum‑команды» в каждой компании. Сейчас хайп схлынул, и на рынке больше скепсиса, чем энтузиазма. Я попробовал разложить эту историю на системную диаграмму: на ней видно, как рынок сначала сам разгоняет спрос за счёт консультантов, обучения, вакансий и историй успеха, а затем так же сам себя охлаждает.
Проблема началась там, где от слов нужно было переходить к изменениям конструкции. Чтобы Agile работал, нужен пересмотр оргдизайна: самоорганизующиеся кросс-функциональные команды, другие принципы принятия решений, мотивации и роли менеджеров. Для большинства организаций это слишком больно, поэтому включаются балансирующие петли: давление сохранить статус‑кво, снижение стандарта изменений, попытка сделать подход совместимым с существующей моделью организации.
Так появляются Copy‑Paste Scrum, «Spotify‑модель по слайдам McKinsey» и SAFe как максимально совместимая с иерархией упаковка Agile‑лексики. Формально всё «по Agile»: роли, ритуалы, артефакты. Фактически — те же управленческие практики, только в новой обёртке. На диаграмме это отдельная петля поверхностных внедрений: растущая их доля увеличивает разрыв между ожиданиями и результатами, разочарование накапливается, доверие падает, и волна хайпа — как у любой management fad — неизбежно схлопывается.
Параллельно всё это время существует другая, тихая петля глубоких изменений оргдизайна. В СБП, Райффайзенбанке и ряде других организаций, разговор шёл о том, как перестроить структуру и управление так, чтобы Scrum вообще имел смысл. Всегда сознательно выступал против копипейста и косметических трансформаций — и сегодня рад, что на стороне тех, кто работает с системой, а не с её вывесками.
А вы какую петлю поддерживаете — поверхностных внедрений или глубоких изменений? | 2 |
| 20 | Организационные способности.pdf | 578 |
