Управление разработкой и проектами

• что сейчас лучше и хуже поддаётся автоматизации: проектирование, дизайн, разработка
• влияние внедрения ИИ на стоимость и сроки производства
• что ждёт нас в будущем

• Почему следующий этап внедрения AI — автоматизация не производства, а управления
• Как разложить работу менеджера на функции, которые может выполнять AI
• Как AI строит план и пересобирает его при изменении сроков, ресурсов и зависимостей
• Как агент синхронизирует команду и готовит коммуникацию для заказчиков и контрагентов
• Чем AI-менеджер отличается от чат-бота, копилота и базы знаний
• Какие управленческие функции уже можно отдать AI, а где пока необходим человек
• Что будет с ролью менеджера

• Почему AI ускоряет разработчика, но не проект. Основные потери времени — передачи задач, переключения между инструментами и неявный порядок работы, а не набор кода.
• Как внутренние эксперименты изменили наш процесс разработки. Переход от выдачи кодинговых агентов к управлению процессом через исполняемые текстовые инструкции.
• Как устроен слой исполняемого процесса. Структура файлов, описание действий, индексы, разрешение инструкций в разных AI-клиентах и жесткие границы прав.
• Как внедрить и масштабировать подход. Что нужно для запуска в своей команде, как распространить его на компанию и какими метриками измерять результат.

• AI уже сильно ускорил отдельные части дизайн-процесса: дизайнер может быстрее собирать прототипы, делать анимацию, писать код и проверять идеи прямо в браузере. Разберу, как из-за этого меняются требования к дизайнерам, состав команды и привычное разделение работы между специалистами.
• Покажу на опыте Red Collar, что происходит с менеджментом и арт-дирекшном, когда производство становится быстрее, а вариантов становится сильно больше. Где AI уже помогает нам менять процесс, где пока создает дополнительный хаос и почему.

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

• Внедрение SDD во все процессы и роли. Как связать работу продуктов, аналитиков, разработчиков и QA через спецификации, критерии приёмки и проверяемые результаты.
• Перестройка ролей в командах. Как меняются задачи, зоны ответственности и взаимодействие людей, когда написание кода передаётся агентам.
• Построение харнесов для разных типов проектов. Как устроить инструкции, контекст, инструменты и проверки с учётом архитектуры, состояния документации и ограничений легаси.

• Почему ИИ-трансформация буксует: крупным компаниям не хватает готового алгоритма системных изменений.
• Что предлагает AI-Native SAFe: операционная модель корпорации, изначально построенной с учётом ИИ.
• Почему ИИ не работает поверх управленческого хаоса, устаревших процессов и неподготовленных данных.
• Что должно трансформироваться вместе с технологиями: стратегия, оргструктура, продукты, процессы и данные.
• Как ИИ-агенты изменят численность команд, распределение задач и привычные корпоративные роли.
• Как токен-экономика повлияет на горизонты планирования, механику принятия решений и бюджетирование.

• Проговорим с аудиторией случаи, когда ИИ сделал такую дичь, что потом приходилось отменять релизы, поднимать бэкапы, объясняться с безопасностью и очень внимательно смотреть в логи.
• Будем говорить не про безобидные галлюцинации, а про реальные истории: сломанный прод, утекшие данные, странные решения, внезапные счета и другие последствия идеи «давайте просто подключим ИИ».
• Будет хороший черный юмор и выводы, которые помогут не повторить чужой факап у себя.
• Приготовьтесь рассказать про свои случаи.

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

У вас есть бюджет и шесть ИИ-инициатив, каждая с убедительным расчётом эффекта. Вы выбираете три и запускаете. Дальше начинается то, что в презентациях обычно не пишут.

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

• AI расширяет поверхность атаки: новые риски возникают не только в приложении, но и вокруг модели, контекста, данных, инструментов, агентной инфраструктуры и ML-цепочки поставки.
• Последствия уязвимости зависят от полномочий системы: одна и та же ошибка имеет разный эффект для чат-бота и агента, который обращается к API, выполняет команды или работает с корпоративными данными.
• Классические угрозы — утечки, кража учётных данных, выполнение вредоносного кода, компрометация рабочих станций и цепочки поставки — сохраняются и получают новые пути реализации через AI.
• Защита должна быть эшелонированной и включать минимальные права, изоляцию, сегментацию, управление секретами, контроль сетевого доступа, проверку данных, фильтрацию входов и выходов, guardrails и мониторинг.
• Безопасность AI — это управляемый компромисс: задача не в полном исключении рисков, а в том, чтобы ограничить возможный ущерб и подобрать достаточный уровень контроля под конкретный сценарий.

• Как использовать AI для анализа требований и поиска противоречий ещё до начала разработки
• Как генерировать тестовые сценарии и тесты на основе требований, спецификаций, API-контрактов и существующего кода
• Как AI может помогать определять области риска и выбирать необходимый объём регрессионного тестирования
• Как применять AI в UI и visual testing и где заканчивается надёжность подобных подходов
• Почему большое количество автоматически сгенерированных тестов не означает высокое качество продукта
• Как проверять сами AI-генерируемые тесты и бороться с ложной уверенностью, hallucinations и некорректными test oracle
• Как меняется роль QA-инженера, когда значительную часть анализа и генерации проверок может выполнять AI

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

Вместе с заказчиками обсудим рабочие модели внедрения AI: какие задачи стоит отдавать подрядчику, что должно оставаться внутри компании и как организовать совместную работу.

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

• Легаси требует контекста и проверок. Неявные бизнес-правила, сложная архитектура и устаревшая документация делают подход «сразу напиши код» ненадёжным.
• Начинать нужно с узких мест процесса. Выбирать сценарии по реальным потерям времени на пути от требований до production, а не по эффектности демонстраций.
• Агентный харнес превращает эксперименты в процесс. Корпоративный доступ к моделям, инструкции, инструменты, границы прав и обучение команды делают работу агентов управляемой.
• Автоматизация не отменяет инженерного контроля. Исследование и план предшествуют коду, тесты и независимое ревью проверяют результат, ответственность остаётся у людей.
• Масштабировать нужно подтверждённый эффект. Начать с нескольких сценариев и измерять сроки поставки, возвраты, дефекты и стоимость изменений — не объём сгенерированного кода.

• Инструмент купили все. Почему себестоимость проектов не изменилась почти ни у кого, и у кого изменилась?
• Кто такой оператор, который сам продает, проектирует и сдает проект, и почему это не разработчик и не one man army?
• Зачем ему агентство, если он может все один?
• Можно ли это масштабировать? Какие регламенты сложились за год и где у модели границы. Кейсы.