Узкие места в проекте: находим по данным задач, а не на глаз

Доля просроченных проектов у пяти крупнейших российских девелоперов выросла с 3,2% в феврале 2025 года до 12,7% в феврале 2026-го. Проблемный объём строительства увеличился с 503,8 тыс. м² до 1,95 млн м². Каждый восьмой строящийся квадратный метр у этих компаний сейчас идёт с отставанием от графика (Invest Foresight).

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

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

Что считать узким местом, а что — просто медленным этапом

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

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

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

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

Почему «по ощущениям» узкое место находят не там, где оно есть

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

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

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

Рынок в 2026 году уже перешёл от догадок к цифровым следам. Крупные банки разбирают связку Process Mining, Task Mining, RPA и ИИ ровно потому, что экспертная оценка «где мы тормозим» систематически расходится с логом событий системы. Формализация дошла и до государственного уровня: в нацпроекте «Экономика данных и цифровая трансформация государства» на 2025–2030 годы закреплены конкретные метрики управленческих процессов, а именно медианный срок согласования, доля просрочек, число возвратов на доработку и загрузка согласующих (РАНХиГС). Эти четыре показателя — готовый минимальный дашборд для любого проектного офиса. Изобретать его заново не нужно.

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

Шесть показателей из таск-трекера, которые выдают узкое место

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

Метрика time in status делает скрытые задержки видимыми, потому что раскладывает общее время цикла на составляющие. Без неё легко пропустить, что «в работе» задача формально числится три дня, а фактически два из них просто ждала внимания. Тот же принцип лежит в основе классической диагностики потока: узкое место ищут через связку cycle time, длины очередей и throughput, причём на уровне отдельных задач, а не крупных вех проекта.

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

Что показывает канбан-доска, чего не видно в диаграмме Ганта

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

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

Гант — карта зависимостей. Одна задержанная задача на критическом пути порождает не одну просрочку, а каскад: смещаются все, кто от неё зависел. Если в проекте одновременно 40 просроченных задач, проверьте, не растут ли они из двух-трёх задач-предшественниц. Часто оказывается, что весь каскад запустила одна точка.

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

Узкое место бывает внешним, ресурсным. В России за три года приостановлено 38 проектов дата-центров общей стоимостью около 2,3 млрд долларов, при этом почти три четверти коммерческой мощности ЦОД сосредоточено в Московском регионе. В трекере такое ограничение выглядит как массовое зависание этапов, требующих подключения внешней стороны. Похожая картина в логистике: приоритетом зимнего отраслевого обзора 2025 года по Дальнему Востоку названа «ликвидация узких мест на суше», то есть простой вагонов и очереди на погрузку. В операционных задачах это видно как повторяющиеся задержки одного и того же типа.

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

Улучшив не то звено, вы сделаете поток хуже

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

Команда наняла двух дизайнеров, скорость дизайна выросла на 40%. Узкое место при этом — единственный согласующий на стороне заказчика. Итог: очередь на согласование выросла с 6 карточек до 11, время цикла проекта увеличилось. Деньги на найм потрачены, поток остался прежним, задачи стали быстрее долетать до пробки и дольше в ней стоять. Для команды это выглядит как ускорение, для заказчика ничего не изменилось.

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

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

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

Кейсы: что дали данные задач в цифрах

Эффект от точной локализации узкого места измеряется десятками процентов времени цикла. Изменения при этом почти всегда точечные, масштабная реформа процесса не требуется.

Промышленное подразделение: 34 минуты → менее 12

Infosys BPM применила digital process discovery и task mining, чтобы разобрать фактические действия сотрудников по операциям, а не то, как процесс описан в регламенте. Среднее время обработки в одном блоке снизилось с 34 минут до менее чем 12, в другом — с 11 до 5 минут. В документе также заявлены потенциальный рост производительности до 90% и потенциальная экономия 336 тысяч долларов (Infosys BPM). Сокращение дало устранение конкретных лишних шагов, которые были видны только в детальных данных по каждой операции.

Агентство: срыв сроков 15% и два виновника, которых не подозревали

Здесь важна оговорка: компания в публикации не названа, речь идёт об агентстве среднего размера, которое в среднем срывало сроки на 15%. Анализ данных на уровне задач за шесть месяцев показал, что основной вклад дают доработки дизайна и клиентские согласования, а не разработка с тестированием. После пересмотра сроков на ревью и добавления буфера перед согласованием среднее время доставки проектов улучшилось на 12% в следующем квартале, а удовлетворённость стейкхолдеров выросла на 18%. Процесс не переписывали, изменили два параметра.

Brightline: узкое место было не в команде, а в способе получения данных

Рост пассажиропотока создал очередь запросов к аналитикам: бизнес-команды ждали SQL-выгрузок и отчётов днями и неделями, что тормозило реакцию на операционные проблемы (кейс Brightline). Аналитики работали быстро, но каждый запрос проходил через одного человека. Если через одну роль проходит вся работа, с высокой вероятностью это и есть ограничение, независимо от того, насколько хорошо этот человек справляется.

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

Данные врут чаще, чем кажется: чек-лист перед анализом

Анализ времени в статусах имеет смысл только при дисциплине их обновления. Без неё вы измеряете качество ведения трекера, а не сам процесс. Это одна из самых частых претензий практиков к аналитике по задачам: данные вроде бы есть, а качества данных нет. Статусы обновляются нерегулярно, этапы называются по-разному, и по доске нельзя понять, где работа реально стоит.

Перед тем как считать метрики, проверьте пять пунктов.

• Статусы обновляются в момент события, а не пачкой в конце недели, иначе время в статусе искажено на дни.
• Внутри статуса «В работе» не прячется фактическое ожидание. Минимум: разделить «идёт работа» и «ждёт».
• Этапы называются одинаково во всех проектах, иначе метрики нельзя агрегировать между командами.
• Задачи сопоставимы по размеру: медиана цикла по задачам от двух часов до трёх недель не говорит ни о чём без сегментации по типу или оценке трудозатрат.
• Просроченные задачи не переносятся «задним числом» без пометки, иначе доля просрочек покажет ноль при фактическом провале графика.

Смотрите медиану и 85-й процентиль вместо среднего. Одна задача, зависшая на 40 дней, сдвигает среднее и полностью скрывает нормальную картину по остальным.

Как локализовать узкое место в Shtab, не перестраивая процесс

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

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

Потом расчёт. Shtab не выводит готовый отчёт «время в статусе» одной кнопкой. Задачи выгружаются в XLSX, и уже на своей стороне считаются медианы по этапам, доля просрочек и число возвратов. Это ручная работа, автоматической аналитики такого рода в системе нет.

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

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

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

Четыре способа расшить узкое место, когда переделывать процесс нельзя

В большинстве проектов ограничение снимается изменением одного параметра потока, реформа для этого не нужна.

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

Третий способ — разгрузить единственного носителя редкой компетенции. Ещё один такой же специалист проблему обычно не решает, а вот вынести из его потока типовые задачи через шаблоны и чек-листы приёмки, передав часть решений на уровень ниже, реально помогает. Об этом подробнее в материале про делегирование задач. Четвёртый способ — изменить порядок входа работы, а не скорость её выполнения. Грамотная приоритизация задач часто даёт больше, чем попытка ускорить исполнение уже принятых в работу задач.

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

План на неделю: с чего начать диагностику завтра

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

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

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

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

Частые вопросы

Что произойдёт, если повысить производительность участка, который не является узким местом?

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

Что является узким местом в процессе?

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

Каковы признаки проекта, в котором есть узкое место?

Пять наблюдаемых сигналов: просрочки концентрируются на одном этапе; часть команды простаивает в ожидании; растёт число задач, стоящих без движения больше недели; доля возвратов на доработку выше 15%; сроки сдвигаются каскадом от одних и тех же задач-предшественниц.

Можно ли найти узкое место без process mining?

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

Как часто пересчитывать метрики?

Раз в 2–4 недели по одному потоку задач. После устранения ограничение обычно перемещается на следующий этап, поэтому диагностика узких мест остаётся регулярной процедурой.

Что делать, если узкое место на стороне заказчика?

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

Заключение

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

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

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

Читайте также

• WIP-лимиты в Kanban: как остановить лавину незавершённых задач
• как рассчитать WIP-лимиты для команды
• Kanban-доска для контроля потока задач
• эскалация задач и инцидентов в проектных командах
• отчётность и дашборды для отслеживания метрик проекта