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

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

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

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

Я сокращаю большинство своих встреч до 15 минут

Чанпэн Чжао, CEO Binance

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

Работа занимает все отведенное на нее время

Но получается, что можно обсуждать большие дела за 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
  • Сделайте себе плагин, который будет писать стоимость встречи, как на скриншоте ниже 😎
Самый меркантильный способ решить проблему бесполезных звонков
Самый меркантильный способ решить проблему бесполезных звонков

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

1919
27 комментариев

Большая часть встреч вызвана манией микроменеджмента у руководства или желанием большей части менеджеров показать, что они работают, или сделать свою работу чужими руками.

Реальная встреча интересантов (пм/кодеры/дизы) длится не более 15 минут.
Причём формат как в кино - да, да, нет, нет, а вот это попробуйте.;))

2
Ответить

Полностью согласна! 15 мин — более чем достаточно чтобы обсудить все вопросы. Остальное можно и в чатике по-быстрому уточнить.

1
Ответить

статья как раз для тех, кто менеджерит и может не замечать подобную проблему :)

Ответить

не "причем", а "при чём".
рускова езыка не учила чукча?

1
Ответить

Всегда нравилось, когда решалось всё в рабочем порядке, в рабочем процессе. Часто этого достаточно. Занимает - минуты.
А если еженедельный сбор по расписанию, не важно - надо или не надо, то ничего хорошего.

1
Ответить

Если честно – не понял фразу "Всегда нравилось, когда решалось всё в рабочем порядке, в рабочем процессе."

Рабочий порядок и рабочий процесс это постоянные созвоны? Или наоборот, когда просто в чатиках все узнают?

Ответить