Каждые две недели у нас проходит ретроспектива. Мы созваниваемся в корпоративном мессенджере и начинаем разрисовывать доску в Miro. В разных форматах мы отвечаем на три одни и те же вопроса: «Что было хорошо? Что было плохо? Что будем менять?».
Сначала обсуждается первый вопрос — про «хорошо». Кто-то смеётся, говорит «код ревью стали быстрее», «выкатили релиз без багов». А потом очередь доходит до кого-то, кто не настроен активно высказываться и наступает тишина. Все ждут его спич, но тот пожимает плечами и бросает: «Да вроде всё нормально».
А это яркий ред флаг. Мы обнаружили молчуна. И вроде не хочет человек высказываться. да и ладно — других послушаем. Но это склонность молчать и умалчивать будет разрастаться как плесень и захватит всю команду. И уже через несколько спринтов такой ответ может стать нормой, а это опасно.
Когда вся команда говорит, что всё хорошо или нормально — это ложь. Потому что идеальных проектов не существует. Если вы не находите проблем — вы просто не хотите их замечать.
Почему мы молчим
Страхов три. И все они иррациональны.
Первый — боязнь показаться нытиком. Сидишь и думаешь: «Вот начну говорить про устаревший webpack, который собирает бандл 5 минут. А всех это вроде бы устраивает Назовут паникёром».
Второй — страх обидеть коллег. Особенно если проблема в профессиональном рабочем конфликте, чужом коде или в ревью, которое затянулось на три дня из-за непонятных причин.
Третий — ложное убеждение, что «так сложилось исторически». Мол, проекту три года, и медленная сборка — это уже не баг, а фича, лучше смириться.
К чему приводит «всё хорошо»
Я видел команды, где ретроспектива превращалась в коллективное самовнушение. Два ретро подряд все говорили «у нас все окей и вообще огонь». А на третий спринт релиз откатывали с прода три раза за неделю, лид уволился, а заказчик пришел с желанием закрыть проект.
«Всё хорошо» — это не гармония в коллективе. Это вязкое болото. В нём нет видимых проблем, но и развития нет. Технический долг накапливается как снежный ком. Вы не обсуждаете, что CI/CD пайплайн пора переписать. Не говорите, что документация устарела и контракты API отличаются от зафиксированных в требованиях. Не поднимаете тему, что тимлид берёт слишком много задач и горит.
А потом бац — и ложится прод.
Как превратить ретроспективу из ритуала в инструмент
Правила простые. Их стоит донести до каждого члена команды.
Правило 1. «Хорошо» не значит «идеально».
Хорошо — это когда мы выкатили фичу. Но почему релиз съехал аж на две недели вперед? Что тормозило? Не бойтесь говорить в стиле «хорошо, но есть нюанс».
Правило 2. Вводим ритуал «Одна вещь, которая бесит».
Каждый участник, включая тимлида и QA, называет ровно одну проблему. Не «всё плохо», а конкретика: «Меня бесит, что мы тратим 10 минут на запуск дев-сервера». Без имён, без обид. Фокус на процессах и инструментах.
Правило 3. Фиксируем боль в цифрах.
«Сборка медленная» — нытье. «Сборка на stage занимает 4 минуты 20 секунд, в два раза дольше, чем месяц назад» — уже проблема. Начинайте мерить. Девтулзы, профилировщики — всё в дело.
Правило 4. Ответственность за решение — не только за «критику».
Сказал «бесит долгий npm install» — будь готов предложить вариант: кэшировать node_modules в CI, перейти на pnpm или хотя бы проголосовать за то, чтобы кто-то это покопал. Ретроспектива без экшен-пойнтов — это просто вечеринка жалоб.
А если ваше мнение игнорируют?
Бывает и так. Ведущий ретро спрашивает «что не так?», а сам сидит с каменным лицом, а потом говорит «это не приоритет». Что делать в таких случаях?
Не получается публично, пробуем лично. Пишите тимлиду или ответственному за планирование: «На ретро я постеснялся, но у нас проблема с тестами: 30% упавших, и мы их чиним руками. Может, выделим полспринта?»
Если вас и после этого игнорируют — это уже не ваш уровень проблем. Это системный баг компании. И тогда «всё хорошо» становится индикатором того, что вам пора обновить резюме. Потому что команда, которая не решает проблемы, не развивается.
Чек-лист для следующей ретроспективы
Подойдите к вашей следующей ретроспективе не как к формальности, а как к обязательному аудиту процессов и инструментов. Вот три вопроса, на которых стоит сфокусироваться, при подготовке к созвону:
- Что мы делаем сейчас, что занимает сильно больше времени, чем должно? (Сборка, деплой, ручное тестирование.)
- Какая проблема у нас уже есть полгода, но мы её не решаем, потому что «нет времени»?
- Если бы мы могли удалить одну вещь из нашего процесса, что бы это было?
Запишите ответы. Потом выберите один пункт и сделайте его задачей на следующий спринт. Не «подумать», а конкретный тикет с исполнителем и дедлайном.
Главная мысль
Сплошной позитив на ретроспективе — признак того, что у команды нет косяков. Но косяки лампочки есть всегда. Просто на них часто закрывают глаза.
Откройте глаза сами и помогите коллегам. Пусть команда увидит все проблемы — маленькие, неудобные, старые. Только тогда вы перестанете тонуть в болоте псевдоидеального проекта и начнёте реально улучшать продукт.
А если кто-то скажет «да ладно, и так сойдёт» — покажи ему эту статью. Или просто спроси: «Ты правда хочешь сидеть в болоте ещё год?»
Желаю успехов!
