Все статьи
Как я перестал объяснять руководству «почему эпики зависают» и просто показал им дашборд
Дата: 08.06.2026
Есть разговор, который я провёл много раз в разных компаниях.
CTO или CPO говорит: «Когда уже сделаете?» — или: «Я не верю этим цифрам — задачи не актуальны, статусы непонятно, что отражают». Agile Coach отвечает: «Нужно улучшить гигиену Jira». CTO кивает, даёт разнарядку разработчикам: актуализируйте! Через месяц всё то же самое.
Проблема не в том, что люди не хотят актуализировать. Проблема системная: у руководителя нет инструмента, который даёт картину за тридцать секунд. Без этого любой разговор про гигиену — это разговор ни о чём. Люди обновляют задачи под давлением, давление спадает, через две недели всё возвращается на круги своя.
Системный подход выглядит иначе. Сначала показать руководителю, что именно он не видит и почему это стоит денег. Потом дать инструмент, который это видит. И только потом говорить с командой про то, как они ведут задачи.
Почему это болит у CTO и CPO
CTO смотрит на бэклог со стороны рисков. Эпики без дат, без ответственных, без описания — это не беспорядок, это слепые зоны. Ты не знаешь, что уже обещано командой и тихо лежит. Не знаешь, где накапливается работа, которая однажды взорвётся срочным фиксом в пятницу вечером. Здоровье бэклога и здоровье архитектурных решений — одно и то же.
CPO болеет предсказуемостью. Ему надо отвечать бизнесу на вопрос «когда». И чтобы получить на него честный ответ, приходится идти к каждому PO или техлиду отдельно, переспрашивать и перепроверять. Это и есть микроменеджмент — не как черта характера, а как единственный способ добыть информацию, которой нигде нет в одном месте. Когда данные о сроках размазаны по головам людей, у CPO нет выбора: либо не знать, либо дёргать команду.
Что я сделал до инструмента
Когда руководство попросило сделать ситуацию с эпиками прозрачной, я не пошёл сразу за инструментом.
Сначала — процесс.
Организовал регулярные чекины, где техлиды готовят и показывают метрики по своим командам. Выровнял команды по методологии — у всех одинаковый формат работы с эпиками. Поговорил с каждым техлидом отдельно: объяснил, что именно мы хотим видеть и зачем это нужно не для отчётности, а для принятия решений.
Только после этого появился вопрос: а как смотреть на эти данные быстро?
Инструмент, который я собрал с Claude
Я не умею писать код. Но я умею точно описывать задачу.
Вместе с Claude я собрал HTML-дашборд, который берёт CSV-выгрузку из Jira и делает аудит в двух разрезах: эпики и задачи.
По эпикам инструмент смотрит на семь вещей. Каждая — про конкретный вопрос, который руководство задаёт вслух или молча.
Нет WSJF — нет оценки приоритета. У нас восемь команд, у каждой свой бэклог. Без WSJF CPO не может приоритизировать инициативы между командами — он просто не знает, что важнее.
Нет ключевой метрики — непонятно, зачем вообще делаем этот эпик. На что он должен повлиять? Если команда не может ответить на этот вопрос при создании эпика, она вряд ли ответит на него в конце.
Нет даты завершения — эпик становится потеряшкой. Такие задачи тихо висят месяцами, искажают статистику и однажды всплывают на квартальном ревью как «а вот это мы не доделали».
Просрочено — смотрим, сколько таких эпиков и у кого. Это не повод для разноса, это повод для разговора.
Нет типа эпика (бизнес или технический) — непонятно соотношение работы в командах. Любой бизнес-эпик должен иметь прогноз: именно это позволяет руководству видеть, за счёт каких инициатив они теоретически придут к стратегическим целям. Без типа эпика эта картина не складывается.
Нет описания — делаем, не зная что. Звучит как карикатура, но встречается регулярно.
Нет ответственного — делаем, но кто именно — вопрос открытый.
Каждый эпик получает Score от 0 до 100% по этим критериям. Разбивка по командам. Просроченные подсвечиваются красным.
По прочим задачам (таски, истории, симпласки, дефекты) дашборд показывает статистику за период.
И ловит аномалии.
Зависшие — в работе больше 60 дней или без движения больше 21 дня.
Долго ждут тестирования — больше 14 дней в очереди QA.
На паузе больше 60 дней — холд легко превращается в помойку, если за ним не следить.
Активные задачи старше медианного возраста по команде — сигнал, что что-то застряло.
Открыты, но не начаты больше 90 дней — мусор в бэклоге, который создаёт иллюзию загрузки.
И отдельно — «влётные» задачи: незапланированные, которые влетели в спринт и повлияли на сроки. Это важно считать, потому что именно они чаще всего объясняют, почему что-то не сделано в срок.
Весь инструмент — один HTML-файл. Никаких серверов, никаких интеграций. Загрузил CSV, увидел картину.
Процесс создания выглядел так: я описывал потребность — «нужно видеть эпики без описания», «нужно считать Score по нескольким параметрам», «нужно разбить по командам». Claude предлагал код, я смотрел, что получается, формулировал следующий шаг. Примерно как работа с разработчиком, который хорошо пишет, но не знает контекста бизнеса. Только быстрее.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на MAX-канал ProAgile.
Реакция команды
Один из техлидов написал после первого просмотра: «Вот эти два блока — прям то, что нужно. Для быстрого нахождения проблемных мест очень хорошо подходит».
Другой попросил встроить в Confluence.
Руководство сейчас рассматривает инструмент для использования в штатном режиме внутри периметра компании.
Почему это работает там, где разговоры не работали
Инструмент не заменил разговоры с техлидами. Он дал нам общую точку отсчёта. Вместо «у нас есть проблема с эпиками» — вот Score по каждой команде, вот конкретные эпики без дат, вот что можно разобрать на этой неделе.
CPO перестаёт спрашивать «а что там с эпиком X» у шести разных людей — он смотрит на дашборд. Техлид видит проблему раньше, чем её поднимет руководство.
Что из этого следует для Agile Coach
Мы часто работаем влиянием без прямых полномочий. Когда данные видны всем, убеждать проще.
ИИ даёт возможность самим создавать такие инструменты — без бюджета на разработку и без очереди в IT. Нужно уметь точно описывать задачу. Это как раз то, чем Agile Coach занимается каждый день.
Одно условие: не начинать с инструмента. Инструмент усиливает процесс, который уже работает. Там, где процесса нет, красивый дашборд ничего не изменит.
Если интересно посмотреть живую версию или обсудить подход, идеи, то пишите в личку в телеграмм, поделюсь файлом и закулисной статистикой по разработке.
