Когда каждая задача помечается как “срочная”, команда теряет фокус и начинает делать то, что громче просят, а не то, что важнее для бизнеса. Режим постоянного тушения пожаров приводит к тому, что все работают на пределе возможностей, но ни один проект не доводится до конца. Чтобы вернуть контроль над производством, нужно остановить хаос, отфильтровать ложную срочность и передоговориться с заказчиками на основе реальной пропускной способности команды.
| Какой вопрос закроем | Что станет понятно |
| Как быстро отделить реальные пожары от ложных | Сможете выделить 2-3 задачи, которые действительно нужно делать прямо сейчас |
| Как защитить команду от новых прилетов | Остановите смену контекста и дадите людям закончить начатое |
| Как говорить с заказчиками, чьи задачи сдвигаются | Снимете негатив и аргументируете перенос сроков на языке бизнеса |
Алгоритм: как разобрать завал прямо сейчас
Если команда прямо сейчас парализована количеством срочных задач, действовать нужно в директивном порядке. Классическое планирование здесь не работает – нужен антикризисный менеджмент.
Шаг 1. Объявить мораторий и собрать все в один список
Первое действие – остановить прием новых задач в работу и прервать попытки команды делать пять дел одновременно.
- Заморозьте бэклог. Сообщите всем заказчикам в корпоративном мессенджере или по почте, что команда проводит экстренную переоценку приоритетов. До окончания процесса (например, до 14:00) новые задачи не берутся.
- Выгрузите все в единое пространство. Соберите тикеты из Яндекс Трекера, таски из Кайтена, просьбы из чатов в Телеграме и устные договоренности в одну простую таблицу или на одну доску. Пока задачи раскиданы по разным каналам, оценить масштаб беды невозможно.
- Остановите переключения. Дайте команде команду: “Прямо сейчас каждый доделывает ту задачу, которая открыта на экране. За новые не браться, старые не бросать”.
Шаг 2. Отфильтровать ложную срочность жесткими критериями
Заказчики ставят статус “Срочно”, потому что для них их задача – главная. Ваша задача – оценить влияние на бизнес в целом. Пропустите весь собранный список через три фильтра.
Фильтр 1. Остановка процессов (Блокеры).
Задача критична, если без нее встает работа компании или клиенты не могут совершить целевое действие. Пример: упал шлюз оплаты, не работает выгрузка из 1С на сайт, лег сервер авторизации. Это делается в первую очередь.
Фильтр 2. Прямые финансовые и юридические потери.
Задача критична, если срыв срока приведет к штрафам по SLA, блокировке счетов налоговой или потере ключевого клиента, приносящего основную выручку. Пример: отправить отчетность до 18:00, исправить баг для клиента уровня VIP, который уже написал претензию.
Фильтр 3. Блокировка других команд.
Задача критична, если из-за нее простаивают другие отделы, и этот простой стоит компании денег. Пример: выдать доступы подрядчикам по платному трафику, иначе бюджет сгорает впустую.
Все, что не прошло эти три фильтра – не горит. Эти задачи переводятся в статус обычных и выстраиваются в очередь.
Шаг 3. Внедрить жесткое ограничение WIP (Work in Progress)
Главная причина, почему срочные задачи копятся – люди берут в работу новое, не закончив старое. Введите правило:
- Один человек – одна задача. Пока разработчик, дизайнер или менеджер не перевел задачу в статус “Готово” или “На проверке”, он не имеет права брать следующую.
- Парная работа на блокерах. Если упал критичный сервис, бросьте на него двух-трех сильных специалистов вместе. Это быстрее, чем один будет копаться два дня, а остальные делать несрочные фоновые задачи.
Развилки: как адаптировать метод под тип команды
Случай 1. Продуктовая разработка и IT
В продукте срочность часто возникает из-за накопленного технического долга или внезапных идей руководства. Здесь важно отделить баги от фич.
- Действие: Введите правило нулевой терпимости к критическим багам. Если баг ломает основной сценарий пользователя (например, добавление в корзину) – вся разработка новых фич останавливается, команда чинит баг.
- Развилка: Если пришла “срочная” фича от стейкхолдера, предложите ему выбрать, какую из текущих задач в спринте выкинуть, чтобы освободить место. Стейкхолдер должен сам принять ответственность за отмену другой работы.
Случай 2. Техническая поддержка и эксплуатация
Здесь все задачи по определению приходят от пользователей, у которых что-то сломалось.
- Действие: Настройте автоматическую маршрутизацию по уровню влияния. Массовые инциденты (не работает у всех) идут в красную линию, индивидуальные проблемы (не открывается файл у одного бухгалтера) – в желтую.
- Развилка: Если красная линия переполнена, переводите сотрудников со второй линии поддержки на первую для первичного разбора и снятия паники, отправляя пользователям шаблонные отбивки о массовом сбое.
Случай 3. Клиентское агентство или студия
Срочность исходит от внешних заказчиков, которые давят договором и угрожают уходом.
- Действие: Приоритизируйте по маржинальности клиента и юридическим рискам. Сначала “тушатся” проекты, где за просрочку прописаны жесткие пени или где завис крупный финальный платеж.
- Развилка: Если мелкий клиент требует срочных правок вне очереди, используйте финансовый барьер: введите тариф “Срочно в выходные/ночью” с коэффициентом x2 или x3 к ставке. В 80% случаев задача сразу становится терпящей до понедельника.
Частые ошибки и точки провала
Ошибка: Нарезка времени на куски (“поделаю все по чуть-чуть”)
Попытка выделить по два часа на четыре срочные задачи за день. Каждое переключение контекста съедает от 15 до 30 минут. В итоге ни одна задача не сдвигается существенно, а усталость команды удваивается.
Как избежать: Запретить работу над несколькими задачами в течение одного дня, если это возможно. Либо делить день строго на две части: до обеда – задача А, после обеда – задача Б.
Ошибка: Согласие на все со словами “постараемся успеть”
Менеджер боится отказать заказчику и берет задачу в работу, хотя физически времени нет. Заказчик уходит с ложным ожиданием, что все будет готово.
Как избежать: Говорить “нет” аргументированно. Показывать текущую загрузку и прямо заявлять: “Мы сможем взять это в работу не раньше четверга”.
Ошибка: Игнорирование узких горлышек
Вы расставили приоритеты, дизайнеры быстро нарисовали срочные макеты и скинули их единственному верстальщику. У верстальщика образовался завал, сроки все равно сорваны.
Как избежать: Приоритизировать задачи нужно не на этапе старта, а по всей цепочке до финального релиза. Если тестировщик перегружен, нет смысла брать в работу новые задачи на разработку.
Ограничения и исключения
Правила жесткой приоритизации работают не всегда. Есть случаи, когда стандартные фильтры придется нарушить.
Прямая директива собственника или генерального директора. Если владелец бизнеса требует сделать задачу немедленно, спорить с помощью матриц и фильтров чаще всего бесполезно и политически опасно. В этом случае задача берется в работу как абсолютный блокер, но менеджер обязан зафиксировать последствия: коротко написать руководству, какие именно проекты встали из-за этого решения и на сколько сдвинутся сроки.
Зависимость от внешних регуляторов. Если меняются требования законодательства, форматы чеков для налоговой или правила интеграции с Госуслугами – эти задачи автоматически становятся высшим приоритетом, даже если они не приносят прямой прибыли. Пропуск срока здесь означает остановку бизнеса извне.
Физические блокеры. Вы не можете приоритизировать задачу по сборке сервера, если комплектующие застряли на таможне. В таких случаях задача принудительно снимается с повестки, даже если она критически важна, и команда переключается на следующую по приоритету, чтобы не простаивать.
Как отказывать и переносить сроки: шаблоны коммуникации
Самое сложное при разгребании завала – сообщить заказчикам, что их “очень срочная” задача откладывается. Используйте формулировки, которые показывают контроль над ситуацией, а не беспомощность.
- Снятие иллюзий: “Сейчас у команды в работе инцидент с падением кассы и исправление критичного бага в корзине. Ваша задача по обновлению баннеров поставлена в очередь следующей. Мы сможем приступить к ней завтра в 11:00”.
- Передача ответственности за выбор: “Я понимаю, что выгрузка отчета нужна сегодня. Прямо сейчас мы делаем для вас интеграцию с CRM, которую вы просили сдать до пятницы. Если мы переключимся на отчет, релиз интеграции сдвинется на вторник. Что для вас сейчас важнее?”
- Отказ от “псевдосрочности”: “Мы оценили задачу. Она не влияет на текущие продажи и работоспособность системы, поэтому мы не можем пустить ее по аварийному процессу. Я добавил ее в бэклог, мы возьмем ее в планирование на следующей неделе”.
