Почему длинные рабочие встречи – зло, что такое тривиальность и причем тут СЕО Бинанса?

GM! Не знаю, собирается ли СЕО Бинанса запустить свой инфокурс, но он написал рассуждение о тайм-менеджменте и как у него получается быть эффективным.

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

Я сокращаю большинство своих встреч до 15 минут (с) Чанпэн Чжао

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

Но получается, что можно обсуждать большие дела за 5 минут и выполнять все на 100 процентов? Нет, немного не так. Паркинсон был умным чуваком и следом за своим самым популярным законом сразу написал второй:

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

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

Воображаемый пример из криптостартапа

Собирается встреча, на которой нужно обсудить производительность API сервиса. На встречу приглашается вся команда (фронтендеры, бэкендеры, дизайнеры, СЕО) и часовая встреча, в теме которой стоит производительность, завершается тем, что дизайнеры рисуют лоадеры, СЕО придумывает юзер-флоу, в котором данные идут долго, а фронтендеры сразу берут все эти задачи в работу.

Решилась ли проблема? Я считаю, что да. Ведь сама по себе проблема заключалась в неудобстве пользователя продукта, но какими ресурсами она решилась? Давайте возьмем за пример компанию, в которой по 2 человека в каждом направлении и СЕО, да сравним. На встрече находятся 7 человек, каждый из которых потратил по часу своего рабочего времени. Дальше СЕО продумывает новый флоу и отдает ТЗ дизайнерам. Возьмем еще 2 часа времени на это. Ну и дальше уже стандартный рабочий процесс с выполнением дизайна, передаче на фронтенд и имплементации. Пусть будет еще 6 часов суммарной работы между дизайнером и фронтендером.

Но что, если воспользоваться законом Паркинсона и сократить время встречи до 10 минут? Тогда кажется разумным, что приглашать 7 человек не имеет никакого смысла, ведь у каждого будет всего по одной минуте на то, чтобы высказаться и к результату придти сложно (это мы еще не берем в расчет, что половина людей опоздает и времени останется еще меньше). Как решать эту проблему? 🤔

А тут на помощь приходит второй вариант: 10 минутная встреча, на которой находятся 2 бэкендера. Они обсуждают CDN и кэширование данных, им не приходится объяснять свои профессиональные термины, и они гораздо проще договариваются. Один из них берет задачу, тратит на нее 6 часов. И проблема решена. Для наглядности прикреплю таблицу

В итоге мы получаем почти 9 часов сэкономленного времени для решения одной и той же проблемы, но с разными коэффициентами эффективности

Добавляем тривиальности

Но ведь в «эффекте велосипедного сарая» говорилось о тривиальности проблем. Так давайте расширим пример для большей наглядности.

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

И вот, у нас на встрече 7 человек, из которых только 2 человека разбираются в бэкенде. Вероятнее всего, 80% времени будет обсуждаться тема первоначальной загрузки сайта, потому что тут свои предложения могут вбросить и дизайнеры, и СЕО, да и фронтендеры, потому что им в итоге выполнять задачу. По итогу: всем будет труднее договориться, задача опять может быть разбита на длинную последовательную работу, а до производительности API никто и не дойдет.

Для наглядности опять попробуем построить таблицу, но предсказать результат здесь будет уже сложнее. Возьмем общий X для обеих ситуаций.

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

А как в итоге правильно то?

Ну, для начала перестаньте звать на встречи всех подряд, без надобности. А вот пошаговый чеклист для эффективных встреч:

• Поймите минимальное количество людей, необходимых для решения проблемы. Позовите только их. Если будет не достаточно — сделайте summary встречи и отправьте другому человеку, которого хотели пригласить.
• Чем короче встречи — тем эффективнее. Но не забывайте про адекватность. Миграцию продукта на другой стек даже 2 фронтендера не успеют обсудить за 10 минут.
• Готовьтесь к встречам. Не делайте так, что на встречах все остальные люди сидят и смотрят, как вы исследуете проблему в прямом эфире. Каждый человек должен подготовиться к встрече и выписать свои тезисы заранее.
• Если получается так, что нужно обсудить несколько проблем — нужно добавить тайм-блоки на обсуждение каждой проблемы. Если не сделать это заранее — большинство обсуждения пройдет за легкой темой.
• Попробуйте решать проблемы асинхронно. Здесь могут подойти любые мессенджеры, но наилучшим вариантом будет почта. Через почту люди стараются формулировать мысль наиболее полно и не отправляют по 20 сообщений с редактированиями, must have
• Сделайте себе плагин, который будет писать стоимость встречи, как на скриншоте ниже 😎

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