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

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

Разговор не заменяет данные. Он объясняет, почему цифра изменилась и какое действие имеет смысл проверить следующим. Паспорт метрик готовят заранее, а на ретро приносят только связанные с ними наблюдения.

Если читать 30 секунд

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

До встречи соберите факты, а не презентацию

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

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

Когда и где → что делал гость → что увидел сотрудник → какое действие потребовалось → чем закончилось.

Фраза «гости не понимают QR» не подходит. Запись «за столом у окна гость открыл меню, но спросил, как вернуться к корзине; официант показал кнопку» уже проверяема. Один эпизод ещё не доказывает частоту, зато позволяет искать точку разрыва.

Если неделя прошла без журнала и единых определений, честно признайте ограничение. Проведите встречу как сбор гипотез, но не называйте её итогом пилота.

Назначьте четыре роли разговора

Роли защищают ретро от спора между должностями. Один человек может совмещать две роли, но обязанности должны прозвучать в начале.

• Фасилитатор держит порядок вопросов и останавливает переход к обвинениям.
• Хранитель фактов быстро находит запись, статус или заметку, на которую ссылаются.
• Секретарь решений заполняет доску и уточняет формулировки.
• Владелец пилота принимает итоговое решение о следующей проверке, но не подменяет обсуждение готовым ответом.

Руководителю лучше не начинать с собственной оценки. Если первым звучит «всё прошло отлично» или «команда саботирует», остальные участники будут подбирать подтверждения под этот вывод.

Откройте ретро нейтральной рамкой

Первая фраза задаёт качество разговора. Подойдёт такая рамка: «Мы разбираем путь заказа и работу процесса, а не оцениваем людей. Сначала называем событие, затем проверяем причину, после этого выбираем действие».

Добавьте две границы. Во-первых, пилот ограничен выбранной зоной и периодом; выводы нельзя автоматически переносить на весь зал. Во-вторых, один яркий случай не важнее повторяющейся последовательности только потому, что его эмоционально описали.

Покажите четыре колонки доски:

Событие	Проверенная или альтернативная причина	Решение	Владелец и дата проверки
что произошло без оценки	что подтверждает объяснение и что ещё возможно	одно изменение или дополнительное наблюдение	одна роль, конкретная дата

Эта доска — главный практический результат ретро. Колонки «понравилось» и «не понравилось» не нужны.

Сначала восстановите путь по эпизодам

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

Для каждого эпизода фасилитатор задаёт одинаковые уточнения:

1. Когда и в какой зоне это произошло?
2. Какой наблюдаемый шаг был перед сбоем?
3. Кто первым заметил проблему?
4. Как команда восстановила путь?
5. Есть ли запись заказа, времени, вопроса гостя или действия сотрудника?
6. Повторилось ли событие при похожих условиях?

Не превращайте эти вопросы в анкету для каждого человека. Они нужны, чтобы восстановить один эпизод совместно. Если ответа нет, карточка получает статус «нужно наблюдение», а не придуманную причину.

Затем проверьте альтернативные причины

Один симптом часто допускает несколько объяснений. Гость не дошёл до заказа из-за непонятной карточки, отсутствующей позиции, слабой связи, цены или желания поговорить с официантом. Зависший заказ может быть связан с сигналом, распределением ролей или нагрузкой кухни.

Используйте три вопроса против поспешного вывода:

• Что ещё могло вызвать тот же симптом?
• Какой факт различит эти объяснения в следующей смене?
• Можно ли проверить причину одним изменением, не перестраивая весь сценарий?

Сильное решение меняет одну переменную или добавляет одно наблюдение. «Переобучить всех и переписать всё меню» скрывает причину. «Уточнить фразу у двух пилотных столов и считать обращения за помощью» оставляет проверяемый след.

Отделите процесс от неприятия пилота

Сопротивление команды нельзя выводить из одной жалобы. Сначала проверьте, не создал ли процесс лишнюю работу без понятной ответственности. Если сотрудник должен следить за новым экраном, вести прежнюю запись и ещё объяснять гостю два конкурирующих сценария, негативная реакция описывает дизайн работы, а не отношение к технологии.

Задайте участникам четыре вопроса:

• Какое новое действие появилось и какое старое должно было исчезнуть?
• В какой момент две роли считали, что отвечает другая?
• Где сотруднику пришлось переписывать уже введённые гостем данные?
• Какой резервный сценарий сработал, а какой создал путаницу?

Если роли не были отрепетированы, не требуйте от ретро ответа о масштабировании. Сначала проведите пятнадцатиминутную репетицию смены и повторите наблюдение.

Дайте каждой роли собственный вопрос

Общий вопрос «что было неудобно?» почти всегда собирает разрозненные мнения. Ролевые вопросы возвращают участника к тому участку, который он действительно наблюдал.

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

Бариста или кухне: какой заказ потребовал уточнения, переделки или отдельного поиска? Был ли состав уже неполным при получении или информация потерялась позже?

Администратору: где заказ вышел из обычной очереди действий, кто это заметил и какой резерв сработал? Сколько похожих событий можно подтвердить журналом?

Владельцу меню: совпадали ли цена, доступность, варианты и описание с фактическим предложением? Какое расхождение могло объяснить отказ без связи с новым каналом?

Владельцу пилота: какое исходное решение должна была поддержать неделя и какие данные всё ещё не позволяют его принять?

После каждого ответа фасилитатор просит показать след события или помечает карточку как гипотезу. Так мнение остаётся полезным, но не маскируется под факт. Если два участника описывают один заказ с разных сторон, объедините записи в одну цепочку, а не считайте их двумя инцидентами.

Превратите карточки в решения

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

1. Исправить сейчас: причина подтверждена, изменение мало и обратимо.
2. Проверить отдельно: есть две правдоподобные причины, нужен различающий сигнал.
3. Оставить без изменения: эпизод единичный, риск мал, данных пока недостаточно.
4. Остановить участок пилота: сбой создаёт риск для гостя или команда не может надёжно принять заказ.

Решение формулируйте как действие и наблюдаемый результат. Не «улучшить табличку», а «заменить первую фразу на пилотных столах; в следующую вечернюю смену отметить обращения за объяснением». Не «наладить статусы», а «закрепить принятие за старшим бариста и проверить все заказы в выбранном окне».

У каждой строки должен быть один владелец по роли. Несколько соисполнителей допустимы, но формулировка «ответственна команда» почти гарантирует, что проверка потеряется.

Закройте встречу контрольным чтением доски

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

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

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

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

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

Что ломает ретро

Общие впечатления вместо событий. Фасилитатор возвращает разговор к времени, месту и действию.

Поиск виноватого. Ошибка сотрудника тоже требует вопроса о доступе, инструкции, сигнале и нагрузке.

Решение до причины. Новая функция или обучение не помогают, если неизвестно, где начался разрыв.

Слишком много действий. Несколько одновременных правок лишают следующую смену объяснимого результата.

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

Ретро считается завершённым после назначения проверки

Хороший разговор не заканчивается фразой «в целом стало понятнее». На доске остаются подтверждённые события, честные альтернативные причины и несколько действий с владельцами. Когда команда знает, что именно изменится и какой факт будет проверен в следующей смене, ретро превращает первую неделю в управляемое продолжение пилота.