Практика: первые 90 дней внедрения ИИ
Этот блок собирает всё предыдущее в план. В 90 днях нет никакой магии, это обычный квартал: срок, за который можно получить первые достоверные данные и который понятен финансовому директору. План делится на 4 фазы, а переход между ними зависит от выполнения условий, календарная дата его не определяет.
Вы технический директор, квартал на внедрение согласован. Осталось решить, как его прожить: что делать в первые 2 недели, когда переходить к следующей фазе и кто будет владеть внедрением после пилота.
Совету нужны даты
Квартал на ИИ согласовали, теперь мне в план нужны даты: когда пилот, когда все команды, когда эффект. А ещё совету нравится, когда к концу квартала уже раскатано на всех.
Как вы построите план на 90 дней?
Что происходит через квартал: все варианты
Цифры условные: они показывают направление изменений, но величину по ним оценивать нельзя. Какие метрики держать на еженедельной панели, сказано в блоке 11, а полный чек-лист самооценки есть в блоке 15.
Вариант A. Сразу в пилот: 6 недель данных, сравнить не с чем
Пилот стартовал на третий день, команда работает с удовольствием. Но через 6 недель вы не можете сказать, стало ли быстрее: сбор данных настроили только на третьей неделе, а baseline собирали задним числом и только по 2 метрикам. На седьмой неделе ИБ увидела трафик к внешней модели и остановила пилот до согласования, на это ушло ещё 3 недели. Расход токенов без лимита за первый месяц съел почти весь квартальный бюджет. К дню 90 у вас половина пилота и спор с финансовым директором о том, что считать результатом.
| Метрика | Было | Стало |
|---|---|---|
| Расход на токены (к квартальному плану) | план | +80% |
| Недель пилота с сопоставимыми данными (план – 6) | – | 4 |
| Время от коммита до прода (метрика DORA) | нет данных | 5 дн |
| Доля сбойных изменений (метрика DORA) | нет данных | 4,7% |
| Открытые замечания ИБ (на день 90) | 0 | 3 |
Вердикт: 6 недель пилота закончились спором о цифрах. Сравнивать их не с чем, а остановка от ИБ съела половину срока.
Что говорят коллеги после варианта A
Даниил: В банке такой старт закончился бы уже на второй неделе, до седьмой он бы не дожил: у нас закрытый контур, поэтому трафик к внешней модели видят сразу. Я понимаю, откуда берётся желание пропустить подготовку: она выглядит как бюрократия, а бюрократии у меня и так хватает. Но встреча с ИБ до выбора инструмента в корпорации единственный шаг, который время экономит. 2 недели в начале обходятся дешевле 3 недель в середине.
Мария: Мы стартовали так же и потом полгода спорили с финансовым директором, было ли ускорение. Без baseline любое улучшение остаётся мнением, данных за ним нет. Сейчас я не начала бы ни одного пилота без 2 вещей: метрик за 3 месяца и лимита на токены. Лимит важнее, чем кажется: у нас один эксперимент с агентом за выходные съел недельный бюджет команды.
- Мария: Даниил, а 2 недель на подготовку тебе вообще хватит, с твоими 3 системами?
- Даниил: Нет, baseline у меня за 2 недели не собрать: выгрузку из 3 систем делают по заявкам. Я бы просил месяц.
- Мария: Тогда начни сбор сейчас, до старта квартала. Месяц ожидания означает месяц, когда люди сидят на личных аккаунтах.
Итог: Пилот без подготовки дал 6 недель данных, которые не с чем сравнить. Для первой попытки это нормальный исход. Главное из блока: без подготовки пилот даёт искажённый результат, а переход между фазами определяют условия вместо календаря. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими. План этих 90 дней можно перенести в AISuppy задачами со сроками – на сайте или в боте курса.
Вариант B. Фазы с условиями перехода: Медленный старт, обоснованный переход
2 недели ушли на подготовку, а финансовый директор дважды спрашивала, когда начнём. Baseline за 3 месяца сняли, ИБ согласовала инструмент и дала участника, лимит бюджета стоял с первого дня. На четвёртой неделе пилота выросли пул-реквесты, поэтому вы сразу ограничили их размер. На день 61 условия перехода выполнены, вторая волна пошла на 4 команды, в том числе на неудобный сервис. Эффект там меньше, но с поправкой на типичность он не хуже. Ревью снова стало узким местом, это первая задача для платформенной команды из 2 человек.
| Метрика | Было | Стало |
|---|---|---|
| Стоимость единицы поставки (все расходы на разработку / число деплоев) | 100 | 96 |
| Время от коммита до прода (метрика DORA) | 6 дн | 5,2 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 4,0% |
| Время на ревью (медиана по пул-реквесту) | 1,5 дн | 1,8 дн |
| Активное использование (пилот и вторая волна, по данным инструмента) | нет данных | 72% |
Вердикт: К дню 90 у вас достоверный результат на 5 командах и список того, что чинить. Дату полного масштабирования вы так и не назвали.
Что говорят коллеги после варианта B
Даниил: Правильно, но в банке «переход по условиям» звучит для правления как «мы не знаем когда». Я бы оставил в плане даты, только назвал бы их «не раньше»: вторая волна не раньше дня 61 и только при выполненных условиях. Одно условие я бы ещё ужесточил: «ИБ без открытых замечаний» нельзя считать формальностью. В корпорации одно открытое замечание на второй волне останавливает сразу все команды, одной дело не ограничится.
Мария: У нас прошло почти так же, а споткнулись мы в одном месте: платформенную команду собрали только после пилота, поэтому первые 2 недели второй волны ушли на её запуск. Теперь я начинаю собирать её на фазе пилота, хотя бы одного человека, который пишет файлы контекста и ходит по командам. С командами я говорю живьём, одной панели мне мало: метрики не объясняют, почему так происходит.
- Даниил: Мария, платформенная команда во время пилота означает ещё 2 человека, которых мне никто не даст под «эксперимент».
- Мария: Хватит одного человека на часть времени, а без него через год у тебя будет 20 несовместимых практик.
- Даниил: Про практики согласен, но людей под это до первых цифр пилота выбить нельзя, тут я с тобой не соглашусь.
Итог: Вы прожили квартал по условиям вместо календаря. Это правильный ответ, хотя Мария права в том, что платформенную команду стоит начинать собирать раньше. Главное из блока: через 90 дней внедрение только начинается, а метод остаётся тем же (baseline, измерения, перестройка процессов). Соберите документ по промпту: с дизайном пилота вы начнёте свой первый день. План этих 90 дней можно перенести в AISuppy задачами со сроками – на сайте или в боте курса.
Вариант C. План по календарю: Масштабировали то, что не работало
Совет получил даты, вы их выдержали. К концу первого месяца на пилоте выросли пул-реквесты и время ревью, но по плану на второй месяц стояли все команды, поэтому вы подключили 20. Проблема ревью стала проблемой всей компании, сбойных изменений стало больше. Платформенной команды нет, поэтому каждая команда придумала свои правила работы с ИИ. На третий месяц вместо отчёта об эффекте вы пишете план отката, а финансовый директор спрашивает, за что платили.
| Метрика | Было | Стало |
|---|---|---|
| Стоимость единицы поставки (все расходы на разработку / число деплоев) | 100 | 109 |
| Время от коммита до прода (метрика DORA) | 6 дн | 6,5 дн |
| Доля сбойных изменений (метрика DORA) | 4,0% | 5,2% |
| Время на ревью (медиана по пул-реквесту) | 1,5 дн | 2,4 дн |
| Активное использование (все команды, по данным инструмента) | нет данных | 58% |
Вердикт: Даты вы выдержали. Но вместе с инструментом вы размножили проблему ревью на все команды, и на день 90 пишете план отката.
Что говорят коллеги после варианта C
Даниил: Даты для совета нужны, это нормально: в банке без них вообще ничего не утверждают. Ошибка в другом: дата стала условием перехода. Я бы оставил те же 3 месяца, но записал в план: если доля сбойных изменений растёт, вторая волна сдвигается по решению технического директора, поводом для эскалации это не считается. Без такой оговорки в корпорации дату никто не посмеет сдвинуть.
Мария: В первый год мы после пилота на лучшей команде через месяц запустили вторую волну без условий перехода. Потом долго разгребали последствия. Каждая команда придумала свои правила и свои файлы контекста, поэтому платформенной команде, которую мы собрали после пилота, пришлось сначала всё это свести. Проблема ревью, которую видно на одной команде, на всех командах становится проблемой всей компании. Чинить её на пилоте намного дешевле.
- Мария: Даниил, ты правда сдвинул бы дату перед правлением, если бы метрики пошли не туда?
- Даниил: Сдвинул бы, потому что объяснить правлению один сдвиг проще, чем откат на 20 командах.
- Мария: Тогда зачем вообще писать даты? Пиши условия перехода, совет к ним привыкнет.
Итог: Календарь заставил масштабировать то, что не работало. Для первой попытки это нормальный исход. Главное из блока: переход между фазами определяют условия вместо календаря, а после пилота внедрением должен кто-то владеть. Если захотите, пройдите развилку заново: реплики Даниила и Марии будут другими. План этих 90 дней можно перенести в AISuppy задачами со сроками – на сайте или в боте курса.
План на 90 дней по фазам
Вы выбрали фазы с условиями перехода. Ниже показано, что входит в каждую фазу, как слушать метрики и команды и что начинается после 90 дней.
Цель: создать условия, без которых пилот даст искажённый результат.
- Снять baseline по метрикам из блока 11 за предыдущие 3 месяца. Если выгрузки делают по заявкам, закажите их за 2–4 недели до фазы 0. Если данных нет, настроить сбор.
- Встретиться с ИБ до выбора инструмента: получить условия согласования и назначить участника пилота от ИБ (блок 05).
- Написать политику использования ИИ на 1 страницу (шаблон в блоке 15).
- Выбрать инструмент с учётом ограничений: контур, оплата, аудит (блоки 03 и 05, коротко – ниже).
- Поставить предохранители на бюджет (блок 04).
- Собрать пилотную группу по правилам блока 13 и выбрать типичный сервис.
- Сформулировать цели пилота через метрики (таблица в блоке 11).
Условие перехода: baseline снят, политика подписана, ИБ согласовала инструмент, бюджет ограничен.
Как выбрать инструмент, если вы в России. Сначала разделите код и данные на 2 группы: с ограничениями (персональные данные клиентов, критичные системы, КИИ) и всё остальное (блок 05). Дальше – 4 пути, их можно сочетать:
- Отечественный поставщик по договору (GigaChat, YandexGPT и другие) – для данных с ограничениями. Качество проверьте на своём наборе эталонных задач (ниже), а не по оценкам поставщика.
- Открытая модель в контуре – когда закон или ИБ не выпускают код за периметр. Нужны оборудование и люди, порог окупаемости считается в блоке 04.
- Зарубежная модель по API – только для кода без ограничений. Способ оплаты и договор согласуйте с юристами и финансами до пилота: если законного способа нет, этот путь закрыт. Доступ может пропасть (блок 03).
- Шлюз перед любой моделью – журнал запросов для ИБ, лимиты и возможность сменить поставщика без переделки процесса (блоки 04 и 05).
- Оплата – только по договору с юрлицом компании. Личные карты и личные аккаунты политика запрещает (блок 05).
- Проверка перед выбором – 2–3 кандидата прогоните на одном наборе эталонных задач и сравните результат.
Личные аккаунты в первые 2 недели. Часть инженеров уже работает через личные аккаунты (блок 02), а разрешённый инструмент появится только к дню 15. Полный запрет на эти 2 недели обычно уводит использование глубже – так было в варианте C блока 12. Что сделать в день 1:
- Разослать временное правило на 5 строк: в любые ИИ-сервисы нельзя отправлять секреты, ключи, персональные данные клиентов и код закрытых систем. Если отправили – сообщить, наказания не будет.
- Спросить команды без последствий, чем они уже пользуются и для каких задач. Ответы пригодятся при выборе инструмента и как точка отсчёта для доли использования через корпоративные инструменты (блок 11).
- Назвать дату, когда появится разрешённый инструмент, и сказать, что после неё личные аккаунты запрещены (блок 05).
- Если у вас данные с ограничениями, КИИ или этого требует ИБ, закройте доступ к публичным ИИ-сервисам с рабочих машин сразу. Тогда не затягивайте фазу 0: каждая неделя без разрешённого инструмента – неделя обходов.
Цель: получить данные на одной команде.
- Обучить пилотную группу на реальных рабочих задачах (блок 13).
- Начать с задач с предсказуемой отдачей: понимание кода, документация, тесты; в небольшой компании – и миграции (блок 07).
- Написать файлы контекста для сервиса: архитектура, договорённости, стандарты (блок 15).
- Каждую неделю смотреть метрики использования, расход токенов, время ревью и размер пул-реквестов. На рост размера изменений реагировать сразу.
- Каждую неделю проводить короткую встречу с пилотной группой и спрашивать, что мешает и что работает.
- Фиксировать для каждого изменения участие ИИ (аудиторский след из блока 12).
Условие перехода: 6 недель данных; сбойных изменений за 6 недель не больше, чем в среднем за 6 недель baseline (деплоев мало, поэтому считайте в штуках: при 23 деплоях 1 сбой меняет долю на 4 процентных пункта); стоимость единицы поставки посчитана; у пилотной группы есть список того, что нужно изменить в процессе.
Цель: проверить, что результат пилота воспроизводится.
- Подключить ещё 3–5 команд, включая команды менее удобных сервисов.
- Платформенная команда (о ней ниже) берёт на себя файлы контекста, настройку инструментов и обучение.
- Исправить узкие места, найденные в пилоте: чаще всего это ревью и согласования.
- Сравнить метрики второй волны с пилотом и с baseline.
Условие перехода к полному масштабированию: эффект на второй волне не хуже, чем на пилоте, с поправкой на типичность; стоимость единицы поставки не выросла; ИБ не имеет открытых замечаний.
Каналов 2, оба нужны: метрики показывают, что происходит, а команды объясняют, почему. Если метрики улучшились, а команды недовольны, то вы, вероятно, выжимаете скорость за счёт людей, а такой результат долго не продержится. Если команды довольны, а метрики не улучшились, вспомните METR: ощущения нельзя считать данными.
Формат такой: по метрикам нужна еженедельная панель с 5 показателями, а с командами нужна короткая встреча раз в неделю на пилоте и раз в 2 недели после него. Формы и опросники не нужны, потому что живой разговор даёт больше.
После пилота кто-то должен владеть внедрением как продуктом, потому что подход «как к проекту» здесь уже не годится. Это платформенная команда: 2–4 человека, которые отвечают за инструменты и их настройку, файлы контекста и шаблоны, обучение и поддержку инженеров, метрики использования и расход токенов, отношения с ИБ и поставщиками, обновление моделей и проверку того, что после обновления ничего не сломалось (набор эталонных задач из блока 03).
Без такой команды каждая продуктовая команда изобретает своё, поэтому через год у вас будет 20 несовместимых практик. В небольшой компании это может быть 1 человек на часть времени, но такой человек должен быть.
Перед тем как считать внедрение состоявшимся, ответьте без самообмана на 10 вопросов в конце раздела. Полный чек-лист находится в блоке 15, а здесь собрано главное.
Если нужна внешняя шкала для сравнения с рынком, у Сбера в AI-Disrupt PDLC (раздел 3.6 методологии) есть шкала зрелости команды из 6 уровней. Главный критерий уровня – медианная длительность задачи, которую агент выполняет без вмешательства человека, второй – какая проверка результата обязательна.
- L0. Устойчивой ИИ-практики нет, агентных задач нет, требований к проверке нет.
- L1. Эксперименты с плагинами в редакторе. Задачи на минуты (автодополнение). Проверка не требуется, нужна только политика разрешённых инструментов.
- L2. Первые инженеры используют ИИ для рутинных задач. Задачи до 30 минут. В конвейере стоит AI-gate: автоматическая проверка, которая блокирует критичные регрессии.
- L3. Разработка от спецификации внедрена, агенты кодирования работают в ветках под ревью. Задачи до 2 часов. Обязательны агент-ревьюер и проверочный пакет (Evidence Bundle: что сделано, чем проверено). Критерий входа: не меньше 5 полных спецификаций, согласие агента-ревьюера с человеком не ниже 80%.
- L4. Параллельное выполнение, несколько сессий агентов одновременно. Задачи до 4 часов, на зрелом уровне до 1 рабочего дня. Полная методика валидации, контрольные точки по ходу задачи, библиотека из 30 и более проверенных паттернов, ревью человека не является узким местом.
- L5. Скоординированные команды агентов. Задачи на несколько дней цепочкой сессий с контрольными точками. Объяснимость решений в реальном времени и полный жизненный цикл агентов (ADLC, agent development life cycle). Только для организаций с платформенной командой и работающим контуром управления.
Ожидаемые сроки переходов по методологии: L0→L1 дни, L1→L2 от 1 до 3 месяцев, L2→L3 от 6 до 12 месяцев, L3→L4 от 12 до 18 месяцев. Авторы предупреждают: погоня за уровнем без фундамента опаснее реального L2, команда получает регрессии и откатывается к L1. Не путайте эту шкалу с 2 другими шкалами Сбера: R0–R5 (что агенту разрешено делать в контуре) и моделью ИИ-зрелости компании, представленной в сентябре 2026 (6 уровней от «Нулевого» до «Инновационного» по 8 областям, от стратегии до ИИ-инфраструктуры). Это разные оси, и смешивать их при самооценке – типичная ошибка.
Это шкала вендора, а её критерии завязаны на методологию Сбера, но 2 вывода из неё я считаю верными для всех. Первый вывод: самым надёжным показателем зрелости служит медианная длительность задачи, которую агент выполняет без вмешательства. Второй вывод: команда, которая трезво оценила себя как L2 с планом на L3, находится в лучшем положении, чем команда, которая объявила L4 и работает на L2.
Основная шкала курса – 5 ступеней из блока 03. Примерное соответствие шкале Сбера (моя оценка):
| Ступень курса | Уровень Сбера |
|---|---|
| 1. Автодополнение | L1 |
| 2. Чат-ассистент | L1–L2 |
| 3. Ассистент в редакторе с контекстом проекта | L2 |
| 4. Агент | L3 |
| 5. Автономный агент | L4–L5 |
Вопросы самооценки:
- Есть ли baseline, с которым вы сравниваете?
- Снизилась ли стоимость единицы поставки?
- Не выросла ли доля сбойных изменений?
- Не стало ли ревью узким местом?
- Используют ли инструмент больше половины инженеров по данным инструмента (ответы в опросе не считаются)?
- Есть ли у ИБ открытые замечания?
- Можете ли вы для любого изменения за последний месяц сказать, участвовал ли ИИ и кто проверял?
- Есть ли кто-то, кто владеет внедрением после пилота?
- Знаете ли вы, что произойдёт, если поставщик модели отключит доступ завтра?
- Что из обещанного в блоке 02 вы можете показать цифрами?
Через 90 дней внедрение по-настоящему только начинается. Дальше я считаю разумным такой порядок: перестройка самых медленных этапов процесса, которые ИИ сделал заметными (блок 12); переход к разработке от спецификации там, где это оправдано (блоки 03 и 06); расширение автономии агентов на задачи, где цена ошибки низкая, а проверка автоматическая; регулярная проверка моделей при обновлении; пересмотр карьерной лестницы и оценки инженеров (блок 13).
Последнее, что нужно сказать: этот курс написан на данных с 2023 по 2026 год. Приложения в блоке 15 я буду дополнять, но через год часть цифр в основном тексте устареет, а часть выводов, возможно, развернётся, как это уже случилось с DORA между 2024 и 2025 годами. Метод при этом не устареет: снимайте baseline, измеряйте, не доверяйте ощущениям, перестраивайте вместе с инструментами ещё и процессы.
Что говорят коллеги
Правильно, но в банке «переход по условиям» звучит для правления как «мы не знаем когда». Я бы оставил в плане даты, только назвал бы их «не раньше»: вторая волна не раньше дня 61 и только при выполненных условиях. Одно условие я бы ещё ужесточил: «ИБ без открытых замечаний» нельзя считать формальностью. В корпорации одно открытое замечание на второй волне останавливает сразу все команды, одной дело не ограничится.
У нас прошло почти так же, а споткнулись мы в одном месте: платформенную команду собрали только после пилота, поэтому первые 2 недели второй волны ушли на её запуск. Теперь я начинаю собирать её на фазе пилота, хотя бы одного человека, который пишет файлы контекста и ходит по командам. С командами я говорю живьём, одной панели мне мало: метрики не объясняют, почему так происходит.
Обсуждение:
Дизайн пилота
Это главный документ, с которым вы начнёте 90 дней. Возьмите состав группы из блока 13, baseline из блока 11 и бюджет из блока 04; полный шаблон есть в блоке 15. Скопируйте промпт в модель, которую разрешила ваша служба ИБ (ChatGPT, Claude, GigaChat, YandexGPT или другую). Модель задаст вопросы по одному и по ответам соберёт документ. Не вставляйте в ответы секреты, персональные данные и код из закрытых систем.
Промпт для документа
скопируйте в свою модельТы – технический директор, который уже запускал пилоты ИИ в разработке. Помоги мне составить «Дизайн пилота» на 90 дней. Первым делом спроси, есть ли у меня готовые документы: состав пилотной группы, baseline метрик, модель окупаемости. Если есть, попроси вставить их в чат и возьми данные оттуда; не переспрашивай то, что в них уже есть. Только после этого задай 4 вопроса о компании, по одному: сколько в ней инженеров; чем она занимается; есть ли жёсткие требования ИБ или регулятора; используете ли вы ИИ в разработке уже сейчас и как. Что нужно выяснить: - Цель: что изменится и на сколько, с числом. Метрика цели должна успеть измениться за срок сбора данных: если от постановки задачи до прода проходит больше месяца, за 6 недель изменения не увидеть – бери время от коммита до прода или отдельные этапы. Отдельно – какой результат будет полезен даже при неудаче. - Baseline: значения метрик за последние 3 месяца. Если baseline нет, спроси, можно ли выгрузить историю за 3 месяца из трекера задач, системы деплоя и баг-трекера: обычно это работа на несколько дней. Если истории нет, скажи прямо: пилот откладывается, сначала настраиваем сбор данных и копим их хотя бы месяц. Включи это в календарь и отметь в списке слабых мест, что сравнение с 1 месяцем слабее, чем с 3. - Группа: кто и сколько человек. - Сервис: какой и почему он типичный. - С каких задач начинаем: понимание кода, документация, тесты, миграции. И что точно не трогаем. - Инструмент: какой и где работает модель. - Бюджет на токены и предохранители: уведомление, остановка, лимит на сессию. - Срок: сколько недель подготовки и сколько недель сбора данных (не меньше 6). - Метрики, которые смотрим еженедельно. - Как отделим эффект ИИ от других изменений: контрольная группа, разнесение по времени или разбивка по этапам. Что ещё меняется за эти 90 дней (найм, новый процесс, автоматизация) и как это учтём. - Критерии успеха: при каких числах пилот удался. - Критерии остановки: при каких событиях или числах останавливаем пилот. Проверь, что критерии успеха и остановки сформулированы числами, а не словами «улучшится» или «не ухудшится». Напомни, что за 6 недель деплоев мало: 1 сбой сильно меняет долю сбойных изменений, поэтому критерии по ней задавай и в абсолютных числах. Правила работы: - Задавай по 1 вопросу за раз и жди моего ответа. - Если ответ размытый, попроси цифру или конкретный пример. - Если я не знаю ответа, предложи 2–3 варианта и коротко объясни разницу. Не придумывай данные за меня. - Если ответа нет и после вариантов, оставь поле пустым и иди дальше. На слово «собирай» собери документ из того, что есть. - Если новый ответ противоречит прежнему, скажи об этом и спроси, какой ответ верный. Если я не могу выбрать, запиши оба значения в список того, что осталось пустым или слабым. - Когда все вопросы закрыты, собери документ в формате ниже. После документа отдельным списком перечисли, что осталось пустым или слабым и как это закрыть. Формат документа: заголовок с датой «[дата]»; таблица «Поле | Содержание» со всеми пунктами выше; затем календарь подготовки на тот срок, который я назвал: «Дни | Что происходит | Результат».
ПримерЗаполненный дизайн пилота
Ниже образец для банка Даниила: 200 инженеров, пилотная группа на базе одной команды, типичный сервис. Это не идеал, а рабочий документ, который можно взять за основу и переписать под себя.
| Поле | Пример заполнения |
|---|---|
| Цель | Сократить время от коммита до продакшена на типичном сервисе на 15%: с 6 до 5,1 дня. Сбойных изменений за 6 недель – не больше, чем в baseline за такой же срок. Вторая цель: получить число – стоимость единицы поставки до и после. |
| Baseline | За июль–сентябрь: время от коммита до продакшена 6 дней (медиана); время от задачи до продакшена 34 дня (для справки: за 6 недель пилота его не измерить); 50 деплоев за квартал (около 23 за 6 недель); доля сбойных изменений 14% (7 из 50, около 3 за 6 недель); время ревью 3,1 дня, медиана пул-реквеста 650 строк, 8 дефектов на проде, расходы на команду 150 000 $ за квартал. |
| Группа | 9 человек: 2 энтузиаста, 5 средних инженеров, 1 скептик (тимлид смежной команды), 1 представитель ИБ. |
| Сервис | Сервис расчёта комиссий (fees-service): монолит на Java, 12 лет, покрытие тестами 41%, около 4 деплоев в неделю. Выбран как типичный, хотя удобнее был бы новый микросервис уведомлений. |
| С каких задач начинаем | Понимание кода модуля fees/, документация к нему, юнит-тесты для непокрытых классов. Не трогаем: формулы расчёта комиссий в core/FeeCalculator и всё, что идёт в регуляторную отчётность. Миграции – не раньше второго года. |
| Инструмент | Один агент в IDE, согласованный с ИБ. Модель отечественного поставщика по договору, данные хранятся и обрабатываются в России. Зарубежные модели запрещены политикой. Модель в контуре банка – после пилота, когда будет понятен расход. |
| Бюджет | 4 800 $ на квартал на токены (около 0,41 млн ₽): 8 активных участников × 200 $ в месяц × 3 месяца, ориентир из блока 04. Предохранители: уведомление при 70%, остановка агентных запусков при 100%, лимит на одну сессию 15 $. |
| Срок | 6 недель данных после 2 недель подготовки. Подготовка – дни 1–14, старт данных – день 15, условие перехода проверяется на день 57. |
| Метрики еженедельно | Время от коммита до продакшена, число и доля сбойных изменений, время ревью, расход токенов, доля инженеров с активным использованием. Одна панель, обновляется по понедельникам. |
| Как отделим эффект ИИ | Разнесение по времени: автоматизацию регресса и другие изменения процесса на fees-service до дня 57 не запускаем. Контрольной группы нет: соседние команды узнают о пилоте и перейдут на личные аккаунты (блок 11). Дополнительно – разбивка времени от коммита до продакшена по этапам: ревью, сборка, ожидание релиза. |
| Критерии успеха | 6 недель данных собраны. Время от коммита до продакшена снизилось не меньше чем на 10%, то есть до 5,4 дня или ниже (цель – 15%, 10% – минимальный порог, при котором переходим ко второй волне). Сбойных изменений за 6 недель не больше 3 из примерно 23 деплоев (в baseline – около 3 за такой же срок). Стоимость единицы поставки посчитана. У группы есть список из 5–10 изменений процесса. |
| Критерии остановки | ИБ выявила утечку данных к поставщику сверх разрешённого. За любые 2 недели подряд больше 3 сбойных изменений (в baseline – в среднем 1 за 2 недели). Расход токенов достиг 100% бюджета до конца пилота. Больше половины группы перестала пользоваться инструментом. |
ПримерКалендарь первых 2 недель (фаза 0)
Условия перехода важнее дат, но подготовку всё равно удобно расписать по дням. Так это выглядело бы у Даниила.
| Дни | Что происходит | Результат |
|---|---|---|
| 1–2 | Встреча с ИБ: условия согласования инструмента, кто участвует в пилоте от ИБ | Список требований ИБ, имя участника |
| 3–13 | ИБ проверяет инструмент по чек-листу из блока 15, параллельно с остальной подготовкой | Решение ИБ: инструмент идёт в пилот, с условиями или без |
| 2–5 | Сведение baseline за 3 месяца из трекера задач, системы деплоя и баг-трекера (выгрузки заказаны за месяц до старта квартала) | Таблица 5 метрик (обязательный минимум из блока 11) |
| 3–6 | Политика использования ИИ на 1 страницу, согласование с ИБ и юристами | Подписанная политика |
| 5–7 | Настройка лимитов и предохранителей на расход токенов | Лимит и уведомления работают, проверено тестовым превышением |
| 7–9 | Набор пилотной группы по правилам блока 13, разговор с каждым | Группа из 9 человек, в том числе скептик |
| 8–12 | Первый файл контекста для сервиса, набор из 10 эталонных задач для проверки инструмента | Файл контекста в репозитории, эталонные задачи прогнаны |
| 10–13 | Обучение группы на реальных задачах из бэклога, 2 занятия по 3 часа | Каждый участник закрыл одну задачу с инструментом |
| 14 | Проверка условий перехода к пилоту | Дизайн пилота подписан, панель метрик работает, сбор данных стартует на день 15 |
Если вы уже собрали baseline (блок 11) и модель окупаемости (блок 04), вставьте их в чат вместе с промптом: модель возьмёт цифры оттуда.
2 недели подготовки – реалистичный минимум, и большая их часть уходит на ИБ и выгрузку baseline. Само согласование инструмента занимает от 2 недель до квартала (блок 05), поэтому начинайте его до старта квартала. Если ИБ не успела к дню 14, фаза 0 продлевается: без согласованного инструмента пилот не стартует. Даты для совета называйте только для фазы 0 и пилота, дату масштабирования – после условий перехода.
подготовка занимает 3–5 дней: политика пишется за вечер, baseline – за полдня, лимит на токены ставится в настройках поставщика. Фазы и условия перехода остаются теми же, календарь просто короче, а «вторая волна» – это вторая команда или второй сервис.
Как собрать набор эталонных задач. Набор нужен, чтобы сравнить кандидатов при выборе инструмента и потом ловить просадку после обновления модели (блок 03).
- Откуда брать: 10 закрытых задач с пилотного сервиса за последние 3–6 месяцев. Берите те типы, что пойдут в первую волну (блок 07): мелкие дефекты, типовые доработки, тесты, документация. Не берите задачи с секретами и персональными данными.
- Что записать по каждой: постановку из трекера, коммит, с которого начинали, и принятое решение с тестами. Правильный результат – то, что смержили, и тесты, которые оно проходит.
- Кто собирает и проверяет: сеньор из пилотной группы отбирает задачи. Второй человек проверяет, что постановка понятна без устных пояснений.
- Сколько времени: ориентир – 4–6 часов на 10 задач у одного человека, плюс прогон.
- Как прогонять: каждую задачу даёте инструменту с той же постановкой и записываете: прошли ли тесты, сколько правок понадобилось. Это точка отсчёта.
- Как поддерживать: прогон после каждой смены модели или версии инструмента. Раз в месяц добавляйте 1–2 новые задачи и убирайте устаревшие. У Марии за год набор вырос до 40 задач (блок 03).
Вы прожили квартал по условиям вместо календаря. Это правильный ответ, хотя Мария права в том, что платформенную команду стоит начинать собирать раньше. Главное из блока: через 90 дней внедрение только начинается, а метод остаётся тем же (baseline, измерения, перестройка процессов). Соберите документ по промпту: с дизайном пилота вы начнёте свой первый день. План этих 90 дней можно перенести в AISuppy задачами со сроками – на сайте или в боте курса.
Дальше блок 15 «Шаблоны и приложения»: Здесь собраны рабочие документы, на которые ссылается курс.