Журнал PoC: проверенные возможности и качество результатов
PoC проверяет, может ли агент выполнить нужные действия в проекте и получается ли результат нужного качества. Статистические показатели эффективности Пилота здесь не требуются: несколько калибровочных задач не дают сопоставимой выборки.
Журнал состоит из накопительного чек-листа кейсов и коротких недельных записей. Единица проверки — возможность или сценарий, а не карточка продуктовой задачи. Для одного кейса можно использовать несколько задач; одна задача может проверить несколько кейсов. Доказательства связывают конкретную проверку с записями выполнения в журналах платформы и результатами в существующих системах.
ИИ-инженер предоставляет технические результаты и доказательства кейсов, РП клиента — факты и обязательства клиентской команды. РП внедрения организует ведение журнала, готовит общий отчёт/презентацию и материалы к контрольным точкам.
Контекст и правила проверки
Схема выполнения и её версия: размещение, Git, трекер и среды … . Для временных систем и копии кода указать ограничения подтверждений. При изменении схемы отмечать, какие кейсы проверены повторно и какие сохраняют доказательства прежнего контура.
- Проект, область, охват агента: …
- Неделя и фаза PoC: … Период: …
- ИИ-инженер сопровождения / участники клиента / кто проверяет содержание: …
- Готовность к PoC, план фазы и существенные изменения области: …
Для каждого кейса отдельно фиксируются: - Техника: действие действительно выполнено в нужной системе, с корректными правами, данными, связями и состояниями. - Качество: содержание правильно, полно для цели, понятно получателю, соответствует правилам команды и позволяет действовать. - Доказательство: запись фактической проверки по формату ниже; для действий агентов обязательны идентификаторы выполнения и событий в журналах платформы в ClickHouse, а также ссылки на полученный результат; дата и проверивший.
Статусы каждой оси: Не проверено / Пройдено / Не пройдено / Неприменимо. Кейс подтверждён, когда обе применимые оси пройдены и представлены требуемые доказательства. Успешный вызов API не подтверждает качество написанного текста. Если сценарий не случился естественно, используется согласованное калибровочное задание в чате с реальным выполнением агентами; искусственные замечания не выдаются за продуктовые дефекты.
При отсутствии сформулированных правил кодирования их соблюдение отмечается как «Неприменимо: правил нет», а отсутствие правил фиксируется в плане. Корректность и понятность кода всё равно проверяются. Для неприменимой возможности указываются причина и согласовавший; существенная возможность выбранного потока не исключается только потому, что пока не работает.
Что считается настоящим прогоном
Функция агента считается проверенной, только если агенты фактически использовали её при решении калибровочной задачи или выполнении калибровочного задания, поставленного в чате. Проверяется заявленный сценарий целиком: вход, действия и результат. Отдельное задание может проверять одну функцию без полного цикла разработки.
Наличие навыка, чтение его текста, ручной вызов API инженером, готовый артефакт неизвестного происхождения или ответ агента «умею это делать» не заменяют прогон. Сообщение агента об успехе сопоставляется с записями выполнения и фактическим результатом. При запуске агентом CI, тестов или деплоя фиксируется связь вызова агента с конкретным внешним выполнением и его итогом.
Условия сценария должны возникнуть в проверке: для обработки замечания нужно предъявить замечание и получить исправление; для проверки отказа — вызвать отказ; для параллельной работы — выполнить перекрывающиеся по времени запуски и проверить изоляцию. Наличие настройки само по себе эти кейсы не закрывает. Учебные входные данные и специально созданные ситуации допустимы и помечаются как калибровочные; действия агентов при этом выполняются на самом деле.
Способы подтверждения кейсов
| Вид проверки | Применение к каталогу | Требуемые подтверждения |
|---|---|---|
| Агентская | По умолчанию все кейсы, кроме перечисленных ниже | Настоящий прогон, записи агента в ClickHouse, фактический результат и оценка его качества |
| Совместная: агенты и люди | COM-10, AN-03, DEV-03, DEV-08–10, QA-10, FLOW-01–05, FLOW-09–10, FLOW-13 — в части предусмотренного участия человека | Настоящий прогон агентской части плюс подтверждения действий людей: ответ, ревью, приёмка, исполнение HITL, изменение литературы или другое действие по кейсу. Кто выполнил каждый шаг, указано явно |
| Действия людей | FLOW-08: участники работают в оркестраторе под своими аккаунтами | Фактические операции участников, аккаунт и проект, время, результат и записи аудита оркестратора либо другие проверяемые следы в системе. Агентский запуск не требуется для действия, которое выполняет человек |
Для DEV-03 и DEV-10 различаются автоматические операции и предусмотренный процессом HITL: ручное применение миграции или сброс среды подтверждают совместный сценарий, но не автономное выполнение этих шагов агентом. Для FLOW-05 и FLOW-13 нужны исходный и повторный прогоны агентов, изменение литературы, навыка или данных и оценка результата; один diff не подтверждает улучшение. Для FLOW-06 и FLOW-12 нужен настоящий запуск агента со сбором данных и проверкой полученной сводки; ручной расчёт может служить эталоном, но не заменяет запуск.
Проверка качества результата человеком нужна и для агентских кейсов. Она не заменяется записью об успешном завершении агента и сама по себе не требует агентского запуска. Для новых кейсов вид проверки выбирается по фактическому составу действий; агентские шаги нельзя перевести в ручные только ради отметки «Пройдено».
Запись фактической проверки
Запись добавляется после каждой попытки. В колонке «Доказательство» каталога указывается её ID или ссылка; одна запись может подтверждать несколько кейсов, если для каждого указаны соответствующие события и результат.
- Проверка и кейсы: ID записи …; ID кейсов и проверяемые условия …; вид проверки … .
- Основание: ссылка/ID калибровочной задачи либо чата и сообщения с калибровочным заданием …; ожидаемый результат … .
- Контекст: проект и контур платформы …; время начала и окончания с часовым поясом …; версии агентов, литературы и настроек …; ревизии кода/тестов и среда, если применимы … .
- След выполнения в ClickHouse: идентификатор запуска/выполнения …; агентские сессии или дочерние запуски …; идентификаторы событий либо точный фильтр, выделяющий события проверяемого действия … .
- Как найти записи: источник журналов (база/таблица, представление или сохранённый поиск) …; ссылка на просмотр либо запрос/набор фильтров с указанными значениями … . Секреты и учётные данные сюда не записываются.
- Результат: ссылки/ID созданных сообщений, документов, MR, коммитов, pipeline, прогонов тестов, артефактов и деплоя по применимости …; ожидаемое и фактическое поведение … .
- Участие людей: кто, какое действие выполнил, где подтверждение …; для чисто человеческого кейса — аудит/следы вместо агентского запуска … .
- Оценка: техника …; качество …; проверивший и дата …; замечания и следующая попытка … .
Названия идентификаторов и полей определяются фактической схемой журналов установленной версии платформы. ИИ-инженер настраивает поиск так, чтобы по записи можно было однозначно найти соответствующее выполнение и действия, включая дочерних агентов. Одного номера задачи или приблизительного времени недостаточно. Если у событий нет отдельных ID, сохраняются идентификатор выполнения и точные фильтры, позволяющие найти нужные записи.
Если выполнение заявлено, но подтверждающие записи не найдены, техническая проверка остаётся «Не проверено» с указанием пробела. Это не основание для «Неприменимо». Обнаруженное нарушение ожидаемого поведения отмечается «Не пройдено». Если срок хранения журналов ограничен, сохраняется необходимая выгрузка подтверждающих записей с исходными идентификаторами и запросом отбора; она также связывается с записью проверки. Повторные попытки не затирают предыдущие результаты.
Накопительный чек-лист кейсов
Кейсы ниже — начальный каталог. Команда уточняет их до проверки; дополнительные сценарии добавляются с ID. В последней колонке для непройденного кейса указывается исправление, ответственный, срок и повторная проверка. После изменения настроек сохраняется история предыдущего результата.
Трекер, Git и коммуникация
| ID | Кейс и ожидаемое качество | Техника | Качество | Доказательство, проверивший / следующий шаг |
|---|---|---|---|---|
| COM-01 | Агент берёт нужную задачу из трекера, читает описание, вложения, ссылки и ограничения без потери существенного контекста | Не проверено | Не проверено | … |
| COM-02 | Создаёт задачу в правильном проекте: ясные цель, объём, критерии и связи; не создаёт дубликаты | Не проверено | Не проверено | … |
| COM-03 | Пишет комментарий к задаче: факт работы, результат, блокировка или конкретный вопрос; без выдуманных действий и лишнего шума | Не проверено | Не проверено | … |
| COM-04 | Создаёт ветку и MR с верной базой и ссылками; описание объясняет изменение, проверки и ограничения | Не проверено | Не проверено | … |
| COM-05 | Пишет комментарии к MR/строкам кода в нужное место; формулировки конкретны, аргументированы и понятны | Не проверено | Не проверено | … |
| COM-06 | Читает и обрабатывает замечание в трекере: понимает смысл, делает нужное действие, сообщает проверенный результат | Не проверено | Не проверено | … |
| COM-07 | Читает замечания в Git/MR, исправляет, повторно проверяет и отвечает по существу; не закрывает обсуждение без основания | Не проверено | Не проверено | … |
| COM-08 | Обрабатывает вопрос/упоминание в чате, использует контекст и отвечает адресату; при нехватке данных уточняет | Не проверено | Не проверено | … |
| COM-09 | Обнаруживает противоречащие поручения и дубли сообщений; уточняет приоритет, не выполняет одно действие повторно | Не проверено | Не проверено | … |
| COM-10 | Запрашивает реакцию нужного человека с понятным действием и ссылкой; получение содержательного ответа фиксируется | Не проверено | Не проверено | … |
| COM-11 | Получает из чата поручение со ссылкой на задачу, запускает её выполнение и сообщает итог со ссылками на MR, DEV и проверки; задача, адресат и фактический результат определены верно | Не проверено | Не проверено | Сообщение → запуск → итоговый ответ; без проверки цикла замечаний |
Аналитика и требования
| ID | Кейс и ожидаемое качество | Техника | Качество | Доказательство, проверивший / следующий шаг |
|---|---|---|---|---|
| AN-01 | Находит действующие требования, спецификации и контракты; различает целевое поведение и наблюдение из кода | Не проверено | Не проверено | … |
| AN-02 | Разбирает задачу: цель, границы, данные, основные и ошибочные сценарии, критерии результата | Не проверено | Не проверено | … |
| AN-03 | Задаёт уточняющие вопросы, обрабатывает ответы, фиксирует решения; неподтверждённое не выдаёт за согласованное | Не проверено | Не проверено | … |
| AN-04 | Создаёт или дополняет требования и спецификации в принятом источнике: текст точен, непротиворечив, проверяем и связан с задачей | Не проверено | Не проверено | … |
| AN-05 | Учитывает права, состояния, границы данных, интеграции, время и исключения по применимости | Не проверено | Не проверено | … |
| AN-06 | Оценивает влияние изменения на соседние правила, контракты и проверки; выделяет новый объём и открытые вопросы | Не проверено | Не проверено | … |
| AN-07 | Предлагает ограниченную итерацию и понятные задачи; сохраняет связь с исходной потребностью | Не проверено | Не проверено | … |
Разработка и инфраструктура
| ID | Кейс и ожидаемое качество | Техника | Качество | Доказательство, проверивший / следующий шаг |
|---|---|---|---|---|
| DEV-01 | Изменяет и собирает код; реализация соответствует согласованному поведению и не содержит посторонних изменений | Не проверено | Не проверено | … |
| DEV-02 | Учитывает сформулированные правила кодирования, архитектурные ограничения и принятые паттерны | Не проверено | Не проверено | … |
| DEV-03 | Готовит версионированное изменение БД и проверяет применение на поддерживаемой предыдущей версии с данными: преобразование, сохранность и совместимость. Применение автоматическое либо через предусмотренный HITL с подтверждением исполнителя; проверен порядок восстановления при сбое | Не проверено | Не проверено | Исходная/целевая схема, скрипт или миграция, данные, результат и фактический способ применения |
| DEV-04 | Изменяет API/интеграцию с учётом контрактов, ошибок, повторов и совместимости | Не проверено | Не проверено | … |
| DEV-05 | Читает ошибку сборки/CI/логов, выявляет причину, исправляет и предъявляет повторную проверку | Не проверено | Не проверено | … |
| DEV-06 | Независимо развёртывает выбранную ревизию задачи без предварительного включения в общую интеграционную ветку: публикация артефакта и деплой по ID; при служебных ветках проверены переназначение, точный SHA и защита от устаревшего pipeline | Не проверено | Не проверено | Версия, конфигурация, резервирование среды, pipeline и результат; выбранный способ деплоя |
| DEV-07 | Выполняет параллельные задачи в независимых DEV; данные, моки и время не влияют на соседнюю работу | Не проверено | Не проверено | ID запусков и событий, перекрывающиеся интервалы выполнения, среды и результаты проверки изоляции |
| DEV-08 | Получает доступ к фактической UAT, воспроизводит замечание; согласованные операции выполняет без срыва приёмки | Не проверено | Не проверено | … |
| DEV-09 | Вносит исправление после замечания без потери уже принятого поведения; доводит результат до согласованной интеграции | Не проверено | Не проверено | … |
| DEV-10 | При смене задачи с несовместимой историей миграций восстанавливает совместимый исходный комплект, применяет изменения новой ревизии и загружает её данные. Повтор подготовки даёт заданное состояние; соседние среды не меняются. Для UAT соблюдены права и разрешение на изменение | Не проверено | Не проверено | Среда/БД, исходный комплект, SHA/артефакт, итоговая схема и данные, проверки, исполнитель; ручные шаги отмечены явно |
Тестирование и приёмка
| ID | Кейс и ожидаемое качество | Техника | Качество | Доказательство, проверивший / следующий шаг |
|---|---|---|---|---|
| QA-01 | Формирует тест-кейсы, данные и ожидаемые результаты по правилам; покрывает позитивные, граничные и негативные случаи | Не проверено | Не проверено | … |
| QA-02 | Создаёт/меняет и запускает unit-тесты без стенда; утверждения проверяют смысл, тест выявляет нужную ошибку | Не проверено | Не проверено | … |
| QA-03 | Создаёт/меняет и запускает API-, интеграционные и контрактные проверки по применимости; зависимости и данные изолированы | Не проверено | Не проверено | … |
| QA-04 | Создаёт/меняет и запускает UI-проверки; действия, ожидания и диагностика устойчивы и соответствуют сценарию | Не проверено | Не проверено | … |
| QA-05 | Управляет моками ошибок и задержек; проверяет восстановление, а не только появление сообщения | Не проверено | Не проверено | … |
| QA-06 | Проверяет регулярные операции и таймеры без длительного ожидания; учитывает условия срабатывания и побочные эффекты | Не проверено | Не проверено | … |
| QA-07 | Выполняет smoke и затронутую регрессию; объясняет выбор проверок, пропуски и ограничения | Не проверено | Не проверено | … |
| QA-08 | Разбирает упавший тест, различает дефект продукта, теста и среды; не ослабляет ожидание ради успешного прогона | Не проверено | Не проверено | … |
| QA-09 | Обрабатывает замечания к автотестам, правит сценарий/код и предъявляет повторный результат | Не проверено | Не проверено | … |
| QA-10 | Обрабатывает результат тестирования человеком, воспроизводит дефект, исправляет и отвечает с доказательством | Не проверено | Не проверено | … |
| QA-11 | Пишет отчёт о проверке с версиями, данными, ожидаемым/фактическим результатом и ограничениями; человек может принять решение | Не проверено | Не проверено | … |
| QA-12 | Выполняет специальные проверки по рискам (миграции, нагрузка, безопасность и другие) в согласованном контуре | Не проверено | Не проверено | Разделить на отдельные кейсы по применимости |
Полный цикл, сопровождение и измерения
| ID | Кейс и ожидаемое качество | Техника | Качество | Доказательство, проверивший / следующий шаг |
|---|---|---|---|---|
| FLOW-01 | Простой случай проходит путь от задачи до интеграции, ревью и продуктовая приёмка выполнены нужными людьми | Не проверено | Не проверено | … |
| FLOW-02 | При наличии в выбранном потоке случая с несколькими связанными изменениями проходит полный цикл без потери связей | Не проверено | Не проверено | По применимости на неделях 2–4; это умение, а не отдельная фаза PoC |
| FLOW-03 | Типичный случай будущего Пилота проходит весь выбранный охват, включая аналитику при её наличии | Не проверено | Не проверено | … |
| FLOW-04 | При отсутствии прогресса вовремя запрашивается помощь или оформляется передача человеку; тексты объясняют причину и оставшуюся работу | Не проверено | Не проверено | … |
| FLOW-05 | Инженер находит повторную проблему по журналам, меняет инструкции/навыки и подтверждает улучшение на повторном кейсе | Не проверено | Не проверено | Записи исходных и повторного прогонов в ClickHouse, изменение и версии литературы/навыков, оценка улучшения |
| FLOW-06 | По описанию процесса и плану мониторинга проверен суточный сбор агентом за прошлый день либо заданные даты, по расписанию или просьбой; повтор и догрузка пропущенного дня не создают дублей. Проверен навык сборки выбранных показателей: передача готовых требований и когорта, идеальные оценки и автоматическая оценка трудозатрат людей по артефактам (основания, диапазоны, дубли, пробелы и список аномалий для РП), TTM, экономия, медианы этапов, исходы, замечания, токены и ожидание реакции; указаны пропуски данных | Не проверено | Не проверено | Пробный расчёт реально выполнен агентом: записи запуска в ClickHouse, источники, сводка и сверка с ожидаемым результатом; статистика эффекта не требуется |
| FLOW-07 | Агент в новой задаче находит и применяет подготовленные навыки и/или сохранённые заметки: выполняет предусмотренные действия и проверки без повторного пересказа инструкций; содержание соответствует подтверждённым правилам проекта | Не проверено | Не проверено | Версии материалов, выполненный кейс, результат и замечания к инструкциям |
| FLOW-08 | Участники используют оркестратор под своими аккаунтами в нужном проекте: выполняют действия по обязанностям, получают и передают требуемый результат | Не проверено | Не проверено | По участникам: аккаунт, проект, фактическая операция, время, аудит/проверяемые следы и результат; реестр выданных доступов сам по себе не подтверждает выполнение |
| FLOW-09 | Агент следует связанным процессу задач и маршруту: получает готовую задачу через выбранный чат и/или статус трекера, не создаёт повторный запуск, меняет разрешённые поля, соблюдает HITL, паузы и возобновление; возвраты, передача и ошибки не теряют историю | Не проверено | Не проверено | Процесс задачи, записи переходов, запросов/ответов; техническая корректность и содержание |
| FLOW-10 | Агент следует Git-процессу: рабочая ветка и цель MR верны, маршрут ревью соблюдён, замечания обработаны, проверки повторены для изменённой версии, merge выполняется с нужными подтверждениями и полномочиями | Не проверено | Не проверено | Git-процесс, ветка/MR, коммиты, проверки, ревью и интеграция |
| FLOW-11 | Минимальный путь онбординга пройден на подключённой версии проектной литературы: сообщение в чате → чтение задачи → решение в feature-ветке → проверки → сборка и публикация артефакта → деплой на DEV → MR и итоговый ответ | Не проверено | Не проверено | Ссылки на MR литературы и MR кода, ревизии, запуск, деплой и результаты; без обязательных замечаний, приёмки и merge |
| FLOW-12 | Агент внедрения собирает по материалам проекта сводку выполнения плана и чек-листов, выделяет пробелы и готовит черновик материалов к статусу; факты подтверждены ссылками, неподтверждённое отмечено явно | Не проверено | Не проверено | Версия агента/навыков, источники и результат запуска, замечания проверившего |
| FLOW-13 | По замечанию РП к оценкам ИИ-инженер исправляет данные или правила агента внедрения и проверяет повторный расчёт на исходных и других известных примерах; причины поправок и версии сохранены | Не проверено | Не проверено | Исходный и повторные запуски агента с записями в ClickHouse, пояснение РП, изменение и оценка результата; учебный пример также исполняется агентом |
Минимальный набор онбординга: неделя 1
Процедура и критерии завершения — в гайде онбординга. Обязательное подмножество каталога: COM-01, COM-04, COM-11, DEV-01, DEV-02, DEV-06, QA-07, QA-11, FLOW-07, объединённое итоговым FLOW-11.
По каждому ID используются две оценки из таблиц выше: техника и качество содержания/результата, со ссылками на доказательства. Специальные условия внутри кейса проверяются по применимости к выбранной схеме; универсальный минимум не исключается из-за неработающего подключения. Уже имеющиеся правила проекта должны быть применены; если дополнительных правил кодирования нет, DEV-02 может иметь обоснованную неприменимость по общим правилам журнала.
COM-06–07 и другие кейсы замечаний, расширенного HITL, ревью, приёмки и интеграции не требуются для завершения недели 1. Их планируют на недели 2–4 по выбранному потоку. Частично проверенный широкий кейс не отмечается полностью пройденным: минимальный вход из чата фиксируется в COM-11, а полный набор ситуаций COM-08 проверяется отдельно.
Сводка онбординга: версия каталог исходных материалов …; Git материалов внедрения …; MR и подключённая ревизия литературы …; сообщение/задача …; запись фактической проверки с ID выполнения и поиском событий в ClickHouse …; MR кода …; ID артефакта и запись деплоя …; результат FLOW-11 …; проверившие и дата …; остаток на неделю 2 … .
Параллельная работа первой недели — создание агента внедрения: версия …; результат первого запуска …; оставшиеся настройки … . Проверки FLOW-06, FLOW-12 и FLOW-13 выполняются в течение PoC и не расширяют минимальный путь FLOW-11.
Недельная сводка PoC
Считать по кейсам, а не по задачам. Повторный прогон одного кейса не увеличивает число возможностей. Каталог и применимость имеют версию; новый кейс меняет знаменатель явно.
| Область | Применимых кейсов | Техника пройдена | Качество пройдено | Обе оси пройдены | Ещё не проверено / не пройдено | Что подтвердили на этой неделе |
|---|---|---|---|---|---|---|
| Коммуникации | … | … | … | … | … | ID кейсов |
| Аналитика | … | … | … | … | … | … |
| Разработка и инфраструктура | … | … | … | … | … | … |
| Тестирование | … | … | … | … | … | … |
| Полный цикл и сопровождение | … | … | … | … | … | … |
Счётчики по осям пересекаются и не складываются. Общий процент не компенсирует критический непройденный кейс. Для текущей фазы отдельно указать нужные ей кейсы, блокеры и повторные проверки.
Качество текстов проверяется по смыслу: правильный адресат и контекст; факты подтверждены; вопрос или следующий шаг понятен; существенные ограничения не скрыты; терминология и тон приняты командой. Проверяющий — аналитик/владелец продукта, разработчик или тестировщик по предметной области.
Контрольные точки фаз
| Когда | Что подтвердить | Решение, основание и следующий шаг |
|---|---|---|
| Конец недели 1 | Завершён онбординг: подключена проектная литература, минимальное подмножество и FLOW-11 подтверждены по технике и качеству. Замечания, приёмка и merge не входят в минимум | MR литературы, MR кода, доказательства минимального пути; решение и остаток … |
| Конец недели 2 | Простой полный цикл повторён, проверены замечания и исправления, ревью и интеграция; повторные проблемы разобраны, готов контур целевых задач | … |
| Конец недели 4 | Пройдены целевые задачи Пилота; собраны доказательства по применимым возможностям; заполнена готовность к Пилоту | Ссылка на чек-лист |
Решение не принимается только по календарю. Если сценарий не работал, фиксируются исправление и повторная проверка; если изменён охват — основание и влияние на будущий Пилот.
Люди и план следующей недели
Инженерная работа: записи о совместных действиях, результатах и фактической передаче обязанностей — здесь или в журнале передачи …; подготовка инженерного отчёта к статусу — кто …, срок …, ссылка … . Передача клиенту может начаться позже в течение Пилота; календарный план необязателен.
Журнал одновременно служит планом и фактом ритмичной работы. До начала недели заполняются ожидаемые действия, исполнители и сроки; по мере выполнения в тех же строках добавляются результат и отклонения. В общем плане внедрения сохраняются этапы и вехи.
| Регулярная работа | План: результат и дата / периодичность | Ответственный | Факт: дата и ссылка на результат | Отклонение / следующее действие |
|---|---|---|---|---|
| Ежедневная сверка | … | … | Решения и изменения обязательств; можно одной сводкой за неделю | … |
| Подготовка отчёта и статус | Публикация отчёта …; встреча … | … | Отчёт и запись решений | … |
| Недельные итоги и следующий план | … | … | Сводка кейсов и обязательства следующей недели | … |
Совмещённые встречи не дублируются. Достаточно ссылок на уже существующие отчёты и решения; отдельный протокол каждого дейлика не требуется.
| Участник | Что обязался проверить/подготовить | Фактический результат и помощь | Следующее действие и срок |
|---|---|---|---|
| Каждый участник поимённо | … | … | … |
- Кейсы следующей недели, ожидаемые результаты, исполнители и проверяющие: …
- Изменения контекста, требований, тестов и инструментов; ответственные и сроки: …
- Ссылка на выбранный бэклог в трекере: …
- Решения обеих сторон, открытые вопросы и следующая встреча: …
Журнал является источником подтверждений для чек-листа готовности к Пилоту. Пройденные кейсы не нужно описывать заново: достаточно их ID, версии и ссылки.
Проверка улучшения
Запись создаётся при выбранном изменении и дополняется после проверки по циклу PDSA.
- Изменение, область и версия, ответственный, срок: …
- До проверки: ожидаемый эффект, метрики результата / процесса / баланса, условия остановки: …
- После проверки: фактические результаты, побочные эффекты, наблюдения участников и ограничения данных: …
- Решение: сохранить / доработать / отказаться; основания, следующая проверка: …