Проектирование 3 из 3 - дэш core-слоя данных

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

Контекст. В большом продукте делается core-слой данных - набор сертифицированных витрин, на которые должна перейти аналитика всей компании. Цель проста на словах и больна на практике: чтобы аналитики перестали ходить в сырой слой, а ходили в core. Чтобы доверяли. Чтобы пользовались.

Дэш у этого продукта один. А смотрят его три разные группы людей - и хотят они принципиально разного.

1️⃣ Команда core-слоя - я и инженеры, которые этот core строят. Цель - видеть adoption: какая доля запросов уже идёт в core, какие домены сертифицированы, где доверие растёт, где валится. Решение - куда вкладывать инженерные руки на следующий спринт. Выходит с приоритетом на ближайшие 2 недели.

2️⃣ BI-партнёры доменов - аналитики и лиды кластеров, которые потребляют данные. Цель - найти свой домен и понять статус: что уже в core, что ещё в сыром слое, на что переключаться сегодня, а на что ждать. Решение - переписывать ли свои дэши и витрины под core прямо сейчас. Выходит со списком собственных миграций.

3️⃣ Менеджмент и data leadership - CDO-уровень и продуктовые руководители. Цель - убедиться, что продукт «core-слой» окупается: сколько денег экономит, сколько ресурсов сэкономили компании, как растёт доверие. Решение - расширять ли инвестиции, давать ли ещё команду, переводить ли в стратегию. Выходит с цифрой для квартального обзора.

Три контура - три разных вопроса к одним и тем же данным. Aдopt-метрика для меня - оперативный сигнал «где буксует». Для BI-партнёра - индикатор «можно ли уже верить этому домену». Для менеджмента - доказательство, что продукт жив.

Соблазн собрать всё на одном экране с фильтрами огромный. Не работает по той же причине, что в первых двух кейсах: разные вопросы требуют разной композиции. Менеджменту не нужен drill до конкретной витрины. Аналитику не нужны сводные индексы по компании. Команде core не нужен квартальный нарратив.

В Workbook ушло три сценария, переключение по ролевой кнопке. Шаблон 5+2 заполнялся отдельно для каждой роли:

▫️ Цель - зачем пришёл
▫️ Ожидаемое поведение - что делает руками
▫️ Ключевое решение - что решает на этом экране
▫️ Каких сценариев быть не должно - что дашборд намеренно НЕ показывает
▫️ Результат - с чем выходит

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

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

На двух контурах шаблон ещё можно держать в голове. На трёх - уже нет. Слишком легко перетянуть вопрос менеджмента в зону BI-партнёра и получить экран, на котором не отвечается ни один из трёх.

Главное наблюдение серии

Метод одинаковый - дэшы разные. Миграция, healthscore, core-слой - это три проектных контекста с разной аудиторией, но проектируются они одинаково: сначала роли с персонами и BI-уровнем, потом 5+2 на каждую роль, потом композиция экранов.

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

Шаблон не магия, а чек-лист. Просто заставляет проговорить вслух то, на что обычно машут рукой - «и так понятно».

🚀 На этом серия закрыта. Позже опубликую шаблон для проектирования взаимодействия 5+2.