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

На связи команда сервиса WEEEK — сервис по управлению проектами. Помимо айтишных тем, мы обожаем без занудства рассуждать о личной эффективности. Кстати, почти уверены, что ты вряд ли дочитаешь этот текст за один раз. Скорее всего, он останется висеть открытой вкладкой где-нибудь между почтой, ещё парой статей, таск-менеджером и вкладкой с новостями. И это мы ещё не учитываем приложения, которые норовят отвлечь сами по себе.

В рабочие дни мы превращаемся в Волка из «Ну, погоди!», который пытается разом ловить падающие яйца. Только у нас вместо яиц — задачи всех размеров, срочности и неожиданности. И они летят с такой скоростью, что удержать всё становится невозможно.

Что такое контекстное переключение

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

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

Термин пришёл из IT: раньше это называлось «контекстная коммутация», и описывало, как операционные системы распределяют ресурсы между процессами. Разница в том, что компьютеры мгновенно возвращаются в нужный контекст, а вот люди — нет.

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

Например, ты пишешь объёмный отчёт. Чтобы сделать это нормально, нужно собрать в голове кучу данных:

• Какова цель отчёта и кто будет его читать?

• Какие цифры нужно подтянуть и где их искать?

• Как всё это оформить и презентовать?

• Сколько времени есть и какие ограничения?

Ты собираешь этот «кокон» контекста вокруг себя — и начинаешь работать. Но стоит что-то отвлечь тебя на секунду, и он рассыпается.

И чтобы вернуть его обратно, нужно время. По данным исследователей, на полное восстановление погружения требуется около 23 минут. Почти полчаса на то, чтобы просто вернуться туда, где был.

Что ломает контекст

1. Уведомления

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

2. Множество задач

Незавершённые дела висят где-то на фоне, создают тревожность, мозг скачет между ними и не даёт сосредоточиться.

3. Поток информации

Новости, экспертные посты, мемы, сообщения — всё это приходится обрабатывать, и каждое требует смены контекста.

4. Окружение

Общество привыкло к мгновенным ответам: написал — жди реакцию за минуту. Такое давление формирует ожидания быстроты. От тебя ждут того же. Иногда окружение буквально вторгается в пространство: при работе из офиса или дома, когда вокруг тебя постоянно другие люди. Мамы, которые вынуждены между заполнением отчётов бегать разогревать макароны и помогать переодевать колготки, признавайтесь, знакомо?! Ладно, ладно, уверены, такие напасти от домочадцев или даже любимых питомцев знакомы многим.

5. Мы сами

Рука так и тянется открыть соцсети, обновить статус заказа или посмотреть мем. Считается, что у зумеров особые сложности с концентрацией — а как тебе кажется?

Чем опасно постоянное переключение контекста

• Обвал продуктивности

Продуктивность — это скорость + завершение. Контекстное переключение ворует и время, и энергию, замедляя движение к цели.

• Снижение внимания и выгорание

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

• Путаница приоритетов

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

Как бороться с переключением контекста

Делимся реально полезными советами:

1. Освободи голову от задач

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

☝ Делай это рефлексом: «Пришла задача — зафиксируй»

2. Создай место для всех входящих

У тебя должно быть одно «корзиночное» пространство, куда падают все новые задачи: входящие письма, идеи, сообщения, запросы. Позже — разберёшь.

3. Определи свои приоритеты — по единой системе

Чёткое понимание, что реально важно делать, убирает лишние раздумья. Используй понятную схему. Например:

• Матрица Эйзенхауэра — разделяет задачи по критериям важности и срочности. Причём в масштабе дня, что удобно для быстрого управления делами и срочными входящими. Причём в важные задачи идут те, что имеют ключевое значение для твоего стратегического развития

• Метод ABCDE — метод приоритизации задач по степени их важности и параметрам сделано/не сделано

• OKR — постановка целей с измеримыми результатами. Цели могут быть очень амбициозными, зато они становятся ярким ориентиром во тьме дневного завала из задач

4. Группируй задачи и управляй временем

Когда список разобран — начинай собирать задачи в логичные блоки.

Варианты группировок:

• выполнять похожие задачи партиями

• делить дни на тематические (стратегия/менеджмент/исполнение)

• начинать с ключевых объёмных задач

Полезные техники:

• Помодоро — 25 минут работы + 5 отдыха;

• тайм-блокинг — выделенные блоки времени под конкретную деятельность;

• тайм-боксинг — жёсткий лимит времени на задачу.

И да, самое простое и эффективное: выключить уведомления хотя бы на час-другой.

Вывода не будет, а то контекст переключим. Будет список того, что стоит почитать по сказанному выше. Можно сохранить и почитать, когда под это будет свой час!

• OKR, метод ABCDE, матрица Эйзенхауэра — все методы приоритизации

• Про тайм-блокинг как способ сделать больше и сохранить продуктивность

• Помодоро-техника и всё о ней

WEEEK — как место для выгрузки задач из головы

Привет, дорогой читатель! Хочу поделиться историей о том, как за 6 лет работы тимлидом в разных компаниях я понял, что наибольшую эффективность работы команды стоит ждать тогда, когда ты служишь своей команде. Сейчас объясню на примерах.

Кстати, термин «servant leadership» ввёл в 1970-х годах Роберт Гринлиф в своём эссе «Слуга как лидер». Он работал топ-менеджером в AT&T, и я понял то же, что и он, только спустя полвека.

Статья – чисто моё мнение и видение ситуации исходя из опыта. В роли тимлида я руководил различными командами: от 1 разработчика до группы из 20 человек (разработчики, тестеры, аналитики).

НАЧАЛО ПУТИ: ОТ ОДНОГО РАЗРАБА ДО ДВАДЦАТИ

Когда я дорос до тимлида, я попал в классическую ловушку. Думал: «Ну всё, теперь я главный, буду раздавать указания и следить за их выполнением». Но реалии были таковыми, что выполнять задачи – это полдела, а вот делать их эффективно – это надо попотеть и примерить на себя роли психолога, «старшего товарища» и лидера, которому доверяют коллеги, кто может свободно общаться с начальством о нуждах команды. По сути, такое связующее звено между эффективной командой и заказчиками. Это и есть суть servant leadership – служить команде, а не командовать ею.

Эту-то эффективность и надо выстраивать тимлиду, приводя команду к максимальной точке эффективности. Микроменеджмент долой!

К слову, обязанности тимлида, руководителя проекта и руководителя продукта в небольших компаниях переплетаются.

АВТОМАТИЗАЦИЯ РУТИНЫ

Первое, что я стараюсь сделать в этой роли – избавить команду от рутины. Настроить автоматизацию в Jira: сценарии для создания задач, автоматические переходы по статусам, уведомления, шаблоны новых задач. Разработчики, тестировщики и аналитики перестают тратить время на заполнение полей вручную, а рабочий процесс по описанию задач поставлен на рельсы.

Дальше берусь за GitLab (а в основном его сейчас используют) – включил линковку задач Jira с MR, проверки code style (линтер + SonarQube), запуск тестов. Также, MR проверяется в полуавтоматическом режиме с помощью AI.

Для тестировщиков будет удобным настроить систему логирования ошибок в проде – Sentry.

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

Таким образом, команда получила больше времени на то, что действительно важно – на написание кода. И, хочу заметить, что всё это должен проконтролировать тимлид (ну и техлид, если имеется).

ЗАЩИТА КОМАНДЫ ОТ НАЧАЛЬСТВА

Отдельная история – это утилиты для сбора статистики по работе сотрудников. Начальство любит цифры, и мы их должны предоставить. Вместо того, чтобы заставлять разработчиков писать отчёты – обычно автоматизируются выгрузки отчётов о закрытых задачах, времени их выполнения в разрезе по каждому разработчику. Всё это можно настроить через Jira API, либо платные плагины. Получилось «два в одном»: менеджмент доволен красивыми графиками, а команда не отвлекается на отчётность.

РИТУАЛЫ БЕЗ ФАНАТИЗМА

Насчёт стандартного набора тимлида: дейлики, ретро, планирование с Planning Poker. Главное – не переусердствовать. Всё для команды, а не команда для процессов. Если какая-то практика не работает, меняем или убираем.

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

Также хорошей практикой будет совместный поход в бар/квест с коллегами.

SCRUMBAN КАК КОМПРОМИСС

Насчёт методологий – никто в чистом виде их не использует. Обычно в моей практике получается так называемый Scrumban – помесь Scrum и Kanban. Почему? Потому что чистый Scrum слишком жёсткий для фронтенда (особенно когда постоянно прилетают «горящие» задачи), а чистый Kanban не особо предназначен для планирования.

Scrumban даёт гибкость Kanban с планированием из Scrum. Команда может быстро реагировать на изменения, но при этом не теряет фокус на основных целях спринта.

ВСЁ ВЫШЕ И ВЫШЕ И ВЫШЕ…

Отдельный навык servant leadership – это умение защищать интересы команды перед руководством. Когда разработчик хорошо работает, но по каким-то причинам не получает повышение зарплаты, моя задача – это исправить.

Готовлю аргументы, собираю метрики производительности, иду к начальству и «выбиваю» повышения. Не всегда получается, но попытки нужно делать. То же касается и обновления оборудования, или повышения в должности. После ответа руководства для самого разработчика перспективы работы в этой компании будут видны чётче. Команда должна знать, что тимлид на её стороне, что тимлид первым принимает удары и берёт ответственность за подчинённых и их ошибки.

Разбор ошибок с командой – всё это делается на общих встречах, а частные проблемы разбираются один на один (не при всех).

ПОЧЕМУ ЭТО РАБОТАЕТ

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

Плюс, такой подход снимает множество конфликтов. Команда понимает, что тимлид – это не «надсмотрщик», а партнёр, который помогает решать проблемы и защитит, если необходимо.

ЗАКЛЮЧЕНИЕ

За примерно шесть лет тимлидерства я понял: лучший руководитель – тот, кого не замечают, потому что всё работает как часы. Моя задача в роли тимлида – создать систему, где команда может эффективно работать без постоянного контроля и не отвлекаясь на посторонние дела.

Servant leadership – это не про мягкотелость или попустительство. Это про создание условий для максимальной продуктивности команды. И да, иногда приходится быть жёстким – но всегда в интересах команды, а не для демонстрации власти.

Если ты ещё не в деле – попробуй этот подход. Возможно, твоя команда станет не только эффективнее, но и счастливее. А счастливые разработчики пишут лучший код.

PS: Я не описал здесь про решение конфликтных ситуаций, но это тоже надо уметь делать деликатно. О чём будет одна из последующих статей.

Эту и другие мои статьи можно всегда обсудить тут «Life Developer. Статьи»