Раз в две недели мы собирались на ретро, обсуждали проблемы и фиксировали договоренности. Потом начинался новый спринт, появлялись срочные задачи и релизы — и уже к следующей встрече 80–90% пунктов оставались нетронутыми. Один из коллег называл такие встречи «нытингами»: пришли, поныли и разошлись.
При этом молчание на ретро не всегда означает, что команду все устраивает. Иногда люди, например, не хотят начинать разговор, который ни к чему не приведет. Иногда боятся реакции руководителя или просто понимают, что еще одна проблема растянет встречу на несколько часов.
Меня зовут Евгений Константинов, я проджект-менеджер в Cloud.ru. За годы карьеры проводил ретро в разных командах, а на прошлом месте работы готовил стажеров. Сегодня я расскажу, как отличить разные причины молчания на ретро и что может сделать ведущий, чтобы встреча приносила пользу.
Красные и зеленые флаги ретро
Ретро не обязано быть бурным. Не страшно, если кто-то промолчал или команда не собрала доску из десятков карточек. Важно, заметили ли участники реальную проблему. А главное — решили ли они ее.
Я бы насторожился, если:
Команда каждый раз возвращается к одним и тем же проблемам.
Участники предлагают только безопасные улучшения вроде «лучше планировать» — критерии готовности у таких решений нечеткие и нет явных definition of done.
После встречи остается длинный список пожеланий без ответственных за задачи.
Спорные темы всплывают только в личных чатах.
Ретро затягивается, и люди соглашаются на что угодно, лишь бы закончить.
Обсуждение ошибок превращается в разбор конкретного сотрудника.
У полезного ретро другая динамика. Команда обсуждает конкретный эпизод, выбирает следующий шаг и возвращается к нему после встречи. Сложную тему можно вынести в отдельный созвон, а часть проблем честно отложить, если они пока не горят. Главное, чтобы участники понимали, что произошло с их идеями и предложениями.
Поэтому оценивать ретро по количеству реплик бессмысленно. Иногда один конкретный пункт полезнее полной доски стикеров.
Три голоса молчания
Прежде чем менять формат встречи, нужно понять, почему люди молчат. Я вижу как минимум три разных сценария.
1. «У меня все и так нормально»
Бывает, человеку реально нечего добавить. Его устраивает своя часть работы, а заметных проблем за спринт не было. Это вариант нормы, тут не нужно выбивать фидбэк из сотрудника.
На наших ретро высказываются не все. Сегодня у одного человека накопилось несколько тем, на следующей встрече больше говорит другой. Кто-то поднимает вопросы на дейлике, и мы сразу переносим их в бэклог ретро. Обязательный круг с вопросом «Вася, а что у тебя?» в такой ситуации только давит и заставляет придумывать проблему. Не повышайте стресс у сотрудников, им и своего хватает.
2. «Давайте уже закончим»
Иногда участник молчит, потому что любая новая реплика грозит еще несколькими часами обсуждения. После долгой встречи люди согласны на любое решение, лишь бы вернуться к работе. Я видел такое однажды: к третьему часу команда уже готова была взять сколько угодно задач, только бы руководитель отстал.
На наших ретро мы стараемся до такого не доводить. Если время заканчивается, а тема только разгорается, фиксируем ее и назначаем отдельную встречу.
По моему опыту, полтора часа — уже предел, после которого людям трудно удерживать внимание.
3. «Все равно ничего не изменится»
Самая неприятная причина молчания — когда человек видит проблему, но не верит, что разговор ее исправит. Возможно, команда уже предлагала изменения, но о них забыли. Или сотрудник боится показаться конфликтным и думает, что критика обернется против него.
Здесь мы упираемся в психологическую безопасность. Иногда дело не в формате ретро, а в том, безопасно ли в команде говорить о проблемах. Если за неудобный вопрос, признание ошибки или несогласие можно получить публичный разнос, люди быстро учатся молчать.
Еще в 90-е исследовательница Эми Эдмондсон изучила 51 рабочую команду и обнаружила связь: люди чаще просили помощи, обсуждали ошибки и искали обратную связь там, где никто не боялся реакции коллег и руководителя.
Поэтому если вашим сотрудникам тяжело делиться проблемами, одной анонимной доски недостаточно. Сначала команда должна увидеть, что сложная тема не обернется наказанием, а после разговора что-то действительно изменится. Или им хотя бы донесут: «Да, мы видим, что проблема есть. Пока не можем ее решить, но возьмемся за нее, как будет время». Это долгосрочная работа, к ней нужно быть готовым.
Как наше ретро превратилось в «нытинг»
Вернемся к проблеме, которую я описал в начале статьи. Она простая, но показательная: мы проводили ретро раз в две недели, обсуждали накопившиеся вопросы и брали пункты в работу.
Затем начинался обычный спринт: нужно было выпускать изменения в прод, разбирать срочные задачи и договариваться со смежными командами. К следующему ретро большая часть договоренностей (8–9 из 10) оставались в прежнем состоянии. Что-то забывали, что-то не успевали, а что-то откладывали без нового срока.
Встреча постепенно теряла смысл. Зачем снова поднимать проблему, если через две недели она останется там же? Так ретро и превратилось в «нытинг».
Мы решили не ждать следующей ретроспективы. Вместо этого выделили время перед встречами, а затем начали несколько раз в неделю возвращаться к бэклогу после дейликов. Пункты постоянно были перед глазами, поэтому команда не могла легко забыть о них.
По каждому вопросу мы выбирали конкретное действие. Что-то небольшое можно было сделать сразу. Для большого дела — собрать пайплайн. Если требовалось долгое обсуждение, назначали отдельную встречу. Когда решение зависело от руководства или другой команды, определяли, кто пойдет с вопросом и когда вернется с ответом.
Не думайте, что все проблемы удавалось решить быстро. Иногда мы понимали, что утонули в бэклоге и вернемся к задаче только через несколько спринтов или даже полгода. Но это уже не пустое обещание: задача записана, команда знает ее статус и понимает, почему сейчас она не в работе.
Со временем в бэклоге стало больше зеленых отметок. Мы закрыли много самых раздражающих пунктов: для этого меняли процессы, проводили отдельные встречи, договаривались со смежными командами. На одной из ретроспектив я открыл старый список и увидел, что часть задач уже выполнена, хотя мы даже не успели это отметить.
Это изменило отношение к ретро в целом. Когда люди видят, что проблема не уходит в долгий ящик, они охотнее поднимают новые темы. Поэтому следующее ретро я бы начинал не с вопроса «Что пошло не так?», а с предыдущих договоренностей: что сделали, что не сделали и почему.
Не пытайтесь решить больную тему за одно ретро
Ретро помогает обнаружить проблему, но не обязано сразу дать готовое решение. Иногда вопрос слишком большой, чтобы разобрать его за оставшиеся 20 минут.
У нас так было с процессом релизов. Из-за особенностей тестирования и работы с оборудованием команда по-разному видела, как нужно выпускать изменения. Я сам добавил эту тему на доску, люди включились, и разговор быстро разросся. В итоге нам понадобилось еще около трех отдельных встреч, чтобы найти компромисс.
Это не значит, что ретро провалилось. На нем мы признали проблему, собрали позиции и договорились продолжить разговор. А уже на отдельных встречах смогли спокойно разобрать детали.
Если тема уводит встречу в сторону, достаточно зафиксировать четыре вещи: в чем проблема, кто продолжит обсуждение, когда состоится отдельная встреча и кто вернется к команде с результатом. Так участники понимают, что их не оборвали, а разговор получил продолжение.
Ошибку обсуждаем со всеми, человека — один на один
Люди не станут рассказывать о проблемах, если ретро нужно для поиска виноватых. У нас случались серьезные ошибки: человек мог случайно уронить тестовую среду или запустить цепочку событий, которая приводила к сбою в проде и долгому восстановлению.
Но на общей встрече мы не обсуждали, что условный Леша все уронил. Мы исходили из того, что такая ошибка могла произойти с каждым, и разбирали процесс: почему одно действие привело к сбою и что изменить, чтобы это не повторилось.
Если сотрудник не понимает, что именно сделал не так, это отдельный разговор один на один.
Я придерживаюсь простого правила: хвалить публично, корректировать поведение лично. Ретро нужно, чтобы улучшать работу команды, а не выдавать индивидуальную оценку.
Так участникам проще признавать собственные ошибки. Человек может сказать: «Я поторопился и нажал не ту кнопку. Давайте изменим процесс, чтобы один промах больше не приводил к такому результату». Команда получает фактуру для улучшения, а не нового виноватого.
На критику сначала выдыхаем
Даже в безопасной команде критика не всегда звучит спокойно. Иногда человек приходит на ретро на эмоциях и вместо аккуратной формулировки выдает: «Двести сторипоинтов на спринт, вы что, угораете?»
Первое, что стоит сделать руководителю, — выдохнуть. Неприятно слышать претензию к процессу, команде или себе. Но если сразу спорить с формулировкой, человек поймет, что говорить было ошибкой.
Я стараюсь искать здравое зерно даже в резкой реплике. В примере со сторипоинтами можно записать саму проблему — команда взяла слишком много работы — и дальше обсудить факты. Сколько задач переехало из прошлого спринта? Сколько команда действительно может взять? Что делать, если она закончит раньше? Эмоциональная претензия постепенно превращается в решение.
Однажды критика была направлена лично на меня. В бэклоге появился пункт «Женя отправляет всех в сад». Коллеги имели в виду, что я отправлял запросы техподдержки дальше по процессу: в документацию или на самостоятельный разбор. Я не стал доказывать, что действовал правильно. За такой формулировкой была понятная проблема, и я начал менять свое поведение.
Первая реакция руководителя показывает всей команде, что будет с критикой дальше. Если человек высказался и его выслушали, а затем вместе попробовали решить проблему, в следующий раз говорить будет проще.
Если проблема в руководителе, формат ретро не спасет
Бывает и более тяжелая ситуация: слова руководителя расходятся с действиями, сотрудников публично ругают, а критика оборачивается против них. Здесь бесполезно просто менять карточки или проводить новую игру. Команда молчит не потому, что ей надоел шаблон, а потому, что не доверяет человеку, который ведет встречу.
Я сам не оказывался в ситуации тотального недоверия команды, поэтому не буду выдавать этот сценарий за личный кейс. Но один из возможных шагов — пригласить внешнего ведущего, например Scrum-мастера, и самому руководителю не приходить на встречу. Команда сможет выговориться человеку, которого не воспринимает как источник риска.
На этом работа не заканчивается. Руководителю придется услышать обратную связь, признать собственные ошибки и постепенно менять поведение. Убедить команду словами не получится: доверие возвращается, когда новые обещания несколько раз совпадают с действиями.
Часть тем вообще не стоит выносить на общее ретро. Личное состояние сотрудника, индивидуальный конфликт или разговор о качестве его работы лучше обсуждать один на один. Ретроспектива не заменяет регулярные личные встречи.
Чтобы ретро приносило пользу, не нужно вытягивать реплику из каждого участника или превращать встречу в трехчасовой разговор по душам. Достаточно заметить реальную проблему, выбрать следующий шаг и не забыть о нем после закрытия звонка в зуме.
Часть решений команда выполнит сразу. Другие превратятся в задачи или отдельные встречи. Иногда честным результатом будет ответ: «Сейчас мы не можем это изменить». Это все равно лучше, чем обещание, которое вы не сдержите и тем самым подорвете доверите команды.
Если команда видит, что ее предложения меняют работу, ей не нужно каждый раз доказывать, что говорить безопасно и полезно. Люди начинают приносить на встречу проблемы, ради которых ретроспективу вообще проводят.
Расскажите, а как у вас обычно проходят созвоны с командой? Делятся ли коллеги наболевшим или пока не удается разговорить их?
