Как сделать митинги продуктивными:

  • Следить за активностью общения?
  • Выписывать все шаги к действиям?
  • Подготавливать протокол совещания?
  • Собирать после митингов обратную связь?

Единственное, что вам поможет - не проводить никаких встреч вообще!

Meetings killing a project meme

Для чего встречи менеджерам

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

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

Совещания призваны освещать “статус”. Рассказать о планах на квартал/полугодие/год. Рассказать о новых процессах. Попытаться получить голосом обратную связь от трудящихся. Провести ретроспективу. Стендап. Груминг. Каждое совещание собирает несколько человек одновременно во времени и все они начинают тратить свое внимание, время и деньги проекта. Поэтому все менеджеры хотят сделать совещания продуктивными, чтобы деньги за час каждого участника встречи не были потрачены напрасно.

Встречи с точки зрения участника

Если взглянуть со стороны участника, то что для него значит совещание? Это магистраль информации, к которой нужно подключиться на какое-то время, прервавшись от своей задачи, усвоить излагаемое, а затем снова вернуться к текущей задаче. Бывает даже так, что после совещания приходится бросить прерванную задачу и начать новую. Кажется, это называется “многозадачность”. Так вот, господа менеджеры, переключая контекст участник проекта теряет концентрацию, и это вредит … ПРОЕКТУ. Та да! Может вы еще не читали исследований на тему “multitasking and brain”, то вот вам статья с громким названием: “Multitasking Is Killing Your Brain” by Larry Kim.

На самом деле таких статей очень-очень много:

Все они не просто чьи-то размышления, там есть ссылки на реальные исследования, в которых показано как многозадачность уменьшает IQ. Поэтому если вы думаете, что “сейчас голосом созвонимся и обсудим всей командой быстренько”, то это прямой удар по качеству проекта.

Что же делать вместо митингов?

Хватит собирать ежедневные совещания, чтобы проверить “статус”, убедиться, что мы “успеваем”, спросить “как дела”, доложить об “обстановке”. Научитесь делать это иными инструментами.

Стендапы

Вместо стендапа посмотрите на доску в Jira, там явно видно кто и чем занимается. При желании можно даже увидить прогресс (или его отсутствие). Чтобы прогресс было проще отслеживать - заставляйте делать детальную декомпозицию задач. Сложные задачи просите разбивать на мелкие. Иначе прогресс не увидеть.

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

Планы по релизам

Посмотрите на сроки релиза. И оцените самостоятельно, “успеваем” мы или нет. При детальной декомпозиции и оценке прогресса можно будет сделать предположение о том, успеем к назначенной дате или нет. Например, пусть есть 15 задач с равной сложностью. За предыдущие две недели сделали 10 задач. Это значит, что за еще одну неделю будет сделано еще 5 задач. И если релиз нужно сделать на этой неделе, то точно не успеем, и надо что-то придумывать.

Обсуждение roadmap-а

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

Ретроспективы

На ретроспективах разбирают проблемы, и некоторые из них пытаются решить. Чем это отличается от задач в трекинговой системе? По собственному опыту: если не готовиться к ретро, то никакую проблему и не вспомнишь прямо на встрече. Есть вариант по-лучше: обнаружил проблему - создай задачу. Не знаешь, как решить? Тогда пусть это будет R&D задача. Знаешь, как решать - напиши качественное описание и расскажи, как, по-твоему, эту проблему можно решить. Затем сформируй письмо и отправь рассылку тем, кто заинтересован в решении этой проблемы, чтобы обсудить и запланировать.

Таким образом каждая проблема не ускользнет от обсуждения и решения. Асинхронно. Без митингов.

Декомпозиция/оценка

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

Жизнь без митингов

Думаете, это сказки? Посмотрите на любой open source проект! Люди работают над открытыми продуктами вместе, даже не зная как зовут друг друга в реальной жизни. Потому что они общаются только через VCS и issue tracker-ы. Все так или иначе используют Open Source в своих проектах (99% проектов содержат в своей кодовой базе хотя бы одну open source зависимость, при этом всего open source кода 70% в среднем в проектах), поэтому это проверенный подход в разработке.

Окей. Вы наверное, считаете, что в реальном бизнесе совсем другая идеология и там зарабатывают деньги. Поэтому такие подходы не будут работать в enterprise. Это не верно, так как есть примеры компаний, работающих 100% remote с минимальным количеством встреч. Вот как GitLab устроил свой менеджмент. У Basecamp есть правило - меньше митингов и прерываний, чтобы сотрудник занимался той задачей, которую ему дали. Помните кучу ссылок про проблемы многозадачности? В Basecamp это давно поняли.

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