В Cisco подготовка стратегической отчётности по проектам и ресурсам занимала 40 часов. Данные лежали в нескольких базах Oracle, и каждую неделю кто-то из команды сводил их вручную в один файл. После перехода на единый дашборд это время сократилось до 15 минут (кейс Cisco).

Цифра красивая, но ловушка в другом. Проблема руководителя обычно не в том, что отчёт собирается долго. Проблема в том, что собранный отчёт ничего не говорит.

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

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

Почему 40 графиков работают хуже, чем семь цифр

Дашборд ломается не от нехватки данных. Он ломается, когда у метрики нет решения, которое она запускает.

Практические руководства по дашбордам сходятся в одном: на управленческом уровне должно быть 5–8 показателей, и у каждого пять обязательных атрибутов — текущее значение, цель, статус (цвет), тренд и владелец. Метрика без владельца и без цели остаётся украшением дашборда.

Celoxis формулирует это жёстче: сильный дашборд отслеживает только те метрики, которые несут управленческий сигнал — отклонение по срокам, отклонение по стоимости, загрузку ресурсов — и строится вокруг действий, а не вокруг сырых данных (Celoxis о дашбордах).

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

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

Три вопроса, на которые дашборд обязан отвечать за минуту

Три вопроса, на которые должен отвечать дашборд руководителя
Три вопроса, на которые должен отвечать дашборд руководителя

Прежде чем выбирать метрики, стоит зафиксировать вопросы, на которые дашборд должен отвечать. Всё, что не отвечает ни на один из них, уходит в отчёты по запросу.

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

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

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

Ниже — семь метрик, которые закрывают эти три вопроса, плюс два слоя, которые большинство дашбордов теряет: качество и связь с целями.

Семь метрик, которые стоят на экране ежедневно

Семь метрик управленческого дашборда

МетрикаКак считатьПорог тревогиПервое действие
Отклонение по срокам% объёма против плана, число сдвинутых вехДва сдвига подряд или >10%Пересобрать критический путь
БюджетРасход против плана и против фактического объёмаРазрыв кривых >15 п.п.Пересмотр объёма работ
Загрузка командыДоля занятых часов от доступного фонда>90% или <50% устойчивоПерераспределить задачи
Риски и блокерыЧисло задач в блоке и дни простояБлок >3 дней, рост 2 неделиЭскалация зависимости
Пропускная способностьФакт/план по закрытым задачам, время циклаПадение при неизменной загрузкеРазбор причин в процессе
Качество% задач, вернувшихся из проверкиРост доли возвратовПересмотр критериев готовности
Прогресс по целям% выполнения 1-2 ключевых результатовСтагнация 2+ неделиПересмотр приоритетов проекта

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

Отклонение по срокам: насколько план разошёлся с фактом

Отклонение от графика, сдвиг вех и прогнозная дата завершения — базовый слой любого дашборда (Rocketlane). Считать просто: доля выполненного объёма против планового на текущую дату плюс число вех, сдвинутых за последние две недели. Порог тревоги — сдвиг двух вех подряд или отклонение больше 10%. Это повод пересобрать критический путь, а не «поторопить команду» на планёрке. Выводить стоит именно прогнозную дату завершения, а не процент готовности: последний почти всегда врёт.

Бюджет: скорость сжигания против прогресса

Статус бюджета, план против факта расходов, отклонение по бюджету — обязательный слой контроля. Сама по себе цифра «израсходовано 60% бюджета» бессмысленна без второй: «сделано 40% объёма работ». Опасен именно разрыв между этими двумя кривыми, а не каждая из них по отдельности. Celoxis приводит ориентир: 45% крупных IT-проектов выходят за бюджет, а 19% рискуют быть свёрнутыми именно из-за этого разрыва. Порог тревоги: расхождение между кривой расхода и кривой прогресса больше 15 процентных пунктов — сигнал пересмотреть объём работ, а не урезать смету на бумаге.

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

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

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

Риски и блокеры: важна динамика

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

Пропускная способность: сколько команда реально закрывает

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

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

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

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

Прогресс по целям: связь проекта со стратегией

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

Метрика Как считать Порог тревоги Первое действие
Отклонение по срокам % выполненного объёма против плана, число сдвинутых вех Два сдвига подряд или отклонение >10% Пересобрать критический путь
Бюджет Расход против плана и против фактического объёма работ Разрыв кривых >15 п.п. Пересмотр объёма работ
Загрузка команды Доля занятых часов от доступного фонда >90% или <50% устойчиво Перераспределить задачи
Риски и блокеры Число задач в блоке и дни простоя Блок >3 дней, рост блокеров 2 недели Эскалация зависимости
Пропускная способность Факт/план по закрытым задачам, время цикла Падение при неизменной загрузке Разбор причин в процессе
Качество % задач, вернувшихся из проверки Рост доли возвратов Пересмотр критериев готовности
Прогресс по целям % выполнения 1–2 ключевых результатов Стагнация 2+ недели Пересмотр приоритетов проекта

Зелёный дашборд опаснее красного

Зелёный дашборд не всегда означает здоровый проект
Зелёный дашборд не всегда означает здоровый проект

Дашборд, на котором всё зелёное, чаще означает плохие метрики, а не здоровый проект.

Ложную зелень создают три механики. Первая — метрики активности: закрытые задачи и залогированные часы растут, индикаторы зелёные, но ни одна из этих цифр не измеряет результат. Вторая — процент выполнения, который руководитель проставляет вручную: он почти всегда «90% готово» вне зависимости от реального положения дел и не предсказывает дату финиша. Третья — усреднение по портфелю: средняя загрузка 75% легко скрывает двух людей на 120% и трёх на 40%.

Источники 2025–2026 годов фиксируют общий сдвиг: от статических отчётов к обновляемым в реальном времени, от метрик активности к метрикам результата, от статуса к прогнозу рисков и загрузки.

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

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

Cisco и Deloitte: что меняется, когда отчёт перестаёт быть ручным

Ключевые цифры трансформации отчётности в Cisco
Ключевые цифры трансформации отчётности в Cisco

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

В Cisco данные по проектам и ресурсам до внедрения были разнесены по нескольким базам Oracle, а стратегическая отчётность собиралась вручную. На новый дашборд вывели шесть срезов: воронку будущих проектов, распределение ресурсов, сроки, бюджет, стоимость на проект и анализ ROI. Скорость принятия решений на уровне портфеля выросла на 75%, экономия на перераспределении ресурсов — $2,3 млн в год.

В Deloitte статусы проектов и вехи до этого жили в таблицах и статических документах, которые обновляли руками и рассылали по почте. Команда собрала единое представление по проектам и ключевым этапам для офиса CEO, и время на подготовку недельной и месячной отчётности резко сократилось (кейс Deloitte). Точных процентов источник не приводит, и кейс важен не цифрой, а природой изменения: ручная рассылка статусов заменена одним актуальным срезом, который не нужно пересобирать перед каждой встречей.

В обоих случаях состав метрик почти совпадает с теми семью, что выше. Эффект дала не аналитика сама по себе, а устранение ручной пересборки данных. Если каждую цифру кто-то вбивает руками перед планёркой, дашборда как инструмента управления ещё нет — есть красиво оформленная таблица.

Как собрать такой дашборд без аналитика и отдельной аналитической платформы

Как собрать дашборд из существующих данных

flowchart LR A[Задачи] --> E[Дашборд] B[Учёт времени] --> E C[Цели и OKR] --> E D[Финансы] --> E E --> F[Действие руководителя]

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

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

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

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

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

Дашборд в Excel или Google Sheets допустим как переходный вариант на первое время. Такой дашборд статичен: к моменту обсуждения на планёрке цифры уже устарели на день-два. Если данные лежат в трекере, читать их нужно оттуда напрямую, а не через ручной экспорт раз в неделю.

Ритм работы с дашбордом: 10 минут утром, 30 минут в пятницу

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

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

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

Работает правило владельца: у каждой из семи метрик есть человек, который объясняет отклонение. Без этого обсуждение сводится к общему «ну, задачи двигаются» — фразе, которая ничего не решает. Второе правило — «один сигнал, одно действие». Заранее записанная реакция (кого собрать, что урезать, чей срок пересогласовать) превращает дашборд из отчёта в инструмент, которым реально пользуются.

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

Семь вещей, которые не нужны на управленческом экране

⚠️ Метрика без владельца — мёртвый груз
Если за отклонением никто не отвечает объяснением, оно просто лежит на дашборде. Графики, которые никто не комментировал месяц, — верный признак, что место можно освободить.

Большая часть «утопления в отчётах» лечится удалением метрик.

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

Третий кандидат на удаление — ручной процент готовности. Он почти всегда застревает на уровне 80–90% и не говорит ничего о реальной дате завершения. Четвёртый — средние значения по портфелю без разреза по людям: средняя загрузка маскирует и перегруз, и простой одновременно.

Дальше идут метрики без владельца. Если за отклонением никто не отвечает объяснением, оно просто лежит мёртвым грузом. Туда же — графики, которые никто не комментировал за последний месяц: верный признак, что метрика декоративная и место можно освободить. И последнее: детализация по подзадачам на верхнем уровне. Такая глубина нужна при разборе конкретной проблемы, а не в еженедельном обзоре.

Три шага, которые можно сделать на этой неделе

  1. Выписать три управленческих вопроса для своего проекта и отбросить всё, что на них не отвечает. Оставить максимум семь метрик.
  2. Привести данные в порядок на одном проекте: сроки, исполнители, оценки трудозатрат, стадии. Посчитать руками две цифры — загрузку команды и разрыв между расходом бюджета и прогрессом по объёму.
  3. Назначить владельцев метрик и порог тревоги для каждой, зафиксировать реакцию на срабатывание и поставить сам ритуал просмотра в календарь: 10 минут утром и 30 минут в пятницу.

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

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

Что такое дашборд для руководителя?

Один экран с 5–8 показателями, у каждого есть значение, цель, статус, тренд и владелец. Задача дашборда — запускать решения, а не описывать прошлое в красивых графиках.

Чем дашборд по управлению проектами отличается от отчёта?

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

Сколько метрик оптимально держать на экране?

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

Можно ли сделать дашборд в Excel?

Как переходный вариант — да. Такой дашборд статичен и требует ручного обновления перед каждой встречей. Кейсы Cisco и Deloitte — это именно уход от ручной пересборки таблиц к живым данным.

Какие KPI у администратора проекта, который ведёт данные для дашборда?

Главный KPI — актуальность данных: доля задач со сроком и оценкой трудозатрат, скорость обновления статусов, время закрытия блокеров, полнота реестра рисков.

Что должен уметь руководитель проекта, чтобы дашборд реально работал?

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

Что такое дашборд для руководителя?

Один экран с 5–8 показателями, у каждого есть значение, цель, статус, тренд и владелец. Задача такого дашборда — запускать решения, а не описывать прошлое в красивых графиках.

Чем дашборд по управлению проектами отличается от отчёта?

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

Сколько метрик оптимально держать на экране?

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

Можно ли сделать дашборд в Excel?

Как переходный вариант — да. Такой дашборд статичен и требует ручного обновления перед каждой встречей. Оба публичных кейса из этой статьи, Cisco и Deloitte, — это именно уход от ручной пересборки таблиц к живым данным.

Какие KPI у администратора проекта, который ведёт данные для дашборда?

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

Что должен уметь руководитель проекта, чтобы дашборд реально работал?

Договариваться о критериях готовности до начала работы, пересогласовывать объём при серьёзном отклонении и читать тренды, а не отдельные значения на один момент времени. Подробнее о нужных для этого навыках — в материале про успех project-менеджера.

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