Руководитель как узкое горлышко: сколько задач сейчас стоит в ожидании вашего решения

Открой сейчас Telegram или почту и оцени навскидку: сколько там сообщений вида «жду твоего ок», «нужно решение», «когда посмотришь ТЗ» висит больше суток? Если пришло в голову число больше трёх - поздравляю, у тебя есть очередь, которую никто не измеряет. Она называется «очередь к руководителю», и она определяет реальную скорость компании куда сильнее, чем кажется.

Почему это не про тайм-менеджмент, а про скорость

Сразу уточню то, что часто подают неверно: пока задача ждёт твоего решения, компания не платит «за простой». Сотрудник, сдавший макет, не сидит без дела - он переключается на другую задачу, потому что у него есть свой приоритетный список. ФОТ отработан, деньги не сгорают, и умножать часы ожидания на ставку, называя результат потерями, просто математически неверно.

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

И самое неприятное - риск. Чем дольше решение висит, тем выше шанс, что клиент уйдёт туда, где ответили быстрее, что условия поменяются, что задача потеряет актуальность и её придётся заводить заново. Это не строка в P&L, это упущенная выручка и отложенные деньги, а они видны только в динамике сделок, а не в зарплатной ведомости.

Формула, которая покажет очередь прямо сейчас

Вот неочевидная часть. Даже если ты каждый вечер добросовестно разгребаешь все свои «ждёт решения» до нуля, средняя длина очереди у тебя не ноль. Это простая логика теории очередей: если решения к тебе прилетают со скоростью, скажем, 40 штук в неделю (пример), а среднее время, которое задача реально висит до твоего ответа - 2 рабочих дня, то в любой случайный момент времени у тебя в очереди стоит не 0 и не 1, а примерно 40 / 5 рабочих дней × 2 дня ≈ 16 задач одновременно (пример расчёта). Шестнадцать людей, процессов или клиентов прямо сейчас чего-то ждут от тебя - даже если ты не видишь список целиком, он существует.

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

Почему «отвечай быстрее» не чинит проблему

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

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

Что делать вместо ещё одной инструкции «отвечать в течение суток»

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

Дальше с этим числом можно работать, и работать надо в трёх направлениях сразу.

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

Делегирование по чёткому критерию. Не «отдай всё, что можно», а явная граница: до такой-то суммы, в таком-то типе задач, при отсутствии юридического риска решает старший сотрудник, и его решение окончательное. Критерий должен жить в самом шаге процесса, а не в голове у двоих.

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

Практический вывод

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

А у тебя есть ощущение, сколько задач прямо сейчас ждут именно твоего решения, или это тоже число, которое никто никогда не измерял?