Подход к метрикам

Зачем эта страница

Инструмент формирует вопросы, которые вы задаете. Откройте типичный отчет со стори-поинтами — и разговор пойдет про оценки и «скорость команды». Откройте JMP — и разговор пойдет про то, сколько времени задачи реально проводят в процессе и где они ждут.

Это не случайность. JMP построен на flow-подходе — взгляде на работу как на поток задач, проходящих через систему. Эта страница объясняет принципы, которые заложены в продукт, — чтобы вы использовали его осознанно, а не просто «смотрели графики».

Она адресована всем, кто пытается улучшить процесс работы — свой или команды: тимлиду, agile-коучу, менеджеру проектов, CTO.

Измеряем реальность, а не оценки

В JMP нет стори-поинтов, velocity и burndown-диаграмм — и это принципиально.

Оценка — это мнение, высказанное до начала работы. Lead time — это факт, измеренный после. Команды тратят часы на покер-планирование, а потом сравнивают прогресс с собственными догадками. JMP предлагает другой путь: смотреть, сколько времени задачи проходят через процесс на самом деле. Эти данные уже есть в Jira — их не нужно ни у кого спрашивать, их невозможно «переоценить» или «недооценить».

Как это видно в продукте: все отчеты построены на фактической истории движения задач — Lead Time, Throughput, WIP, CFD. Ни одного поля для ручного ввода оценок.

Распределения, а не средние

«В среднем задача занимает 8 дней» — фраза, которая скрывает больше, чем сообщает. За этой средней может прятаться половина задач по 3 дня и хвост по 40.

JMP везде показывает распределения и процентили: P50 (медиана), P85, P95. Вместо ложно-точного «будет готово за 8 дней» — честное «85% таких задач завершаются за 12 дней или быстрее». Это вероятностное обещание, и оно единственно честное: будущее не детерминировано, и говорить о нем стоит на языке вероятностей.

Как это видно в продукте: гистограмма Lead Time с линиями P50/P85/P95, Control Chart с перцентильными границами, Percentile Trend, целящийся именно в динамику процентилей.

Данные должны быть честными

История переходов в Jira бывает неполной. Большинство инструментов молча рисуют уверенную цифру поверх дыр в данных. JMP поступает иначе: если часть таймлайна задачи пришлось восстанавливать, вы увидите пометку «реконструировано» и предупреждение «lead time приблизителен».

Принцип простой: лучше честная приблизительная цифра, чем точная с виду, но недостоверная. Решения, принятые на основе красивой, но фальшивой точности, обходятся дороже, чем осознанная работа с неопределенностью.

Как это видно в продукте: пометки реконструкции и предупреждения в диалоге Поток задачи, отдельный подсчет исключенных задач в отчетах вместо тихого их выбрасывания.

Факты, а не обвинения

JMP сознательно не вешает ярлыки. Возврат задачи назад по доске показывается как «возврат» — не как «переделка»: может, это брак, а может, нормальная итерация ревью. Долгая колонка показывается как «самая долгая стадия» — не как «бутылочное горлышко»: диагноз требует контекста, которого у инструмента нет.

Инструмент показывает, что произошло. Что это означает и что с этим делать — решает команда, которая знает свой контекст. Метрики — материал для разговора, а не приговор.

И главное: метрики — не кнут. Данные о потоке нужны, чтобы улучшать систему работы, а не чтобы давить на людей. Как только метрика становится инструментом наказания, она перестает отражать реальность — люди начинают оптимизировать цифру, а не работу. Поэтому предмет измерения в JMP — процесс: колонки, очереди, время ожидания. Персональной производительности JMP не считает.

Метрики ради решений, а не отчетов

Отчет, который никто не обсуждает и по которому никто ничего не меняет, — потраченное время, сколько бы графиков в нем ни было.

JMP спроектирован для регулярной практики: открыть на ревью процесса, увидеть изменение, обсудить причину, договориться об эксперименте, через месяц проверить эффект. Каждый отчет отвечает на конкретный вопрос: «сколько занимает?» (Lead Time), «сколько успеваем?» (Throughput), «где копится?» (CFD, WIP), «что застряло?» (Aging). Если отчет не ведет к вопросу или решению — он не нужен, даже красивый.

Как это видно в продукте: диалог «Поток задачи» с кнопкой копирования сводки для ретро, дашборды как постоянная панель для регулярных встреч, тренды к предыдущему периоду в метриках.

Начать можно сегодня

Улучшение процесса часто откладывают до «сначала наведем порядок в Jira» или «внедрим правильный процесс». Flow-подход позволяет не ждать: ваша доска уже генерирует данные о потоке — каждый переход задачи между колонками записан.

JMP берет эти данные как есть: без выделенной инфраструктуры, без Jira-администратора, без изменения процесса команды. Поставили расширение — через минуту видите реальную картину. Она может не понравиться — но это уже начало улучшения, а не его отсрочка.

С чего начать

1. Быстрый старт — откройте свою доску и посмотрите на Lead Time и Throughput.
2. Найдите одну вещь, которая вас удивила, — длинный хвост распределения, растущий WIP, задачу-выброс.
3. Принесите ее на ближайшее ретро — не как обвинение, а как вопрос.

Остальное — дело регулярности.