Как вы проводите ретроспективы в своей команде? Используете Confluence или Miro с такими техниками, как «start, stop, continue» или 4L? Как вы количественно оцениваете, стала ли ваша команда лучше за определённый период — будь то год или квартал? Полагаю, что никак, ведь извлекать данные из визуальных инструментов или вики‑страниц, которые часто хаотично оформлены за целый год, — задача непростая.
Сколько раз вы помечали проблему как «TBD», которая в итоге оказывалась в бэклоге среди других таких же «TBD», которые позже было трудно приоритизировать? А если некоторые из этих «TBD» требовали одобрения от топ‑менеджмента — например, на получение бюджета на увеличение вычислительных мощностей для быстрой компиляции или запуска тяжёлых тестов? Предполагаю, что в половине случаев вы оставляли попытки предоставить достоверные данные для обоснования бюджета или приоритизации задач.
Я тоже проходил через это, пока не реализовал решение для JIRA — Multi‑team Metrics & Retrospective. Очевидно, что один из самых критически важных этапов ретроспективы — это анализ невыполненных коммитментов, что чаще всего означает незавершённый скоуп задач. Самый эффективный способ прогрессировать во времени я считаю анализ проваленных задач в каждом конкретном случае — согласно соответствующей метрике за конкретный период времени: будь то спринт, месяц, квартал, полугодие, год или релиз в PMIS (трекере задач). Для этого нам нужно:
1. Визуализация, например, бар‑чарт. Каждый столбец представляет определённую метрику — незавершённый скоуп, неоценённые задачи и т. д. Такие диаграммы можно строить по спринтам, месяцам, кварталам, полугодиям или годам, чтобы отслеживать прогресс по различным метрикам во времени — в том числе для нескольких команд, например, если они работают в одном домене и используют общий бэклог. Также важно иметь возможность строить кастомные метрики, так как у каждой команды могут быть свои критерии успеха.
2. Ретроспектива на месте — возможность кликнуть на столбец, увидеть список проваленных задач, выбрать причину(ы) из предопределённого, но настраиваемого выпадающего списка и описать в текстовом поле, как избежать этого в будущем — всё это в одном представлении.
3. Отчёт по основным причинам низкой эффективности за любой период времени — спринты, месяцы, кварталы, полугодия или годы — с возможностью сравнения периодов (например, 2024 против 2023 года для одной команды или сразу нескольких, например, работающих в одном домене (команда1, команда2) ABC: 2024 против 2023). Это позволит увидеть, как менялись причины со временем.
4. Отчёт по метрикам с возможностью drill-down — визуализация из первого пункта с возможностью погружения в подпериоды. Если период отчёта — год, в рамках отчётной встречи может потребоваться понять, как распределялись задачи по году. В таком случае можно углубиться до полугодий, кварталов, месяцев или спринтов в том же интерфейсе.
...
С реализованными четырьмя пунктами вы обнаружите, что вопросы, поставленные в начале статьи, больше не вызывают затруднений:
У вас появятся количественные результаты ретроспектив, представленные в двух форматах — бар-чарты (столбчатые диаграммы) с метриками и пай-чарты (круговые диаграммы) со списком причин по проваленным метрикам — по спринтам, месяцам, кварталам, полугодиям или годам.
Чтобы увидеть все рабочие элементы, проваленные по одной и той же причине, достаточно кликнуть на причину в отчёте из пункта 3.
Чтобы понять, какие препятствия самые критичные и требуют устранения, просто откройте отчёт со списком причин, упорядоченным по количеству проваленных задач, как описано в пункте 3.
Обосновывать запросы бюджета или обсуждать с руководством причины неудач или замедленного прогресса становится гораздо проще, когда есть чёткие данные, собранные без усилий.
Реализовать такую систему может быть непросто, но как только вы это сделаете, путь к раскрытию полного потенциала вашей команды будет открыт. Благодаря этой системе мне с командами в последений раз удалось достичь:
2-кратного увеличения производительности и скорости поставки
3-кратного роста flow efficiency
4-кратного повышения точности планирования и соблюдения командных обязательств
Ранее я использовал различные обходные пути и сторонние приложения, чтобы реализовать часть описанного выше функционала в JIRA, но в какой-то момент я просто решил создать отдельное приложение — Multi-team Metrics & Retrospective.
