Проектирование 1 из 3 - дэш миграции хранилища

Начинаю серию из трёх постов про проектирование дашбордов - не про инструменты, а про метод. На трёх живых кейсах покажу шаблон «Проектирование взаимодействия», который применяю на каждом новом дэше с широкой аудиторией.

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

Главный соблазн - сделать «один большой дэш для всех». Плитки KPI сверху, графики посредине, таблица снизу. Не работает.

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

Один дэш = один контур потребителей. Контуров два - либо два дэша, либо два сценария в одном Workbook. Смешивать нельзя.

Какие вопросы должны закрываться:

1️⃣ Какой сейчас статус готовности?
2️⃣ Какой темп миграции?
3️⃣ Какие домены отстают, какие опережают?
4️⃣ Не видно ли странных ускорений или провалов в объектах?
5️⃣ Если есть отклонения - какие и в чьей зоне ответственности?

Пятый - ключевой. Он превращает дэш из «красивого монитора» в инструмент решения. Action items не висят в воздухе, а привязаны к фамилии и задаче.

Шаблон «Проектирование взаимодействия»

Сейчас 5 пунктов про дэш и 2 про условия, в которых он живёт. К этой форме я пришёл не сразу.

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

5 пунктов про сам дэш:

▫️ Цель - зачем сюда пришёл
▫️ Ожидаемое поведение - что делает руками: фильтры, сортировки, клики, drill-down
▫️ Ключевое решение - что решает на основе экрана
▫️ Каких сценариев быть не должно - что дашборд намеренно НЕ показывает
▫️ Результат - с чем выходит (action items или «ничего делать не надо»)

2 пункта про условия:

▫️ Сигналы доверия - почему верит цифрам
▫️ Контекст использования - когда заходит, как часто, регулярно или одноразово

Над каждой ролью - персона-карточка с должностью, опытом, техническими навыками и BI-уровнем (★1–5). Это не для красоты: человек с BI ★★★★★ и sql-high живёт в дэше иначе, чем с ★★ и Excel.

Применение к миграции

Два контура - менеджер и куратор домена.

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

Куратор домена - каждый день фильтрует свой домен с drill до объектов, понимает куда вложиться сегодня, выходит со списком своих объектов по приоритету; чужие домены и общие KPI компании только мешают. Доверяет, потому что статусы совпадают с его трекером задач.

Это два сценария одного Workbook - «обзорный» и «по домену», переключение одной кнопкой. Никакого «универсального экрана с фильтрами» - даже фильтры разные.

Вывод

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

Шаблон с 5+2 выглядит избыточно, пока не попробуете раз. На втором кейсе он превращается в напоминалку: «ты не закрыл сигналы доверия» - значит дэшу не будут верить, как ни рисуй.

🚀 Дальше в серии: дэш здоровья метрик (где разделяются «куратор» и «оунер метрики») и дэш core-слоя (где контуров уже три).