Никому не нравятся дни с долгими бесконечными совещаниями или тысячей коротких, разбросанных в течение дня, но для разработчика такие дни являются наименее продуктивными и наиболее удручающими.
Эта статья призвана указать на то, что делает совещания неэффективными, и как создать здоровую и продуктивную культуру совещаний в команде. Я надеюсь предложить уникальный взгляд, так как за последний год я работал и как разработчик, и как менеджер продукта.
Борьба разработчика
Если вы разработчик, вы знаете боль вглядывания в проблему, погружения в десятки файлов, строк и методов, чтобы понять суть вопроса. Вы наконец-то улавливаете, что вызывает проблему, и планируете принять меры, как вдруг начинается совещание.
После посещения совещания, на котором вам, вероятно, не нужно было быть, вы возвращаетесь к коду и вам нужно догнать поезд мысли, ушедший со станции час назад. Даже если вы документировали свои действия ранее, трудно снова восстановить этот контекст.
Эта потеря контекста ещё более болезненна, когда у вас возникают проблемы с запуском вашего локального окружения. Вы можете потратить часы на устранение неполадок, прежде чем даже приступить к реализации своей функции.
Наконец-то вы добираетесь до написания кода, и БАЦ — обед. Еще через 30 минут или час вам нужно перезапускать когнитивный процесс.
Как разработчик, вы каждый день сталкиваетесь с новыми проблемами и усердно работаете над поиском креативных решений для них, будь то запланированные задачи или какое-то новое обновление ломает ваши локальные среды. Отвлечение на другие задачи в середине работы может нарушить ход мыслей и замедлить решение проблем, что является сутью такой работы.
Это небольшой пример того, как даже одно совещание может нарушить продуктивный поток.
Что делает совещание непродуктивным?
Проведение совещаний часто неизбежно, но как нам перейти от множества непродуктивных совещаний к здоровому режиму эффективных? Во-первых, нам нужно понять, как выглядит плохое совещание.
Слишком много приглашённых людей
Если аудитория слишком велика, вовлеченность будет ниже, и люди будут менее склонны высказываться. Чем больше группа, тем больше людей подумают: «Это меня не касается, зачем я здесь?»
«Это можно было бы отправить по электронной почте»
Это утверждение возникает в рабочем мире слишком часто. Совещание начинается и заканчивается тем, что говорит только один человек, извергая информацию, не требующую обсуждения. При отсутствии диалога между другими членами команды люди будут задаваться вопросом, почему эта информация не была разослана по электронной почте или в объявлении.
Нет четкой повестки дня с самого начала
Когда нет повестки дня для совещания, обсуждение может вращаться вокруг общей темы, но только в ходе диалога может быть выявлена фактическая решаемая проблема. Это один из основных способов растянуть 30-минутное совещание на час.
Следование по кроличьим норам
Побочным продуктом возникновения хороших вопросов является то, что иногда они уводят группу в сторону от темы. Когда модерация не откладывает преследование этой конкретной мысли на потом, совещания уходят от темы и в итоге тратят драгоценное время. Кроме того, если никто не делает заметки и не отслеживает эти темы, ценные идеи будут потеряны.
К сожалению, все эти характеристики объединяются в создание дополнительных совещаний. На исходные темы не получены ответы, возникло больше вопросов, и каково решение исходной проблемы и всех этих новых? Вы угадали, больше совещаний.
Создание решения
К счастью, у многих из этих проблем есть простые решения.
Если вы человек, который руководит командой и проводит эти совещания, попробуйте внедрить несколько методов для повышения общей эффективности.
Установите основное рабочее время
Работайте со своей командой, чтобы выделить блок времени, в течение которого они могут ожидать работы без перерывов; это может значительно повысить производительность и моральный дух команды. В этот промежуток времени (скажем, с 9 утра до 12 дня) не будет запланированных или незапланированных совещаний, если только это не абсолютно необходимо. Несколько преимуществ:
- Члены команды будут чувствовать себя свободными в решении проблем, потому что понимают, что их не прервёт внезапное совещание.
- Команда будет чувствовать, что выполняемая ими работа ценится, потому что для неё выделено специальное время.
- Другие подразделения, пытающиеся назначить совещания со всей вашей командой, будут лучше понимать, как выглядит ваша доступность.
Установите командные нормы для совещаний
Соберитесь как команда, чтобы определить, как выглядят внутренние совещания. Нужно ли всем включать свои веб-камеры? Какие совещания повторяются? Где мы отслеживаем темы, к которым нужно будет вернутся позже? Что мы делаем, когда совещание затягивается?
Формулирование и запись этих ожиданий поможет команде лучше понять, как будут проходить совещание. Они должны понимать, какие совещания проходят каждую неделю и как будут выглядеть неожиданные совещания с другими группами. Сделайте это совместной работой, чтобы совещания больше не казались принадлежащими только одному человеку; они должны принадлежать команде!
Периодически возвращайтесь к этим нормам, чтобы новые члены также чувствовали, что их вклад ценен, и чтобы дела не застаивались.
Всегда имейте повестку дня
Если вы когда-либо получали приглашение от своего начальника с единственной темой «Время NN:NN», вы знаете боль неизвестности. Вы начинаете перебирать в уме любую возможность того, что вы сделали не так, или что недавно произошло, что могло бы поднять эту тему. Чёткая повестка дня совещания должна развеять эти опасения и открыто изложить темы.
Если все находятся на одной волне ещё до начала совещания, будет намного легче оставаться в теме, сохранять фокус и задавать правильные вопросы. Повестка должна содержать решаемую проблему, кто приглашен и как долго, как ожидается, продлится совещание.
Всё это установит, кто должен быть на совещании. Если это строго техническое совещание, следует отметить, что присутствовать должны только разработчики. Эта важная информация даст всем знать, чего ожидать, и модерация будет намного проще, так как вы сможете отложить многие темы, ссылаясь на повестку дня.
Роль разработчика
Если вы разработчик, вы не должны чувствовать себя исключенными из обсуждения этих идей. Ваше мнение должно иметь значение в том, как проводятся совещания, даже если вы просто присутствуете!
Поощряйте хорошую практику проведения совещаний, высказываясь, когда чувствуете, что обсуждение уходит от темы.
Высказывайте свое мнение о том, как проводятся повторяющиеся совещания. Если они неэффективны, попросите совместно поработать над их улучшением.
Участвуйте в обсуждениях — уникальные точки зрения часто являются ключом к поиску решений. Ваша точка зрения может быть ответом!
Активно выступайте за основное рабочее время, если чувствуете, что у вас недостаточно времени в течение дня для написания эффективного кода.
Разработчики могут стать недооценёнными и перегруженными работой, если руководители не понимают, как даже простые совещания отнимают время от работы. Не всегда понимают, сколько работы иногда требуется только для того, чтобы всё запустить и настроить, так что будьте защитником самих себя и делайте своё мнение известным.
Заключение
Совещания могут быть невероятно полезными, но также и невероятно утомительными; мы все должны стремиться сделать их эффективными. Мы должны постоянно оценивать, как мы их проводим, чтобы убедиться, что мы не впали в неэффективные привычки.
Эти советы не являются чем-то революционным, но они являются хорошим напоминанием о том, как мы относимся к своему времени и времени наших коллег.
Надеюсь, вы сможете привнести это в свою команду и увидеть положительные изменения в том, как вы работаете вместе. Удачи!
Это перевод статьи Live Long & Ponder. Оригинальное название: "Why Developers Hate Meetings: A Deep Dive into the Problem".