Отчёт показывает, что среднее время исправления дефектов сокращается, но критические ошибки по-прежнему долго остаются открытыми. Как скорректировать метрику, чтобы она не скрывала этот риск?
Нужно отказаться от единственного среднего значения и анализировать время исправления по важным срезам: серьёзности дефекта, сервису, команде и процентилям распределения. Для управления качеством следует отдельно контролировать, например, медиану и высокий процентиль времени исправления критических дефектов, а также долю таких дефектов, нарушивших установленный срок реакции.
Среднее может уменьшаться за счёт большого числа быстро закрытых мелких ошибок, пока небольшая группа критических дефектов остаётся без внимания. Поэтому метрика должна показывать не только типичный результат, но и проблемный «хвост» распределения.
Агрегированные показатели появились как удобный способ сравнивать команды и отслеживать динамику процесса. Однако по мере усложнения продуктов стало очевидно, что одно число часто смешивает дефекты с разной ценой ошибки и скрывает редкие, но опасные случаи.
Именно поэтому в управлении качеством используют сегментацию, процентили, целевые сроки реакции и показатели нарушения этих сроков. Такой подход связывает метрику не просто со скоростью работы, а с реальным риском для пользователей и бизнеса.
Среднее время исправления считается по всем закрытым дефектам. Если команда быстро устранила много косметических проблем, среднее уменьшится даже тогда, когда один платёжный или относящийся к безопасности дефект месяцами остаётся открытым.
Такое измерение создаёт ложный сигнал улучшения. Руководитель может сократить время на анализ критических ошибок, потому что общий показатель выглядит хорошо, а команда — оптимизировать работу под количество быстрых закрытий вместо снижения наиболее существенного риска.
Сначала нужно определить, какие характеристики действительно меняют приоритет: серьёзность, влияние на пользователей, наличие обходного пути, затронутый компонент и возраст дефекта. Затем время исправления следует считать отдельно для значимых групп, а не объединять все дефекты в один показатель.
Практический набор может включать:
Медиана показывает типичный результат и меньше зависит от единичных экстремальных значений. Высокий процентиль показывает длинный хвост: например, 95-й процентиль отвечает на вопрос, насколько долго исправляются самые затяжные случаи.
Важно заранее зафиксировать начало и конец измерения. Например, временем исправления можно считать период от регистрации дефекта до его исправления, принятого проверкой; если считать до перевода в статус «готово к выпуску», процесс может выглядеть быстрее, чем он есть для пользователя.
Нельзя бездумно сравнивать команды по этой метрике. Команды могут обслуживать разные продукты, иметь разную сложность дефектов и разные полномочия на выпуск исправлений. Метрика полезнее как инструмент анализа собственной динамики и соблюдения целевых сроков, чем как единственный рейтинг сотрудников.
Также нужно учитывать незакрытые дефекты. Если считать только завершённые работы, задержанные критические ошибки могут вообще не попасть в расчёт. Их следует включать в отдельный показатель возраста открытого бэклога или использовать согласованный метод анализа цензурированных наблюдений.
В продуктовой команде среднее время исправления дефектов снизилось с десяти до шести дней. Проверка по категориям показала, что почти все быстрые закрытия относились к интерфейсным ошибкам, тогда как критические дефекты в расчётном сценарии исправлялись от 18 до 35 дней.
Рассматривались три варианта. Можно было оставить среднее как единственную метрику, но это сохраняло ложное ощущение улучшения. Можно было перейти только на максимальное время, однако один исключительный случай делал бы показатель чрезмерно нестабильным. Третий вариант — использовать медиану для типичного результата, высокий процентиль для хвоста и отдельный контроль просроченных критических дефектов.
Выбрали третий вариант. Для критических дефектов установили целевой срок реакции и еженедельный разбор всех нарушений, а общую медиану оставили как вспомогательный показатель. В результате команда обнаружила, что основная задержка возникала не в исправлении кода, а в ожидании решения владельца продукта и повторной проверки, после чего изменила порядок эскалации.
Максимум зависит от одного самого долгого случая и плохо отражает типичную работу процесса. Он полезен для поиска исключений, но не позволяет понять, улучшилась ли обычная скорость исправления. Поэтому его разумно использовать вместе с медианой, процентилем и анализом конкретного просроченного дефекта.
Серьёзность может назначаться непоследовательно или пересматриваться после исправления, создавая возможность манипуляции результатом. Нужны зафиксированные критерии классификации, аудит изменений приоритета и единые правила выбора момента начала и окончания измерения.
Нужно проверить связанные результаты: уменьшились ли возраст и количество критических открытых дефектов, снизилась ли доля дефектов, дошедших до пользователей, соблюдаются ли сроки реакции и не выросло ли число повторно открытых дефектов. Одна метрика скорости не доказывает улучшение качества, если команда стала закрывать дефекты формально или переносить сложные случаи в другую категорию.