Дашборд — инструмент для понимания того, что данные соответствуют ситуации, в которой находится продукт. Но для поиска причин проблем продукта дашборд не подходит.
Для наглядности, рассмотрим ситуацию с панелей приборов автомобиля.
Если вы стоите на обочине с заведенным и прогретым движком, то показатели на панели приборов будут одни. Если мчитесь по трассе на скорости 100 км/ч на пятой передаче, то показатели будут другие, если на четвертой передаче, то третьи. Только водитель сопоставит показатели с текущей ситуацией и сделает вывод — всё ок или что-то не так.
В движении вы тратите на панель приборов мизерную часть своего времени. Остальное время — управляете, смотрите вперед, следите за знаками и т.д. Если вы не водитель, то показатели тахометра вам ни о чём не скажут.
Наоборот, автомеханик может весь день наблюдать за тахометром или датчиком температуры, но он не изменит сложившуюся ситуацию, пока не влезет под капот.
При ремонте автомобиля механик вряд ли будет ориентироваться на панель приборов. Скорее всего он достанет свои инструменты, с помощью которых получит необходимые ему показатели двигателя и его составляющих — коннектор OBD2-сканер или другое ПО. Так он разберется и устранит поломку. Такие показатели отсутствуют на панели приборов.
Таким образом, дашборд редко используют для отладки как водитель, так и механик.
Аналогична ситуация с работой аналитиков в продуктовой команде. Дашборд — это хорошо, но это вершина айсберга. Взглянув на него — вы не определите причину “поломки”, вы лишь поймете, что “поломка” имеет место быть.
Для грамотного управления продуктом нужны глубокие выкладки текущей ситуации и понимание в целом — что происходит с продуктом. А для этого дашборд снова не подходит. Аналитик будет использовать свои инструменты, более специализированные под конкретную проблему.
Поэтому важно понимать назначение дашбордов и их ценность для продуктовой команды.
Насколько высоко вы оцениваете необходимость дашбордов для своих проектов? Как часто вы используете данный инструмент?
