2026-09-18 - AgileDays: tiny-teams и другие новости

Версия 18:13, 18 сентября 2026

Прошла очередная AgileDays. В этом году она была в однодневном формате на площадке Goelro, и погода очень благоприятствовала общению на улице, под открытым небом. Даже один из треков выступлений был на улице вокруг реального костра. Всего было четыре трека выступлений и два трека мастер-классов. И замечательная атмосфера, как всегда на AgileDays.

Про ИИ: tiny-team и другие особенности

Большое количество выступлений было посвящено ИИ, что вполне естественно. В них я зафиксировал очередное изменение, которое несет ИИ – переход к tiny-team, или two burger team вместо two pizza team – сокращение размера команды до 1-3 человек, при сохранении скоупа работ, который выполняет команда. В такую команду обычно входит Продукт, задача которого – новые идеи и бизнес-функционал, и Технарь, разработчик или тестировщик, который обеспечивает техническое качество того, что сделал ИИ. В такой команде накладные расходы на коммуникацию сведены к минимуму. Идеалом с этой точки зрения является solo-team, команда из одного человека, но от него требуется слишком широкий кругозор, сочетание бизнесовых и технических компетенций, это встречается редко. А вот команда из пары человек вполне справляется без особого расширения компетенций.

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

Правда, маленькая команда несет риски: bus factor становится единицей, этот риск надо компенсировать. Можно укрупнять область ответственности команды, чтобы было несколько специалистов. Кстати для больших продуктов аналогичные изменения приводят к тому, что большая команда в 12-15 человек или даже 2-3 команды команды превращаются в одну маленькую. При этом внутри все равно можно делить ответственность за код, как рекомендовал метод Feature Driven Development (FDD) Джеффа де Люка, по которому я много лет назад проходил мастер-класс у автора. Он, правда, был не очень распространен, так как предполагал разделение ответственности за код, а не общее владение, о котором говорил mainstream agile-методов.

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

Люди удивляются, что ускорение разработки не дает бизнес-эффекта. Но это проявление давно известной проблемы. В Kanban есть такая метрика, как дол касаний: число дней, когда задачей как-то занимались по отношению к общему числу дней, пока ее выполняли. Она хорошо кластеризует массив задач, часть задач пролетают быстро с высоким показателем, а другие – долго ждут, там доля касаний составляет 10-15%. То есть из 60 дней, пока задачу выполняли, что-то по ней делали только 6 дней, а остальное время задача чего-то ;olfkf – то внешних согласований, то исполнителя, занятого другим. При этом анализ показывает, что такое значение имеют наиболее сложные задачи, которые при этом важны для завершения какого-то функционала, их ждут сильнее всего. ИИ на эту метрику практически не влияет, потому что проблема тут – в организации процессов, менять надо именно ее. И это – лишь один из примеров.

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

Так что Agile-практики сохраняют актуальность, хотя Agile и перестал быть флагом. И на конференции говорили не только про ИИ, но и про практики Agile и Agile-трансформацию. Среди них хочу отменить интересное выступление по agile-трансформации разработки железа для радиорелейных станций – антенн, плат и так далее.

А теперь, после этого общего обзора – конспекты выступлений.

Панель AGI-days: будущее организаций, кросс-функциональных команд и ролей в мире с ИИ

Панель открывала конференцию, в ней участвовали Алексей Грабарник из ГПБ, Антон Чижов МТС, Илья Забелин из Сбер, Владимир Сидоров из Северстали, Алексей Кашерин из Сбер, Наталья Цеберс из Вкусвилл и Асхат Уразбаев.

Я не буду пересказывать все реплики, но отмечу ряд интересных тезисов.

Вкуссвилл сделал mcp, чтобы клиенты покупали где угодно – из Яндекса, из ChatGPT. Пока подключают только гики, но средний чек там x3. А вообще это – шаг в будущее: там у каждого будет личный ИИ-помощник, который организует его жизнь, и это – интерфейс, который позволяет это делать.

А внутри у них проблема в слабой документированности знаний и процессов – Вкусвилл построен на самоорганизующихся командах, сильна устная традиция передачи знаний в коммуникации. Сейчас работают над этим, 200 человек энтузиастов – юристы, технологи, бухгалтерия, их прокачивали и они описывают свои знания на внутренней платформе. И их поддерживает команда, которая понимает, технологии ИИ – mcp, оркестрация агентов, настройка других инструментов.

Северсталь. Сделали ИИ-платформу полного цикла для исследований, включая обоснование инвестиций. Вообще Северсталь долго вкладывается в цифру и AGI (GPT) – поверх цифровизации и классического ИИ, с которого начинали в 2016 – разгоняли агрегаты, оптимизировали, и так далее, дают до 2 млрд в год прибыли. AGI – с 2023 года прототипы, в 2024 пилоты, в 2025 платформа ДаВинчи. По штучным инициативам 300 тысяч часов экономии, в этом году выйдут на прибыль сотни млн с переходом на млрд в 2027.

Асхат напомнил, что, как писал Салтыков-Щедрин, проблема России – дураки и дороги, то есть менеджмент и инфраструктура. Если для внедрения Agile-методов проблемой был менеджмент корпораций, то для ИИ – инфраструктура. Потому что на западе (и в мелких компаниях) начинают с того, что всем купили Клод, и дальше смотрят на результат, работают над его повышением. А в России сразу говорят, что код секретный, поэтому только on-premise. А там или слабые модели, с которыми непросто получить эффект и выше точка входа, или большие расходы на железо, для которых сразу хотят бизнес-план возврата инвестиций с цифрами, который невозможен для эксперимента. Поэтому все идет медленно и много симулякров.

Антон МТС. Если вы проходили Agile-трансформацию, у вас команды 10-12 человек, и они могут доставлять ценность. Можно все закупить Клод, и кода станет больше. Но увеличится ли эффективность командная? Они поставили эксперимент. Командная эффективность – выросла всего на 10-20%. Но при этом вырос lead time – потому что вырос wait time – появилось больше очередей внутри. Они попробовали команды поделить – 4-5 человек. Эффективность выросла, очереди и lead time – меньше. Уменьшили до 1-3 человек в команде – эксперимент идет. Однако, при таком размере становятся важными инструментами harness – чтобы обеспечить качество и учет корпоративного контекста. И характер работы человека меняется – он должен уметь погрузиться в любую фичу, на всем цикле, не только код, а гипотеза и приемка.

Я отмечу, что когда-то давно в ИТ не было разделения на разработчиков разных видов, аналитиков, тестировщиков и всех остальных, были просто программисты. Это возвращается.

Асхат Уразбаев. AI SDLC at Scale: как масштабировать агентную разработку

На мой взгляд, у Асхата – самое сильное выступление конференции. Хотя в целом он говорил известные вещи. Но хорошо и структурно. А начал – с интересного исторического экскурса. В истории человечества был период, когда ценности производили другие, это – Древняя Греция: граждане вели общественную деятельность по желанию, и управляли своими рабами, которые делали все остальное. И сейчас времена возвращаются, только вместо рабов – агенты, работают не за еду, а за токены, но тоже недорого, и ты должен ими управлять.

Tiny-team, Solo-team, burger-team (вместо pizza-team). С скрам-треке тоже, есть ST Разраб – с ним переписываются в чате, а он делает, что нужно: он умеет и разработку курсов, и вайбкодинг и многое другое – в презентации был список скиллов. Большинство спек закрывается в тот же день. Они сделали себе, и помогают сделать тоже самое другим.

Что делать с легаси? Внутри они все переписали – CRM, ведение дел. Но если легаси большое – то можно погружать в агентов постепенно, частями.

Есть путь зрелости команд по использованию ИИ

• Без ИИ.
• Спрашиваем ИИ – локальный помощник в редакторе кода с контекстом файлов.
• Спека по которой работаем с агентами: дизайн, логика.
• Агентный пайплайн: требования, код и так далее. Улучшение результата и улучшение процесса на человеке, harness крутит он
• Управляемая автономия, когда анализ и улучшение процесса тоже на агентах.

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

Как исправляется? SDD и пайплайн, с исправлением спеки по результатам. OpenSpec – самый простой стандарт propose (требования) – apply – archive. И там еще несколько. Был еще Intent Driven Development, он проиграл. И еще Zero assumption: никаких скрытых допущений.

Это меняет базовую механику Agile: мы не делаем быстрый прототип, а должны продумать с разработать спеку. И размывается фокус, появляется мультитаскинг, у разработчика – три чата открыто, потому что Клод 15-20 минут думает – ты делаешь другую задачу.

Я отмечу, что написать код и написать спеку- сильно разные компетенции. В некотором смысле, спека и есть код, она достаточно формальна. Однако в современных системах для кода – autocomplete и множество других штук, чтобы писать эффективно, а для спеки этого нет.

AI harness – упряжка, ярмо для агентов. В Клоде есть модель: читать – планировать – запускать – проверять. А вокруг – знания. Аналитику рассказываем: где база контактов, разработчику – как у нас пишут код. И строим агентский пайплайн.

У них – много агентов, они умеют выполнять разные команды (планирование, аудит), а скиллы оркестрируют агентов их выполнять. Ревью тоже делает модели, и у них ревью делает другая модель.

С ревью результата человеком – проблемы. Я нажимаю «дальше», потому что текст прочесть и детально проверить невозможно, а в целом он кажется разумным. Поэтому надо фокусировать агентов так, чтобы было проще ревью, а не работа ИИ. Способ – decision log: какие были альтернативы решений и почему выбрана конкретная альтернатива. И если спеку прогнать, в логе будет 10 решений, и ты можешь сказать: седьмое решение неверное, потому что видишь альтернативы, это проще проверки самой спеки.

Контроль качества – это не только баги, но и архитектура, стиль написания и понятность кода и многое другое. У них доля починок 10-15% не растет с ростом проекта. Quality Gate – специальная проверка после определенного этапа. Отдаем агенту список замечаний, он исправляет, повторяем проверку, если с третьего раза не прошел – то зовем человека. Гейты: спецификация согласована с владельцам; приемка – результат работает и выполняет требуемые функции; технические проверки; обновление документация. Это – внутри пайплайна.

Есть еще внешние проверки, например, у архитектора или безопасности: если tiny teams выкатывают кучу кода, они не успевают. Поэтому проверки надо агентизировать, их агенты встраиваются в quality gates. И тогда ты как архитектор для масштабирования не находишь 10 архитекторов, а пишешь агента. Только для этого архитектор должен уметь описывать свои представления о правильной архитектуре в виде чек-листа или политик, а не просто говорить «что-то мне не нравится такое решение, переделайте». Агенты будут форсить этот переход, и это – хорошо.

Чем больше радиус поражения – blast radius – тем больше и раньше ревью.

Когда нужно решение человека?

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

Метрика автономии агентов – насколько импакт.

Ретроспективы работы агентов. Когда баг исправлен, надо понять причину, почему он произошел и причины устранить. Так же по другим типам инцидентов, например, по результатам задачи не обновили тикет в jira или документацию. Ретро – автоматизированные, если правка harness маленькая – агент правит сам, но в конце недели человек смотрит. А большие изменения человек идет вместе с агентом.

Структура команд – team topologies. У каждой команды свой harness и pipelene, но есть общий подход, чтобы quality gates встроить и единообразно поддерживать. Команды поддержки – тоже маленькие. 1-2 человека, green grass – с нуля. И enabling team – помогает работать и запускает делает команду за командой.

Context engineering. Чем больше – тем эффективнее работа. Есть организация, где все созвоны валятся в базу знаний. Выяснили, что команда обсуждала несколько раз – вытащили изменения из созвонов. Это огромная интересная история. Можем ли весь бизнес описать. Это задача следующего года, маленькая организация проще, с крупной – тяжело.

Базу знаний – три уровня. Для начала – набор md-файлов, технически в репозиторий их кладут по-разному. Там надо захватить метрики и ответственность организации в целом, но это немного информации. Дальше берут процесс за процессом, например, начиная с продаж. Но для начала надо выстроить онтологию организации, основные объекты. Например, для Scrumtrek – набор проектов, компреды, тренера и зависимость: к проекту подключаем тренера и так далее. А дальше есть коробка из файлов, и там процесс inject knowledge, который это обрабатывает. Он длинный, может занимать неделю, и там куча условий, например, трекинг на файл, из которого получены конкретные знания. А дальше с этим уже может работать Клод, например, взять все компреды по канбану и создать новый, и он будет сразу достаточно хорошего качества.

Метрики. Смотрим на тоже самое, что раньше, но новых метрик пока нет, хотя можно придумывать. Например, процент решений, которые принимает ИИ по сравнению с человеком. Но бизнесу нравится TTM от идеи до результата. Когда green grass – один день. Когда Клод будет уметь из коробки – будет круто.

Виталий Пальчиков и Роман Астахов из Сбер. От AI-инструментов к AI-команде: как меняются роли и процессы внутри команды

Сбер внедряет ИИ сверху по площади, и руководство требует метрики – доля коммитов, использование токенов. Концепцию от руководства рассказывали на Saint Highload, можно посмотреть мой конспект, а в выступлении рассказ, как это выглядит снизу.

Есть парадоксы использования ИИ.

• Люди хотят моментальной экспертизы – и не могут проверить результат
• Люди хотят убрать рутину, но переживают, то останутся без работы, для некоторых людей работа – документы по шаблону, и не все рады, когда появляется кнопка «сделать релиз»
• Люди хотят переложить работу на ИИ, но боятся брать ответственность. Например, аналитики не готовы взяться за задачи восстановления проектных решений по коду с помощью ИИ.
• Все хотят ускорить свою работу, но совокупное ускорение небольшое – код ускорили, остальное – нет.

Как начали внедрять ИИ в команду. Офис трансформации рассказывает концепт. Три участника: Человек (намерение), ИИ (исполнитель) и Среда (она знает контекст и интегрировано). В теории – понятно, но как внедрить?

Таймлайн.

• Май 2026 – впервые на еженедельных планерках пошла тема ИИ. И на дейликах начал рассказывать, как использует ИИ (транскриб собеседований и другие задачи) – и побуждал использовать. Использовали, чтобы создать описания таблиц, чтобы по описанию сделать код и так далее.
• Декабрь 2026 – Появился Giga IDE – разработчикам зашло, можно копировать задачу из конфлюенса и получить сразу код, а вот и аналитикам не хавтало контекста, а тестировщикам описания кейсов.
• Март 2026. Начали понимать агентов и создавать их. Инструкции для агентов – скиллы для генерации и взаимодействие с корпоративным контекстом. Был Giga IDE, а теперь скиллы и интеграции для получения контекста – jira, confluence. Но у аналитиков и тестеровщиков по-прежнему проблемы, не хватало UI и оркестрации процесса.
• Июнь 2026 – сделали свой харнесс и UI. Разложили процесс по этапам и можно от этапа к этапу передавать инструмент, каждый человек работает со своим этапом и передает результат на следующий этап. ТТМ для простых доработок уменьшился +35%, было 10 дней, стало 6-7 дней. Но поняли, что ИИ ускоряет отдельные этапы, а переход между ними – нет, это особенность старого PDLC.
• Август 2026 – пилот по перестройке процесса. К ним пришел офис трансформации и предложил поучаствовать в пилоте по SDD.

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

Итого.

• Просто ИИ выдать нельзя. Используют как помощника, но не более. Чтобы агентизировать – надо учить, рассказывать о возможностях. Каждую неделю концепция меняется, не все успевают. Скиллы, как работать с ограничениями, интеграции
• Спецификация – главный актив. Не код, а описание проекта. Надо менять подходы к созданию спецификации, андо вести понятно для людей и компьютеру. Хорошая спецификация может быть заменой хорошей модели – GigaChat – неплохая модель, но не топовая, но при хорошей спецификации работает хорошо.
• Процессе надо менять – с безопасностью, с сопровождением – у нас не страницы в confluence, а не спецификация, и как согласуется (hash-суммы)
• Меняется роль человека. Он создает не артефакты, а намерения, артефакт делает ИИ, а человек – валидирует.
• Конфигурация команд. Есть малая инженерная команда. Есть гипотеза, что еще центры компетенций (как в больнице ренген), он считает, что нет. Сейчас в команде несколько аналитиков, разработчиков и тестеров, можно будет сократить до одного каждой роли – потому что только валидация на человеке останется. Но end2end роль человек не сможет взять. Но если там по одному человеку – будут риски ухода.

Вопрос. А то делать с развитием сотрудников? Сейчас джун-миддл-сеньор, они развивают и обучают? Ответ. Сейчас есть руководитель разработки, он лидит несколько инженерных команд и онбординг нового сотрудника выполняет Роман, а что делать если он уйдет – непонятно.

Вопрос. На чем джуны учатся? Ответ – есть спецификация, и ИИ может ответить на любой вопрос.

Вопрос. Зачем джун? Есть пул задач, надо делать, Ему отдают задачи, он учится сам, на его вопросы отвечает ИИ. Зачем Продукту вообще надо брать джуна? Потому что есть ограничение по ставкам. А потребность – не от джуна. Выдают ресурс меньше. Сейчас задача – научиться компенсировать отсутствие ресурса за счет ИИ. Как джуну, вчерашнему студенту, научиться взаимодействовать с безопасниками? Человек после ВУЗа – в шоке. Немного помогают скиллы: скилл профи системного аналитика – берешь вещь и ожидаешь, что подумаешь. К джунам стало больше требований – но дают и инструмент – скиллы, ответ в виде чата.

Вопрос. Есть человек, который обладает набором знает по архитектуре, безопасности, по продукту, по процессу поставки. Сеньор 10 лет этому учился. А сейчас? Ответ: весь этот контекст есть в спецификации – как релизится, как с безопасностью. ИИ ответит.

Вопрос. А нет ли опасности, что не смогут? Ответ: Отец говорил: «вы даже на логарифмической линейке считать не сможете, какие вы инженеры».

Вопрос. Спецификации – это программы нового уровня. Там ошибки, кто будет способен увидеть? Ответ. Был кейс, внутри под капотом проект работал, а внешне плохо. Тут джун идет к руководителю, спрашивает – и у него появляется экспертиза. Но ему надо разобраться во внутреннем устройстве фичи. Если не получается – спрашивают модель. Если поняли – ок, если нет – идут к эксперту. Инвестируют время в обучение специалиста – каждый трек, каждую неделю статус. Еще есть Quality Gate – Агент-сеньор, и он валидирует, а если нет – зовут эксперта, он один на несколько команд.

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

С совокупным ускорении есть проблемы. Команды стали брать больше задач, но в релизную команду и команду сопровождения упираются.

Вопрос про квоты на ИИ – не к ним, от них требуют больше использовать, хотя смотрят, чтобы в рамках конкретной фичи было меньше переработок.

Алексей Павлихин. Грань между развитием и результатом: три дилеммы эффективного управления!

Это рассказ про позицию руководителя. Который может быть добрым к себе, к руководству и к сотрудникам, но не ко всем трем одновременно. Это создает дилеммы, которые надо решать. И в выступлении были конкретные кейсы.

Алексей из Webbankir. Они поднадзорны ЦБ, выдают кредиты.

Руководитель может быть добрым для себя – не вовлекаться, смотреть со стороны; можно быть удобным для акционеров; можно быть удобным для сотрудников.

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

Он помогал трансформации ГПБ, а потом перешел на управленческую позицию, у тебя P&L, команда каждый день кушает зарплату. Как выбирать, какую позицию занимать, на что опираться.

Agile-среди и бизнес-среда – это про разное. Agile – развитие способности, оставляет право на ошибку, максимизирует будущую адаптивность. Бизнес – результаты в срок, коммиты перед топами, ограничивать цену ошибки, закрепляет личную ответственность, максимизирует текущую эффективность.

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

Что сдвигает в тоталитаризм?

• Высокая цена ошибки.
• Отсутствие обратимости, безопасной отмены
• Недостаточная компетентность команды
• Отсутствие времени, для обучения команды.
• Чем выше риск и срочность – тем больше руководитель концентрирует.

Люди: развивать или увольнять? Кейс: команда довольна, любит сотрудника, помогает коллегам, но системно не выполняет обязательства, обратная связь была – не помогает. Варианты: инвестировать в развития, новый срок и критерии, смена роли, расставание.

Кого должен защищать руководитель: команду или сотрудника? Руководитель должен защищать команду: если из-за одного потонем, проблема – у всех. Методы: самооценка, 360, оценка руководителя, интуиция. Если нащупал слабого сотрудника – надо нападать, сами очень редко выползают.

Самая важная история: вам хорошо бы понимать свои ценности и рассказать их команде. Расскажите про красные флаги. Для него это – несоблюдение договоренностей и нечестность. А дальше команда должна это принять.

Шкала: развиваю – поддерживаю – фиксрую – меняю – расстаюсь. Удобный руководитель растягивает, дает последние шансы. Развитие круто, но нужен срок и результат. У него: три красных флага – расстаемся. А после первого – начинается работа с сотрудником и поиск резерва.

Делегировать или вмешиваться. Команда выбрала вариант, с которым вы несогласны. Команда несколько недель обсуждала, у руководителя – контекст от регуляторов и другая информация. Варианты: принять выбор команды, вернуть на пересмотр, решить совместно (это хорошо, но долго, встречи до 5 часов), отменить и назначить свое.

Как выбирает? Требует Excel и данные (модель, бизнес-экономика), смотрит рынок и конкуренты, спрашивает про рассмотренные альтернативы и А/Б тесты. Важный прием – надеть шапку аналитика – взять таймаут на изучение материалов, особенно если прибегают эксперты, накидыают цифры и требуют решения быстро.

Признаки, что команда не готова к решению: нет цифр, на вопросы не отвечают или неуверенно; смежные подразделения не понимают контекст (надо запускать фичу – а маркетнинг не в курсе); здесь и сейчас мгновенно – нет.

Шкала: Делегирую, направляю, согласую, указываю. Принятие решение: соберите информацию и решайте. Чем выше цена ошибки – тем больше надо вам вовлекаться.

Информация: раскрывать или сохранять конфиденциальность?

Кейс. Топ-менеджер уходит к конкурентам. Он сказал, что через 2 месяца уйдет, он должен завершить переговоры и так далее. Если ему закрыть доступ – он не сможет доделать, если оставить – он узнает планы на следующий год, а он, возможно, уйдет к конкурентам.

Варианты: оставить полный доступ, закрыть стратегические решения, передать преемнику, немедленно вывести из управления (одним днем). Инструментарий: классификация информации – у кого к чему есть доступ. Матрица доверия, RACI. Красные флаги: говорить плохо за спиной; вести двойную игру; раскрытие конфиденциального.

Шкала: Открываю – Объясняю – Дозирую – Доступ по роли – Закрываю.

Рассказывать ли, что кто-то уходит, или надвигается другой кризис? Есть принцип: не ври, не пропадай и объясни что происходит. Что не решено, что известно и так далее.

Финал. Одна шкала для трех дилемм. В кризисе забираешь все решения на себя. Например, утечка данных произошла. Если run – согласуем, и есть норма ошибок. Курьер потерял заказ – то надо разбираться. Если делаем change – меняемся, новые фичи – надо инвестировать в потенциал команды, а для этого надо давать информацию.

Удобный руководитель выбирает один режим, а эффективный – меняет режимы по ситуации.

Что делать с конфликтом? Прихожу на встречу и говорю: могу уволить одного, второго или обоих. Или договоритесь за неделю. Или могу помочь договориться. И рассказать, как ты видишь ситуацию: я вижу, что ты не любишь, а ты – эмоционально реагируешь. Дальше выписываешь табличку, и если не соблюдают – расставаться.

Вопрос: а если с командой и результатам хорошо, а не совпадают именно ценности? Ответ. Он смотрит на бизнес и цели. Культура – сложно. Может, HRD.

У него другой вопрос: он видит тех, кто через один вниз, и если они не эффективны, а руководитель и команда так не думают.

По первому красному флагу делают кадровый резерв с HRD – это долго. Дальше 1:1, срок 2-3 месяца. И дальше – назначить зама или ждать преемника. Директор по рискам – год ищешь. Под все роли должен быть кадровый резерв. Сведите ваших людей к ограничениям рынка. Сколько искать на рынке, столько и даешь на изменения.

Мансур Дукузов. Куда уходит Agile, в какие города? Новая география практик вне разработки

Внедрение Agile для ИТ – не актуально: те, кто хотел – уже изменились? а остальные работают как умеют. Что делать тем, кто умеет это делать? Если у тебя получается успешно внедрять – ты умеешь проводить изменения. Можно попробовать заняться ускорением TTM с помощью ИИ – это тоже про изменение. А можно пойти в другие отрасли, где эффект Agile – актуален. Agile не исчезает, он меняет прописку. Надо искать новые территории, его путь – в трансформацию бизнес-функций, об этом был рассказ.

Замечу, что применение Agile за пределами ИТ – старая тема. Банки больше десяти лет используют, но и в других отраслях есть много разных кейсов, в свое время тема была актуальна и у меня есть несколько статей с обзором кейсов: банки, корпорации и госструктуры, производство, в школах.

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

Путь: Стратегия – Продукт – Разработка – Ценность. Проблемы могут быть до ИТ – в Стратегии и Продукте. И надо идти туда.

Функциональные колодцы типовой организации: Development, Operations, Finance, Supply Chain, HR, Commercial. Раньше решали вопросы между бизнесом и ИТ. А теперь надо разбираться со структурой бизнеса, анализировать причины проблем во взаимодействии функциональных подразделений, выходить на стратегию, помогать топам разбираться. В Agile много эффективных инструментов для этого, например, value stream mapping.

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

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

Процесс выпуска новых продуктов – шоколадки и печеньки. TTM длинный, хочется быстрее. И задача – понять проблемы, потому что часто приходят сразу с решением. И тут диагностика value stream mapping – ключевой инструмент. И они там нашли узкое место, с которого начали цифровизацию и расшивку.

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

Ускорение критического продукта. Если конкурентам придет идея создать печение со вкусом клюквы будет год, а у них – три года. И надо не просто поговорить, а тоже визуализировать – это создает пространство, в которое можно класть гипотезы изменений. . Value stream mapping, и там brain storm и ключевые гипотезы.

Помочь стейкхоледрам собрать единое видение продукта. Многие компании были филиалами, в 2022 голова ушла, а стейкхолдеы жили в параигме исполнения решений и мыслят так же. А тут надо самим придумывать. Задача – вовлечь стейкхолдеров в придумывание целей и инициатив и создание единого видения с показателями-критериями успеха.

Помочь финансовой функции понять, как должно выглядеть будущее. При этом, чтобы не было локальной оптимизации, когда нам – хорошо, а смежникам – плохо. Нужна картинка. Аналитика процессов финансовой функции: пообщаться внутри и со стейкхолдерами, сравнить проблемны финансов и бизнеса в целом. Они нашли 5 стримов: данные, множественность систем, диджитал навыки, finance governance, end2end процессы. С процессами сложно – есть которые идут долго, в которых очень много людей…

Инструменты нам знакомы: VSM и другие. Местность – новая, это не ИТ. Надо в ней разбираться. И надо смотреть. Задержки на согласованиях, ручные процессы и так далее. И если мы увидели коренную причину даже в другом отделе – надо помочь ее решить. И инструменты внедрять точечно – те, которые уместны и решают конкретную проблему. А не внедрять какой-то метод, например, scrum, повсеместно. Внедрять точечно. И самые полезные – достаточно редкие, VSM или brain storm – они вскрывают проблемные точки.

Вячеслав Баженов. Живые процессы: 5 шагов, чтобы компания успевала за изменениями

Вячеслав – CEO Бридж Групп: топ-5 по RAEX, 350 чел, 550 млн выручка. Есть проблема: как планировать год, если горизонт – месяц? Коронавирус, обломки БПЛА рушат каналы продаж (завязки на wildberries), ИИ меняет все. Друг торговал пальто, оборот 400 млн wildberries, у себя все убрал – сейчас нет бизнеса.

У него есть книга «Курс» – по ней занимаются с руководителями. В выступлении – краткое изложение методики, которая позволяет структурировать анализ, наприавить фокус внимания в конкретные точки.

Пять пунктов: Смотри наружу (8S) – убирай – меняй ритм (канбан) – обратная связь (клиентоцетричность) – пробуй малым (новые продукты малым бюджетом.

Есть система 7S: по кругу Strategy – Structure – Style – Skills – Staff – Systems, в центре Shared values. Это – для стабильных условий, сейчас добавляется окружение – Surroundings: clients, рынок, регулирование, технологии. Когда директор смотрит на компанию – это постоянная боль, проблемы. 8S помогает найти проблемные точки.

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

Кейс fl.ru – биржа фриланса, они купили у Северстали 2 года назад. 30 человек тестируют гипотезы, 90 за год, прибыли нет, выручки тоже. Половину уволили, остальное реструктурировали, и сейчас 40% прибыли.

Убирай. Есть штуки, которые надо начинать делать, продолжать делать и переставать делать! Пока маленькие – фокус на старт, новые гипотезы. Когда большая – фокус на стоп, закрывать бизнес-процесс. У многих есть стратегический продукт, который приносит убытки, но очень нравится начальнику – может, его пара закрыть?

Российское регулирование – антипаттерн, 10 лет назад было просто открыть новую компанию, несколько документов, а недавно они делали анализ законодательной базы – у компании после открытия должно быть 180 документов.

У них были стратсессии, через год приходили – непонятно, что изменилось. Внедрили Канбан – каденции, планирование квартала, итоги, промежуточное ретро – и исполнение по стратегическим задачам выросла до 80%. Сейчас надо трекать чаще, у них сейчас на еженедельной планерке оглядываемся на цели, и если не то – меняем, убираем.

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

Не запускайте Шаттлы. Был стартап в одной компании – открывали кофе-точку чтобы протестировать гипотезы. Там как всегда – команда проекта, включили маркетолога, потом директора по маркетингу, три месяца согласовывали бюджет, через год проект закрыли, так ничего и не сделав, при этом еженедельный бюджет команды проекта был 1.5 млн. А есть целые здания, когда специалисты набраны, на работу ходят, но фактическая работа не начата, потому что нет разрешения на бурение.

У них ассортиментная матрица 54 товара, было обучение всех менеджеров по продажам всей матрице. Теперь сделали жизненный цикл продукта

• Идея (проверяется через пост, видео, вебинар, базовый ленддинг)
• MVP (есть описание продукта и минимальная реклама 30тр)
• Продукт (есть три продажи – и только тогда пишут регламенты и учат всех)
• Бестселлер.
• И еще есть архив, куда ушло то, что не нужно.

Менеджеры знают про все 54 продукта, но учат их 7 бестселлерам, и тем 11, что продаются регулярно, но там – меньше. А если видят, что подходит что-то редкое – зовут специалиста.

Есть продукты, которые застряли. MVP – до СВО все носились с этим, ESG и так далее, Сейчас кончилось, вместо этого воинский учет. Он их не трогает – они базу выполняют, норму выполняют, и верит – СВО закончится, и охрана труда воспрянет.

Раньше сразу с идеи сразу делали обвязку и тест гипотез был очень долгий. Например, первую историю с коронавирусом они прозевали – они знали что говорить, но месяц согласовывали внутри, а там паника спала и конкуренты подсуетились. А по воинскому учету – лендинг сделали за сутки, воинский учет – самое востребованное направление.

Итого.

• 8S – диагностика. Соответствие целям, стратегии.
• Убирай лишнее. А зачем мы это делаем
• Начинайте легко

Все процессы на новую выручку или оптимизацию текучки. И можно сравнивать.

Влас Стригуненко и Паата Вахтангишвили. Agile против физики: как гибко разрабатывать hardware продукт, который нельзя сделать за спринт, пять или даже двадцать?

Еще одно замечательное выступление на конференции – о применении agile-методов для разработки железа для радиорелейных станций. Проблема в том, что считать инкрементом спринта, чтобы это можно было считать приращением ценности. И они решили этот вопрос не формально, а концептуально: итогом спринта будет знание, которое приобрели. Это может быть новый чертеж платы или схемы, который прошел через мат.моделирование, новый прототип, например, макет платы на 3d-принтере, прошедший какие-то испытания, или результат испытаний – оказалось, что финальные испытания изделия можно разделить на ряд этапов, и часть из них проходить с не полностью готовым прибором, постепенно наращивая функционал. Такой подход позволяет перенести выявление ошибок на ранние этапы, где их исправление требует меньше ресурсов, что и влияет на срок разработки и запуска продукта.

А теперь – подробнее. У компании НТР два направления: она пишет софт для базовых станций и создает аппаратуру для радиорелейных станций – антенны, платы, блоки и модули, вместе с управляющим софтом. Внедрение Agile-методов началось с софтверной части. В 2025 году завершался пилот по российской базовой станцией завершался, и надо было вывести сразу много станций. Это высококонкурентный рынок – конкурируем с Nokia, Huawei и другими гигантами, и телеком ожидает сопоставимых характеристик.

Проблема – непрозрачность процесса и приоритетов, в результате было неясно, когда результат дозреет. Диагностика ситуации нашли характерную проблему для организаций, которые переходят от стартапа к корпорации: много сильных спецов, которые могут автономно делать то, что нужно, но между ними – ад взаимных зависимостей. Чтобы решить, внедрили SAFe с квартальным планированием, которое как раз увязывает зависимости. Нашли кучу зависших задач и взаимных ожиданий, но проблема начала успешно решаться. В результате за год ввели в эксплуатацию 1910 станций.

Руководство было довольно, и решило второй этап внедрения – разработку железа. Agile столкнулся с физикой. При создании устройства есть процессы, которые ускорить невозможно. Испытание в термокамере – сутки. А еще есть закупка комплектующих, и это – долгий процесс. Двухнедльная нарезка на спринты сама по себе не сильно помогает.

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

На этапе начального проектирования функционал и геометрия платы за счет моделирования. На поздних этапах – есть прототип, на котором заказчик какие-то аспекты ПМИ может провести. Железку можно разложить на этапы, и для каждого – проверять ПМИ. Только важно следить, чтобы доработки не ломали то, что уже работает.

Интересная визуалиация в V-модели, по нисходящей ветви Стратегия – Продукт – Система – Архитектура – Команда, а по восходящей идет HADI-цикл: Гипотеза – Эксперимент – Simulation – Прототип – Тест, и в нем на каждой стадии проверки. Чем раньше увидели ошибку – тем дешевле исправить: ошибка в требованиях на этапе начального производства дешева, а когда уже в серию ушло – проблемы. Поэтому Agile для hardware – не делать быстрее, а быстрее обнаруживать ошибки.

Дальше при внедрении была типичная проблема: молодые ребята, которые не разбираются в предметной области, приходят к инженеру, классному специалисту, и говорят, что ему надо работать иначе – использовать тикеты в jira, оценка работы и так далее. И надо вовлечь, чтобы он не воспринимал это как очередное бюрократическое обременение. Сработала практика вовлечения людей в принятие решений и обсуждения с ними. И реальная реакция на обратную связь, особенно от ярких критиков: она часто идет от небезразличных людей и они могут сказать много ценного. А еще – обучать и поддерживать людей, повторяя сколько потребуется: объяснить пожилому инженеру, что такое story point – тяжело, но можно, и надо искать понятные объяснения.

Но гарантий выполнения работы в срок – нет. Конкретная история: заложили в новое изделие архитектуру по аналогии с другим продуктом, но обнаружили, что архитектура недостаточно эластична в части работы с сетью. Подошли к квартальному планированию с идеей сделать за квартал новую архитектуру. Но пошло не так – новая архитектура вызывает пожары, их надо тушить, инженеры тушат, бизнес спрашивает в чем проблема, через несколько испытаний поняли, что не взлетает. Вернулись к начальной архитектуре, нашли там быструю адаптацию. Разработчики дважды переписывают софт, и в железо тоже модифицировали. Но есть понимание, что если бы не agile, то новую архитектуру тянули бы до последнего, до предсерийных испытаний – а тут обнаружили проблему раньше.

При этом надо понимать, что Agile-методы, SAFe или любой другой фреймворк – лишь один компонент. Нужна инженерная культура и системное мышление.

Вопрос: Если вы завтра придете в новую компанию – три шага? Ответ: Канбан описать дизайн системы, что есть – а дальше уже можно с этим работать.

Как синхронизированно? У них несколько продуктов, и квартальное планирование выстроено по 2 недели. Сначала базовые станции, потом железячный поезд, потом эксплуатация и внутренние продукты. Внутри железа – все в один день и спринты тоже синхронно.

Специалистов они выращивают из вчерашних студентов, железячнкиков нельзя нанять готовых. Долгий цикл выращивания – продукт технически сложный.

Вопрос. Как вы видите перспективы замены ГОСТов на эту систему? Ответ. ГОСТ 15 серии отползет на кладбище. Меняется CAD topology позволяет делать невероятное – реактивные двигатели и так далее на 3d-принтере. Система ГОСТов на таком уровне сложности не сможет работать.