Задача «горит», срок уже на горизонте, а в командном чате снова появляется дежурное «ну как там?». По данным Habr / Менеджмент, менеджер продукта Вера из YouGile предлагает смотреть не на виноватых, а на узкие места в работе: то есть на этапы, где задачи системно лежат дольше нормы и ломают ритм всей команды.
Поводом для заметки стала короткая практическая колонка в корпоративном блоге YouGile на Habr. Автор описывает знакомую для любой продуктовой или разработческой команды картину: дедлайны уже поджимают, статус вроде бы «в работе», но понять, что именно застопорилось, можно только после серии сообщений и созвонов. Вместо ручного контроля по людям предлагается более трезвый подход: сначала описать нормальный ход процесса, затем искать отклонения, разбирать причину задержки и только после этого менять правила работы. Логика простая, но для российских команд, где менеджмент нередко держится на личном контроле и чате, она звучит почти как санитарный минимум.
Ключевая мысль автора в том, что узкие места в работе нельзя увидеть, пока у команды нет хотя бы базового представления о норме. Если не договориться, сколько в среднем занимает разбор входящих задач, сколько длится согласование и сколько можно ждать ответа от клиента, любая задержка будет выглядеть либо катастрофой, либо бытовой рутиной. Вера предлагает сначала зафиксировать эти ожидания в общем чате, таблице или таск-трекере. Пример из текста предельно прикладной: входящие задачи сотрудники разбирают в течение дня, согласование укладывается в 1–3 дня, ожидание ответа от клиента может занимать до 10 дней. Только на таком фоне видно, где действительно появилось бутылочное горлышко, а где процесс идет так, как и был устроен.
Дальше начинается самое полезное для практики. Автор советует не гадать, почему «все тормозит», а искать аномалии по статусам: какие задачи стоят на одном этапе заметно дольше привычного срока. В маленькой команде это можно делать вручную, просто проходя утром по задачам и задавая прямой вопрос, что именно мешает продвинуть работу. В YouGile для этого используется счетчик времени на текущем этапе: если обычно согласование занимает пару дней, а конкретная задача висит там неделю, значит, проблема уже не в ощущениях менеджера, а в наблюдаемом отклонении. Для ИТ-команд это важный сдвиг: обсуждение перестает быть эмоциональным и становится операционным. Не «почему вы опять не успели», а «почему этот этап живет в 3 раза дольше, чем мы сами считаем нормой».
Отдельно автор раскладывает причины задержек на пять типовых сценариев. Первый: задача просто потеряла актуальность и неделями лежит без движения. Второй: исполнитель перегружен, и старые задачи копятся именно у него. Третий: возник блокер, то есть человеку не хватает вводных, материалов или решения извне. Четвертый: нарушена гигиена процесса, когда задача формально числится активной, но фактически ей никто не занимается. Пятый: сам этап спроектирован неудачно, поэтому задачи раз за разом застревают именно здесь, например на согласовании. Этот список хорош тем, что снимает привычное менеджерское искушение все свалить на дисциплину конкретного человека. Иногда проблема действительно в загрузке или приоритетах, но не реже она сидит в самой конструкции процесса.
Практические меры в заметке тоже без экзотики, и в этом ее сила. Если на этапе стабильно копятся карточки, нужно ограничить количество задач в работе, то есть ввести WIP-лимит. Если в системе много старых и уже ненужных задач, их нужно убирать в бэклог или архив, чтобы они не искажали картину загрузки. Если этап слишком широкий, его стоит дробить: условное «Согласование» почти всегда скрывает несколько разных очередей ожидания, от клиента до юристов или руководителя. Если команда по-разному понимает, когда задача готова к следующему статусу, нужно формализовать правила перехода: что считается завершением этапа, кто проверяет результат, в каком виде задача может двигаться дальше. Наконец, ожидание внешнего ответа автор предлагает маркировать отдельно, чтобы не путать его с реальной активной работой. Для разработчиков и продактов это, по сути, напоминание о старом, но регулярно игнорируемом принципе: не вся «занятость» равна прогрессу.
В тексте есть и еще один важный слой, который выходит за рамки конкретного инструмента. Хотя примеры показаны на YouGile, описанный подход легко переносится на любой трекер или даже на простую доску в таблице. Суть не в функции счетчика или стикера как таковой, а в дисциплине наблюдения за потоком задач. Российские ИТ-команды давно живут между двумя крайностями: либо избыточные отчеты, которые никто не читает, либо полное доверие к статусу «в работе», пока не начнется аврал. Алгоритм из статьи предлагает промежуточный вариант: не собирать бюрократию ради бюрократии, но и не управлять проектом по интуиции. Особенно это актуально для небольших команд, где менеджер, продакт и иногда еще и аналитик часто живут в одном человеке.
Есть и понятный бизнес-сигнал. Когда узкие места в работе видны рано, компания снижает стоимость управленческой паники: меньше срочных пингов, меньше хаотичных переключений контекста, меньше задач, которые внезапно «всплыли» за день до релиза. Для HR и руководителей это тоже полезная рамка: если у одного сотрудника стабильно копятся задачи, причина может быть не в слабой мотивации, а в неправильной нагрузке или в том, что через него проходит слишком много обязательных согласований. Для фаундеров и директоров вывод еще жестче: если весь критический путь регулярно упирается в одного человека, это уже не частный сбой, а архитектурная проблема команды.
В финале автор пишет, что вместо ручных отчетов использует сводную доску, где автоматически собираются просроченные дедлайны, загрузка сотрудников и активные блокеры, а сам сервис доступен бесплатно для команд до 10 человек. Но главный вывод шире любого продукта: в 2026 году узкие места в работе остаются не следствием нехватки чатов, созвонов и напоминаний, а следствием непрозрачных процессов. И чем раньше команды перестанут лечить это сообщением «ну как там?», тем меньше им придется разгребать последствия в последний день спринта.