Короткий ответ. Ретроспектива команды нужна, чтобы посмотреть на завершённый период и изменить способ работы, а не ещё раз перечислить текущие задачи. Выберите границы обсуждения, соберите конкретные наблюдения и разберите одну повторяющуюся трудность. В конце договоритесь об одном посильном изменении: кто поможет его проверить, на каких задачах и когда вы вернётесь к результату.
Определите, на какую работу смотрите назад
«Давайте обсудим, что у нас не так» — приглашение слишком широкое. Один человек вспомнит вчерашний разговор, другой — прошлогодний проект, третий начнёт распределять задачи на завтра. Чтобы ретроспектива не растворилась в общей усталости, обозначьте период или завершённый этап.
Это может быть месяц работы студии, подготовка серии занятий или законченная часть проекта. Назовите, что входит в разговор и что остаётся за его пределами. Текущие срочные решения вынесите отдельно: встреча о прошлом процессе не должна незаметно превращаться в оперативную планёрку.
Пригласите людей, которые участвовали в этой работе и видели разные её части. Заранее объясните, кто ведёт обсуждение и кто может подтвердить предлагаемые изменения. Если у команды нет полномочий менять внешний процесс, она всё равно может сформулировать вопрос для ответственного, но это не то же самое, что принять решение за него.
Соберите наблюдения до готовых решений

Начните с нескольких минут самостоятельных заметок. Так у участников будет возможность сформулировать свою мысль до того, как разговор задаст самый быстрый или уверенный коллега. Можно использовать бумагу или привычный рабочий документ — специальная доска не обязательна.
Попросите описать событие, его влияние на работу и вопрос, который остался. «Дважды искали актуальную версию текста перед передачей макета» даёт предмет для разбора. «У нас бардак» передаёт впечатление, но пока не показывает, что менять.
Собирайте и полезный опыт. Если команда обсуждает только сбои, она может случайно отказаться от того, что уже помогает. Например, короткое подтверждение готовности материалов перед началом работы стоит сохранить, даже если сам проект завершился с другими сложностями.
| Первая формулировка | Более предметное наблюдение | Вопрос для обсуждения |
|---|---|---|
| «Все постоянно отвлекают» | Уточнения по одному заданию приходили в нескольких разговорах | Где собирать вопросы по конкретной передаче работы? |
| «Никто ничего не проверяет» | Перед началом следующего этапа не было общего подтверждения версии | Как понять, какой материал готов к использованию? |
| «Сроки опять плохие» | Изменение исходных материалов не сопровождалось обсуждением нового объёма | В какой момент пересматривать договорённость о работе? |
| «Этот проект прошёл легко» | Перед передачей участники сверили готовность и открытые вопросы | Что из этого порядка можно сохранить? |
Не требуйте доказательств для каждого переживания, но разделяйте наблюдение и объяснение причины. Участник может сказать, что ему было трудно получать ответ. Это повод уточнить ситуацию, а не сразу объявить коллегу невнимательным. Если фактов не хватает, отметьте неопределённость вместо коллективной догадки.
Обсуждайте условия, а не характер коллег
Роль ведущего — помочь разобраться, как возникла ситуация. Полезны вопросы «что было известно в тот момент?», «где ожидания разошлись?» и «какого сигнала не хватило?». Вопрос «почему вы снова так сделали?» часто уже содержит обвинение и сужает возможность объяснить контекст.
Одни и те же события участники могли видеть по-разному. Дайте каждому описать свою часть, не требуя немедленно согласиться с общей версией. Если разговор перешёл на личные качества, верните его к конкретным действиям и рабочим условиям.

Правила разговора стоит проговорить: не перебивать, не приписывать мотивы, не использовать личные признания как аргумент против человека. Но одной фразы «здесь безопасно» недостаточно. Люди опираются на прежний опыт общения. Не обещайте анонимность, если формат её не обеспечивает, и не вынуждайте участника публично объяснять чувствительную ситуацию.
Если возник острый личный конфликт или вопрос, требующий отдельного решения руководителя, обозначьте другой порядок обсуждения. Ретроспектива не должна превращаться в публичное разбирательство. Ведущий может остановить конкретную тему, уточнить, кто возьмёт её дальше, и вернуться к совместной работе.
Учебный сценарий: завершённая серия клиентских проектов
Представим небольшую команду, которая готовит тексты и визуальные материалы для клиентов. Завершилась серия проектов. На ретроспективу выделили час; задача — понять, почему передача материалов несколько раз требовала повторного уточнения. Это учебный пример, а не описание результатов реальной компании.
Сначала — границы и события. Ведущий напоминает, какие проекты обсуждаются. Участники самостоятельно записывают эпизоды, затем коротко поясняют их. Команда отмечает и удачную передачу, где заранее согласовали актуальную версию.
Затем — одна тема. Среди наблюдений есть разные сложности, но команда выбирает передачу текста дизайнеру: ситуация повторялась, участники понимают её и могут изменить собственный порядок. Другие темы сохраняют отдельно, не обещая исправить всё одновременно.
Дальше — восстановление условий. Автор считал файл готовым, потому что отправил ссылку. Дизайнер ждал отдельного подтверждения. Оба действовали исходя из разных ожиданий. Обсуждение не заканчивается выводом «надо внимательнее»: команда называет отсутствующую договорённость.
В конце — ограниченная проверка. На следующем подходящем проекте участники попробуют передавать материал одним сообщением: актуальная ссылка, что готово и какие вопросы ещё открыты. Они заранее назначают короткое обсуждение после этой передачи, чтобы понять, помог ли новый порядок.
Что изменилось в формулировке: вместо «улучшить коммуникацию» появилось конкретное действие в конкретной точке работы. Его можно выполнить, заметить пропуск и обсудить без оценки личности сотрудника.
Превратите пожелание в одну проверку

Хороший кандидат на улучшение находится в пределах влияния команды, связан с наблюдаемой трудностью и не требует большой перестройки до первой попытки. Если предложение звучит как «заменить все инструменты», уточните, какую конкретную проблему это должно решить и можно ли проверить более узкое действие.
Не выбирайте изменение только по числу голосов, если оно создаёт существенную нагрузку для одного участника. Обсудите, кто будет делать дополнительную работу и что потребуется. Согласие на общую идею ещё не означает согласие лично выполнять новый процесс.
Ответственный за проверку не становится виноватым, если идея не поможет. Его роль — напомнить о договорённости, собрать наблюдения и вернуть вопрос в обсуждение. Само действие могут выполнять несколько участников.
Карточка одной проверки
- Наблюдение
- При передаче текста не всегда понятно, какая версия готова для следующего этапа.
- Что попробуем
- В одном сообщении укажем актуальную ссылку, готовность материала и открытые вопросы.
- Где проверяем
- На следующем согласованном проекте, а не сразу во всех процессах.
- Кто поддерживает проверку
- Автор и дизайнер подтверждают порядок; координатор возвращает тему к обсуждению.
- Что наблюдаем
- Пришлось ли повторно искать версию, чего не хватило в сообщении, не добавилась ли лишняя работа.
- Когда обсуждаем
- После первой завершённой передачи, в заранее выбранное время.
Критерий не обязательно должен быть процентом. Для небольшой проверки достаточно конкретных вопросов к одному эпизоду. Не выдавайте единичный удачный случай за доказанное улучшение всех проектов. Сначала убедитесь, что участники действительно попробовали договорённость и одинаково поняли её.
Вернитесь к изменению, даже если оно не сработало
На следующем обсуждении начните не со сбора новых претензий, а с предыдущей договорённости. Что попробовали? Что помешало? Где возникла польза, а где лишний шаг? Команда может сохранить действие, упростить его, проверить ещё раз или отказаться.
Если никто не применил изменение, не делайте вывод, что сама идея бесполезна. Разберите, почему: не наступила нужная ситуация, не было времени, участники забыли или задача оказалась слишком большой. Это разные причины, требующие разных решений.
Краткий итог ретроспективы должен содержать выбранную тему, действие и порядок проверки. Личные реплики и спорные оценки не нужно автоматически переносить в общий отчёт. Заранее определите, кто увидит результаты и какая информация действительно нужна для продолжения работы.
- Понятно, какой период и какую тему обсуждали.
- Наблюдения отделены от предположений о причинах.
- Выбрано действие, а не только лозунг.
- Участники подтвердили свою роль в проверке.
- Названы признаки, по которым будете обсуждать результат.
- Есть время для возвращения к договорённости.
Частые вопросы
Нужна ли ретроспектива, если период прошёл спокойно?
Можно обсудить, что помогло работе и что стоит сохранить. Не нужно придумывать проблему ради встречи. Если содержательной темы нет, формат и периодичность можно пересмотреть.
Что делать, если команда молчит?
Дайте время на самостоятельные заметки и предложите вспомнить конкретный эпизод. Не требуйте откровенности по кругу. Проверьте, понятна ли цель и не воспринимают ли участники обсуждение как скрытую оценку их работы.
Можно ли выбрать больше одного улучшения?
Можно, если есть ресурсы и независимые понятные проверки. Но для начала одна выполнимая договорённость часто удобнее списка, к которому никто не вернётся. Количество не является показателем качества встречи.
Должен ли руководитель вести ретроспективу?
Не обязательно. Важно, чтобы ведущий мог удерживать рамку и не подменял вопросы готовыми выводами. Если руководитель участвует как собеседник, полезно дать другим описать свои наблюдения до его оценки.
Оставьте улучшению время для проверки
После ретроспективы важно не потерять следующий разговор. Согласуйте, когда вернётесь к выбранному изменению, а для отдельных обсуждений предложите доступное время по ссылке Sayly. Сам разбор, решения и их выполнение остаются работой команды.
Посмотрите возможности планировщика на главной. В демо можно попробовать клиентский выбор услуги и времени на примере бьюти-сервиса — это пример записи, а не инструмент проведения ретроспектив.