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

• Одно подключение типовое: клиент прислал все данные, специалист может начать работу.

• Второй клиент просит ускорить уже запланированное подключение.

• Третий хочет интеграцию с сервисом, который команда пока не проверяла.

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

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

• По первой ждали подтверждения очередности.

• По второй никто не решился сдвинуть чужую задачу.

• По третьей не знали, что можно обещать клиенту до исследования.

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

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

Такая система выглядит работающим процессом до первого отсутствия человека, который удерживает её в голове.

Ниже разберём пять ошибок на одном составном примере.

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

Приоритет определяют в личном чате

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

Как он выбирает, никто не сформулировал. Исполнитель пишет: «Что делать первым?» — и ждёт ответа.

Здесь не требуется универсальная формула приоритета. Требуется объяснить, кто владеет очередью и какие обстоятельства позволяют её менять.

Например:

1. сначала выполняем работу с уже подтверждённым сроком;

2. критическая неисправность прерывает плановую работу;

3. просьба клиента ускориться сама по себе не меняет очередь, пока владелец процесса не оценил влияние на другие обязательства.

Это возможные правила для команды из примера, а не готовая политика для любой компании.

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

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

Тогда вопрос звучит так: «Какую работу и с какими последствиями мы сдвигаем?».

Задачу делегировали, право на решение оставили наверху

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

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

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

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

Исключение отправляют руководителю без допустимого промежуточного шага

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

У команды будто есть два варианта: согласиться с клиентом или ждать возвращения руководителя.

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

Не каждое исключение можно решить заранее.

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

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

• Запись «ждём руководителя» не описывает работу.

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

Срок проверки зависит от задачи и договорённости с клиентом.

Назначили замещающего, но не передали ему решения

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

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

Для активной заявки достаточно короткой записи:

• что обещано;

• какой шаг выполнен;

• что мешает следующему;

• кто принимает решение;

• когда нужен ответ;

• где хранится переписка.

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

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

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

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

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

Ручное спасение скрывает ожидание и повторяющиеся пробелы

Через два дня руководитель возвращается и за полчаса отвечает на все накопившиеся сообщения.

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

• Первая заявка ждала разрешения без причины,

• Вторая — владельца решения о приоритете,

• Третья — правила работы при неопределённости.

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

В разборе работы с пользовательскими обращениями в Авито среди полезных метрик названы, например, доля тикетов без владельца и ошибки приоритета.

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

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

Как это могло бы работать для трёх заявок

Для начала достаточно зафиксировать несколько классов решений там, где команда ведёт задачи.

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

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

Его отсутствие не должно останавливать сбор данных и стандартную работу.

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

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

1. Сможет ли команда начать первую?

2. Кто и на основании чего ответит на вторую?

3. Появятся ли у третьей ответственный, проверяемый вопрос и дата следующего сообщения клиенту?

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

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

Для проверки спросите: «Какие конкретно решения остановятся, если я завтра недоступен?»

Ответы показывают, где уточнить правило, где передать полномочие, а где организовать замещение.

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

Что проверить в своей команде

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

• Кто может изменить очередь и какие действующие обязательства он обязан проверить?

• Какие действия исполнитель вправе сделать самостоятельно, а какие обещания давать нельзя?

• Что происходит с исключением до окончательного решения и когда заинтересованные стороны получают обновление?

• Может ли замещающий человек продолжить работу и принять необходимые решения по переданным задачам?

• Какие повторяющиеся вопросы руководитель закрывает вручную и сколько задач ждут этих ответов?

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

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

На курсе «Оптимизация бизнес‑процессов» вы научитесь диагностировать такие проблемы, находить точки роста и выстраивать процессы, которые не требуют постоянного ручного вмешательства.

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

• 6 октября в 20:00. «Как найти точки роста и улучшить бизнес‑процесс: от диагностики до новой модели». Записаться

• 19 октября в 20:00. «Как наладить процессы без вложений: никаких бюджетов, систем и выделенных команд». Записаться