Вчера я резко понадобился всем сразу: ожили личные проекты, началось планирование переноса фич в production, а на dev параллельно нашли баг и критическую ошибку. Ломает не список задач, а шум входящих.

Знакомое состояние: каждая отдельная задача понятна, но вместе они превращаются в кашу. Один поток просит внимания по личному проекту. Второй тянет в обсуждение production-релиза. Третий дергает из-за бага на dev. Четвертый звучит еще громче, потому что на том же dev появилась критическая ошибка.

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

Главная проблема здесь не в количестве задач. Количество можно пережить, если оно лежит в очереди. Сложнее, когда несколько людей и процессов одновременно ожидают, что именно их тема сейчас станет первой. Возникает конфликт ожиданий, а мозг платит налог за каждое переключение.

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

Рамка, которую я хочу применять жестче:

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

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

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

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

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

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

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

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

#engineering #teamlead #backend #infra #production #dev #incidentmanagement #izagprog