Командные процессы

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

Какие есть челленджи при использовании ИИ на уровне команды:

• Как сделать, чтоб каждый не изобретал свой велосипед для решения одних и тех же проблем?
• Как не превратить репозиторий в ИИ-слоп?
• ИИ может значительно ускорить каждого отдельного разработчика. Как в этой ситуации сделать, чтоб они не начали мешать друг другу (дублирование работы; смены контрактов, интерфейсов и тестов; генерация несовместимых кусков кода)?

Становятся ещё более важными традиционные командные процессы:

• Проведение границ между задачами
• Принятие решений о смене архитектуры или контрактов
• Синхронизация знаний о репозитории
• Поддержание логичной структуры репозитория и границ между модулями
• Актуализация документации

Поэтому рекомендуется иметь на уровне компании и команды различные общие практики:

• Оценка готовности команды к использованию ИИ-агентов
• Ведение командного плейбука с общими правилами и рекомендациями
• Переиспользование ресурсов - скиллов, MCP, плагинов, настроек
• Разные полезные практики для улучшения эффективности ИИ типа парного ИИ-кодинга

Первые шаги для лидов

На основе нашего опыта рекомендуем начать с таких шагов:

• Сформулировать цели внедрения ИИ - ускорить разработку, снять рутину с разработчиков и не только, уменьшить количество багов и инцидентов, отчитаться перед начальством
• Сформулировать главные риски и проблемы - потеря контроля над кодовой базой, рост количества багов, неэффективное использование ИИ-инструментов, неконтролируемые затраты, неготовность репозиториев и команд под работу с ИИ, риски безопасности (агент положит прод, ключи утекут в облако)
• Для каждого риска и проблемы сформулировать, как мы будем их решать на уровне компании, отдела, команды. Какие правила будут обязательными, а какие рекомендуемыми
• Выбрать инструмент для пилота. Намного проще будет настраивать что-то одно - Claude Code, Codex, Cursor, Opencode, Pi, вариантов масса
• Если вы лид лидов, то провести встречу с лидами, рассказать все пункты выше, получить фидбек
• Если у вас большая команда, запустить пилот на ограниченное количество людей. Желательно, чтоб это был микс - и те, кто уже сами используют ИИ, и те, кто почти его не использовал (скажем, только в формате веб-чата для ответов на вопросы)
• Во время пилота рекомендуем уделить особенное внимание следующим аспектам
  • Помощь в настройке. Как ни странно, большая часть людей отсекается на этом этапе. Не работает VPN, VPN конфликтует с корпративным, не хватает RAM, не удаётся нормально настроить разрешения для ИИ-агента. Можно выделить под это целый день и ходить помогать людям всё корректно настроить
  • Общие настройки безопасности. Например, в Claude Code в Team-плане можно выставить обязательные для всех настройки
  • Сбор фидбека. Что нравится, что не нравится, какие были успешные и неуспешные кейсы
  • Сбор статистики. Как кто использует, как часто, какого размера сессии
  • Общая база знаний на уровне компании/отдела - очень помогает как стартовая точка
  • Какие практики будем использовать на уровне команды - засетапим командный документ по использованию ИИ, покодим в паре, соберёмся на общую встречу, проведём анализ готовности к использованию ИИ (смотри ниже)
  • Критерии успеха пилота и метрики - будем ли собирать какие-то сложные метрики или достаточно обратной связи и субъективного ощущения?
• По итогам пилота делаем вывод - расширяем и внедряем полноценно, продляем пилот, сворачиваем пилот, пробуем другой инструмент
• Если принято решение о превращении пилота в полноценное внедрение, то на этом этапе пора заняться более взрослыми штуками, например:
  • Общий прокси, через который будут проходить все запросы (для безопасности)
  • Удобный сбор статистики и дашборды
  • Общий MCP-реджистри с безопасно настроенными инструментами
  • Эксперименты со Spec-Driven Development фреймворками
  • Эксперименты с автономной разработкой и autoresearch
  • Как нужно изменить командные процессы, чтоб не превратить репозиторий в ИИ-слоп, а продакшн в кучу багов и инцидентов?

Что необходимо сделать перед началом внедрения ИИ-агентов

На старте рекомендуем оценить готовность ваших репозиториев и командных процессов к работе с ИИ-агентами.

Есть прикольный фреймворк Agent Readiness, по нему можно оценить готовность по восьми критериям:

• Style & Validation - настроены ли прекоммит-хуки - линтеры, стайлеры
• Build System - есть ли задокументированные способы запустить и протестировать проекты?
• Testing - есть ли у агента возможность быстро верифицировать результаты своей работы?
• Documentation - есть ли в репозитории вся нужная документация? Есть ли какие-то неявные знания, не описанные на бумаге?
• Dev Environment - настроен ли у каждого энв, в котором агент может запускать скрипты, команды?
• Code Quality - удобен ли проект для ИИ-агента? Все файлы меньше 500 строк, функции меньше 50 строк, чёткие границы между модулями
• Observability - наличие и доступ до логов, трейсов, трейсбеков (Sentry, ELK, логи кубика)
• Security & Governance - настроено ли всё так, чтоб агент не мог уронить прод-кластер, удалить данные, ликнуть пароли?

Ещё можно добавить Data - есть ли у агента удобный доступ до данных, необходимых для работы.

Пример практического описания уровней зрелости

• Первый - есть ридми, линтер, юнит-тесты
• Второй - есть общий CLAUDE.md, прекоммит-хуки, базовые правила безопасности
• Третий - есть удобные E2E-тесты, детальная документация для агента
• Четвёртый - оптимизированные билды, быстрые способы верификации работы
• Пятый - декомпозиция задач, авто-восстановление сервисов

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

Начинаем внедрение ИИ-инструментов

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

На что обратить внимание в первую очередь:

• Процесс работы над задачами - от постановки до деплоя и мониторинга. Отдельно выделим:
  • Тестирование - правила проверки результата перед созданием PR
  • Код-ревью
  • Написание и обновление документации
• Сбор фидбека по процессу внедрения ИИ в разработку

Результаты обсуждений зафиксировать в документе с обязательными и рекомендуемыми практиками - командный playbook. На первое время, пока практики не устоятся, важно иметь один источник правды. Что может содержать плейбук:

• Описание процесса работы над задачей, обязательные и рекомендуемые правила
• Правила проверки результата и код-ревью
• Примеры хороших кейсов
• Повторяющиеся процессы

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

Скажем, BMAD-Method хорош, если стартуете какой-то новый проект в соло, потому что он эмулирует полноценный пайплайн разработки через скиллы:

• Брейнсторминг идеи (скилл bmad-brainstorming)
• Сбор текущего состояния (bmad-document-project, bmad-generate-project-context)
• Рисёчи (bmad-domain-research, bmad-market-research, bmad-technical-research)
• Создание Product Requirements Document (bmad-create-prd)
• Проверка PRD на ошибки и логические несоответствия (bmad-validate-prd)
• Создание архитектуры (bmad-create-architecture) и UX-дизайна (bmad-create-ux-design)
• Декомпозиция на эпики и сторисы (bmad-create-epics-and-stories)
• Проверка готовности документации (bmad-check-implementation-readiness)
• И далее по циклу разработки — создаём описание новой стори (bmad-create-story), разрабатываем (bmad-dev-story), делаем код-ревью (bmad-code-review)

Кажется, что это оверкилл, но подход в целом интересный, особенно для частично написанных проектов.

Плюсы:

• Намного меньше шанс пропустить что-то важное — ошибку в коде, противоречия в бизнес-требованиях, важный юзер-кейс
• Система сама спрашивает, когда нужно человеческое вмешательство на разных этапах — от планирования до код-ревью

Минусы:

• Очень прожорливо на токены, особенно если использовать Opus для субагентов
• Генерируется очень много маркдаунов, которые все лень читать

Полезные практики

• Парный вайб-кодинг — более опытный и менее опытный (в использовании ИИ-агентов) участники вместе решают какую-то задачу