Краткая аннотация

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

Введение

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

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

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

1. Я начала записывать, что на самом деле означает срочно

В течение трёх недель я фиксировала все задачи, которые приходили с явным требованием сделать их быстрее обычного. Таких набралось 64. Для каждой я записывала четыре вещи: кто поставил задачу, к какому моменту она была нужна, что произойдёт при задержке и сколько других процессов от неё зависит.

Результат оказался почти комичным. Только у 17 задач была реальная стоимость задержки. Остальные становились срочными по совсем другим причинам:

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

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

Это сильно изменило картину. Одна задача могла звучать совершенно спокойно, но блокировать работу трёх человек. Другая приходила с требованием сделать немедленно, хотя результат был нужен только через четыре дня. Формально вторая выглядела срочнее. Экономически первая была намного важнее.

2. Самая дорогая потеря происходила из-за постоянного переключения контекста

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

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

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

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

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

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

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

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

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

3. Я перестала спрашивать, насколько задача срочная

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

Это оказалось намного полезнее.

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

Я стала делить срочные задачи на несколько типов:

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

Для первых двух типов я действительно меняла свой план сразу. Для остальных сначала смотрела на текущую очередь.

Особенно полезной оказалась идея стоимости задержки. Я стала мысленно считать её хотя бы приблизительно.

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

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

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

После этого некоторые решения стали приниматься почти механически.

Я даже ввела для себя простой коэффициент приоритета:

Приоритет = стоимость задержки × количество зависимостей × чувствительность ко времени.

Это не математическая модель в строгом смысле. Я не выставляла каждой задаче баллы до третьего знака после запятой. Но сама логика очень помогала.

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

А вот задача, которую никто не назвал срочной, но которая блокирует запуск проекта, автоматически становится первой.

Вывод

Через несколько недель я увидела довольно неприятный эффект.

Самые громкие задачи действительно очень редко были самыми важными.

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

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

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

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

Если ничего из этого не происходит, я почти всегда оставляю её в общей очереди.

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

Раньше мой день управлялся тем, кто последним написал мне в мессенджер.

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

Разница оказалась намного больше, чем я ожидала.