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

⚡️ Давайте знакомиться Привет, я Илья Павличенко. Канал вырос, новых людей много — расскажу, кто я и чем занимаюсь. Я эксперт по организационному дизайну и 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-бизнес оказался задачей организационного дизайна. Нужно спроектировать память, полномочия, границы, механизмы контроля и взаимодействие между исполнителями. Что в этом кейс самое интересное / крутое для вас?

⚡️ Системное мышление подорожало Прямо сейчас у меня параллельно идут четыре потока по системному мышлению — около сорока человек одновременно. И результаты, которые они показывают, впечатляют: люди решают кейсы, вокруг которых ходили кругами не первый месяц, и наконец видят, за какую ниточку тянуть. Откуда такой спрос — мне понятно. Узкие специализированные навыки дешевеют на глазах, их всё увереннее забирает AI. И на этом фоне дорожает то, что лежит в основании: философия, бережливое мышление, теория очередей, системное мышление. Видеть систему целиком и решить, куда бить, — работа человека. Элизабет Стоун, директор по продукту и технологиям Netflix, рассказывала об этом у Ленни Рачицкого: при найме она теперь смотрит в первую очередь на системных мыслителей, а глубокая узкая экспертиза отходит на второй план. Логика простая — экспертиза устаревает вместе с инструментом, а понимание взаимосвязей переносится в любой домен. Заодно я выложил в открытый доступ свой скилл для Claude. Он собирает историю, вытаскивает переменные, определяет архетип, строит диаграмму циклов (CLD) и ищет точки приложения усилий. Внутри 11 системных архетипов, 12 рычагов Медоуз, разбор по айсбергу и девять эталонных кейсов. Системное мышление становится мощной практикой для лидеров, и для этого есть программа Professional Systems Thinker. Следующий поток собирается на 3 ноября: восемь модулей, от основ до сложных многоконтурных историй. К середине вы берёте свою настоящую хроническую проблему из организации и ведете ее через всю программу как сквозной кейс — с разбором каждую неделю, пока не появится работающее решение. Группы я держу небольшими и стартую от восьми человек: наберётся раньше — начнём раньше, так что заглянуть на страницу лучше сейчас. В какой системе вам нужно детально разобраться?

⚡️ Взрослые люди сами себя оценивают Иногда сталкиваюсь с инфантильными командами. Люди не дают друг другу честную обратную связь, не говорят, что коллега не тянет, не решают, кого нанять или с кем расстаться. Все несут менеджеру. Потом менеджер говорит: «Люди не готовы к самоорганизации». Но дело не в людях. Просто есть система, в которой взрослые ведут себя как дети. Если только менеджер нанимает, увольняет, оценивает и распределяет деньги, другого поведения ждать странно. В Haier, компании примерно с 80 000 сотрудников, система другая. Раз в месяц сотрудники получают прозрачную performance-оценку. Все видят, кто сколько получил и за что. Три звезды — нормальный результат. Четыре-пять — выше награда. Две и ниже — ниже доход, меньше шансов на новые контракты, talent pool, в пределе — выход из компании. Это как рейтинг в Airbnb или Uber. Работа превращается в репутацию, а репутация влияет на деньги и возможности. Оценка не просто социальная, она тотально прозрачная. Она полезна именно потому, что ее видят все. Армин Трост описывает тот же принцип через P2P-оценивание, peer recognition и выборные комиссии по зарплатам. Практики разные, принцип один: право оценивать должно принадлежать не боссу, а социальному окружению, а результат оценки должен быть виден всей системе. Поэтому в моей методологии DAO, версия 2 появился новый гайдлайн — «Социальная оценка вклада». Хотите взрослых людей — проектируйте взрослую систему. Как вам такое?

⚡️ Максимизируйте зависимости между командами Звучит почти как вредный совет. Мы привыкли считать зависимости проблемой и проектировать команды так, чтобы они как можно меньше зависели друг от друга. Бас Водди, со-создатель LeSS, собрал хороший список практик командной работы. Для контекста: LeSS — это мультикомандный Scrum, когда несколько команд вместе разрабатывают один продукт. И здесь важна оговорка. Все эти советы имеют смысл, если вам нужны высокая адаптивность и скорость. Если это не ваша цель, часть практик действительно может оказаться плохим советом. Что стоит избегать внутри команды: - каждый работает над своей задачей; - работа идет по цепочке UX → разработка → тестирование; - каждый держится только за свою специализацию; - большие фичи растягиваются на много спринтов; - команда блокируется зависимостями и берет следующую работу. Что пробовать внутри команды: - детальная вторая часть Sprint Planning и мелкие задачи; - несколько Daily Scrum за день; - несколько пар работают над одной задачей; - вся команда работает над кодом вместе (моб-программирование); - вся команда сосредотачивается на одной задаче (сворминг); - пожертвовать одним человеком: он берет на себя внешние прерывания, пока остальные работают вместе. И самое интересное — практики между командами: - никакой предварительной раздачи задач командам; - максимизировать зависимости: связанные задачи специально брать разным командам; - временно объединять две команды на спринт; - проводить общую вторую часть Sprint Planning; - подключаться ко второй части Sprint Planning другой команды; - временно переходить в другую команду (путешественник); - выделять ведущую команду для большой инициативы (Leading Team). Мне особенно нравится идея максимизации зависимостей. Если постоянно защищать команды от совместной работы, знания и контекст тоже останутся внутри отдельных команд. А здесь зависимость сознательно используют как повод работать и учиться вместе. Какие практики попробовали бы?

⚡️ Как делить фичи между value areas Продолжаю допиливать свое программное обеспечение для проектирования организаций, которое собрал с помощью вайбкодинга. Недавно добавил туда области ценности — value areas — прямо в тепловую карту (heatmap). Для больших продуктов это особенно важно. Когда команд много, специализация почти неизбежна. Но специализироваться можно вокруг разных областей ценности: сегментов клиентов, шагов процесса, инноваций. И то, как вы определяете эти области, во многом зависит от выбранного стратегического фокуса. Теперь в инструменте для каждой value area отдельно пересчитываются тепловая карта, 80% самых частотных компонентов и аналитика автономности. Но дальше возникает практический вопрос: что делать с фичей, которая попадает сразу в несколько value areas? Предлагаю такую логику: - если фича подходит нескольким value areas — смотрим на саму фичу и решаем, какая область лучше ее покрывает; - если необходимые компоненты есть только у команд одной области — команды этой области берут фичу; - если нужны возможности команд из нескольких областей — команды координируются; - такое взаимодействие можно использовать, чтобы команды осваивали недостающие компоненты; - если похожие фичи повторяются, это сигнал постепенно расширять покрытие команд. Мне нравится этот принцип: границы value areas задают специализацию, но не превращают продукт в жестко нарезанные куски. Как делите спорные фичи?

⚡️ Семь принципов оргдизайна Сейчас готовлю вторую версию методологии Designing Adaptive Organizations (DAO) и заодно попробовал сформулировать принципы, на которые в действительности опираюсь, когда помогаю проектировать организации. Получилось семь. 1. Проектировать из стратегии, а не копировать чужие модели. Выводить организационный дизайн из собственной стратегии, необходимых способностей и контекста, даже если популярные фреймворки и консультанты предлагают другое решение. 2. Оптимизировать целое, а не части. Максимизировать результат всей системы, даже если локально это ухудшает показатели отдельных команд, функций или подразделений. 3. Оптимизировать поток, а не ресурсы. Минимизировать lead time и время ожидания, даже если специалисты в итоге загружены меньше. 4. Устранять очереди, а не управлять ими. Искать и устранять причины их появления. Kanban, уменьшение рабочих пакетов и управление потоком полезны, но сами по себе источник очереди не убирают. 5. Устранять зависимости, а не управлять ими. Менять границы и формировать e2e-юниты, даже если ради этого приходится дублировать компетенции и терять часть экономии от масштаба. 6. Балансировать автономию и экономию от масштаба. Давать e2e-юнитам достаточно автономии для быстрого потока. Общими оставлять те способности, где выигрыш от масштаба перевешивает стоимость возникающих зависимостей. 7. Создавать дизайн со всей системой, а не узкой группой. Вовлекать в проектирование микрокосм организации — представителей всех ее частей и уровней, которых затронут изменения. Это не попытка сформулировать универсальные законы оргдизайна. Скорее моя ретроспектива: какие принципы снова и снова определяют мои решения на практике и сейчас лежат в основе второй версии DAO. Какой принцип вам ближе?

⚡️ AI ускоряет людей. Компанию — нет В свежем исследовании McKinsey есть интересное противоречие. 80% респондентов говорят, что AI повысил их личную продуктивность. Но только 37% видят вклад AI в EBIT компании — и эта доля почти не изменилась за год. Для системного мышления здесь нет ничего удивительного. Рассел Эйкофф формулировал эту мысль примерно так:

«Эффективность системы определяется взаимодействием ее частей, а не эффективностью каждой части по отдельности».

AI сегодня отлично ускоряет отдельные части организации: разработку, аналитику, маркетинг, работу менеджеров. Но это классическая локальная оптимизация. Если работа потом ждет другую команду, согласование или решение руководителя, выигрыш растворяется в очередях. Более того, ускорение отдельных частей может ухудшить эффективность целого. Одна функция начинает производить работу быстрее, следующие этапы не успевают ее принимать, растут очереди, незавершенная работа и координационная нагрузка. И данные McKinsey хорошо это показывают: почти три четверти AI high performers фундаментально перепроектируют workflows, тогда как среди остальных организаций это делает примерно четверть. Отсюда мой prediction: маленькие компании и предприниматели могут получить от AI непропорционально большой выигрыш. Им проще менять весь поток работы. Большим организациям придется перепроектировать процессы, границы команд и структуры власти. А на такие изменения они идут гораздо тяжелее. Как вам такой вывод? DAO — обучение оргдизайну | DAO Практикум — проектирование своей организации

⚡️ RenDanHeYi: каждый становится предпринимателем С удовольствием прочитал Start-up Factory — книгу Joost Minnaar и Pim de Morree о модели RenDanHeYi в Haier. Это одна из самых радикальных моделей организации работы. Идея RenDanHeYi — заменить значительную часть иерархии сетью предпринимательских единиц, связанных рынком, контрактами и экономическими результатами. Вместо привычных функций и департаментов — тысячи microenterprises со своим P&L и широкими правами на решения. Одни работают напрямую с внешним клиентом, другие продают им внутренние сервисы. Отношения между ними строятся через контракты. Особенно интересно это работает с shared services. В обычной компании HR, Finance, IT, закупки — монополисты. Нужен сервис — выбора нет. В Haier microenterprise может расторгнуть контракт с внутренним поставщиком, выбрать другого или купить услугу на внешнем рынке. Если внутреннюю функцию нельзя заменить, это монополия. Внутренний рынок касается и денег конкретного человека. Есть базовый доход, своего рода safety net, а существенная часть заработка зависит от того, какую ценность создала microenterprise. Достигли результата — появляется дополнительный пул. Создали больше ценности — пул растет. Дополнительный profit команда распределяет внутри себя. Поэтому принцип Haier «каждый становится предпринимателем» — не метафора. Система напрямую связывает каждого участника microenterprise с клиентом и экономическим результатом: получил ли клиент ценность, выполнен ли контракт, заработала ли microenterprise. И здесь интересна связь с проблемой вовлеченности, engagement. Обычно компании пытаются лечить ее опросами, программами вовлеченности и работой менеджеров. Haier меняет экономическую систему, чтобы у человека была прямая связь между клиентом, результатом и собственным выигрышем. Что интересно, сама идея не новая. Еще Russell Ackoff в Re-Creating the Corporation описывал мультиразмерную организацию и внутреннюю рыночную экономику: клиентские, продуктовые и сервисные единицы взаимодействуют как покупатели и поставщики, а внутренние функции лишаются гарантированной монополии. Haier довел эту логику до радикальной практики: контракты вместо распоряжений, рынок вместо внутренних монополий, profit sharing вместо фиксированной зарплаты, предприниматели вместо сотрудников. А вы смогли бы работать в такой системе? Что в ней кажется сильным, а что опасным?

⚡️ Как раскрыть потенциал организации и ускориться в 2-3 раза Последние 15 лет я помогаю организациям ускоряться — от стартапов до больших банков и телекомов. По мере роста часто происходит одно и то же: людей и ресурсов больше, а работа движется медленнее. Растут очереди и согласования, зависимости, конфликты целей и Time-to-Market. Мой опыт подтверждает: у любой организации есть потенциал ускориться в 2–3 раза. Самое сложное — найти, где именно спрятан этот потенциал. Поэтому я записал серию видео о том, как находить эти ограничения. Переходите по ссылке. А вы догадываетесь, где спрятан потенциал вашей организации?

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

⚡️ 30 паттернов вместо 16 У меня давно была библиотека из 16 паттернов промптинга. Из них можно собирать хорошие промпты и инструкции для AI-ассистентов и агентов. Я решил ее серьезно обновить и довольно сильно заморочился с The Prompt Report — большим научным обзором, где авторы собрали 58 техник промптинга для текстовых LLM. Если хочется заморочиться еще сильнее, можно открыть исследование и читать его целиком. Тащить все 58 к себе я не стал. Прошелся по всему списку, посмотрел на пересечения и практическую полезность и в итоге расширил библиотеку с 16 до 30 паттернов. Один из моих любимых — Дерево рассуждений (Tree of Thoughts). AI разворачивает несколько веток решения, сравнивает их, отбрасывает слабые и при необходимости может вернуться к тому, что раньше отбросил. Например:

«Предложи три возможных направления решения. Для каждого оцени плюсы, риски и последствия. Отбрось слабые ветки и развивай наиболее перспективную, при необходимости вернись к альтернативе»

. Мне эта штука нравится тем, что одной инструкцией можно довольно сильно поменять способ работы AI с задачей. Вместо первого попавшегося ответа он начинает исследовать несколько вариантов и сравнивать их между собой. Для каждого паттерна в файле есть короткое объяснение и несколько готовых примеров. В конце я оставил большой промпт для подготовки ретроспективы, где разные паттерны уже собраны вместе в одного AI-ассистента. Получилась версия 2.1. PDF прикладываю к посту. Как планируете это использовать?

⚡️ Vibe Coding и Vibe Montage Последние месяцы довольно много приходится заниматься видео: встречи закрытого клуба, модульные программы, тренинги. Обычно я делаю записи, а потом отправляю их участникам в Telegram. И монтаж каждый раз превращался в отдельную боль. У меня два оператора, плюс иногда московская студия. Файлы передаются, что-то ломается, появляются битые записи, начинается выяснение, на чьей стороне проблема. Один ролик завис почти на две недели. А еще каждый монтаж стоил мне 2–6 тысяч рублей. В какой-то момент меня это просто задолбало, и я решил попробовать Codex в ChatGPT. Показал ему несколько уже смонтированных роликов в моем стиле, создал проект, поставил плагин Remotion и начал собирать видео сам. И получилось. Сейчас у меня уже есть настройки и пресеты. Обычно хватает двух-трех проходов: первая версия, несколько правок, еще один прогон. То, что раньше занимало несколько дней, теперь занимает 15–20 минут. Я называю это Vibe Montage. Еще недавно я платил за каждый монтаж и ждал несколько дней. Теперь делаю его сам за 15 минут на ChatGPT. Времена, конечно, шикарные. Расскажите, как вы экономите время и деньги с помощью AI.

⚡️ Кейс: 58% автономности, 0% поставки Один мой коллега проджект-менеджер столкнулся с типичной проблемой. Четыре ключевых архитектурных компонента находились за пределами его команды. Из-за этого постоянно возникали зависимости и лишние согласования. Он и раньше понимал эту проблему. Но она была размазана по десяткам ситуаций: тут ждем одну команду, там нужен чужой компонент, здесь снова зависимость. Все это было известно, но общей картины не было. Он собрал с командой HeatMap в моем программном обеспечении для диагностики организации. И тут случился хороший aha-момент. Оказалось, что команда самостоятельно выполняет 58% работы. Вроде немало. Но из 11 элементов беклога самостоятельно доводит до конца 0. То есть команда много чего могла делать сама, но закончить самостоятельно хотя бы один элемент не могла вообще. Карта показала и причину: почти каждый элемент в какой-то момент упирался во внешний компонент или организационную функцию. И вот тут разговор про оргструктуру резко стал предметным.

«Мы за 2 недели на изи поменяли структуру департамента и втянули 3 компонента внутрь юнита, максимально легко и без сопротивления команд или менеджмента».

По словам участника, менеджмент понял ситуацию с первого раза, и end-to-end команда появилась за один спринт. Особенно зашел автоматический вывод по матрице: «юнит может начать работу, но не может закончить». Очень простая фраза, но она сразу отрезвляет. Мне нравятся такие инструменты потому, что они делают видимым то, что до этого существовало только кусками в головах людей. HeatMap — один из модулей моего ПО для диагностики и проектирования организаций. Там есть и другие модули, матрицы и способы посмотреть на организацию с разных сторон. Мы используем этот инструментарий в двух программах — DAO «Дизайн адаптивных организаций» (ссылка) и DAO Практикум «Проектирование вашей организации» (ссылка). На Практикуме участники работают со своей реальной организацией: собирают данные, визуализируют устройство системы и проектируют изменения. Бывало: работаем много, закончить не можем?

⚡️ Рабочий поток — единица автоматизации в Uber В Uber единицей проектирования становится рабочий поток. Для этого Uber собирает Agentic Pods: AI-инженер работает вместе с экспертом из финансов, операций, маркетинга, поддержки или другой функции. Первые дни инженер наблюдает, как работа происходит на самом деле: где люди копируют данные руками, обходят ограничения систем, ждут согласований, переключаются между инструментами. И тут у меня сильное дежавю из Extreme Programming. В первой версии XP одной из практик был On-Site Customer: разработчик и человек, для которого создаётся система, должны работать рядом. Короткая дистанция между технической компетенцией и знанием реальной работы была встроена прямо в дизайн метода. Agentic Pods выглядят как современная версия этой идеи. Только теперь рядом с экспертом сидит AI-инженер и вместе с ним перепроектирует уже не отдельные шаги, а весь поток работы. После этого они вместе перестраивают поток вокруг AI-агента и за десять дней доводят решение до рабочего состояния. Результаты выглядят впечатляюще. Распределение капитала для 150 городов сократилось с 15 часов до 30 минут. Финансовая отчётность — с двух дней до 10 минут. Проверка маркетинговых страниц — с двух недель до 50 минут. Но интереснее сам механизм. Если автоматизировать одну операцию внутри старого процесса, остальные ограничения остаются на месте. Передачи работы, согласования, старые системы и ручные проверки продолжат определять скорость всей системы. AI это повод заново спроектировать поток работы. Самые сильные возможности для AI трудно увидеть на процессной схеме. Они становятся заметны рядом с человеком, который делает эту работу каждый день. Оригинальный пост: https://x.com/VaibhavSisinty/status/2075199615801159974 Разбор кейса: https://www.iqsource.ai/en/blog/uber-agentic-pods-10-day-playbook/ Что теперь считать единицей автоматизации?

⚡️ Kimi K3 — еле успеваю пробовать новинки AI-инструменты сейчас меняются с такой скоростью, что еле успеваю их пробовать. Вроде слежу за новинками и что-то тестирую, но новых моделей становится всё больше. Вчера впервые нормально зашёл в Kimi K3. Авторизовался через Google и сразу собрал рабочий вариант сайта в бесплатной версии. Результат получился лучше, чем на похожих задачах у меня получалось с ChatGPT и Claude: интерфейс аккуратнее, часть деталей Kimi K3 поняла с первого раза, и правок потребовалось меньше. Потом посмотрел независимые тесты. В Code Arena Kimi K3 Max сейчас занимает второе место по созданию сайтов и интерфейсов, выше Claude Fable 5 и GPT-5.6 Sol. В AA-Briefcase, где моделям дают большие задачи с документами, таблицами, презентациями и исходными материалами, Kimi K3 тоже заняла второе место и особенно хорошо показала себя в анализе информации и качестве результата. В целом Kimi K3 сейчас сильна в создании сайтов и интерфейсов, работе с большими объёмами информации и длинных задачах, где AI сам разбивает работу на шаги и использует инструменты. Сразу же оформил подписку на месяц. Хочу погонять Kimi K3 на реальных задачах и посмотреть, насколько первое впечатление подтвердится. Буду рассказывать о результатах. Как у вас новинками?

⚡️ Системное мышление: кейс решения организационной проблемы. Хороший кейс решения организационной проблемы от Вячеслава Сидячкина. В его компании быстро рос поток обращений в поддержку. Поддержка не справлялась, разработка не успевала подключаться к сложным случаям, а обсуждение постепенно свелось к взаимным претензиям. Вячеслав поговорил с представителями нескольких команд, собрал паттерны и построил causal loop diagram — CLD. Диаграмма показала, что рост организации увеличивал количество клиентских сценариев и обращений, нагрузка росла, ответы замедлялись, возникало больше эскалаций. После этого Вячеслав показал CLD участникам и вовлек людей в обсуждение. Стало видно: все элементы связаны, поэтому искать виноватого бессмысленно. Нужно менять систему. Одним из результатов стало решение усилить логирование и диагностику, чтобы быстрее получать контекст по сложным обращениям. Здесь интересен алгоритм работы агента изменений: - Идите на gemba. Поговорите с людьми из разных частей системы. - Ищите паттерны. Повторяющиеся события и причинно-следственные цепочки. - Визуализируйте систему. Постройте CLD. - Верните картину людям. Покажите диаграмму, подкрепляя связи конкретными наблюдениями. - Исследуйте систему вместе. Вовлеките людей в обсуждение того, какие связи стоит изменить. CLD здесь — способ создать общее понимание системы и запустить изменения. Весь experience report: 👉 https://scrum.ru/tpost/bsn82pbtu1-ot-poiska-vinovatih-k-izmeneniyu-sistemi Какие фишки вы используете для запуска изменений?