Разработка дашборда Power BI: как составить техническое задание

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

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

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

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

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

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

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

Это ядро технического задания. Каждый показатель описывается по единой схеме: название, точная формула расчёта, единица измерения, источник исходных данных, периодичность и допустимые разрезы. Формулировка «выручка» недостаточна — нужно указать, включает ли она НДС, учитываются ли возвраты, берётся ли дата отгрузки или дата оплаты.

Минимальный набор атрибутов для каждой метрики:

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

Полезно сразу расставить приоритеты. Разделение показателей на обязательные и желательные позволяет запустить рабочую версию быстрее, а второстепенные метрики добавить на следующем этапе. Избыточный список KPI в первой версии — типичная причина, по которой проект не доходит до внедрения.

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

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

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

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

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

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

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

Регламент обновления определяет актуальность всей отчётности. В ТЗ указывается частота — раз в сутки, несколько раз в день или в реальном времени — и допустимое время формирования. Здесь же выбирается режим работы модели: импорт данных с периодическим обновлением или прямые запросы к источнику. Первый вариант быстрее для пользователя, второй актуальнее, но нагружает систему-источник.

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

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

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

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

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

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

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

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