Зачем вообще нужно ТЗ на дашборд
В идеальном мире вы приходите к разработчику и говорите: «нужен дашборд по продажам». Через две недели получаете ровно то, что и хотели. В реальном мире эта формулировка значит для разработчика «сделай как считаешь нужным». Он что-то нарисует, вы посмотрите, скажете «нет, не это», и начнётся круг переделок, который не имеет шанса закончиться.
По нашим аудитам и разговорам с командами — больше половины проектов BI, которые «застряли в правках» или «сделали, но никто не пользуется», начинались без нормального ТЗ. Не потому что разработчик плохой — а потому что разработчик не умеет читать мысли. И в момент, когда заказчик впервые видит готовый макет, он осознаёт, чего он на самом деле хотел — и это, как правило, не то, что на экране.
Хорошее ТЗ решает три проблемы сразу:
- Согласовывает ожидания до старта. Не «сделаем — посмотрим», а «сделаем именно вот это, и вот по этим критериям поймём, что готово».
- Экономит деньги. Каждая итерация переделки в BI-проекте стоит дороже, чем час разговора по ТЗ. Особенно если «не нравится» означает «нужно перестроить модель данных».
- Создаёт точку отсчёта. Через 6 месяцев, когда у команды появится новый запрос и подрядчик предложит «расширить дашборд», у вас будет документ, к которому можно вернуться.
Подчёркнём: ТЗ — это не многотомник на 200 страниц с DAX-формулами. Это 3–5 страниц структурированного текста, который читается за 15 минут, и любой человек из команды может по нему понять, что и для кого делается.
Пять блоков, без которых ТЗ не работает
Дальше — пять обязательных разделов любого ТЗ на дашборд. Если хоть одного нет — разработчик будет догадываться, и через две недели вы окажетесь в цикле «не то».
Блок 1. Цель и аудитория: кто, зачем, в каком контексте
Главная ошибка ТЗ — начинать с графиков и метрик. Сначала — кто и зачем. Дашборд для коммерческого директора и дашборд для продавца — это два разных продукта, даже если показывают одни и те же цифры.
В этом разделе ТЗ должно быть:
- Роли пользователей. Не «сотрудники компании», а «коммерческий директор, 1 человек, открывает 2–3 раза в день» и «руководители региональных продаж, 8 человек, по утрам».
- Контекст использования. На большом мониторе в офисе или на телефоне в дороге. Один на один с экраном или на общем совещании. От этого критически зависит компоновка и размер шрифтов.
- Уровень подготовки. Финдиректор, который десять лет читает P&L, — и маркетолог, для которого «маржа» — термин из соседнего отдела. Им нужны разные подсказки и разная плотность информации.
- Какие решения принимаются по дашборду. Это самый важный пункт. «Перераспределить бюджет между регионами», «эскалировать на генерального», «отозвать партию у поставщика» — это конкретные действия, под которые проектируется отчёт. Если нет ясности с решениями, то дашборд получается «информационным» — то есть бесполезным.
Тест на «информационный» дашборд. Спросите себя: что именно я буду делать иначе, увидев эти цифры? Если ответ «ничего, просто буду в курсе» — это информационная панель, и её никто не будет смотреть через две недели. Если ответ «приму решение X на основе значения Y» — это управленческий дашборд, и он будет жить.
Блок 2. Вопросы, на которые отвечает дашборд
Самая полезная часть ТЗ — список из 3–7 конкретных вопросов. Не список метрик, а именно вопросов в форме, как их задаёт пользователь.
«Показать всю информацию по продажам».
«Дашборд по маркетингу».
«Аналитика по клиентам».
«Какой регион впереди / отстаёт от плана выручки за текущий месяц?»
«Какой канал даёт самую низкую стоимость лида прямо сейчас?»
«Какие 10 клиентов снизили закупки больше чем на 20% за квартал?»
Хороший вопрос — это вопрос, на который дашборд может ответить за 3–10 секунд после открытия. Если для ответа нужно нажать четыре фильтра и промотать вниз — это уже не тот вопрос.
Когда у вас 3–7 таких вопросов — разработчик автоматически понимает, что именно должно быть в центре экрана, что на втором плане, а что вообще не нужно. Если вопросов больше пятнадцати — это два или три разных дашборда, и их надо разделить.
Блок 3. Метрики и формулы
Вторая по важности часть ТЗ. Здесь нельзя писать «выручка» — нужно писать «выручка по отгрузке (не по оплате), без НДС, в рублях, по курсу ЦБ на дату документа». Это четыре параметра, и каждый из них может оказаться спорным.
Сделайте таблицу:
| Метрика | Бизнес-описание | Формула | Единица | Приоритет |
|---|---|---|---|---|
| Выручка | Выручка от продаж по отгрузке | Sum(Реализации.СуммаБезНДС) по дате документа | млн ₽ | Must |
| Маржа | Валовая маржа после COGS | Выручка − Sum(Реализации.СебестоимостьБезНДС) | млн ₽ | Must |
| Маржа, % | Маржинальность от выручки | Маржа / Выручка | % | Must |
| План, % | Выполнение плана продаж | Выручка / ПланПродаж[на период] | % | Should |
Приоритеты по MoSCoW: Must — без этой метрики дашборд не работает; Should — важно, но MVP запустится без неё; Could — сделаем во второй фазе.
Самая частая ошибка — пропустить колонку «формула». Все думают, что «выручка — это же очевидно». Через две недели разработчик показывает дашборд, у вас выручка не сходится с 1С, и вы тратите неделю на разбор «почему». Оказывается, разработчик взял по оплате, а вы ожидали по отгрузке. Или он добавил НДС, а вы считали без. Это типичный конфликт, который ТЗ снимает за 5 минут — если колонку «формула» заполнили.
Блок 4. Источники данных
Здесь должны быть перечислены все системы, откуда тянутся цифры:
| Система | Объект | Владелец | Частота обновления | Доступ есть? |
|---|---|---|---|---|
| 1С:УТ 11 | Регистр накопления «Реализация» | ИТ-департамент | SQL-репликация, 5 минут | да |
| 1С:Бухгалтерия | Регистры по счёту 90.01 | Бухгалтерия | Ежедневно к 9:00 | да |
| amoCRM | API: Сделки, Контакты | Отдел продаж | Каждые 30 минут | токен запросить |
| Wildberries | API статистики | E-commerce | Раз в день | да |
Самый болезненный пункт — «Доступ есть?». В половине проектов оказывается, что токена amoCRM нет, у 1С нет учётной записи с нужными правами, а Wildberries вообще никто никогда не тянул. И это всплывает на второй неделе разработки, когда уже спроектированы витрины. Доступы заказывайте до ТЗ — это самый недооцениваемый пункт подготовки.
Также в этот блок включите качество данных. Где есть пробелы, какие поля могут быть пустыми, насколько чисты справочники. Если в 1С номенклатура называется «Болт ☑», «Болт» и «Болт.» — BI это не починит, и разработчику нужно знать про эту проблему до старта (см. «BI начинается не с подрядчика»).
Блок 5. Функциональные и нефункциональные требования
Функциональные: что дашборд должен уметь делать.
- Какие фильтры — перечислите явно (период, регион, продукт, менеджер).
- Drill-down: при клике на регион — детализация по городам?
- Drill-through: переход на отдельную страницу детализации с контекстом?
- Экспорт: Excel, PDF, CSV. Кто, когда, в каком формате.
- Email-рассылка: дайджест по понедельникам в 9:00?
- Row-Level Security (RLS): кто видит свои данные, кто — все. Без RLS дашборд для руководителей региональных продаж работать не будет.
Нефункциональные: как дашборд должен работать.
- Время загрузки — SLA (≤3 секунд — стандартный ориентир).
- Платформа — Power BI, Datalens, что-то ещё.
- Среда публикации — Power BI Service, Report Server, on-prem.
- Браузеры — Edge, Chrome, плюс мобильные.
- Безопасность — коммерческая тайна, ПДн, NDA. Это влияет на выбор хранилища и контура развёртывания.
Эти два списка — про то, что разработчик не может «прикинуть на глаз». RLS либо есть в ТЗ, либо его нет, и тогда модель данных проектируется по-другому. SLA в 3 секунды и в 30 секунд — это разные архитектуры.
Wireframe: что должно быть нарисовано
Самая недооценённая часть ТЗ — грубый макет. Не Figma-прототип за неделю работы дизайнера, а квадратики на бумаге или в PowerPoint, на которых видно — что где должно лежать.
Этот эскиз сразу даёт ответы на несколько критичных вопросов: главных KPI — три, периода динамики — 12 месяцев, рейтинг регионов — топ-N с сортировкой по убыванию, есть таблица детализации с drill-through. Разработчик читает этот wireframe за 30 секунд и понимает 80% решений по компоновке.
Не нужно дизайнить. Не нужно подбирать цвета. Нужно — расположить квадраты на листе так, чтобы было видно: что главное, что вторичное, какой блок где.
Скачать готовый шаблон
Чтобы не собирать ТЗ с нуля — возьмите наш шаблон. Заполните пустые поля, добавьте свой wireframe и референсы — и документ готов.
Шаблон ТЗ на дашборд
Markdown, 14 разделов, ~5 КБ. Открывается в любом редакторе. Свободная лицензия.
Если удобнее работать в Word или Notion — скопируйте содержимое и вставьте, разметка читается везде. В Word можно сразу преобразовать заголовки в стили H1/H2.
17 вопросов для самодиагностики
Прежде чем звать разработчика, пробегитесь по этому списку. Если на большинство вопросов ответ «не знаю» — ТЗ ещё не готово, и стоит вернуться к бизнес-команде за уточнениями.
- Кто конкретно будет открывать дашборд (роли, имена)?
- Сколько раз в неделю будут открывать? Если меньше двух — нужен ли вообще дашборд или хватит email-рассылки?
- На каком устройстве и экране будут смотреть?
- Какова главная задача: мониторинг, анализ, отчётность, исследование?
- Сформулированы ли 3–7 конкретных вопросов, на которые отвечает дашборд?
- Перечислены ли ключевые метрики с формулами и единицами измерения?
- Согласованы ли спорные правила расчёта (выручка по отгрузке/оплате, остатки с резервом или без)?
- Указаны ли приоритеты MoSCoW для каждой метрики?
- Перечислены ли все источники данных?
- Получены ли доступы и токены ко всем источникам?
- Известна ли частота обновления по каждому источнику?
- Перечислены ли фильтры и срезы, которые нужны?
- Решены ли вопросы RLS (кто видит какие данные)?
- Определён ли SLA по скорости загрузки?
- Есть ли wireframe хотя бы на листе А4?
- Есть ли 2–3 референса «нравится» и 1–2 «не нравится»?
- Сформулированы ли критерии успеха через 30 дней после публикации?
Если «да» меньше чем на 12 пунктов — стоит провести предварительную сессию с командой. Полтора часа разговора сейчас экономят две недели правок потом.
Семь типичных ошибок при составлении ТЗ
1. «Хочу всё и сразу»
Заказчик просит 30 метрик на одной странице, потому что «мало ли что понадобится». Получается визуальный шум, в котором не видно главного. Решение — разделение по приоритетам Must/Should/Could и разнесение на несколько страниц по иерархии «обзор → детализация».
2. Описание решения вместо задачи
«Хочу красный столбец рядом с зелёным, и чтобы внизу была надпись».
«Хочу видеть отставание по регионам сразу при открытии — чтобы реагировать в тот же день».
Когда вы описываете задачу, разработчик может предложить визуализацию лучше, чем вы придумали. Когда диктуете дизайн — получаете именно то, что попросили, но часто не то, что вам нужно.
3. «Сделаем — посмотрим»
Самая опасная фраза в BI-проекте. Она означает «у нас нет ТЗ, давайте начнём, и по ходу разберёмся». Разберётесь — но через 4–6 итераций. Бюджет проекта при этом удваивается. Лучше потратить лишний день на брифинг, чем два месяца на переделки.
4. ТЗ от ИТ, а не от бизнеса
Когда ТЗ пишет ИТ-директор без участия конечных пользователей — получается технически безупречный документ, который не отвечает на реальные вопросы бизнеса. Конечный пользователь должен подписать ТЗ или хотя бы поучаствовать в обсуждении.
5. Игнорирование контекста использования
Дашборд, спроектированный для большого монитора, выглядит как каша на планшете. Дашборд для ежедневного открытия требует другой плотности информации, чем ежеквартальный обзор. Эти решения принимаются на этапе ТЗ, а не в момент демо.
6. Отсутствие критериев успеха
Без строки «через 30 дней после запуска дашборд должен открываться 80% коммерческой команды минимум 3 раза в неделю» — оценить, удался ли проект, невозможно. Сделали — получили похвалу — забыли — через год никто не помнит, открывал ли его кто-то после первой презентации.
7. Отсутствие рамок «не входит в scope»
Если не прописать, чего не будет в MVP — проект расползётся. Каждое совещание будет добавлять «а ещё хорошо бы…», и через две недели вы поймёте, что делаете не дашборд, а ERP. Запишите явно: «В первую версию НЕ входит: интеграция с X, мобильное приложение, прогнозирование». И возвращайтесь к этому списку при каждом «новом» предложении.
Как продуктивно работать с разработчиком
ТЗ — это стартовая точка, не конечная. Дальше начинается совместная работа, и тут есть несколько правил, которые сильно облегчают жизнь обеим сторонам.
- Описывайте задачу, не решение. «Хочу видеть отставание» — это задача. «Сделай красный бар» — это решение. Решений много, и разработчик чаще знает, какое лучше работает.
- Не запрашивайте всё сразу. 100 метрик на одном экране никто не читает ежедневно. Доверьтесь разработчику в расстановке приоритетов — это его профессия.
- Тестируйте на реальных пользователях. Не на коллегах из соседнего отдела, а на тех, кто будет открывать дашборд каждый день. Их первая реакция стоит больше, чем любые ваши предположения.
- Ожидайте итераций. Хороший дашборд доделывается после первого месяца использования — это нормально и закладывается в план.
- Если разработчик говорит «это невозможно» — попросите объяснить. Иногда оказывается, что задача решаема на 80% альтернативным способом. А иногда становится понятно, что ограничение упирается в модель данных, и нужно или менять модель, или ограничивать функционал.
- Не меняйте ТЗ задним числом. Если добавляются новые требования — это phase 2, новый бюджет, новый срок. Иначе разработчик начинает чувствовать, что ТЗ — фикция, и качество следующего ТЗ катастрофически падает.
Чек-лист «ТЗ готово к передаче»
- Документ помещается в 3–5 страниц без шрифта 8 кегля.
- Любой человек из команды читает его за 15 минут и понимает суть.
- Раздел «Назначение» отвечает на три вопроса: для кого, зачем, какие решения.
- Список из 3–7 ключевых вопросов, не абстракций.
- Таблица метрик с формулами и приоритетами Must/Should/Could.
- Список источников данных с отметкой «доступ есть».
- Перечень фильтров, drill-down, экспортов, RLS.
- Wireframe, пусть и нарисованный от руки.
- 2–3 референса «нравится», 1–2 «не нравится».
- Список того, что не входит в MVP.
- Критерии успеха через 30 дней после публикации.
- Подпись бизнес-владельца и ИТ-владельца.
Если все пункты есть — отправляйте. Если хоть одного нет — дописывайте, иначе разработчик будет догадываться, и дальше начнётся «не то».
Что дальше
Это первая часть пары. Скоро выйдет вторая — «Как сделать дашборд по ТЗ» — взгляд с другой стороны: как BI-разработчик читает ТЗ, какие принципы дизайна закладывает, что делает на каждом этапе. Если вам интересна обратная сторона — подпишитесь на t.me/deeonedev, выложим там.
Связанные материалы:
- Гид по визуализациям — какой график выбрать под задачу. Полезно при составлении ТЗ — увидите, какие варианты вообще существуют.
- BI начинается не с подрядчика — что нужно навести в учётной системе до старта BI-проекта. Параллельная задача составлению ТЗ.
- Финансовая отчётность простым языком — если дашборд для финансовой команды, эти определения вам пригодятся.
- Методология DEEONE — как мы ведём проекты от ТЗ до сопровождения.
- BI-аудит за 5 дней — если не уверены в готовности данных, мы проверим до старта.