Ретроспектива в японской команде: как устроена

Ретроспектива в японской команде: как обсуждать проблемы без обвинений

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

Формат: тихое письмо и общая доска

Ретроспектива проходит по фиксированному сценарию. Сначала каждый участник вслух делится общим впечатлением о спринте — это разогрев. Затем 10–15 минут тишины: все пишут карточки в колонки Keep и Problem. Тишина — ключевой момент: она уравнивает интровертов и экстравертов, не давая первым высказавшимся задать тон обсуждению.

Keep: благодарности конкретным людям

Колонка Keep обычно самая заполненная. Карточки выглядят как «Спасибо X за помощь с деплоем» или «Благодарен, что подхватил ревью, пока я был в отпуске». На первый взгляд это кажется формальностью, но на самом деле это важный противовес: здесь можно и нужно называть имена, но только в позитивном ключе. Это балансирует общую непрямолинейность обсуждения проблем.

Problem: проблемы без имён

Когда дело доходит до колонки Problem, имена исчезают. Вместо «PO постоянно меняет требования» пишут «требования менялись несколько раз за спринт, что затрудняло стабильность объёма». Информация та же, но нет цели для атаки. Это не уход от конфликта — проблемы реальные и они «залетают». Примеры типичных карточек:

• Критерии приёмки были неясны в некоторых задачах, поэтому работа переделывалась.
• Ревью скучивались в конце спринта, создавая бутылочное горлышко.

Все понимают, о ком и о чём речь, но формулировка направляет разговор на процесс, а не на защиту или нападение. В японском языке это подкрепляется грамматически: можно описать проблему без подлежащего («〜になってしまった», «〜が発生した»), и это естественный способ выразиться.

Голосование: от проблем к Try

Карточки Try не пишут заранее — их выводят из проблем. Каждый участник получает 2–3 голоса, и топ проблем по голосам становятся целями следующего спринта. Это простой фильтр, который гарантирует, что в работу попадают действительно волнующие команду вопросы, а не только те, что озвучил самый громкий участник.

Где всё ломается

Главная слабость — не в выявлении проблем, а в их решении. Превращённые в бэклог-элементы, Try часто остаются там навсегда. Мы хороши в диагностике спринта, но плохо помним о ней в следующем. И это, похоже, универсальная проблема, не только японская.

Практические выводы

Что вы можете забрать в свою команду уже сегодня:

1. Формулируйте проблемы без указания на людей — это снижает защитную реакцию и позволяет обсуждать суть.
2. Используйте тихое письмо перед обсуждением, чтобы голос каждого был услышан.
3. Создайте колонку Keep для благодарностей — это укрепляет командный дух.
4. Выводите Try из проблем голосованием, чтобы приоритеты отражали мнение всей команды.
5. Следите за выполнением Try: назначайте ответственных и сроки, иначе они застрянут в бэклоге.

Начните с малого: на следующей ретроспективе попробуйте переформулировать одну проблему без имён и посмотрите, как изменится разговор. Уверен, вы почувствуете разницу.