Пять записей с саммита, с опозданием на три недели
Воркшоп, четыре живые сессии вопросов и ответов и нить, проявившаяся лишь во время наверстывания упущенного
Global Agile Summit завершился 6 мая. Эти пять записей я посмотрел через пару недель после того, как Oikosofy разместила их в видеобиблиотеке. Воркшоп по мобильному программированию от Вуди Зуйла, четыре последующие сессии вопросов и ответов в прямом эфире с Джейсоном Литтлом, Маркусом Буллоком, Клинтоном Китом и Джошуа Талером — примерно пять часов материала, втиснутых в неделю вечерних просмотров.
Задержка была непреднамеренной, но оказалась продуктивной. Просмотр сессий, состоявшихся с разницей в несколько дней, одна за другой, в тихую неделю, выявил нить, которую я не уловил бы в прямом эфире: каждый из этих спикеров, с разных точек зрения и разных направлений, раз за разом возвращался к одному и тому же операционному вопросу: как сохранить человеческий фактор, когда инструменты достаточно быстры, чтобы сделать человека ненужным?
Зуйл ответил игрой. Литтл построил структуру ТЭК. Буллок обнаружил это, когда четыре недели автоматизации прошли без единого разговора с клиентом, а Кит — когда подсчёт голов на парковке дал неверный результат. Талер принёс меч.
Вуди Зуйл — Mob Gaming с Вуди Зуйлом
Это был воркшоп, а не доклад (единственный в этой серии). Группа Зуйла играла в Baba Is You, головоломку, в которой правила мира представляют собой физические текстовые блоки, которые можно переставлять, применяя технику мобпрограммирования. Один человек управляет клавиатурой, другой — навигацией, задавая намерение, остальные наблюдают и ждут своей очереди.
Я смотрел запись через несколько недель после саммита. Меня поразило то, что сам процесс мастер-класса и был контентом. Головоломки — это средство; то, что вы видите, — это как люди учатся передавать высокоуровневое намерение, не давая пошаговых инструкций.
Первая фраза Зуйла: «Я здесь не для того, чтобы говорить вам, что делать. Я здесь просто для того, чтобы поделиться с вами тем, что я сделал». Он называет свои наставления пиратским кодексом — это скорее ориентиры, чем правила. Базовый принцип происходит от Левеллина Фалько: чтобы идея перешла из чьей-то головы в компьютер, она должна пройти через руки кого-то другого. На практике навигатор говорит «отключи утверждение „флаг — это стоп“, чтобы мы могли свободно двигаться», а не «нажми влево три раза, затем вниз». Зуйл выделяет три уровня инструкций: намерение, инструкции, локация. Навигатор нацелен на самый высокий уровень, на котором водитель может работать.
Момент, который я записал: навигатор застревает на головоломке. Зуйл даёт слово: у кого-нибудь есть идея? Участник поднимает руку и делится наблюдением: несколько камней можно сдвинуть одновременно, что могло бы нарушить одно из логических утверждений игры. Но предложение обращается к навигатору, а не к водителю. Навигатор решает, пробовать ли это. Зуйл явно формулирует социальный договор: помощники предлагают, навигатор выбирает, никто не берет на себя управление.
Это перекликается с тем, как я работаю с ИИ-агентами. Когда я направляю Claude Code на выполнение задачи, я остаюсь на уровне намерения («исправь детектирование флип-флопа в переводческом конвейере») и позволяю агенту самому определить подход. Когда он сбивается с курса, я корректирую. Когда я затрудняюсь с выбором направления, я прошу предложить альтернативы и делаю выбор. Протокол «водитель-навигатор», которому Зуйл обучает группу людей, почти идентичен паттерну взаимодействия, который я уже использую с группой агентов.
Во время рефлексии один участник сказал: «Я как будто перемудряю. Я думаю на пять шагов вперёд и порой не пробую». Другой заметил, что «есть желание сначала дать правильный ответ». Ответ Зуйла: каждый раз, когда тебе кажется, что что-то не сработает, это хороший момент для эксперимента. Неудачу можно отменить — клавиша Z сбрасывает всё, так же как и контроль версий.
Вот в чём мобильное программирование отличается от того, как работает большинство команд. В мобильном приложении попробовать неправильное решение обходится недорого, потому что все видят неудачу и учатся на ней вместе. Работая в одиночку, неудача остаётся незаметной, а обучение замыкается в одной голове. Я проводил джуниоров именно через этот переход — от страха пробовать к спокойствию в неудаче, потому что команда впитывает результат. Мобильное программирование ускорило бы этот процесс.
Зуйл завершил фразу, которую я снова и снова прокручиваю в голове: «Командная работа не заменяет работу в одиночку, а работа в одиночку не заменяет командную. Мы можем иметь и то, и другое». Затем он добавил, что если какая-то задача кажется такой, что должна выполняться в одиночку, потому что это простая рутинная работа, — возможно, именно пора её автоматизировать. Для человека, который разрабатывает оркестрацию агентов, чтобы она брала на себя повторяющуюся часть работы службы поддержки, это меня задело.
Краткое мнение об этом воркшопе я написал в посте на LinkedIn. Более развернутый формат здесь позволил мне углубиться в сам процесс — геймплей как средство обучения, траектория фасилитации от строгой к открытой, параллель «водитель-навигатор» с управлением ИИ, о которой Зуйл нигде не упоминает, но которую я проследил насквозь.
Джейсон Литтл — «Обучение ваших сотрудников-ИИ» (LIVE Q&A)
Подготовленный доклад Литтла (рассмотренный в сводном материале по Дню 2) представил фреймворк: относиться к ИИ-агентам как к сотрудникам — с онбордингом, обучающими данными и командными рабочими договоренностями. Эта сессия вопросов и ответов затронула операционную реальность повседневной работы такой системы.
Опорным тезисом было его правило 95%. Когда ИИ делает что-то неожиданное, в 95% или более случаев проблема в вашем промпте, инструкциях или контексте, а не в модели. Литтл представляет это как понимание того, что LLM — это механизмы сопоставления паттернов без какого-либо намерения. «Здесь нет мышления. За этим нет интеллекта». Как только ты это усвоишь, твои промпты меняются.
Что подтвердила сессия: я строю собственную оркестрацию так же, как Литтл строит свою экосистему Claude: единая точка входа, разветвленная на специализированные навыки, каждый из которых сведен к одной ответственности. Архитектура та же самая: папка с инструкциями, узконаправленные обучающие данные, цикл обратной связи, который периодически сверяет результат агента с тем, чего я на самом деле хотел.
То, что подтолкнуло меня дальше, — это антисикофантизм. Литтл описал навык «адвоката дьявола», который должен указывать на нелепость в его стратегических решениях. «ИИ покладист… его нужно подтолкнуть». Один из слушателей возразил: просто попросить о несогласии — это породить искусственное несогласие. Литтл согласился. Когда критика обоснована внешним ориентиром, а не просто призывом «будь жестким», она становится обоснованной, а не показной. Я уже использую подсказки с несколькими вариантами ответов в своей работе по расследованию тикетов именно потому, что единственный ответ от покладистой модели ненадежен. Но я не создал отдельного соревновательного агента для своего собственного стратегического мышления. Вот та конкретная вещь из этой сессии, которую я планирую попробовать.
Самый острый обмен мнениями произошёл между Литтлом и слушателем, который доказывал, что обусловленная ИИ неэффективность организационной разобщённости в крупных предприятиях фундаментально отличается от старой борьбы с аджайл-трансформацией: «скорость создания неэффективности и шума в 1000 раз выше». Литтл отстаивал свою позицию: паттерн изменений тот же, независимо от скорости. Культурная проблема в основе — мыслители проектируют процесс, исполнители принимают спущенный мандат — не изменилась за пятьдесят лет. Я поймал себя на том, что согласен с обоими. Паттерн тот же. Скорость усугубляет его.
Маркус Буллок — «Устойчивость, доверие и второй шанс» (LIVE Q&A)
Сессия Буллока отличалась от его подготовленного доклада больше, чем у других. Если доклад (рассмотренный в итоге за День 1) был посвящен созданию человекоцентричных технологий, то сессия пошла по его собственной траектории: тюрьма в 15 лет, основание Flikshop, создание Flikshop School of Business внутри тюрем и операционное напряжение между масштабированием с помощью ИИ и сохранением человеческого контакта.
Момент, который запомнился мне больше всего: Буллок описал, как создавал автоматизированные дашборды для партнеров с помощью Claude Code. Рабочий процесс был лаконичным: от первого взаимодействия с клиентом до персонализированной отчетности — полностью автоматизированным. Тогда он осознал, что прошло четыре недели без единого живого разговора с клиентом. «То, как мы развивали компанию, заключалось в том, чтобы делать вещи, которые не масштабируются… а затем выяснять, как построить системы вокруг того, что не масштабируется, так, чтобы это позволяло нам масштабироваться на фоне».
Это предложение — самая честная в операционном смысле вещь, которую я услышал за все пять сессий. Ты не начинаешь с масштабируемой версии. Ты делаешь ручную работу, выясняешь, что имеет значение, а затем автоматизируешь всё вокруг этого, сохраняя те человеческие элементы, которые с самого начала и заставили эту штуку работать.
Когда кто-то спросил о лидерском риске, Буллок ответил без промедления: лидер берёт на себя негативные последствия. Не как лозунг с плаката — как операционный принцип. «Вопрос на самом деле не в том, есть ли риск, а в том, кто берет на себя негативные последствия этих рисков?»
Я брал людей с минимальным опытом и за годы выращивал их до среднего уровня. Убеждение Буллока о вторых шансах, о том, что талант скрывается там, где большинство организаций уже решили не смотреть, резонирует с той работой. Механизм отличается. Операционное убеждение то же самое: среда формирует результат в большей степени, чем одни лишь природные способности, и большинство организаций недоинвестируют в среду.
Обсуждение доступа к ИИ в противовес результатам стало самым острым поворотом. Один участник сформулировал это как модель наркоторговца: бесплатные пробники сейчас, плата за зависимость потом. Буллок подтолкнул к чему-то более конкретному: «Доступ позиционируют как равный, но результаты быстро формируются у тех, кого по-настоящему вовлекли, кого поддержали и в кого вообще вложили средства». Доступ без поддержки — это не доступ. Эта формулировка применима и за пределами AI-инструментов.
Клинтон Кит — «Разработка игр, какой мы её знаем, подходит к концу» (LIVE Q&A)
Кит написал книгу «Agile Game Development with Scrum» и уже два десятилетия является ведущим экспертом по agile в игровой индустрии. Как человек, следящий за процессом разработки игр со стороны потребителя, я больше всего хотел услышать именно эту сессию.
История с метриками кранча запомнилась мне больше всего. Кит описал себя как «мастера принудительного кранча» — менеджера, который приказывал работать по выходным и считал себя хорошим лидером, потому что был рядом с командой. Затем он перешёл на скрам и начал измерять фактическую скорость доставки фич за спринт вместо подсчёта часов, проведённых в офисе.
Данные: на 50% больше времени в студии давало на 20–30% больше фич в первые несколько недель. Через три недели производительность резко упала. Через месяц команды поставляли меньше фич за спринт, чем до начала кранча. Он уже знал это интуитивно. Но метрика — прозрачная, видимая — изменила его поведение, потому что он уже не мог отвести взгляд. «Сделать влияние кранча видимым — это одна из вещей, которые может дать Agile. То, что ты с этим делаешь, к сожалению, не всегда означает принятие правильного решения».
Построить доверие с командами, чтобы те брали на себя обязательства самостоятельно, занимает месяцы. Разрушить это доверие возвращением к принудительному кранчу — достаточно одной ночи. Кит рассказал о командах, которые начали самостоятельно устраивать «кранч», как только стали ответственными за свои обязательства, и о том, как его роль изменилась с «приходи в эти выходные» на «держись подальше» — не из доброты, а потому что метрики показывали: больше часов даст меньший результат.
Последний вопрос задел Кита за живое: «Ты никогда не переживаешь, что аджайл на самом деле использовали как механизм приспособления, а не как лекарство?» Он рассказал, как заходил в крупную студию, обучал сотни разработчиков скраму, а потом получал пятнадцать минут с топ-менеджментом — который весь сидел в телефонах. «Должен существовать этот фундаментальный уровень хорошего лидерства, который просто необходим. Но были организации, в которые я заходил, где его не было».
Некоторые из этих усилий не изменили организацию. Но разработчики переносили полученные знания в свою следующую студию. Влияние накапливается через смену работы, а не внутри организации, которая оплатила обучение. Это наблюдение — одно из тех, которые я узнаю по опыту работы в другой сфере: долгосрочная отдача наставничества проступает в следующей роли человека более отчётливо, чем в его текущей.
Джошуа Талер — «Создание команд, которые ИИ не сможет заменить» (LIVE Q&A)
Сессия Талера была самой короткой — около двадцати семи минут — и наиболее сжато сведена к одному тезису: люди остаются необходимыми там, где экспертиза глубокая, контекстно-зависимая и обремененная регулированием.
Первым в его докладе прозвучал эпизод о фехтовании. Талер занимает руководящую должность в Society for Creative Anachronism, волонтерской организации, занимающейся средневековыми реконструкциями, и описал это как свой полигон для лидерской подготовки. Ключевой навык, который он назвал: «влияние без полномочий». Нельзя приказать волонтерам подчиняться. Ты задаешь направление достаточно чётко, чтобы следовать за ним было естественным выбором.
Именно эту формулировку я больше всего ассоциирую с тем типом лидерства, который мне по душе. Руководствуя командой поддержки в стартапе, я трачу больше времени на то, чтобы дать людям возможность решать проблемы, чем на решение проблем за них. Когда мне что-то нужно от другой команды, я привожу аргумент и жду. Талер пришёл к этому через фехтование. Я пришёл через годы работы в технической поддержке. Путь разный; операционный принцип — нет.
Что касается интеграции AI-инструментов, Талер предложил один архитектурный принцип: слабая привязка через слой API. Каждый AI-инструмент существенно изменится в течение двух-трёх лет. Создай промежуточное ПО; меняй инструмент под ним. Это совпадает с тем, что я сделал на своём новостном конвейере в этом году — полностью заменил источник поиска, а остальная часть системы этого даже не заметила.
Обсуждение GDPR подняло общеотраслевой вопрос: ИИ хочет доступа ко всему; регулирование защиты данных ограничивает, что можно обрабатывать и как. Позиция Талера: «Доверяй, но проверяй. Думаю, здесь немного меньше доверия». Ожидать, что какой-то ИИ-инструмент справится с обеспечением соответствия без человеческого аудита — это, как он выразился, подвергаться риску провала, из-за которого компании банкротятся.
Просматривая эти пять сессий за одну неделю, я выделил не дискуссию об ИИ: каждый трек конференции в 2026 году затрагивает ИИ. Я обратил внимание на то, насколько последовательно каждый спикер приходил к одному и тому же операционному вопросу, исходя из разных отправных точек.
Ответ Зуйла, социальный протокол: навигатор задает намерение, водитель выполняет, никто не берет руль в свои руки. Ответ Литтла, структура тек: агенты одного назначения, одна задача на нить, циклы обратной связи. Буллок обнаружил это случайно: четыре недели чистой автоматизации без единого разговора с клиентом показали ему, что человеческий контакт был продуктом, а не дашбордом. Ответ Кита, метрика: подсчёт машин на парковке говорил, что кранч работает; данные спринта говорили, что нет. Талер построил слой middleware и ожидал, что всё под ним будет заменено.
Вопрос, лежащий в основе всех пяти: когда исполнитель движется быстрее, чем директор успевает думать, что не даёт суждению директора исчезнуть в оптимизации?
Воркшоп Зуйла дал самую конкретную версию. Навигатору не нужно решать головоломку быстрее. Навигатору нужно передать то, что имеет значение, достаточно чётко, чтобы водитель мог это выполнить. Это разделение не исчезает, когда водитель — это AI-модель. Более того, оно приобретает ещё большее значение, потому что модель выполнит всё, что описано достаточно чётко, включая неправильное.
Я хочу когда-нибудь попробовать мобильный формат Baba Is You со своей командой. Не как регулярное мобильное программирование (моя команда для этого слишком мала и слишком разбросана), а как фасилитационное упражнение для того навыка, который имеет наибольшее значение, когда пошаговый исполнитель не обладает собственным суждением: задавать намерение и сдерживать порыв задать локацию.