У части метрик история короче — оси начинаются там, где появляются данные. Фильтр показывает состояние Jira сейчас, а число — снимок на момент сбора, поэтому за старые месяцы они могут расходиться.
Чем закончились треды в #production_emergency и можно ли было обойтись без CRM.
Считается не из Jira, а из вкладки «PE threads»: каждый тред из #production_emergency разобран руками.
Состав исходов по месяцам. Тональная рампа упорядочена по тому, насколько тред довели до отслеживаемой работы: светлое — стал задачей, тёмное — исход так и не разобрали.
Оправданность призыва: можно ли было обойтись без CRM. Второй вопрос про тот же тред — исход говорит, что получилось, а это, к кому вопрос. Рампа идёт по возрастанию «насколько это не наш вопрос», красным помечена крайняя категория.
Доля призывов, которых можно было избежать — «могли сами» плюс «не к CRM». Это число, с которым идут к саппорту и КС. Порога нет: сколько считать нормой, покажет накопленная история.
Чем закончился тред: светлое — стал задачей, тёмное — так и не разобрали.
Можно ли было обойтись без CRM. Избежные — две верхние: «могли сами» и «не к CRM».
Доля избежных призывов: «могли сами» плюс «не к CRM».
Сколько багов пришло и сколько закрыли. Разница по месяцам — в карточке «Успеваем ли».
Обе метрики — счётчики, поэтому одна ось. Разрывы в линии означают отсутствие данных, а не ноль.
Сколько задач вышло в релиз и сколько багов на проде за месяц.
Расхождение между «создано» и «баги на проде» за отдельные месяцы — известная проблема самой таблицы, см. блок расхождений ниже.
Где нашли баги месяца: на приёмке, пострелизом или легаси на проде.
Доли, а не абсолютные числа: счётчики скачут вместе с объёмом релизов, а доли показывают, учимся ли мы находить раньше. Сумма всегда 100%.
На приёмке — все её находки: дефекты и баги с acceptance_bug (метрика «Тест: создано»). Пострелизом — postrelease_bug, легаси — release_bug. До 1 октября 2026 слой приёмки считал только acceptance_bug и не видел дефектов: в сентябре выходило 9,7% вместо 71%.
Месяцы у слоёв разные по смыслу: приёмка — задачи, которые тестировали в этом месяце и выпустят позже; пострелиз — задачи, которые вышли в этом месяце, а тестировали их часто в прошлом. Поэтому столбик — срез потока находок, а не оценка приёмки конкретных релизов.
Растёт ли долг: столбик вверх — пришло больше, чем закрыли. Сами линии — в карточке «Создано и пофикшено».
Новая метрика, в таблице её нет. Столбик вверх — за месяц пришло больше, чем закрыли, и долг вырос; вниз — разгребли накопленное. Вычитать две линии глазами больше не нужно.
Из каких приоритетов состоят баги месяца: чем темнее, тем серьёзнее.
Приоритет — упорядоченная шкала, поэтому одна тональная рампа: чем темнее, тем серьёзнее. Стопка показывает состав месяца.
Сколько дней баги пролежали под заниженным приоритетом, прежде чем его подняли, и какие это баги.
«Под прежним» — сумма дней от создания до последней смены приоритета по багам, закрытым в месяце, которым приоритет подняли. Понижения не считаются: баг, который сняли с High на Medium, ничего не потерял. Пример: CRM-7925 в сентябре 2026 пролежал 68 дней под Medium и стал High за 2 дня до закрытия.
Раньше здесь был график разницы медиан двух MTTR. Она почти не реагирует на отдельные баги — те же 68 дней сдвинули сентябрьскую медиану на 1 день, — а понижения считала потерями.
Список — баги, закрытые в месяце, у которых последняя смена приоритета позже создания. Смену в день создания от «не меняли» не отличить: скрипт хранит даты, а не время. «—» значит, что построчных данных за месяц нет, а не ноль.
Сколько дней чиним баг: от создания и от последней смены приоритета. Сколько дней баги пролежали под заниженным приоритетом — в карточке запоздалая переприоритизация.
На странице на виду — все баги, PE и High: за ними следим строго. Medium и Low там под кнопкой. Разрыв между линиями внутри панели — насколько поздние смены приоритета сдвинули медиану; сами потерянные дни — в карточке запоздалой переприоритизации.
Сколько багов лежит и насколько они старые: высота столбика — размер бэклога, цвет — возраст.
Корзины возраста — упорядоченная шкала, поэтому одна тональная рампа: чем темнее, тем старше. Сумма корзин равна размеру бэклога, он же «всего» в подсказке; отдельный график размера убран как повтор.
Какие лейблы преобладали: чем крупнее, тем больше багов, точное число — рядом.
Что преобладало. Размер — по количеству, число стоит рядом: кегль даёт ранг, а точное значение читается, не угадывается. Разбивки · frontend и · backend в облако не идут — это части родительского лейбла, рядом с ним они читались бы как отдельные категории. За период и за последний месяц картины разные: rush_dev за полгода третий, а в июле его ноль.