Тут важно выделить две фазы, как в брейншторме:

1. обсуждение проблем и генерация идей по устранению проблем;

2. выбор среди тех идей, которые будем реализовывать.

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

Далее из идей выбираем несколько (5±2) конкретных улучшений, которые команда готова сделать. Устройте голосование, если идей целая куча. Желательно успеть за следующий спринт.

Некоторые типы идей я отсеиваю. Или прошу переформулировать.

1. «Мы работали плохо, теперь давайте работать лучше».

Спасибо за лозунги. Но я не знаю, как это реализовать.

2. «Не жрать после 18:00» или «Проводить стендап за 10 минут ровно».

Богатая идейка! Больше похожа на правило.

Если бездумно добавлять правила – место кончится. Или будет вагон правил, которые не блюдут. А это дискредитирует власть. Или это будут правила, которые помнит только их автор. И ненавидит коллег за несоблюдение.

Переформулируйте на локальное и исполнимое: «Не жрать после 18:00 в течение следующего спринта», например. Вот это реалистичнее.

3. «Давайте будем закладывать больше времени на подготовку и архитектуру».

Во-первых, это тоже правило. Во-вторых, не люблю, когда добавляются буферы времени.

На это есть Закон Паркинсона: работа занимает все отведенное на нее время. И даже чуть больше. Сколько буферов ни закладывай – будет мало.

Давайте лучше адекватно оценивать задачи и делать дело так быстро, как это возможно, не?

4. «Давайте проверять после тестировщика – другим тестировщиком».

Ну уж нет! Чем больше проверяющих, тем хуже качество. Зачем мне стараться, если за мной перепроверят и под носом подотрут? Рассеивается ответственность.

Я хочу «встроенное» качество как можно ближе к центру создания ценности. Я хочу встроенное в программистов качество. И они это могут!

5. «Пусть менеджер нам кофе приносит. С козинаками. И веером нас обдувает».

На ретроспективах менеджеру легко наловить себе обезьян на голову. Я видел ретроспективы, где команда навешивала на менеджера-слабака кучу правил, которые должен выполнять только менеджер.

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

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

6. «Давайте все к черту перепишем».

Вот это происходит у меня прямо сейчас, в работающем проекте аптечной сети, где 5000 аптек, первая в стране доставка лекарств online, тысячи пользователей. Просто проекту 4 года, и там нет реактивного фреймворка. А это не так весело и круто. Программисту скучно.

То есть, идея предложена как бы во благо проекта, но чувствуется сильный личный мотив. Почесать ЧСВ, поиграть с технологиями, стать незаменимым и так далее. Словом, почувствовать себя крутым! Я не вижу ничего дурного в таких личных мотивах – они полезны. И без их удовлетворения не будет кайфа на работе.

Но формулировку мы поменяем. «Составить план рефакторинга» – уже теплее. Этот план я внимательно изучу на целесообразность, адекватность прогнозов. Согласую с клиентом и внедрю. Постепенно.

7. «Пусть дизайнеры всегда теперь делают по-другому».

Это когда проблемы пытаются решить за счет отсутствующих на ретроспективе людей. Иногда – оправданно. Но! Естественно, отсутствующие будут не согласны.

Или придумываем правила, которые нужно распространить на всю компанию, а не только на одну команду.