Ретроспектива на данных: как перестать спорить, «кажется или правда»
Коротко. Типичная ретроспектива держится на памяти участников, а память устроена неудобно: она хранит последние дни и самые эмоциональные эпизоды. Из-за этого половина времени уходит на спор «стало хуже или нам кажется». Данные о структуре рабочего дня закрывают именно этот спор — и только его. Всё остальное — что с этим делать, почему так вышло, кому тяжело — по-прежнему приносят люди. Ниже: что взять на ретро, как это сформулировать, чтобы обсуждение осталось про процесс, и чего от данных ждать не стоит.
Данные закрывают ровно один спор — «кажется или правда». Остальное приносят люди
Содержание
- Что взять на ретро
- Как это подать команде
- Три вопроса, на которые данные отвечают
- Как проверить решение ретро
- Где данные молчат
- Чего делать нельзя
- Чек-лист подготовки
- FAQ
Что взять на ретро
Достаточно одного экрана и трёх цифр. Не двенадцати графиков — иначе ретро превратится в разбор дашборда.
Одно наблюдение с основанием — этого хватает, чтобы начать разговор по делу
Полезный минимум:
- Что изменилось — переход «было → стало», а не только процент.
- Своя норма группы — «обычно у нас 7,7» рядом с текущим значением. Без неё цифра ни о чём не говорит.
- Где проявляется — интервал дня, в котором изменение сильнее всего.
И одна цифра для разговора о цене вопроса:
Это не «потерянные» часы — это часы, которые не могли быть непрерывной работой
Как это подать команде
Формулировка решает больше, чем сами данные. Одно и то же число можно превратить в совместный разбор или в разнос.
| Так работает | Так ломает |
|---|---|
| «У нас выросло дробление в интервале 10–12. Что там появилось?» | «Вы стали хуже работать, вот график» |
| «Средний непрерывный блок — 23 минуты. Хватает ли этого для наших задач?» | «Почему вы не можете сосредоточиться?» |
| «Цифра — повод посмотреть на расписание» | «Цифра — повод объясниться» |
Практическое правило: данные ставят вопрос, ответ приносит команда. Как только становится наоборот, люди начинают подстраивать поведение под метрику, и она перестаёт измерять то, ради чего заводилась — это закон Гудхарта в чистом виде.
Полезно заранее проговорить, что метрики не привязаны ни к оценке, ни к премиям: как формулировать метрики, чтобы они не превращались в наказание.
Три вопроса, на которые данные отвечают
«Это правда изменилось или нам кажется?» Есть значение сейчас, есть обычное значение этой же команды за 90 дней, есть уровень уверенности вывода. Спор закрывается за минуту.
«Когда началось?» Сравнение периодов показывает, в какой половине окна произошёл сдвиг — дальше вспоминать становится намного легче.
«Где именно больно?» Разбивка по часам сужает разговор с «весь день рваный» до конкретного интервала.
Как проверить решение ретро
Ретро без проверки решения — это обмен мнениями. Проверка простая:
- Записать решение как изменение одного условия. «Переносим синк на 16:00» — проверяемо; «стараемся меньше отвлекаться» — нет.
- Назначить дату проверки — минимум через две недели: сравнение требует данных с обеих сторон.
- Не менять параллельно другие вещи — иначе результат нечитаем: как проверить гипотезу экспериментом.
- Вернуться к тем же цифрам на следующем ретро и сравнить сопоставимые периоды: как сравнивать периоды.
Где данные молчат
- Почему так вышло. Совпадение по времени — не причина: корреляция и причинность.
- Кому тяжело. Все цифры по группе; персональных срезов нет, и агрегат не считается для группы меньше пяти человек.
- Что происходило вне компьютера. Совещания в переговорке, обсуждения у доски, обдумывание — в данных не отражаются вовсе.
- Насколько хорошо сделана работа. Структура дня ничего не говорит о качестве результата.
Чего делать нельзя
- Открывать ретро с графика. Начинать стоит с того, как прошёл период по ощущениям команды, и только потом сверяться с цифрами — иначе обсуждение с первой минуты идёт вокруг метрики.
- Разбирать конкретного человека по данным. Таких данных нет, и попытка их вывести — это уже другой продукт: этичный контроль сотрудников.
- Ставить целевое значение по метрике. Оно будет достигнуто и перестанет что-либо значить.
- Делать выводы по одной неделе. Тренд или случайность.
Чек-лист подготовки
- Открыт один экран, а не двенадцать графиков.
- Выписаны три цифры: что изменилось, обычное значение группы, где проявляется.
- Сформулирован вопрос, а не вывод.
- Проговорено, что метрики не связаны с оценкой и премиями.
- Решение записано как изменение одного условия.
- Назначена дата проверки — не раньше чем через две недели.
FAQ
Зачем данные на ретроспективе, если команда и так всё помнит? Память хранит последние дни и самые эмоциональные эпизоды. Данные закрывают ровно один спор — «изменилось или кажется», — и освобождают время на обсуждение причин.
Не превратится ли это в разбор полётов? Превратится, если начинать с графика и говорить о людях. Работает обратный порядок: сначала ощущения команды, потом сверка с цифрами, и вопрос вместо вывода.
Какие три цифры брать? Что изменилось (переход «было → стало»), обычное значение этой же группы за длинный период и интервал дня, где изменение сильнее всего.
Через сколько проверять решение? Не раньше чем через две недели: сравнение делит период пополам и требует достаточно дней с данными в каждой половине.
Можно ли посмотреть данные по конкретному участнику? Нет. Персональных срезов для руководителя нет, а групповой агрегат не считается, если в группе меньше пяти человек.
Что делать, если цифры не совпали с ощущениями команды? Это самый ценный случай: либо метрика измеряет не то, что вы думали, либо ощущение опирается на пару ярких дней. Разбираться стоит с обеими версиями.
Посмотреть на живых данных. В демо DevPace открыт раздел руководителя: наблюдения с основанием, своя норма группы и часы дробления — то, что берут на ретро. Синтетические данные, без регистрации: открыть демо компании. Коротко о том, что это даёт руководителю — на отдельной странице.
Опубликовано: 13 августа 2026 г.