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

Ты уже погрузился в код, держишь в голове архитектуру, зависимости и детали реализации. Решение постепенно складывается, работа идёт. И тут... ГРАНАТА!!! Ой, в смысле... "Нужно быстренько сделать".

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

В итоге день проходит в работе: что-то исправил, кому-то помог, разобрался с очередной проблемой. А задача, которой собирался заниматься с утра, почти не сдвинулась. Состояние: День прошёл, число сменилось - ничего не изменилось :D

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

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

Случаи, когда действительно нужно отложить текущие задачи и разбираться: 1. Продакшен лежит или критически важная функция перестала работать. 2. Пользователи массово сталкиваются с проблемой и не могут выполнить ключевое действие. 3. Обнаружена критическая уязвимость или есть риск потери данных. 4. Проблема прямо сейчас приводит к серьёзным финансовым или операционным потерям.

Важно, но не обязательно прямо сейчас: 1. Появилась новая функциональность, которую хотелось бы получить как можно скорее. 2. Нашли некритичный баг, у которого есть обходное решение. 3. Возникла идея улучшить существующий процесс, но текущая реализация продолжает работать. 4. Появилась задача, которую просто хочется закрыть побыстрее, хотя последствия ожидания незначительны.

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

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

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

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