Рабочие шаблоны внедрения

Этот документ объясняет применение форм. Полный каталог определяет, что копировать на Подготовке, а что создавать позднее. Заполненные формы хранятся в Git внедрения; существующие задачи и решения подключаются ссылками. Все даты и времена ведутся с согласованным часовым поясом.

Отдельная форма: Журнал Пилота — итоги недели и бэклог следующей. Гайды и примеры перечислены в этапе Подготовка.

Для планирования проверок: реестр тестов и план развития.

Общая форма для требований, спецификаций, тест-кейсов и автотестов: реестр артефактов проекта, оценка полноты и план развития. Как организовать требования — в гайде и примере. Детальный реестр тестов связан с общей формой; дублировать задачи плана не нужно.

Паспорт внедрения

Шаблон паспорта проекта · Заполненный пример · Гайд по заполнению.

Паспорт фиксирует цель и область внедрения, сроки, условия участия команды, порядок решений и правила оценки результата. Заполняется короткими пунктами в Git материалов внедрения; подробные рабочие правила подключаются ссылками.

Назначения людей — в «Команде проекта». План этапов и гейтов — в общем плане работ. Фактические результаты — в журнале PoC и журнале Пилота. Подтверждения готовности — в чек-листе PoC и чек-листе Пилота.

Организация участия команды

Назначения заполняются в «Команде проекта», встречи — в календаре паспорта. Отдельные регламенты времени участия, сроков реакции и замещений не требуются; привлечение и замену людей организует РП.

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

Для проекта заполняется короткий документ «Команда проекта»: только назначения «роль — имя», отдельно для клиента и сопровождения. Пример заполнения.

Состав и смысл ролей описаны в методологии, момент подключения — в гайде участия по периодам. При совмещении имя повторяется у соответствующих ролей; при нескольких исполнителях перечисляются все имена. Для незакрытой роли указывается «не назначен». Проверяется охват функций, необходимых ближайшим работам; к Пилоту — всего выбранного потока, включая ревью, тестирование, продуктовую приёмку, merge и выпуск. Для будущего назначения указываются ответственный РП и срок в плане/трекере.

Профиль потока задач

Краткое описание выбранного потока. Если сведения уже есть в паспорте и процессах, достаточно ссылок на них; отдельная копия не обязательна.

Шаблон · Пример.

Изменение режима проверки

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

Шаблон · Пример.

Передача обязанностей ИИ-инженера

Шаблон журнала передачи · Пример · Общий гайд инженера.

Типовой сценарий обучения приведён в общем гайде. Отдельный план передачи необязателен: в журнал записывают совместную работу, её результат и фактические изменения обязанностей. Этот раздел можно вести в недельном журнале, без второго документа. Если проекту нужен план, он составляется под его условия; передача не является новым гейтом внедрения.

Общий план работ

Шаблон плана · Заполненный пример.

Это верхнеуровневый план проекта внедрения ИИ в разработку ПО: Подготовка → GATE-01 → три фазы PoC → GATE-02 → Пилот с вехами конкретного проекта → GATE-03. РП внедрения ведёт и актуализирует план; РП клиента подтверждает обязательства, сроки и зависимости своей команды. Изменения рассматриваются на общих встречах. План показывает ожидаемые результаты этапов, даты и основания решений о переходах.

Подготовка представлена одной строкой: её направления выполняются параллельно, а готовность проверяется по обязательным результатам. PoC состоит из трёх заданных фаз. Вехи Пилота выбираются под цели клиента и могут быть связаны с развитием инструментов, артефактов или продукта. Универсальной последовательности вех Пилота методология не задаёт.

Связь с другими документами

Как заполнить

1. Указать даты Подготовки и PoC, предварительные границы Пилота и даты GATE-01–03. Для фаз PoC использовать: неделя 1 — онбординг, неделя 2 — простые задачи, недели 3–4 — целевые задачи.
2. Для Подготовки заполнить чек-лист обязательных результатов ниже. Сведения, исполнители и подтверждения ведутся в отдельных документах Подготовки; общий план сохраняет одну строку этапа.
3. Заменить роли в скелете именами ответственных за результат этапа или вехи и указать участников решения. Ответственный координирует получение результата, а не выполняет всё лично.
4. Выбрать вехи Пилота из целей проекта, продуктового плана и планов развития. Для каждой указать проверяемый результат, источник, ответственного и дату. Если вехи пока не определены, сохранить эту отметку, назначить ответственного и дату их определения; не придумывать универсальные фазы.
5. По результатам недельных разборов обновлять прогноз дат и достижения вех. Изменение цели, состава вех или срока фиксировать с основанием. Регулярные действия и их выполнение записывать в журнал.

Для этапов и вех фиксируются состояние, фактическая дата и ссылка на результат; для гейтов — решение, его основания и дальнейшие действия. Наступление даты само по себе не означает готовности к переходу.

Изменение охвата, процесса или режима проверки в плане

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

В записи различаются дата рассмотрения и предполагаемая дата введения. К рассмотрению РП собирает подтверждения, варианты и позиции владельцев продукта, технических решений и качества. Для введения нужны записанное решение, выполненные условия, обновлённые инструкции и настройки. Если решение не принято или условия не выполнены, прежний режим сохраняется; в плане отмечаются результат рассмотрения и следующий шаг.

Даты, ответственный и проверяемый результат относятся к вехе. Время обсуждения и состав встречи берутся из календаря паспорта; конкретные подготовительные действия — из недельного журнала и связанных задач. Не каждое обсуждение на статусе становится вехой: сюда включаются значимые изменения условий внедрения. Форма записи и пример находятся по ссылкам выше; критерии изменения ревью — в регламенте.

Обязательные результаты Подготовки

До начала PoC должны быть получены условия онбординга и минимального прохода выбранной области:

• Подготовлены цели, область и ожидаемый эффект; состав команды и ответственные за необходимые работы назначены, полномочия конкретных операций отражены в процессах.
• Заполнены постановки первых задач, критерии результата и способ приёмки; определены типы задач будущего Пилота, план кейсов трёх фаз PoC и их календарь.
• Подготовлен контекст проекта: архитектура, зависимости, правила и индекс доступных требований, спецификаций и тестов; пробелы и дальнейшее развитие зафиксированы.
• Проверены доступы агента к репозиториям и другим системам первых задач, включая сеть, аккаунты и нужные операции; необходимым участникам предоставлен и проверен доступ к оркестратору.
• Подключены и проверены обязательные основная text-to-text и зрение; допустима одна модель. В реестре всех пяти назначений явно указаны замена лёгкой основной либо отдельное подключение, использование TTS/STT для видеороликов либо отказ от них с причиной. Для используемых моделей определены on-premises / облако поставщика и поставщик; решения подтверждены, необходимые позднее подключения имеют сроки.
• Готовы DEV, деплой, данные и зависимости первых задач; описаны работа с БД и восстановление. Определён порядок приёмки; если первой приёмке нужна UAT, проверены её готовность и диагностический доступ агента.
• Собраны исходные правила статусной модели задач, Git/MR и ревью; отдельно — маршрут агента с допуском, HITL, доработками и передачей человеку. Платформа работает, доступно рабочее место ИИ-инженера; проверены его доступы и интеграции платформы. Указаны каталог исходных материалов, Git материалов внедрения и репозиторий литературы проекта. Адаптация агентов и навыков в MR выполняется на неделе 1 PoC.
• Подготовлены сценарии проверки первых задач и план измерений: границы, источники, исходная база, владельцы сбора и сроки готовности к Пилоту.

Полный перечень проверок и доказательств — START-01–23. Перечень выше группирует эти условия, а не создаёт второй чек-лист. Для неприменимого условия сохраняется основание. Полные требования, готовый набор автотестов, автоматические миграции и весь пул сред не обязательны для старта: нужны условия первых задач и ответственные со сроками для остального, до зависимых сценариев.

Скелет плана внедрения

Скопировать отдельный шаблон плана; заполненный пример показывает этапы, гейты и проектные вехи. Шаблон сохраняет одну строку Подготовки, три фазы PoC и вехи Пилота без недельных повторяющихся работ.

GATE-01 проверяется по готовности к PoC, GATE-02 — по готовности к Пилоту. GATE-03 опирается на итоги Пилота: достигнутые целевые метрики либо поддержанный всей рабочей командой и стейкхолдером план их достижения. Инженерное сопровождение может продолжаться.

Как выбирать вехи Пилота

Веха — значимый проверяемый результат, а не очередная неделя или встреча. Например:

Это примеры для выбора, а не обязательный набор или порядок. Вехи могут достигаться параллельно; Пилот не делится ими на универсальные фазы. Работы по развитию могут начинаться ещё на PoC. Достижение отдельной вехи не подменяет критерии завершения Пилота.

Обязанности и участие

Регулярные обязанности берутся из гайдов ролей, назначения — из «Команды проекта», проектные уточнения — из паспорта внедрения. Отдельная личная карточка не заполняется.

Регулярные обязанности

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

Личный план внедрения

Разовое поручение фиксируется в плане, трекере или журнале этапа: исполнитель, ожидаемый результат, срок и получатель. В остальных документах достаточно ссылки на эту запись.

Фактические результаты

Факт выполнения собирается в журнале этапа из задач, MR, сообщений и отчётов. Указываются результат и доказательство, своевременность, помощь или замена исполнителя, остаток. При недостатке данных требуется уточнение; отсутствие подтверждения не означает выполнение.

Сводные показатели внедрения

Подробную методическую форму учёта отдельных задач пока откладываем. Существующие карточки и журналы систем остаются источниками; заново вести их в Markdown не требуется.

• На PoC — каталог проверенных кейсов: техническая работоспособность, качество содержания, доказательства и повторные проверки.
• На Пилоте — сводки недельных когорт: объём в идеальных часах, TTM, оценка экономии, медианы этапов и контекст исходов/качества/затрат. Набор выбирается в коротком шаблоне (пример); алгоритмы — в навыке сбора, который настраивает ИИ-инженер сопровождения.
• У каждой сводки — период, версия правил, источник и ограничения полноты данных.
• Общие затраты внедрения показываются отдельно, без повторного учёта затрат задач.

Разбор прогресса

При необходимости разбора участия использовать отдельную запись или раздел журнала этапа. Не создавать второй параллельный учёт.

Шаблон · Пример.

Протокол перехода или завершения

Решение обычно записывается в чек-листе или журнале этапа. Эта форма нужна только для отдельного протокола, если его требует проект.

Шаблон · Пример.

План достижения целевых метрик

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

Шаблон · Пример.

Запись об адаптации

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