Как провести двухнедельный AI delivery-пилот без замены Jira или Linear

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

Выберите процесс с реальным результатом

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

• один понятный результат;
• один основной репозиторий;
• названный владелец продукта или разработки;
• несколько задач для людей или coding agents;
• существующий путь ревью и CI;
• отсутствие зависимости от миграции всей компании.

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

Сформулируйте вопрос до настройки

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

• проектный контекст копируется в агентные сессии;
• результат агента попадает в GitHub без актуальной задачи;
• владелец или следующий шаг неясен;
• статусы сводятся вручную;
• ревьюеры сначала ищут подтверждения;
• заблокированную работу замечают поздно.

Выберите две или три проблемы, которые должен проверить пилот.

Зафиксируйте baseline

Возьмите предыдущий сопоставимый процесс или первые два дня пилота и запишите:

• принятые задачи;
• минуты человеческой координации;
• возвраты из-за отсутствующего контекста, границ или подтверждений;
• результаты агентов без текущего владельца или задачи;
• блокеры, впервые найденные на ревью;
• время от «готово к ревью» до фактического решения.

Не используйте число pull request или token consumption как главный результат. Пилот успешен, когда полезная работа доходит до ответственного человеческого решения с меньшим операционным ремонтом.

День 0: определите полномочия и приёмку

До подключения агента запишите:

• кто отвечает за результат пилота;
• кто может принимать работу;
• какой репозиторий и проект TAM входят в границы;
• от имени какого человека или сервисного аккаунта действует каждый ИИ-клиент;
• какие проекты и операции разрешены Principal;
• какие подтверждения должна возвращать каждая задача реализации;
• какие действия всегда требуют человека.

Назначение не выдаёт доступ. Агент получает только необходимые рабочее пространство, проект и операции.

Дни 1–2: соберите delivery-среду

1. Создайте рабочее пространство и проект пилота в TAM.
2. Добавьте реальную цель, требования и условия приёмки.
3. Подключите GitHub к проекту.
4. Подключите один coding-клиент через поддерживаемый путь TAM.
5. Для интерактивной сессии используйте авторизацию человека, для постоянной командной работы — сервисный аккаунт.
6. Установите или выберите нужные TAM Skills.
7. Создайте первые задачи с владельцами и явными требованиями к подтверждениям.

Не подключайте все клиенты сразу. Одного достаточно, чтобы проверить модель работы.

Дни 3–8: выполняйте работу

Используйте одну и ту же задачу от назначения до ревью. Для каждого элемента:

• владелец открывает текущую задачу и контекст TAM;
• исполнитель работает в подходящем инструменте;
• прогресс и блокеры остаются у задачи;
• данные репозитория возвращаются в ту же запись;
• ответственный человек проверяет результат;
• приёмка или отклонение фиксируются явно.

Ведите короткий журнал координации. Отмечайте каждый случай, когда человек заново собирает контекст, исправляет ответственность, копирует статус, устраняет последствия устаревшего предположения или ищет подтверждения. Если в пилоте участвует @tam, используйте его для плана, follow-up, блокеров и готовности. Доступ к @tam не является условием проверки рабочего пространства TAM, MCP или GitHub-интеграции.

Дни 9–10: завершите ревью, а не демонстрацию

Для каждой задачи ответьте:

• Было ли требование актуальным в начале?
• Были ли ясны идентичность и полномочия исполнителя?
• Осталась ли задача авторитетной delivery-записью?
• Пришли ли данные GitHub вместе с передачей?
• Был ли блокер виден до ревью?
• Смог ли ревьюер принять или отклонить результат без реконструкции проекта?

Впечатляющий код без ответов на эти вопросы — не успешный delivery-результат.

Используйте небольшой scorecard

Добавьте качественный вопрос: Выбрала бы команда эту delivery-запись для следующего похожего процесса? Одного «да» при худших цифрах недостаточно. Лучших цифр при неудобной работе тоже.

Оставьте Jira или Linear на время пилота

Сосуществование работает, когда граница явна:

• поместите в TAM только выбранный процесс;
• не дублируйте каждую задачу в обеих системах;
• при необходимости оставьте общекорпоративную отчётность в текущем инструменте;
• передавайте верхнеуровневый статус пилота вручную в согласованные моменты;
• не обещайте автоматическую двустороннюю синхронизацию;
• не переносите историю, которая не нужна пилоту.

Цель — проверить модель delivery, а не механизм миграции.

Остановите пилот, если граница небезопасна

Поставьте работу на паузу, если:

• никто не отвечает за приёмку;
• идентичность или права агента неясны;
• доступ к репозиторию или проекту шире необходимого;
• работу нельзя безопасно восстановить;
• команда использует фиктивную задачу, чтобы не затронуть реальный процесс;
• подтверждения для ревью недоступны.

Остановленный пилот тоже полезен: он нашёл границу, которую надо исправить до расширения автономности.

Примите решение по результату

Расширить

Запись оставалась актуальной, издержки снизились, ревьюеры получили лучшие подтверждения. Добавьте один соседний процесс.

Повторить

Модель перспективна, но настройка, задачи или Skills применялись непоследовательно. Повторите пилот того же масштаба после одного конкретного исправления.

Остановить

Продукт не уменьшил наблюдаемую проблему координации или команда не может безопасно с ним работать. Оставьте текущую систему и зафиксируйте причину. Не превращайте смешанный результат в план развёртывания на всю компанию.

Запустите пилот

Создайте один проект TAM для одной живой цели. Подключите один coding-клиент и один репозиторий. Используйте scorecard десять рабочих дней.