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

Если вы тимлид, руководитель, скрам-мастер, agile-коуч или просто инженер, который устал от «встреч ради встреч», — наш опыт может вам пригодиться. На связи Алексей Нелюбов, старший консультант по гибким методам разработки в YADRO. В статье расскажу, как мы подошли к описанной проблеме системно: не запрещали созвоны и не устраивали «разгрузочных дней», а собрали данные, проработали каждую группу встреч отдельно и закрепили договоренности в правилах.

Небольшой спойлер о результатах: команда стала тратить на встречи на 188 часов в месяц меньше — это примерно рабочая нагрузка еще одного инженера. Ниже — пошаговый разбор: как собирали данные, что сработало, что не очень и как мы удерживаем результат.

Навигация по тексту

• Откуда взялась проблема

• Шаг 1. Собираем данные: опрос фокус-группы

• Шаг 2. Анализируем: что показали оценки

• Группа 1. Встречи внутри GSM QA: улучшаем сами

• Группа 2. Встречи по фичам: фасилитация, RACI и правила для участников

• Группа 3. Частные «плохие» встречи: право не ходить

• Группа 4. «Хорошие» встречи: высокая оценка — тоже повод разобраться

• Результат: плюс один инженер

• Как удержать результат

• Бонус: куда деть потребность в неформальном общении

• Итоги: чек-лист, если хотите повторить

Откуда взялась проблема

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

Похожая модель и у нас. В дивизионе Телеком разработка идет по фичам. Под каждую фичу собирается рабочая группа (working group, WG): аналитики, разработчики, тестировщики, продакт-менеджеры, архитекторы, представители заказчика. Постоянные же команды собраны по специальностям, и GSM-тестирование — одна из них.

Если хотите выстраивать процессы в больших телеком-проектах вместе с нашей командой, откликайтесь на открытые вакансии. Прямо сейчас мы ищем:

• Senior Project Manager,

• Руководитель группы системных аналитиков,

• Ведущий менеджер программ проектов.

Другие вакансии смотрите на карьерном сайте YADRO.

В 2025 году, когда мы комплексно взялись за наведение порядка во встречах, в GSM-тестировании было пять команд по 6–7 человек, то есть всего чуть больше 30 инженеров. Одни тестируют непосредственно GSM-фичи, другие — решения, где GSM так или иначе задействован: транспорт, платформу, NMS (Network Management System). От каждой команды в рабочую группу фичи обычно входят один-два тестировщика. Сейчас команд уже больше, и департамент продолжает расти.

Как устроено тестирование телеком-продуктов в YADRO, мы рассказывали в отдельной статье.

Помимо рабочих групп, у инженера есть и внутренние встречи департамента: синхронизации команд, созвоны с руководителем, обмен знаниями, обсуждения с архитекторами. По отдельности каждая из них полезна, но в сумме они занимают заметную часть рабочего времени. Особенно когда команда быстро растет, как наша в 2024–2025 годах.

Когда на ежемесячных ретро и в разговорах один на один инженеры стали чаще поднимать тему встреч, а опросы вовлеченности показали общее снижение удовлетворенности совещаниями, мы решили посмотреть на картину целиком. Ретро показывали, что тема важна для многих. На 1-1 звучали конкретные примеры проблемных встреч, хотя готовых предложений, как сделать лучше, было мало. Можно было разбирать каждый случай по отдельности, но вместе с руководителем департамента мы решили подойти к вопросу системно и начать с данных.

Почему мы начали с данных. Эту привычку я вынес еще из техподдержки онлайн-игр, где начинал карьеру. Там я понял: если просто прийти с идеей и сказать, что так будет лучше, ничего не изменится. Нужно посчитать, что именно и насколько станет лучше, — нужны факты. Мой путь к роли ATL (Agile Team Leader) вообще получился нелинейным: техподдержка игр, тестирование и QA-лидирование в геймдеве, софте и железе, и только потом телеком. Как опыт из разных сфер помогает инженеру расти, я подробно рассказывал в отдельной статье на «Истовом инженере».

Шаг 1. Собираем данные: опрос фокус-группы

Опрашивать все 30+ тестировщиков мы не стали. Вместо этого собрали фокус-группу: по 2–4 человека от каждой из пяти команд, на старте около 15 человек. Выборка должна была быть репрезентативной, но не отнимать у команд много времени, поэтому мы брали людей с разным опытом и ролью:

Сколько людей нужно для выборки. Команд с тех пор стало больше, но при повторных опросах мы по-прежнему берем по 2–4 человека от каждой, то есть от 14 до 28 человек. Этого хватает, чтобы увидеть общую картину, не отвлекая всех.

Для опроса хватило простой таблицы. Каждый участник перечислял все свои встречи за последние два-три месяца и указывал по каждой:

• название;

• длительность и периодичность — из них получаем, сколько часов в месяц уходит на встречу;

• что человек на ней делает — слушает, докладывает или обсуждает;

• субъективную полезность для себя по шкале от 1 до 10, где 1 — «абсолютно бесполезно, зачем я туда хожу», а 10 — эталонная встреча, после которой вопросы решены, процессы понятны, а сил только прибавилось;

• комментарий.

Так выглядел пример заполнения:

Любой руководитель знает: если попросить заполнить форму, вовремя ее заполнят не все. Мы напоминали про опрос на каждой командной встрече: заполнение займет 15 минут, а для нас это очень важно. Тем, кто не справлялся сам, помогали. Например, если человек вносит в календарь не все встречи, садились и вспоминали вместе. В итоге таблицу заполнили все участники фокус-группы.

Шаг 2. Анализируем: что показали оценки

Мы свели таблицы вместе, упорядочили и просуммировали. Первое наблюдение: если встреча была объективно проблемной — затягивалась, собирала лишних участников, плохо модерировалась, — большинство это замечало и оценивало ее низко. Отношения в командах достаточно открытые, так что никто не постеснялся и не завысил оценку.

Второе: там, где оценки сильно расходились, например пятеро поставили 9, а один — 2, мы лично уточняли причину у инженера. Иногда это было что-то неочевидное, что заметил только он. А иногда — сугубо личное: «встреча в 9 утра, а мне ребенка в садик отводить» или «тема не моя, я сидел и не понимал, зачем я там».

Почему люди отвечали честно, хотя опрос был неанонимным. Agile-лидер не линейный руководитель инженеров, он работает «сбоку». С командами у нас есть договоренность: если человек не хочет, чтобы его отзыв передавали с именем, мы обезличиваем обратную связь.

В итоге мы выделили четыре группы встреч:

Внутренние встречи и встречи рабочих групп вместе занимали около 80% времени, которое инженеры проводили на созвонах. Четвертую группу мы тоже разобрали: важно понять не только что работает плохо, но и почему что-то работает хорошо. Дальше — по каждой группе отдельно.

Группа 1. Встречи внутри GSM QA: улучшаем сами

Встречи внутри GSM QA организуем мы сами — руководители, техлиды и ATL, так что и карты нам в руки. Порядок действий был такой:

1. Уточнили жалобы. «Мне не нравится эта встреча» может касаться чего угодно — частоты, длительности, пользы, формата, долгих споров, отсутствия повестки или неудачного времени.

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

3. Провели встречи в новом формате и снова собрали обратную связь. Где нужно — докрутили. В среднем становилось лучше за 1–2 итерации, но на некоторых встречах формат пришлось менять три раза.

Несколько примеров:

• Сокращение вдвое. На одной из встреч целый час слушали, кто что протестировал за месяц, — и это было неинтересно. Мы сократили ее в два раза и поменяли формат. Получилась, как в известной комедии, «такая же встреча, только с повесткой и в два раза короче».

• Модерация с таймером. На отчетных встречах выступления часто затягивались. Мы ввели лимит в три минуты на человека, и кто-то из нас следил за временем по таймеру.

• Перевод в переписку. Если статус или новость можно написать в чат, пишем в чат. Сейчас у нас много тематических чатов, и информация рассортирована по ним.

Как отпустить лишних с затянувшейся встречи. Бывает, что обсуждение на общей встрече затягивается: тема интересна пятерым, а сидят пятнадцать. Отпустить остальных можно по-разному, от самого мягкого способа к более решительному:

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

2. Остановить обсуждение и назначить отдельную встречу только для нужной группы.

3. Если мягкие способы не работают, подключить руководителя. Он может прямо попросить команду не слушать встречи в фоновом режиме, а потратить это время на задачи.

Если с первой попытки не получалось, мы просили помощи у коллег: других agile-лидеров, руководителей, людей со свежим взглядом. Работа не закончена и сейчас: недавно впервые за год у нас накопилось столько новостей, что мы не уложились в получасовой слот, и мы снова думаем, как улучшить формат. Непрерывное улучшение — один из базовых принципов Agile, и встречи тут не исключение.

Отдельное решение касалось встреч, которые организуют сами команды. Мы сказали: «Это ваши встречи. Итоговая цель — зеленая сборка и 100% тестов к нужному сроку. Если для этого не нужно собираться каждый день и достаточно через день — собирайтесь через день». Команды так и сделали, и качество работы не просело.

Группа 2. Встречи по фичам: фасилитация, RACI и правила для участников

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

Начали с рабочих групп внутри GSM

Первое, чего не хватало, — структуры, модерации и фасилитации. Ответственными за встречи рабочих групп мы назначили аналитиков. Логика простая: аналитики пишут требования и вместе с разработкой и тестированием проверяют, что фича сделана по ним. В каждой рабочей группе есть минимум один аналитик, и он первым начинает работать с фичей. Всех аналитиков мы отправили на внутренний курс по фасилитации и проведению встреч.

Кроме конкретного ведущего и организатора, для каждой встречи рабочей группы нужны:

• понятная повестка — у нас она ведется на странице в Confluence;

• состав участников, подобранный под конкретную повестку;

• договоренность выносить в чат все, что не требует созвона.

Описали роли: RACI-матрица

Следующим шагом мы договорились о ролях — например, кто за что отвечает на этапе Discovery или когда команда прорабатывает требования к фиче. Роли описали в формате RACI:

• R (Responsible) — исполнитель, который делает работу;

• A (Accountable) — главный ответственный, с которого спрашивают за результат;

• C (Consulted) — те, с кем консультируются;

• I (Informed) — те, кого информируют об итогах.

Роли в матрице:

• Feature Discovery Lead (FDL);

• технический продакт-менеджер (Technical Product Manager, TPdM);

• архитектор решения или ПО (Solution / Software Architect, SA/SWA);

• Requirements and Specification Engineer (RSE);

• Algorithms and Models Engineer (AME) — опционально;

• представитель тестирования, например архитектор тестирования или инженер по тестированию;

• представитель разработки, например Component Technical Leader (CTL) или разработчик;

• Feature Owner Team Leader (FOTL);

• архитектор по безопасности (Security Architect, SecArch) — если нужно вовлечь специалистов по безопасности. Решение принимает сам SecArch или рабочая группа на ранней стадии Discovery.

Пример матрицы:

Теперь у каждой роли есть понятное описание: зачем ее представитель приходит на встречу, какую подготовку от него ждут и какой результат он должен дать.

Правила для участников

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

1. Запросить повестку встречи, если ее нет.

2. Уточнить, нужен ли он на встрече, и определить цель визита. Если цели нет — не ходить, а если что-то понадобится или забудется, прочитать ИИ-выжимку со встречи.

3. Если от встречи нужен только ответ на один короткий вопрос — задать его в начале без очереди или заранее добавить в повестку, а потом уйти, не дожидаясь конца.

4. Подсветить проблему организатору или эскалировать ее своему руководителю, если правила не соблюдаются.

Эскалация действительно работала. Пару раз я вместе с техлидом ходил к организаторам встреч из других департаментов. Для ведущего проблема была неочевидна, а для нас — вполне ощутима. Нас выслушали, и вопросы решились.

Масштабирование на весь Телеком

Отработав подход на своих, мы пошли к коллегам. Вместе с другими ATL мы рассказали о результатах руководителям всех департаментов дивизиона Телеком и предложили делать так же. Через некоторое время инициатива дошла до директоров дивизиона. Они изучили наш опыт, немного переформулировали и распространили похожие рекомендации, а местами и требования, на весь Телеком.

Группа 3. Частные «плохие» встречи: право не ходить

В третью группу попали редкие или уникальные встречи небольшого круга людей, которые не понравились конкретному человеку. С каждым мы поговорили и задали простой вопрос: «Что будет, если ты не придешь и предупредишь об этом организатора?». Ответы были примерно такие:

• «Скорее всего, ничего».

• «Может, спросят, что не нравится, — я и скажу».

• «Все пропало, шеф!» — редкий случай, когда человек действительно должен там быть.

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

Мы напомнили инженерам:

• как корректно дать обратную связь организатору и на что обращать внимание;

• все правила, описанные выше для рабочих групп;

• что многие общие встречи для широкой аудитории опциональны.

Хороший пример — общая встреча по обмену знаниями для всего дивизиона. На нее приглашали всех, хотя участие было опциональным, и многие ходили месяц-другой, не находя для себя ничего интересного. Темы там каждый раз новые, поэтому разумнее заранее посмотреть повестку и идти, только если тема нужна для работы.

Если обратная связь организатору не помогает, у нас есть механизмы эскалации — как внутри департамента, так и на уровне всего дивизиона. Обращения по ним регулярно разбирают и анализируют.

Группа 4. «Хорошие» встречи: высокая оценка — тоже повод разобраться

Казалось бы, встреча хорошая — живи и радуйся. Но мы спрашивали и здесь: почему ты считаешь эту встречу хорошей? В большинстве случаев причины были ожидаемыми:

• адекватная длительность — если проблему можно обсудить за пять минут, ее обсуждают пять минут и расходятся;

• фасилитация — грамотное управление временем, каждому дают высказаться;

• повестка до встречи;

• только нужные участники.

Но встречались и частные причины, не связанные с пользой для работы:

• крутой спикер — «я там ничего не понимаю, но он так здорово рассказывает»;

• удобное время — «сходил в обед, послушал, посидел»;

• встреча нечастая — раз в три месяца, почему бы и не сходить;

• классная компания — пообщались за жизнь, а на работе это никак не сказалось.

Здесь мы напомнили принцип «Платон мне друг, но истина дороже». Если на встрече все прекрасно, но пользы для работы она не приносит, лучше от нее отказаться: это все-таки рабочее время. Из интересного доклада можно посмотреть в записи самые полезные фрагменты или прочитать его автоматическую расшифровку. Особенно важно это, когда времени не хватает, например в конце спринта.

Потребность в неформальном общении при этом не исчезает. Как мы ее закрыли, расскажу в конце статьи.

Результат: плюс один инженер

В августе 2025 года мы пересчитали, сколько времени команда тратит на встречи, и сравнили с замером до начала работы. Экономия составила 188 человеко-часов в месяц на команду и почти 6 часов на каждого сотрудника, в обоих случаях это минус 26%.

Освободившиеся часы чуть превышают месячную норму рабочего времени одного сотрудника. Проредив и оптимизировав матрицу встреч, мы как будто взяли в команду еще одного инженера. Цифру подтвердили с руководителем при планировании и оценке квартальных работ: при расчете доступных ресурсов команды руководители поначалу удивились, откуда взялся «лишний» человек.

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

Важно понимать: такой эффект бывает один раз. Это как генеральная уборка после долгого перерыва: в первый раз выносишь пять мешков хлама, а в следующие — уже по одному. Тем не менее каждая квартальная сверка дает еще несколько часов в месяц на инженера.

Сколько времени это заняло. Начали мы примерно в апреле 2025 года. Быстрые решения по встречам внутри GSM QA дали эффект почти сразу, и к концу лета мы сделали повторный замер. С рабочими группами было сложнее: изменения нужно было прорастить во всех департаментах, и на это ушло около восьми месяцев. Считаю до момента, когда даже самые активные критики на просьбу «скажи что-нибудь плохое» отвечали «да все нормально».

Матрица встреч

Все встречи, общие для сотрудников GSM QA, мы свели в одну таблицу в Confluence. По каждой встрече в ней указано содержание, сколько человеко-часов в месяц она требует и сколько удалось сэкономить после оптимизации. Вот фрагмент по состоянию на июнь 2026 года:

Для встреч по обмену знаниями мы заранее публикуем план-график с темами докладов. Встреча очень высоко ценится, но каждая конкретная тема нужна не всем: интересно — приходите, неинтересно или нужно доделать задачу — не приходите.

Как удержать результат

Работа над встречами на этом не заканчивается: в команды приходят новые люди, а договоренности со временем забываются. Вот что мы делаем.

Ходим по «плохим» встречам и разбираемся на месте. На первом этапе мы посещали почти все проблемные встречи. Если я видел там нашего инженера, которому эта встреча не нужна для работы, писал ему и предлагал попробовать обойтись без нее. Обычно через неделю человек сам говорил: «Не хожу, и ничего плохого не происходит. Один раз написали, что-то уточнили — и всё».

Раз в квартал проводим сверку по тому же механизму, что и первый опрос. В этом помогают четыре вещи:

• На 1-1 и ретро спрашиваем о качестве встреч напрямую — какая встреча вам нравится, а какую стоит улучшить или убрать.

• Используем корпоративное обучение. На уровне компании появляются курсы и статьи о встречах, в том числе курс «Эффективные рабочие встречи» на внутренней образовательной платформе. Мы назначили его всем инженерам. Для некоторых курс стал поводом впервые задуматься, что от лишней встречи можно отказаться или предложить организатору ее сократить.

• Действуем на опережение. Если видим, что встреча затягивается или идет не так, пробуем новые форматы или частоту, не дожидаясь жалоб. Для agile-лидера это часть работы, поэтому каждый квартал я стараюсь предложить хотя бы одно действенное улучшение, а не формальное «для галочки».

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

Зафиксировали подход в инструкции для ATL, которой может пользоваться любой лидер. Ее цель — провести аудит коммуникаций членов команды и оптимизировать их, а структура повторяет наш путь: сбор данных → анализ результатов → оптимизация → подсчет выгоды → повтор. Отдельный раздел — что делать, если оптимизировать нужно встречи не своей команды.

Периодически напоминаем о правилах гигиены коммуникаций — внутри команд и через рассылки на весь дивизион и всю компанию YADRO.

Как провести изменения без сопротивления

В основном люди восприняли изменения спокойно. Исключения были: некоторым коллегам привычнее решать вопросы в долгих жарких обсуждениях. Для таких встреч мы немного изменили формат и сократили состав. Иногда помогал простой вопрос: «Ты сам поставил этой встрече низкую оценку и уходишь с нее без результата. Зачем на нее ходить?».

Хорошо сработал еще один прием. На одной из общих встреч мы вместе разобрали, что такое хорошая и плохая встреча в принципе, какие из этих признаков есть у наших встреч и что сделать, чтобы плохих стало меньше. Можно было сразу прийти с готовыми правилами, но решения, которые люди сформулировали сами, приживаются гораздо легче: «Вы сами сказали, что хорошей встрече нужен регламент по времени, — давайте вместе его соблюдать».

Что показал повторный опрос в июне 2026 года

На этом можно было бы остановиться. Стало сильно лучше, но «плохие» встречи в списках у людей все еще есть. Причины в основном три:

1. «Вдруг что, а я не в курсе». Хожу уже десятый раз, ни разу не понадобился, но вдруг.

2. «Мне не сказали не ходить». Пришло приглашение, я принял — значит, подошел ответственно.

3. Привычка. «Хожу уже год, зачем удалять».

Решаем это и точечно, и системно. Точечно — разговариваем с человеком о том, что будет, если он не придет. Системно — собрали рекомендации для организаторов и участников встреч. Вот что в них входит:

• как понять, нужна ли встреча вообще;

• как правильно создать встречу в Outlook — с участниками, временем, местом и форматом, названием, обязательной повесткой и материалами;

• «золотые правила» до, во время и после встречи;

• роли на встрече и обязанности фасилитатора;

• как не упустить важное, если не идешь на встречу, — например, прочитать выжимку из сервиса автоматической расшифровки.

Что дальше

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

Бонус: куда деть потребность в неформальном общении

Когда все работают онлайн, хочется пообщаться по-человечески, и раньше это происходило прямо на рабочих встречах. Разгонять такие разговоры — не вариант, поэтому мы поступили по принципу «не можешь остановить — возглавь» и вынесли неформальное общение в отдельные форматы.

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

Пятничные посиделки. Сначала мы запустили пилот в одной команде: в пятницу в конце рабочего дня собирались на час с включенными камерами и играли в онлайн-игры для компаний вроде «Мафии» или «Крокодила». Эффект мы измерили в цифрах: вопрос, который раньше решался в среднем за 10 минут, стал решаться за 3. Люди перестали стесняться обращаться друг к другу напрямую: раньше с вопросом шли ко мне, а теперь сразу к коллеге. Сейчас формат доступен всем командам по запросу: кто-то уже достаточно пообщался, а кому-то он нужен.

«Полезные привычки». Второй формат — онлайн-доска, на которой каждый делится, например, топ-3 своих рабочих привычек. Это одновременно и обмен опытом, и знакомство. Ты узнаешь, что коллега бегает по утрам, у него есть собака и дети, — и он перестает быть просто аватаркой в мессенджере. Если общение начнет переходить личные границы, мы готовы мягко направить его в нужное русло, но пока таких случаев не было.

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

Итоги: чек-лист, если хотите повторить

1. Соберите данные. Возьмите фокус-группу по 2–4 человека от команды с разным опытом. Для опроса хватит простой таблицы со встречами, их длительностью и частотой, часами в месяц, ролью участника, оценкой полезности от 1 до 10 и комментарием. Добейтесь 100% заполнения — напоминайте и помогайте.

2. Проанализируйте. Ищите встречи с устойчиво низкими оценками, а с разбросом оценок разбирайтесь лично.

3. Разделите встречи на группы по тому, кто на них влияет, — свои, кросс-командные, частные и «хорошие».

4. Оптимизируйте каждую группу своим способом.

• Свои встречи — сокращайте, проводите реже, модерируйте, переводите в чат.

• Кросс-командные — назначьте ведущего и обучите его фасилитации, опишите роли в RACI, введите правила для участников.

• Частные — верните людям право не ходить и научите давать обратную связь организатору.

• «Хорошие» — проверьте, что встречи полезны именно для работы.

5. Посчитайте выгоду в человеко-часах и подтвердите ее с руководителем при планировании.

6. Повторяйте сверку раз в квартал, спрашивайте о встречах на ретро и 1-1, закрепите правила в документах и обучении.

Главное, что мы поняли: проблема неэффективных встреч решается не запретами, а прозрачностью. Когда у каждой встречи есть цель, ведущий и повестка, а у каждого участника — понимание, зачем он пришел, и право не прийти, время освобождается легко. В нашем случае это 188 человеко-часов в месяц, которые можно посвятить задачам.

А как устроены встречи у вас? Расскажите в комментариях, что помогло навести порядок в календаре — или почему пока не получается.