В зависимости от задачи BI-разработчик может самостоятельно собирать требования на дашборд, а может работать с готовым техническим заданием (ТЗ).
🦄 Давайте сегодня пофантазируем, как выглядит идеальное ТЗ на дашборд:
🤩Оно существует, причём в письменном виде
Во-первых, трудно угодить требованиям, которых нет.
Во-вторых, письменный вид ТЗ более эффективен, чем голосовые сообщения, потому что формулирование текста заказчиком помогает систематизации мыслей. К тому же с текстом проще работать, например, использовать его в системах управления проектами (типа Jira).
🤩Оно согласовано с ключевым пользователем, если заказчик и пользователь дашборда не совпадают
Грустно переделывать дашборд с нуля, когда заказчик показал его своему руководителю, и тот попросил всё поменять.
А если уровней руководства больше, то просьб поменять становится больше, а значит появляются версии 3.0, 4.0 и т.д., и с каждой версией становится ещё грустнее.
🤩Из ТЗ понятен контекст – обозначена целевая аудитория и группы пользователей, какие бизнес-вопросы дашборд должен решить
«Дашборд в вакууме» не принесёт реальную бизнес-ценность.
🤩Содержит информацию об источниках данных и логику разработки витрин – названия таблиц, витрин, справочников, связи между ними, описание расчёта метрик
Самостоятельный поиск данных и уточнение методологии расчёта занимают очень много времени.
🤩В ТЗ указаны нюансы, которые важны для заказчика и которые будут проверяться при приёмке дашборда
Например, если важно специальное форматирование шрифтов в таблице (бывает и такой изысканный запрос), то нужно это отметить.
🤩Содержит примеры графиков и интерфейса, если есть чёткие требования к визуализации
Если вы увидели у коллеги из другого отдела интересный график и хотите такой же, то добавьте скриншот или ссылку на него.
Лучше 1 раз увидеть, чем 100 раз услышать и пытаться со слов или из описания понять, что же нужно.
🤩Содержит очерёдность этапов, если это важно
Сразу всё сделать невозможно, если с задачей работает всего один человек. Но с большой задачей можно расправиться последовательно.
Чтобы то, с чего начал разработчик, не стало неожиданностью, нужно приоритизировать этапы.
🤩Не меняется
Такого, конечно, не бывает, но мы фантазируем🌟
Изменение требований вызывает трудозатраты не только на создание нового/переделку старого, но и на изящное вписание новых фич в существующий функционал.
❓Что бы ты добавил? Встречал ли
#дашборд #fun