10. Вред и польза собраний

Я не очень-то люблю собрания. Особенно всякие статус митинги, дейли митинги, координационные сессии и пр. Но не все так просто. Для некоторых вещей собрания совершенно необходимы. Сколько их должно быть? Какие важные, а какие не очень? Сколько времени на них тратить еще ОК? Давайте поговорим на эту тему.

Сейчас я вот читаю книжку про SAFe, и там просто неимоверное количество собраний. Рядовой разработчик около 20–25% времени (!) там проводит на собраниях. А Product Owner, вероятно, из них просто не вылазит. Scrum в этом отношении немногим лучше.

Мое мнение таково. Разработчики должны тратить на собрания не больше четырех часов в неделю, то есть около 10% своего времени. Для менеджмента планка поднимается до 50%, или до 20 часов в неделю. Лично у меня на собрания уходит около 20% времени, то есть около 8 часов в неделю.

В первую очередь, нужно совершенно беспощадно выпиливать все статус митинги. Если вы, как менеджер, хотите знать обо всем, что происходит в команде, поймите одно — вам это не нужно. Вам не нужно знать, что происходит, но вам необходимо замечать *важные* проблемы. Статус митинги часто используются как механизм выявления проблем. Отчасти это работает, но из-за каденса собраний проблемы доносятся поздно. Процессы должны выстраиваться таким образом, чтобы проблемы доносились (и решались) в момент возникновения. Люди должны понимать, какие проблемы они могут решить сами, а для каких необходимо внимание руководства. Кажется, это сложно…

Но нет! Это легко! По умолчанию команда разработчиков имеет право решить любую проблему. К руководству следует обращаться, только если решение существенно увеличивает время разработки, либо команда сама не уверена в правильности решения. Если же команда уверена и это все укладывается в разумные рамки, пусть решает как ей хочется. Да, ошибки неизбежны, но решая ВСЕ проблемы самостоятельно, менеджер просто не дает людям возможности научиться.

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

Какие собрания полезны?

1. Создание единого контекста. Например, когда руководитель компании рассказывает о том, куда мы двигаемся и что вообще происходит вокруг. Или когда собираются дизайнеры и показывают друг другу над чем они работают и какие решения принимают. Или новичкам рассказывают о том, как компания работает и куда они вообще попали. Или перед стартом новой фичи команда целиком обсуждает, зачем ее надо делать и как это будет происходит. Создание контекста очень важная задача. Без единого контекста очень сложно объединить людей более-менее общими целями. Без единого контекста компания превращается в группу разрозненных и плохо взаимодействующих команд, а команда в группу разрозненных и плохо взаимодействующих людей.
2. Решение проблем. В одиночку проблемы решать весело, но в небольших группах еще веселее. Живая дискуссия с участием 3–6 человек часто бывает плодотворной. Желательно чтобы перед дискуссией все ее участники подумали о решениях самостоятельно. Почему-то этим часто пренебрегают, и думают, что можно вот так просто пойти на собрание и решить любую проблему без подготовки. Иногда можно, но с подготовкой глубина дискуссии гораздо выше.

Полезны ли разнообразные планирования? Да, если они помогают создать единый контекст. Полезны ли ретроспективы? Да, если там решаются проблемы. Вообще очень полезно начать с 0 собраний, и потом добавлять некоторые по необходимости. Так делает любой уважающий себя стартап. Со временем собрания добавляются, но почему-то не удаляются. В итоге в старых компаниях их какое-то неимоверное количество. Просто потому, что “всегда так было” и статус кво никто даже не оспаривает. Так что нужно время от времени пересматривать все имеющиеся собрания, убирать ненужные и пробовать заменять их асинхронными способами коммуникации. Например, текстом.