Maker’s Schedule vs Manager’s Schedule: почему встречи ломают разработку
Maker’s Schedule vs Manager’s Schedule: почему встречи ломают разработку
Иногда кажется, что часовая встреча — это просто часовая встреча.
Ну, подумаешь, поставили созвон с 11:00 до 12:00.
Потом ещё один с 14:00 до 15:00.
Вроде бы у разработчика всё равно остаётся несколько свободных часов.
Но проблема в том, что разработка плохо живёт в нарезке по часу.
Чтобы нормально разобраться в задаче, нужно загрузить контекст в голову:
что меняем, где это лежит, какие есть ограничения, что уже пробовали, какие могут быть побочные эффекты.
И только ты более-менее вошёл в поток — звонок.
После звонка нужно снова вернуться, вспомнить, где остановился, открыть файлы, восстановить мысль. Формально встреча заняла час. По факту она могла сломать половину дня.
Пол Грэм хорошо описывал эту разницу через два типа расписания:
Manager’s Schedule — день менеджера легко режется на слоты по 30–60 минут.
Встреча, ещё встреча, синк, обсуждение, планирование.
Maker’s Schedule — день человека, который что-то создаёт, работает большими непрерывными блоками.
Код, архитектура, дизайн, текст, анализ — всё это требует длинного фокуса.
И вот тут появляется типичная проблема тимлида.
Тимлид часто живёт в manager’s schedule, а команда — в maker’s schedule.
Если об этом не помнить, можно случайно начать оптимизировать свой календарь за счёт фокуса команды.
Например:
— поставить короткий синк посреди утра;
— разбить день разработчика двумя “быстрыми вопросами”;
— назначить обсуждение на 16:00, когда человек почти добрался до решения;
— постоянно дёргать в личке, потому что “там же всего один вопрос”.
Каждое такое действие выглядит маленьким.
Но вместе они превращают рабочий день в кашу.
Что можно попробовать:
1. Блоки без встреч
Например, не ставить встречи команде до обеда или выделить 2–3 дня в неделю с длинными фокусными окнами.
2. Office hours для вопросов
Не дёргать разработчика хаотично, а собирать вопросы в конкретное окно.
3. Async-first для несрочного
Если вопрос не требует живого обсуждения прямо сейчас, лучше написать контекстом: что случилось, что нужно решить, какие варианты уже есть.
4. Не путать доступность и эффективность
Если человек быстро отвечает в мессенджере, это не значит, что он эффективно работает. Иногда это значит, что он вообще не может сфокусироваться.
Мне кажется, одна из задач тимлида — не просто ходить на встречи самому, а ещё и защищать команду от лишних встреч.
Потому что фокус — это тоже ресурс команды.
И его очень легко потратить незаметно.
А у вас что чаще ломает рабочий фокус: встречи или внезапные “быстрые вопросы”?
Иногда кажется, что часовая встреча — это просто часовая встреча.
Ну, подумаешь, поставили созвон с 11:00 до 12:00.
Потом ещё один с 14:00 до 15:00.
Вроде бы у разработчика всё равно остаётся несколько свободных часов.
Но проблема в том, что разработка плохо живёт в нарезке по часу.
Чтобы нормально разобраться в задаче, нужно загрузить контекст в голову:
что меняем, где это лежит, какие есть ограничения, что уже пробовали, какие могут быть побочные эффекты.
И только ты более-менее вошёл в поток — звонок.
После звонка нужно снова вернуться, вспомнить, где остановился, открыть файлы, восстановить мысль. Формально встреча заняла час. По факту она могла сломать половину дня.
Пол Грэм хорошо описывал эту разницу через два типа расписания:
Manager’s Schedule — день менеджера легко режется на слоты по 30–60 минут.
Встреча, ещё встреча, синк, обсуждение, планирование.
Maker’s Schedule — день человека, который что-то создаёт, работает большими непрерывными блоками.
Код, архитектура, дизайн, текст, анализ — всё это требует длинного фокуса.
И вот тут появляется типичная проблема тимлида.
Тимлид часто живёт в manager’s schedule, а команда — в maker’s schedule.
Если об этом не помнить, можно случайно начать оптимизировать свой календарь за счёт фокуса команды.
Например:
— поставить короткий синк посреди утра;
— разбить день разработчика двумя “быстрыми вопросами”;
— назначить обсуждение на 16:00, когда человек почти добрался до решения;
— постоянно дёргать в личке, потому что “там же всего один вопрос”.
Каждое такое действие выглядит маленьким.
Но вместе они превращают рабочий день в кашу.
Что можно попробовать:
1. Блоки без встреч
Например, не ставить встречи команде до обеда или выделить 2–3 дня в неделю с длинными фокусными окнами.
2. Office hours для вопросов
Не дёргать разработчика хаотично, а собирать вопросы в конкретное окно.
3. Async-first для несрочного
Если вопрос не требует живого обсуждения прямо сейчас, лучше написать контекстом: что случилось, что нужно решить, какие варианты уже есть.
4. Не путать доступность и эффективность
Если человек быстро отвечает в мессенджере, это не значит, что он эффективно работает. Иногда это значит, что он вообще не может сфокусироваться.
Мне кажется, одна из задач тимлида — не просто ходить на встречи самому, а ещё и защищать команду от лишних встреч.
Потому что фокус — это тоже ресурс команды.
И его очень легко потратить незаметно.
А у вас что чаще ломает рабочий фокус: встречи или внезапные “быстрые вопросы”?