Метрики и проверка улучшений
Внедрение должно сокращать сроки поставки и трудозатраты на производство ПО при сохранении качества и допустимых рисков. Используются метрики результата, процесса и баланса. Метрики результата показывают достигнутый прогресс относительно согласованных целей внедрения. Метрики процесса и баланса нужны для управления: помогают обнаружить задержки, препятствия, ухудшение качества или рост нагрузки и затрат, чтобы выбрать действие. Такое разделение применяется в Model for Improvement; ниже оно адаптировано к внедрению ИИ в разработку ПО.
Определения и матрица предприятие / команда × результат / процесс / баланс, типовые метрики и расчёты находятся в описании показателей. Группа определяется целью измерения: при ускорении поставки дефекты контролируют баланс, при улучшении качества — результат.
Как выбрать показатели
Работу организует РП внедрения вместе с РП клиента; ИИ-инженер и профильные специалисты готовят изменение и данные. На входе — цели, действующие процессы и сведения мониторинга; результат — проверенное изменение и запись решения в журнале Пилота, на PoC — в журнале PoC. Недельный разбор запускает очередную проверку; внеплановый разбор возможен после ошибки или находки HOTL.
Для выбранного потока команда определяет, что улучшает, в каких границах, к какому сроку и по какому признаку признает улучшение. Численный ориентир устанавливается с учётом исходных данных и ресурсов. Область и условия цели согласуются с участниками, на чью работу повлияет изменение. Такой способ постановки цели соответствует рекомендациям Model for Improvement.
В плане мониторинга фиксируются:
- ожидаемый результат и показатели его достижения;
- показатели процесса, которые помогают проверить предполагаемую причину улучшения;
- показатели баланса и условия, при которых требуется вмешаться;
- определения, источники, границы расчёта, период наблюдения и ответственные за разбор.
Достаточен небольшой набор, по которому команда действительно принимает решения. Например, для ускорения небольших изменений: срок поставки — результат; ожидание ревью — процесс; дефекты после интеграции и время проверяющих — баланс.
Агент собирает сведения ежедневно, команда разбирает их еженедельно. На графиках отмечаются изменения навыков, моделей, инструментов и правил работы. Числа дополняются наблюдениями специалистов: что помогло, что пришлось переделать, какая нагрузка стала незаметной в трекере. Пропуски данных показываются явно. Эти приёмы следуют рекомендациям по измерениям.
Как проверять изменения
Из Model for Improvement используются три вопроса: что хотим улучшить; как поймём, что стало лучше; какое изменение попробуем. Ответы связывают цель с действием. Затем изменение проверяется коротким циклом PDSA.
| Шаг | Действие команды |
|---|---|
| Спланировать | Выбрать конкретное изменение, ограниченную область и срок проверки; заранее записать ожидаемый эффект, способ наблюдения и условия остановки |
| Попробовать | Применить изменение в выбранной области, сохранив обязательные проверки; собрать результаты и неожиданные наблюдения |
| Изучить | Сопоставить результат с ожиданием: эффект, изменение процесса, побочные последствия и ограничения вывода |
| Скорректировать | Сохранить изменение, доработать или отказаться; определить следующую проверку либо условия расширения применения |
Например, агент-тестировщик регулярно пропускает проверки прав доступа. ИИ-инженер добавляет в навык явные сценарии проверки ролей. До пробы команда ожидает уменьшения таких пропусков без существенного роста ручной проверки и выбирает ближайшие подходящие задачи. На разборе рассматривает полноту доказательств, замечания человека и затраты проверки. При улучшении сохраняет навык и проверяет его на других сценариях; при отсутствии эффекта пересматривает инструкцию или инструменты.
Небольшая проба помогает найти полезное изменение, но не доказывает надёжность на всех типах задач. Расширение области требует проверки в соответствующих условиях. Смена режима HITL/HOTL оформляется отдельным решением; удачный цикл не снимает человеческие проверки автоматически.
Для цикла достаточно записи в действующем журнале PoC или Пилота: изменение, ожидание, область и срок, ответственный, наблюдения и решение. PDSA применяется внутри Подготовки, PoC и Пилота и не заменяет этапы внедрения и их гейты.