«Командная ретроспектива»

Это регулярная встреча команды (часто проводится в онлайн формате). Ретроспектива используется для улучшения рабочих процессов команды, причём в постоянно действующей команде с повторяющимися процессами она обычно проводится раз в две недели, а во временной проектной команде, где на каждом этапе новые процессы, можно реже — как минимум один раз после завершения проекта.
Проходит ретроспектива с использованием инструмента «Документы с одновременным редактированием», это повышает наглядность при обмене идеями и обеспечивает точные формулировки уже на самой встрече, а не после неё. Удобно использовать уже готовый шаблон документа из описания Командной ретроспективы.

Это успешные аспекты в работе команды, выявленные за время, прошедшее с проведения прошлой ретроспективы. На такие аспекты хочется обратить внимание, чтобы порадоваться находкам, поблагодарить за них коллег, сохранить их — сделать частью процессов команды, ведь они помогают добиваться результата.
Чтобы закрепить полученный успешный опыт, эти находки позже попадут в типовые инструкции, правила и принципы работы команды, другими словами в стандарты работы (регламенты).

Это шаги, которые нужно выполнить, чтобы исправить недостатки в процессах команды, выявленные за время, прошедшее с проведения прошлой ретроспективы. Другими словами, это задачи, чтобы «дотянуть» обнаруженные минусы до будущих плюсов — они позже попадут на Доску задач команды.
При первом знакомстве «Дельта-плюсы» часто кажутся непонятными, их хочется заменить на «минусы», найденные в процессах работы. Есть команды, которые так и делают — формулируют на ретроспективе «минусы», а только потом ищут «Дельта-плюсы» (способы их устранения). Но такой подход может приводить к затягиванию встречи: участники начинают мыслить проблемами, вместо поиска решений.

Заранее ещё до начала встречи каждый участник команды вспоминает полученный недавно опыт и анализирует свои процессы для выявления удачных находок и возможностей улучшения. В этом помогают такие шаги:

1. Перечитать полученную обратную связь от внешних и внутренних заказчиков команды, а также от коллег, партнёров и руководителей. Проверить, не было ли пропущено что-то, что требует оперативного решения, задуматься, что можно использовать для развития процессов команды.
2. Перечитать критически свои регламенты: типовые инструкции, этапы Конвейера, правила и принципы, а также свой Кодекс роли. Задуматься, что в этих документах помогло в работе, а что уже пора усовершенствовать.
3. Обновить значения метрик работы команды, сформировать отчёты и графики по продуктивности. Разглядеть в них прожитую историю команды и найти возможные аномалии и ограничения.
4. Прочитать свои ответы на брифингах команды из блока «Мешает». Задуматься о возможных причинах помех и способах устранения самих причин (полезно погружаться в поиск первопричины, пять раз задавая себе вопрос «почему это произошло»).
5. Вспомнить, когда приходилось разрывать ритм работы команды и внезапно переключаться на срочную задачу. Задуматься, как можно было бы заранее предусмотреть эти ситуации или научиться справляться с ними спокойно по инструкции.

Напомнить об этих шагах может координатор системной работы (или лидер, временно исполняющий его роль).

Заранее ещё до начала встречи координатор системной работы (или лидер, временно исполняющий его роль) создаёт общий документ по шаблону из данной статьи, внутри которого будет проходить Командная ретроспектива:

1. Создать внутри папки команды текстовый документ по шаблону с названием вида «ГГГГ-ММ-ДД Ретроспектива».
2. Если типовой шаблон ретроспективы ещё не подготовлен, то вручную создать в документе блоки-заголовки: «Плюсы» и «Дельта-плюсы». Указать стиль «Заголовок 1» для созданных заголовков блоков. Добавить нумерованный список в оба блока. Можно заранее записать имена участников команды в пунктах списков.

В самом начале встречи лидер команды или координатор системной работы помогает команде настроиться на улучшение процессов именно в контексте целей:

1. Напомнить друг другу текущие бизнес-цели организации, в которых участвует команда, а также цели команды.
2. Предложить участникам задуматься о том, как процессы команды должны поддерживать поставленные цели.

Когда участники настроились, координатор системной работы (или лидер, временно исполняющий его роль) помогает команде пройти первый круг — заполнить блок «Плюсы», предлагая каждому участнику команды выполнить следующие шаги:

1. Сформулировать текстом в общем документе «плюсы» с момента прошлой ретроспективы (а если это первая подобная встреча, то с начала работы команды или со старта текущего проекта).
2. Задуматься в процессе записи «плюсов», какой ценный опыт мы приобрели за последнее время, какими находками хочется поделиться, чему хочется порадоваться, что важно было бы зафиксировать в типовых инструкциях, чтобы сохранить это в привычках команды.
3. Задуматься в процессе записи «плюсов», как имеющиеся инструкции помогли решить типовые задачи. Это нужно, чтобы вспомнить, что такие инструкции у команды имеются, а дальше найти успешные моменты из практики, которыми можно дополнить инструкции, чтобы сохранить эти находки.
4. Озвучить свои записанные «плюсы» и поделиться обратной связью с коллегами на их «плюсы» (например, что-то добавить или выразить поддержку).

После прохождения первого круга координатор системной работы (или лидер, временно исполняющий его роль) помогает команде пройти второй круг — заполнить блок «Дельта-плюсы», предлагая каждому участнику команды выполнить следующие шаги:

1. Сформулировать текстом в общем документе «дельта-плюсы» с момента прошлой ретроспективы.
2. Задуматься в процессе записи «дельта-плюсов», что нужно улучшить в работе команды, чтобы достигать цели и выполнять свои текущие задачи. Найти отклонения, которые мешают команде.
3. Задуматься в процессе записи «дельта-плюсов», как можно доработать типовые инструкции и описания процессов (Конвейеров команды), что нужно переделать или добавить, чтобы регламенты помогали решать типовые задачи и достигать поставленные цели.
4. Убедиться, что пункты в разделе «Дельта-плюсы» сформулированы именно как задачи — то есть описывают конкретное действие по «дотягиванию» найденного «минуса» до будущего «плюса». Можно использовать инструмент «Постановка осмысленной задачи».
5. Озвучить свои записанные «дельта-плюсы» и поделиться обратной связью с коллегами на их «дельта-плюсы» (например, что-то добавить или выразить поддержку).

Когда оба круга ретроспективы пройдены, координатор системной работы (или лидер, временно исполняющий его роль) помогает команде завершить встречу фиксацией полезного результата и гармонизацией эмоционального состояния. В этом помогут шаги:

1. Договориться, кто и когда займётся обновлением инструкций и процессов на основании новых находок в блоке Плюсы, кто поставит необходимые задачи на Доске задач.
2. Договориться, кто и когда возьмёт в работу «дельта-плюсы», кто перенесёт их на Доску задач в колонку «Единый список задач», чтобы команда могла взять их в работу на одном из следующих рывков.
3. Спросить, какие вопросы остались у команды, выслушать и зафиксировать необходимые первые шаги в блоке «Дельта-плюсов», если это нужно.
4. Дать команде краткую обратную связь на тему прогресса в развитии процессов работы.
5. Предложить лидеру дать напутствие команде, чтобы поднять мотивацию после разбора проблем в блоке «Дельта-плюсов».

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

• метрика должна быть «честной», то есть опираться на объективные данные и не приводить к ошибкам мышления, например, когда не учитывается дополнительный контекст;
• метрика должна помогать принимать решения, подсказывать, что именно можно сделать для улучшения, а не просто сигнализировать об отклонении в процессах;
• метрика должна исходить из понимания идеального результата или оптимального процесса, к которому хочется стремиться, а не просто ратовать за всё хорошее.

Подобрать подходящие метрики бывает непросто, и на первых порах для примера идеального результата можно взять само стремление выстроить системную работу с задачами, проектами и процессами. Самое частое ограничение при внедрении Системной работы — это невыявленные «застревания», когда задачи, проекты или экземпляры процессов длительное время не переходят в своё очередное состояние, но это становится заметно слишком поздно. Вот на этих «застреваниях» и можно сосредоточиться для начала при внедрении метрик.
«Застревания» можно разделить на два типа:

1. «Застревания» задач конкретного вида, например, задачи сбора обратной связи от клиентов часто не выполняются за один рывок.
2. «Застревания» задач в конкретных этапах, например, в Конвейере подключения новых клиентов постоянно накапливаются карточки на этапе «Согласовать условия».

Для первого типа «застревания» метрику можно получить на графике затрат времени на конкретные задачи или на задачи конкретного типа, или можно просто смотреть количество дней нахождения задачи в колонке доски для конкретной карточки.
Для второго типа «застревания» метрику можно получить на коммулятивной диаграмме, рассматривая горизонтальные участки графика, то есть периоды, когда количество карточек не изменялось в конкретной колонке.
Примеры популярных метрик, которые по мнению делового сообщества уже доказали свою полезность:
1. Пропускная способность
Какой объем работы ваша команда может выполнить за определенный период — именно количество завершенной работы
https://kaiten.ru/blog/throughput/

2. Удовлетворённость внутренних и внешних клиентов, а также партнёров
Усреднённое значение за период, которое получается сбором обратной связи через простую форму (с возможностью обменяться подробностями).

3. Среднее время работы над задачей и среднее время выполнения запроса клиента
Среднее время работы над задачей — сколько в среднем команда тратит времени, чтобы довести задачу до результата.
Среднее время выполнения запроса клиента — это среднее время работы над задачей плюс время ожидания задачи в очереди задач
https://kaiten.ru/blog/lead-time-vs-cycle-time/

4. Конверсия
Доля экземпляров типового процесса (например, запросов или заказов), которые перешли из одного этапа Конвейера на следующий этап, а не покинули Конвейер. Например, доля презентационных встреч с клиентами, которые перешли в подготовку конкретного коммерческого предложения, а не были отброшены из-за отказа клиента.