Я долго не считала эти паузы чем-то важным. Закончила задачу, отправила результат, закрыла вкладки. Следующую вроде бы можно начинать сразу.

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

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

Проблема оказалась не в самих перерывах

Сначала я решила, что просто стала чаще отвлекаться.

Попробовала убирать телефон подальше, закрывать Telegram, заранее составлять список дел. Почти ничего не изменилось.

Тогда я несколько дней просто записывала время.

Например:

В 11:20 закончила правки документа.

Следующей задачей нужно было открыть таблицу, проверить цифры и подготовить короткий отчёт.

Фактически таблицу я открыла только в 11:41.

Куда делась 21 минута?

Пять минут отвечала на сообщение. Потом зачем-то проверила почту. Увидела письмо, которое вообще не требовало немедленного ответа. Потом пошла налить чай. Вернулась и ещё несколько минут вспоминала, что собиралась делать.

И вот здесь я впервые поняла, что проблема немного сложнее обычного отвлечения.

Когда одна задача заканчивается, вместе с ней исчезает готовый рабочий контекст.

Я уже понимаю, какие файлы открыты, что именно нужно сделать, где остановилась и какой следующий шаг.

А у новой задачи этого контекста ещё нет.

Нужно заново войти в неё.

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

Само по себе это несложно. Но мозг почему-то очень охотно выбирает более простой вариант: посмотреть сообщения.

Самыми дорогими оказались короткие паузы

После нескольких дней наблюдений я увидела довольно неприятную картину.

Длинных перерывов у меня почти не было.

Зато было много маленьких.

7 минут после одной задачи.

12 минут после другой.

18 минут перед началом следующей.

Если за рабочий день таких переходов пять или шесть, легко теряется около часа.

При этом вечером совершенно не возникает ощущения, что я час ничего не делала.

Наоборот.

Кажется, что весь день была занята.

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

Просто большая часть этих действий не двигала мои основные задачи вперёд.

Что я сначала пыталась сделать

Первой идеей было убрать все отвлекающие вещи.

Отключила лишние уведомления.

Закрыла мессенджер.

Стала оставлять телефон в стороне.

Это немного помогло, но не решило проблему.

Потому что источник оказался не только во внешних отвлечениях.

После завершения задачи мне всё равно нужно было решить, что делать дальше.

И именно в этот момент начиналось небольшое внутреннее сопротивление.

Особенно если следующая задача была неприятной, сложной или плохо сформулированной.

Тогда я попробовала другой подход.

Стала заранее писать не просто список задач, а первый конкретный шаг для каждой.

Не подготовить отчёт.

А открыть таблицу продаж и проверить данные за вчера.

Не заняться презентацией.

А открыть последний файл и переделать третий слайд.

Не проверить проект.

А открыть список замечаний и начать с первого пункта.

Разница оказалась неожиданно большой.

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

Ещё одна вещь, которая сработала

Я перестала пытаться начинать новую задачу мгновенно.

Раньше мне казалось, что хороший рабочий день выглядит примерно так:

закончила одно — сразу начала другое.

На практике это только усиливало желание отвлечься.

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

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

Пять минут.

После этого возвращаюсь и начинаю следующий заранее записанный шаг.

Парадоксально, но официальные пять минут работают лучше, чем неофициальные двадцать.

Потому что второй вариант обычно начинается с мысли я только быстро проверю сообщения.

Что я делаю сейчас

У меня осталось три простых правила.

Первое — ещё до начала рабочего блока я знаю, какая задача будет следующей.

Второе — для неё записан первый конкретный шаг.

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

Полностью паузы никуда не исчезли.

Да и не должны.

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

Самым полезным оказалось даже не сэкономленное время.

Рабочий день стал ощущаться спокойнее.

Раньше я постоянно замечала, что вроде бы занята, но почему-то сильно отстаю от собственного плана.

Теперь хотя бы понимаю, где именно раньше терялось время.

И оказалось, что иногда оно исчезает не во время работы.

А в тот момент, когда одна работа уже закончилась, а следующая ещё не началась.

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

Введение

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

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

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

1. Два часа работы и два часа жизни задачи — совершенно разные величины

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

Условно я считаю так:

время прохождения = активная работа + ожидание + возвраты + восстановление контекста + технические паузы

Последние четыре компонента легко не замечать, потому что они воспринимаются как что-то внешнее. Я же не работал над задачей в это время. Но для заказчика разницы нет. Если запрос отправлен в понедельник, а результат получен в среду, задача заняла три дня независимо от того, сколько часов я провёл внутри файла.

Однажды я специально восстановил историю небольшой доработки отчёта. Нужно было добавить показатель, который уже хранился в базе. Никакой новой архитектуры, сложного API или миграции. Чистого времени получилось примерно 1 час 55 минут. Но задача прожила почти 27 часов рабочего времени. Первый раз я открыл её утром, обнаружил неоднозначность в формуле и написал аналитику. Ответ получил после обеда. К тому моменту уже переключился на другой проект. Вернулся ближе к вечеру, вспомнил структуру данных, сделал расчёт и отправил результат на проверку. На следующий день выяснилось, что показатель нужен не за календарный период, а относительно даты сделки. Снова открыл запрос, снова восстановил контекст, поменял условие, протестировал.

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

2. Основное время короткой задачи часто находится в очереди

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

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

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

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

Каждый отдельный шаг маленький. Именно поэтому такие процессы выглядят безобидно.

На практике здесь начинает работать простая механика очереди. Допустим, специалист способен проверять восемь запросов в день и в среднем получает семь. На бумаге свободная мощность есть. Но запросы приходят не равномерно по одному каждый час. В 10:00 может не быть ни одного, а в 14:30 одновременно появятся пять. В этот момент даже десятиминутная проверка перестаёт означать ответ через десять минут.

Есть ещё одна вещь, которую я раньше недооценивал: загрузка человека и скорость прохождения задач связаны нелинейно. Когда календарь почти полностью заполнен полезной работой, для новой задачи просто не остаётся зазоров. Любая неожиданность создаёт очередь. Поэтому команда, загруженная на 95–100 процентов, может выглядеть очень эффективной по занятости и одновременно медленно выпускать результат.

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

Я видел это на вполне бытовом примере. Для изменения одной формы мне требовалось подтверждение трёх полей. Само подтверждение занимало у владельца продукта минут пять. Но у него шли встречи с 11 до 15 часов. Я написал в 10:47. Ответ пришёл в 15:18. Пять минут чужой работы превратились для моей задачи в четыре с половиной часа ожидания.

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

3. Переключение контекста превращает несколько пауз в повторную работу

Самая дорогая часть подобного процесса для меня начинается после первого прерывания.

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

Мне снова нужно понять, где я остановился.

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

Поэтому я начал отдельно отмечать четыре вида потерь:

• ожидание внешнего решения;
• переключение на другую работу;
• повторное погружение;
• переделку после появления новой информации.

Одна такая пауза почти ничего не меняет. Пять пауз меняют экономику задачи полностью.

Допустим, чистая работа занимает 120 минут и разбита на четыре подхода. После каждого переключения мне требуется в среднем по 10–15 минут, чтобы вернуться к прежней скорости. Получается ещё около 45 минут, хотя функциональность задачи вообще не изменилась. Если один из подходов закончился переделкой, к ним легко добавляется ещё полчаса.

В итоге двухчасовая задача становится почти трёхчасовой даже без учёта ожиданий.

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

Я однажды замерял похожую работу по истории изменений файла и сообщениям. Картина получилась почти комичная. Первый подход — 38 минут. Потом ожидание 2 часа 17 минут. Второй подход — 21 минута. Затем другая срочная задача. Возврат через 3 часа 40 минут. Ещё 34 минуты работы. Ночью задача, естественно, не двигалась. На следующий день проверка, возврат, 27 минут исправлений и финальная отправка.

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

И то и другое правда.

Вывод

После нескольких таких разборов я почти перестал доверять оценке вида эта задача на два часа, если речь идёт о сроке. Для оценки трудоёмкости она полезна. Для прогноза готовности — недостаточна.

Теперь, когда мне нужно понять реальный срок, я мысленно смотрю не только на объём работы, но и на количество переходов между людьми и системами. Если мне нужны два согласования, доступ от администратора, проверка результата и ответ заказчика, это уже не двухчасовой процесс. Даже если непосредственно за клавиатурой я действительно проведу два часа.

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

Поэтому теперь при задержках я стараюсь не начинать с вопроса, кто работал медленно. Сначала раскладываю путь задачи по времени. В какой момент она действительно выполнялась, где лежала без движения, сколько раз возвращалась назад и сколько раз человеку приходилось заново погружаться в неё.

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