Привет! Меня зовут Анастасия и я проектный менеджер и scrum‑мастер в Окко. Проектным менеджментом я занимаюсь около семи лет: успела поработать с hardware проектами, CRM‑системами, мобильной разработкой, ритейлом.

За последние два года я провела больше ста ретроспектив. Внутри одной команды, между несколькими командами, иногда — в роли приглашенного фасилитатора. В какой‑то момент поняла, что ретроспективы научили меня гораздо большему, чем просто опыт фасилитатора встреч — я начала иначе смотреть на саму работу менеджера. 

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

В этой статье расскажу, что изменилось в моей работе после появления роли Scrum Master, что оказалось самым неожиданным открытием и почему из всех Scrum‑ритуалов именно ретроспектива стала самым ценным инструментом?

Что такое ретроспектива Scrum и зачем она нужна

Для начала стоит разобраться с терминологией. В командах часто говорят о «ритуалах» или «церемониях Scrum», хотя формально Scrum описывает события. По состоянию на август 2026 года актуальной официальной редакцией руководства остается версия ноября 2020 года. Внутри спринта — фиксированного цикла длительностью не более месяца — определены планирование спринта, ежедневная синхронизация, обзор спринта и ретроспектива.

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

Ретроспектива завершает спринт, а ее официальная цель — определить способы повысить качество и эффективность работы. Для месячного спринта она ограничена тремя часами, для более коротких спринтов обычно занимает меньше времени.

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

Для моей истории последнее особенно важно. Я не перестала быть проектным менеджером, став скрам‑мастером. Это были две роли, которые в моей рабочей реальности существовали одновременно. Именно это сочетание заставило меня посмотреть на привычные задачи с другой стороны.

Как роль скрам‑мастера изменила работу проектного менеджера

Вообще‑то карьерный план у меня был другим. Примерно через пять лет работы проектным менеджером мне стали регулярно задавать вопрос: почему я не перехожу в продуктовый менеджмент?

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

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

Что изменилось, когда я начала совмещать две роли?

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

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

Именно в этот момент ретроспектива перестала для меня быть очередной встречей в календаре. Сам принцип регулярного анализа работы появился не вместе со Scrum. В двенадцатом принципе Agile Manifesto зафиксирована идея, что команда через регулярные интервалы анализирует, как стать эффективнее, а затем корректирует свой способ работы. То есть речь идет не о проведении разговора ради разговора, а о цикле «проанализировали — изменили».

Почему ретроспектива кажется бесполезной

Именно про ретроспективу я чаще всего слышала как о самом бесполезном событии Scrum.

Я слышала такие отзывы и от коллег, и от знакомых из ИТ, и непосредственно от участников команд.То есть, команда собирается, обсуждает проблемы, закрывает доску в Miro, возвращается к работе, а через две недели снова приносит на встречу ту же тему. И если ретроспектива раз за разом выглядит именно так — у меня для вас плохая новость. Это действительно бесполезное мероприятие.

Повторение тем — не только субъективное ощущение команд. Исследователи Тимо Лехтинен, Юха Итконен и Каспер Лассениус проанализировали 37 командных ретроспектив в распределенной организации почти за три года. Они обнаружили, что некоторые проблемы возвращались в обсуждения на протяжении длительного периода. Команды чаще вырабатывали корректирующие действия для проблем, которые считали находящимися в зоне собственного контроля, а часть вопросов требовала решений за пределами команды.

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

Хорошая ретроспектива продолжается после встречи

Для себя я постепенно пришла к правилу: ретроспектива должна оставлять после себя не только заполненную доску. Мало собраться, пожаловаться и посмеяться. Нужно понять, что именно команда хочет изменить и сформулировать это изменение достаточно конкретно. Определить, кто проследит за реализацией и когда команда вернется к результату. Важно попробовать изменить сам процесс, а потом проверить, помогло ли это.

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

Результат проверки вполне может быть отрицательным. Команда что‑то попробовала, эффект не появился — значит, гипотеза не сработала. Это все равно полезнее, чем месяцами обсуждать проблему не меняя формулировки.

Не забывайте о проблеме доверия

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

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

В проекте Google Aristotle исследователи изучали 180 команд, включая 115 инженерных и 65 команд продаж, и проверяли большое число факторов через десятки статистических моделей. Среди обнаруженных характеристик эффективных команд на первое место они поставили психологическую безопасность. В материалах исследования она описывается именно через возможность межличностного риска: например, сотрудник может признать ошибку или задать вопрос, не ожидая, что команда использует это против него.

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

Как ретроспектива превращается в поиск виноватых

Мое первое знакомство с ретроспективами было далеко не позитивным. В предыдущей компании они больше напоминали разбор полетов. Формально вопрос звучал как «что можно улучшить?». Фактически обсуждение быстро превращалось в «кто виноват?».

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

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

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

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

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

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

На той ретроспективе мы в итоге не разобрали все стикеры. Раньше я могла бы считать это признаком плохо проведенной встречи: раз все темы не успели обсудить, значит, фасилитация не удалась. Но дело в том, что мы потратили много времени на корректировку вопросов. Я поняла, что мы не можем уйти со встречи без action items, поэтому проголосовали за самые «больные» стикеры и именно по ним обозначили варианты решений. И это оказалось важнее количества закрытых карточек.

Не каждую проблему надо решать на ретроспективе

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

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

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

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

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

Когда команде «нечего обсуждать»

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

Открываешь доску — там почти ничего нет. Спрашиваешь, что можно улучшить? А в ответ: всё нормально.

Раньше я могла воспринимать такой диалог буквально: возможно, действительно нечего обсуждать. Но потом увидела закономерность. Иногда проблема не в отсутствии материала, а в масштабе вопроса. Ответ на вопрос «Что нам нужно улучшить?» требует от человека за несколько секунд просканировать весь спринт, все процессы и взаимодействия и самому понять, что из этого заслуживает обсуждения.

Поэтому лучше сузить задачу. Например: «Что в наших процессах в этом спринте сработало особенно хорошо и что нам важно не потерять?» Или вернуть команде конкретное наблюдение: «Во вторник на ежедневной синхронизации обсуждали такую‑то сложность. Она еще актуальна?»

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

Интересно, что исследование Алессандры Милани, Маргарет‑Энн Стори, Вивека Катиала и Лорен Пит 2025 года описывает похожую проблему уже с точки зрения данных. Авторы опросили представителей 19 команд. В выборке 84% команд проводили ретроспективы примерно каждые две недели, 63% обычно отводили на встречу час, а 79% использовали собственные доски и инструменты. При этом только шесть респондентов сообщили об использовании объективных проектных данных непосредственно в обсуждении, тогда как девять указали на использование субъективных данных. Исследователи отмечают, что подготовка ретроспективы часто начинается еще до встречи: команды заранее добавляют темы и собирают показатели.

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

И, наоборот, показатель без контекста легко превращается в оружие. Само по себе количество закрытых задач ничего не говорит о сложности этих задач. Число комментариев при проверке кода ничего не сообщает о профессионализме разработчика. А количество дефектов без понимания продукта и способа их обнаружения тоже может легко ввести в заблуждение. Поэтому задача ретроспективы для меня — соединить наблюдения команды с проверяемыми фактами там, где это возможно.

Как выбирать формат ретроспективы под состояние команды

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

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

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

Межкомандные проблемы

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

На уровне нескольких команд появляются зависимости. Команда А может видеть проблему, но не владеть системой, в которой она возникает. Команда Б может отвечать за часть процесса, но не иметь права изменить общий порядок работы. Какой‑то вопрос может находиться на уровне продукта, архитектуры или организации. Поэтому одна из полезных проверок при обсуждении — находится ли изменение вообще в зоне влияния участников встречи. Если да, имеет смысл формулировать эксперимент и попробовать его.

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

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

Почему фасилитатору важно не приносить готовое решение

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

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

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

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

Как понять, что ретроспектива сработала

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

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

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

Чему сто ретроспектив научили меня как менеджера

Попробую собрать этот опыт в несколько ключевых мыслей:

  • Ретроспектива — это не встреча, а инструмент изменения. Её ценность определяется тем, изменилось ли после обсуждения хоть что‑то в способе работы.

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

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