Запрос «сделайте нам красивый дашборд» звучит понятно ровно до первой встречи. Красивый для кого? Что человек должен решить? Какая выручка — по заказу или оплате? Как часто обновлять?
Хорошее ТЗ отвечает на эти вопросы до того, как разработчик нарисует двадцать графиков. Дашборд начинается с управленческого действия, а не с палитры.
Что это такое простыми словами
Требования описывают пользователей, решения, показатели, разрезы, источники, обновление, права, взаимодействия и критерии приёмки. Этого достаточно, чтобы оценить работу и снизить число переделок.
Макет важен, но он не заменяет формулу. Если на нём написано «прибыль», рядом должен существовать контракт: состав доходов и расходов, период, дата и владелец.
Техническое задание может быть коротким. Пять точных страниц полезнее сорока страниц общих слов, которые одинаково подходят магазину, заводу и космодрому.
Зачем это бизнесу
Собственник заранее понимает, какие решения поддержит отчёт. Команда данных видит объём источников и проверок. Пользователи могут принять результат не по ощущению, а по сценариям.
Требования защищают и от лишнего. Если график не помогает ни одному решению, его можно не строить. Экономится экран, время и будущая поддержка.
Отдельный блок об обновлении и ошибках делает дашборд продуктом, а не одноразовой презентацией.
Как сделать: пошаговый порядок
- Назовите пользователей и три решения, которые они принимают регулярно.
- Для каждого решения выберите основной показатель, сравнение и допустимый порог.
- Опишите формулы, источники, дату, единицы и владельцев показателей.
- Задайте фильтры, детализацию и путь от сигнала к списку объектов.
- Определите частоту обновления, время готовности, права и поведение при ошибке.
- Соберите прототип, проведите сценарную проверку и запишите критерии приёмки.
Формула или логика расчёта
Для приоритета используйте простую оценку: частота решения × стоимость ошибки × число пользователей. Показатель, который собственник проверяет ежедневно и по которому распределяет бюджет, попадёт в первую версию раньше редкого интересного среза.
Подробный пример с числами
Компания заказала дашборд продаж с 28 виджетами. На интервью выяснилось, что директор каждое утро решает три задачи: где отстаём от плана, какие сделки рискуют перенестись и кому нужна помощь.
Первую версию сократили до семи блоков. Для прогноза зафиксировали сумму, вероятность этапа, плановую дату и просрочку следующего шага. Источником стала CRM, обновление — каждый час до 9:00.
Критерий приёмки: итог по закрытым сделкам совпадает с контрольной выгрузкой на 100%; открытые сделки расходятся не более чем на согласованные статусы; страница открывается быстрее пяти секунд; пользователь видит только свой регион.
Разработка заняла меньше времени, а директор стал использовать отчёт на ежедневной встрече. Оставшиеся 21 виджет никто не попросил вернуть (они пережили это достойно).
Как провести приёмку дашборда
Начните с данных. Выберите контрольный период и сверьте общий итог, несколько групп и конкретные строки. Проверяйте не только обычные продажи, но и возврат, отмену, частичную оплату и запись на границе периода. Итог без крайних случаев даёт ложное спокойствие.
Затем пройдите пользовательские сценарии. Руководитель должен за минуту увидеть сигнал, открыть причину и получить список объектов для действия. Если на каждом шаге нужен экспорт в Excel, дашборд пока показывает, но не помогает.
Проверьте обновление: время последней успешной загрузки, поведение при задержке и уведомление. Пользователь должен отличать «сегодня всё спокойно» от «сегодня данные не приехали». Пустой график не обязан хранить интригу.
Отдельно протестируйте права. Войдите под каждой ролью, попробуйте прямую ссылку, экспорт и детализацию. Скрытая вкладка не защищает данные, если набор доступен через другой путь.
Проверьте производительность на реальном объёме и обычном устройстве. Зафиксируйте время первого открытия, фильтрации и перехода к деталям. Если целевой порог не выполняется, решайте модель и запросы до расширения дизайна.
Через месяц после запуска посмотрите использование и решения. Какие страницы открывают, какие фильтры применяют, какие сигналы привели к действию? Неиспользуемый блок можно убрать или переделать. Приёмка продукта продолжается после технической сдачи.
Короткий чек-лист
- контрольные суммы и строки
- крайние бизнес-сценарии
- путь от сигнала к действию
- свежесть и ошибка загрузки
- права и экспорт
- скорость и фактическое использование
Как превратить расчёт в решение
В ТЗ добавьте состояния интерфейса: данных нет, загрузка идёт, источник опоздал, доступ запрещён, фильтр ничего не нашёл. Пустая белая область не объясняет пользователю, что делать дальше.
Определите детализацию. Руководитель видит отклонение по региону, затем проваливается до менеджера и сделки. Если путь заканчивается на втором графике, действие снова переезжает в ручную выгрузку.
Согласуйте единицы и формат. Рубли или тысячи рублей, календарная или рабочая неделя, НДС внутри или снаружи. Эти мелочи не мелкие, когда руководитель сравнивает план и факт на встрече.
Планируйте развитие. Первая версия закрывает три решения, а backlog хранит следующие проверенные задачи. Новый виджет добавляется вместе с пользователем, действием и источником — иначе экран снова начнёт собирать коллекцию.
Что должно быть зафиксировано
- состояния без данных и ошибки
- путь до объекта действия
- единицы и календарь
- критерии мобильного вида
- backlog с бизнес-причиной
Рабочий план на четыре недели
Пилот нужен не ради ещё одного файла. За месяц команда должна получить воспроизводимый расчёт, увидеть ограничение и принять хотя бы одно решение. Объём специально небольшой: один сегмент, один процесс и один ответственный. Так результат можно проверить, а не объяснять масштабом.
- Неделя 1: проведите интервью и зафиксируйте три решения будущих пользователей.
- Неделя 2: согласуйте метрики, источники, права, обновление и состояния ошибок.
- Неделя 3: соберите прототип и пройдите путь от сигнала до конкретного действия.
- Неделя 4: сверьте данные, скорость и доступы, затем проведите приёмку на реальных сценариях.
Перед стартом сохраните исходные значения, правила и дату. После каждого этапа записывайте не только итог, но и время команды, ручные действия и найденные ошибки. В конце сравните результат с исходной точкой и решите: расширяем подход, дорабатываем конкретное место или спокойно закрываем гипотезу. Любой из трёх ответов полезен, если он подтверждён данными.
Назначьте короткую встречу через неделю после пилота. На ней нужен один экран: что изменили, что получилось, где ограничение и какое действие приняли. Если ответ нельзя уместить на одном экране, скорее всего, пилот пытался решить слишком много задач одновременно.
Хороший пилот оставляет после себя рабочий артефакт: проверенную формулу, карту данных, правило процесса или прототип. Назначьте владельца и дату следующей проверки. Без этого даже удачный результат быстро становится презентацией, которую все помнят примерно, а повторить уже не могут (так себе наследство).
Сразу договоритесь о границе масштабирования. Запишите, какой результат считается достаточным, сколько ручной работы допустимо и что должно произойти, чтобы подключить следующий источник, отдел или сегмент. Это защищает от двух крайностей: бесконечного пилота без внедрения и слишком быстрого развёртывания сырого решения на всю компанию. Перед расширением повторите контрольный расчёт на новом участке и убедитесь, что правила не потеряли смысл.
И ещё: сохраните один неудачный пример. Он лучше общей инструкции показывает команде, где метод перестаёт работать, какое ограничение нужно проверить и почему автоматический вывод нельзя принимать без контекста.
Рядом с неудачным примером запишите способ ручной сверки и человека, который принимает решение в спорной ситуации. Тогда исключение не остановит весь процесс и не превратится в новую тайную формулу, известную одному сотруднику.
Ограничения и типичные ошибки
- Не начинайте с копирования чужого дашборда — решения и данные отличаются.
- Не пишите «данные из CRM» без таблиц, полей и правил статусов.
- Не принимайте средний итог без проверки строк и крайних случаев.
- Не забывайте мобильный сценарий, экспорт и доступ, если они нужны.
- Не обещайте real-time, когда решение принимается раз в неделю.
Как мы используем это в работе
Я начинаю с интервью с собственником: что он сделает иначе, увидев сигнал? Затем вместе с командами проверяю формулы и источники на реальных строках.
Разработчику отдаём не картинку, а сценарии и критерии. Маркетингу и продажам — свои разрезы в общей логике. После запуска смотрим использование: если блок не открывают и он не участвует в решении, убираем.
Если ТЗ уже превратилось в список пожеланий, можно вернуть его к решениям и данным. Кнопка ниже — чтобы обсудить структуру со мной.
Что сделать прямо сейчас
Возьмите будущий дашборд и заполните одну строку: пользователь → решение → показатель → порог → действие. Повторите для трёх главных задач. Это будет сильнее половины типового ТЗ.
