Фраза «покажите нам всё» звучит как плохое требование. В ней нет конкретного пользователя, перечня показателей, периода, источников и даже понятного результата. Но за ней обычно стоит нормальная потребность: заказчик видит много разрозненных данных, регулярно получает отчёты вручную и боится потерять что‑то важное при переходе к новой аналитической системе.
Проблема начинается, если воспринять эту фразу буквально. Тогда в первый релиз пытаются включить все таблицы, показатели, фильтры и варианты детализации. Система растёт ещё до того, как становится понятно, кто и для чего будет ею пользоваться.
Я столкнулся с этим при проектировании BI‑контура для организации, где данные о разных направлениях деятельности уже находились в операционных системах и единой базе, но значительная часть отчётности проходила через выгрузки и ручную обработку. Пользователям были нужны сведения об учебных процессах, финансах, задолженностях, движении контингента, нагрузке и других направлениях. На верхнем уровне запрос действительно можно было свести к формулировке: собрать всё в одном месте.
Но «всё» нельзя использовать как границу проекта. Его сначала нужно разобрать на решения, роли, показатели, источники и сценарии проверки.
Почему заказчик просит всё
Обычно это не попытка намеренно раздуть объём работ. У такой формулировки есть несколько практических причин.
Во‑первых, заказчик знает текущий процесс лучше, чем будущую систему. Он понимает, какие отчёты получает сейчас, но ещё не представляет, как изменится работа после автоматизации. Поэтому безопаснее попросить перенести всё.
Во‑вторых, разные подразделения используют одни и те же данные по‑разному. Для одного пользователя важен общий итог, для другого динамика, для третьего конкретные записи, из которых получился показатель. На общей встрече эти потребности складываются в длинный список без приоритета.
В‑третьих, ручной отчёт часто содержит элементы, назначение которых уже никто не может объяснить. Столбец переносится из месяца в месяц только потому, что он был в предыдущем файле. При проектировании системы его автоматически записывают в обязательные требования.
Наконец, существует страх упустить данные. Если аналитик сразу начинает сокращать список, это может восприниматься как потеря функциональности. Поэтому полезнее не спорить со словом «всё», а постепенно показывать, что разные группы данных относятся к разным решениям и этапам проекта.
Не начинать со списка экранов
Первая ошибка при сборе требований — сразу обсуждать будущий интерфейс:
сколько будет вкладок;
какие диаграммы разместить на главной странице;
где нужен фильтр;
каким цветом показывать отклонение;
можно ли выгрузить результат в Excel.
Эти вопросы понадобятся, но позже. Если начать с них, требования быстро превращаются в описание макета. При этом остаётся неизвестным, почему пользователь открывает систему и какое решение принимает после просмотра.
В предыдущем материале я уже разбирал принцип «сначала решение, потом дашборд». При сборе требований этот принцип становится первым уровнем декомпозиции. Для каждого будущего раздела нужно определить:
Кто им пользуется.
Какой вопрос возникает у пользователя.
Какое решение он принимает.
Какие данные нужны для этого решения.
Что пользователь делает после обнаружения отклонения.
Например, формулировка «показывать результаты подразделений» ещё не объясняет задачу. Требование становится полезнее, когда известно, что руководитель регулярно сравнивает подразделения по единой методике, выбирает объект с отклонением и переходит к причинам результата.
На этом этапе не обязательно знать окончательный состав диаграмм. Но уже можно проверить, нужен ли показатель вообще.
Сначала разобрать текущую отчётность
В рассматриваемом проекте данные проходили последовательность от операционных систем к общей базе и API, затем попадали в выгрузки, вручную обрабатывались аналитическим подразделением и превращались в отчёты и справки.
Если смотреть только на последний файл, большая часть требований останется скрытой. Итоговая таблица не показывает:
из какой системы пришло поле;
какие записи исключили;
как объединили справочники;
какие значения исправили вручную;
кто согласовал формулу;
насколько регулярно обновляются данные;
какие промежуточные действия выполняет аналитик.
Поэтому сбор требований я начинаю с разбора существующего процесса. Нужен не только готовый отчёт, но и путь его формирования:
Кто запрашивает информацию.
Кто готовит результат.
Какие источники используются.
Какие преобразования выполняются вручную.
Какие проверки проводятся перед отправкой.
Какие вопросы возникают после получения отчёта.
Какие части результата используются для реального решения.
Это позволяет отделить потребность пользователя от особенностей текущего файла. Аналитическая система не обязана повторять ручной отчёт столбец в столбец. Но она должна сохранить значимую логику расчёта и проверки.
Разделить требования на несколько уровней
В одном списке обычно смешиваются разные типы требований. Например:
Нужен отчёт по подразделениям, данные должны обновляться автоматически, руководители должны видеть только свои направления, на главной странице нужна динамика, а ещё должна быть выгрузка и полное описание всех таблиц.
Это не одно требование, а сразу несколько уровней системы.
1. Бизнес‑требование
Объясняет, зачем создаётся аналитический раздел. Например: сравнивать подразделения по согласованным показателям и находить отклонения, требующие внимания.
2. Пользовательское требование
Описывает, что должен сделать конкретный пользователь: выбрать период, увидеть сравнение, перейти к детализации, проверить составляющие показателя или выгрузить результат.
3. Требование к данным
Фиксирует источник, состав записей, период, правила очистки, детализацию, дату обновления и обработку пропусков.
4. Требование к показателю
Определяет формулу, числитель, знаменатель, исключения, единицу измерения и допустимые разрезы.
5. Функциональное требование
Описывает поведение системы: фильтрацию, переход между уровнями, сортировку, экспорт, сохранение состояния или отображение предупреждения.
6. Требование к доступу
Определяет, какие данные видит каждая роль и на каком уровне применяется ограничение.
7. Критерий приёмки
Позволяет проверить результат: какие действия выполняет пользователь, что должно отобразиться и с чем сверяется значение.
Такое разделение защищает от ситуации, когда цвет диаграммы описан подробно, а формула показателя остаётся «как в старом отчёте».
Карточка показателя вместо названия
Одной из самых опасных иллюзий является уверенность, что название показателя понятно всем одинаково. Слова «количество», «активные», «выполнено», «задолженность» или «среднее значение» выглядят очевидно, пока не начинается расчёт.
Для каждого существенного показателя я бы фиксировал отдельную карточку:
Поле | Что необходимо указать |
|---|---|
Название | Понятное пользователю наименование |
Назначение | Какое решение поддерживает показатель |
Формула | Как рассчитывается итоговое значение |
Объект расчёта | Событие, документ, человек, операция или другой объект |
Период | За какой интервал считается значение |
Источник | Откуда поступают исходные данные |
Исключения | Какие записи не участвуют в расчёте |
Разрезы | По каким признакам показатель можно группировать |
Обновление | Когда данные считаются актуальными |
Владелец | Кто подтверждает смысл и методику |
Проверка | С каким источником или расчётом сверяется результат |
Карточка нужна не ради документации. Она уменьшает количество решений, которые разработчик или аналитик вынужден принимать самостоятельно.
Если формула не зафиксирована, её всё равно кто‑то определит. Только произойдёт это уже в SQL‑запросе, BI‑модели или коде визуализации, где бизнес‑пользователь её не увидит.
Требование «покажите всё» может относиться не к отчёту
В одном из рабочих запросов требовалось полное описание аналитической модели: таблиц, столбцов, мер и связей. Формулировка снова выглядела как запрос на всю доступную информацию, но задача была другой.
Пользователю нужен был не дашборд и не новый показатель, а техническая инвентаризация модели. Это отдельный тип результата, для которого нужны свои критерии полноты:
все пользовательские таблицы включены;
служебные объекты исключены;
для столбцов указана принадлежность к таблице;
меры отделены от исходных полей;
связи представлены отдельно;
результат можно повторно получить после изменения модели.
На первых итерациях часть запросов не давала ожидаемого результата, а после исправления в выгрузке оставались служебные локальные таблицы. Это хороший пример того, почему фраза «выгрузить всё» не является критерием приёмки. Нужно заранее определить, какие объекты входят в понятие «всё», какие исключаются и как проверяется полнота.
Составить карту источников до разработки
Когда показатели выбраны, их нужно связать с реальными данными. Для этого не требуется сразу проектировать всю будущую архитектуру. Достаточно карты источников:
Показатель или объект | Система‑источник | Способ получения | Детализация | Обновление | Известные ограничения |
|---|---|---|---|---|---|
Показатель A | Операционная система | API или выгрузка | По объекту и периоду | По установленному регламенту | Возможны неполные записи |
Показатель B | Единая база | Запрос к представлению | По подразделению | После обновления источника | Требуется согласование справочника |
В рабочем документе вместо условных названий указываются конкретные объекты. Для публичного примера они намеренно обезличены.
Карта быстро показывает три класса требований:
показатель можно построить на доступных данных;
показатель можно построить после подготовки или согласования данных;
показатель пока нельзя достоверно рассчитать.
Последний вариант тоже является результатом аналитической работы. Лучше зафиксировать ограничение до разработки, чем добавить на дашборд число с неподтверждённой методикой.
Учитывать разные роли, а не «пользователя системы»
Требование «системой будут пользоваться сотрудники» почти ничего не даёт для проектирования. Даже внутри одного процесса роли различаются.
Руководителю может быть нужен общий результат и список отклонений. Аналитику — формулы, разрезы и детализация. Ответственному за подразделение — только собственные данные. Администратору — состояние обновления и ошибки загрузки.
Для каждой роли полезно определить:
доступный набор данных;
стартовый экран;
основные действия;
необходимую детализацию;
допустимые выгрузки;
действия при отсутствии или ошибке данных.
Это влияет не только на интерфейс, но и на модель доступа. Если ограничение применяется только к визуальному фильтру, оно не становится полноценным разграничением данных.
Приоритет вместо попытки реализовать всё сразу
После декомпозиции исходный запрос обычно становится ещё длиннее. Появляются формулы, источники, роли, проверки и ограничения. На этом этапе особенно важно не принять полный реестр за объём первого релиза.
Я разделяю требования как минимум на три группы:
Без этого пользователь не сможет пройти основной сценарий.
Это улучшает работу, но не блокирует основной сценарий.
Это отдельное развитие системы после проверки первой версии.
В первую группу должны попадать не самые заметные функции, а минимальный замкнутый контур: пользователь открывает раздел, видит корректный показатель, обнаруживает отклонение, переходит к объясняющим данным и понимает, что делать дальше.
Если в первой версии есть двадцать диаграмм, но нет возможности проверить источник значения, система формально показывает больше, а помогает меньше.
Проверять требования сценариями
Большой документ сам по себе не гарантирует, что участники одинаково понимают результат. Поэтому требования нужно превращать в сценарии приёмки.
Для BI‑раздела сценарий может выглядеть так:
Пользователь с определённой ролью открывает отчёт.
Выбирает период и доступное подразделение.
Видит общий показатель и ориентир для сравнения.
Переходит к детализации выбранного отклонения.
Сверяет составляющие с согласованным источником.
Получает понятное состояние, если данные отсутствуют или ещё не обновлены.
Такой сценарий одновременно проверяет права, фильтры, расчёты, переходы и обработку исключений.
Отдельно нужны негативные проверки:
роль не видит недоступное подразделение;
пустой период не превращается в нулевой результат;
неполное обновление сопровождается предупреждением;
сумма детализации соответствует агрегированному значению;
выгрузка учитывает те же фильтры, что и экран.
Именно на этом этапе формулировка «сделать фильтр по подразделению» превращается в проверяемое поведение системы.
Как выглядит итоговый комплект требований
Для аналитической системы мне недостаточно одного технического задания с последовательным текстом. Практичнее использовать несколько связанных представлений:
Реестр решений — кто пользуется аналитикой, какой вопрос решает и какое действие выполняет.
Список ролей — права, доступные данные и основные сценарии.
Словарь показателей — формулы, периоды, исключения и владельцы.
Карта источников — происхождение данных, способ получения и ограничения.
Прототип отчёта — последовательность от общего результата к детализации.
Критерии приёмки — позитивные и негативные сценарии проверки.
Очередность реализации — первый контур и последующие этапы.
Эти документы не должны существовать независимо. Показатель связывается с решением, источником, ролью, экраном и проверкой. Если связь потеряна, требование легко реализовать формально, но не по смыслу.
Что получилось в реальном кейсе
Исходный широкий запрос удалось разложить на направления аналитики, пользователей, показатели и источники. Один из созданных отчётов используется для сравнения подразделений по согласованной логике.
Я не могу подтвердить количественный эффект внедрения: время подготовки отчётности и влияние системы на скорость решений отдельно не измерялись. Поэтому главный подтверждённый результат здесь не процент экономии, а переход от неограниченного запроса «показать всё» к проверяемым требованиям и работающему аналитическому сценарию.
Чек‑лист сбора требований
Перед передачей аналитической системы в разработку я бы проверил:
Определены ли пользователи и их роли?
Для каждой роли зафиксированы решения и действия?
Разделены ли бизнес‑, пользовательские и технические требования?
Есть ли карточка для каждого существенного показателя?
Указаны ли источники, детализация и период обновления?
Зафиксированы ли исключения из расчётов?
Различаются ли ноль, отсутствие и неполные данные?
Описаны ли ограничения доступа?
Отделён ли первый релиз от полного реестра пожеланий?
Есть ли сценарии проверки расчётов, фильтров и детализации?
Понятно ли, что именно означает «всё» для каждого результата?
Итог
Фраза «покажите нам всё» не является готовым требованием, но её не стоит просто возвращать заказчику со словами «сформулируйте точнее». Обычно она указывает на разрозненную отчётность, ручные операции и отсутствие общей картины.
Задача аналитика — не механически записать все пожелания и не сократить их по собственному усмотрению. Нужно проследить путь от решения пользователя до показателя, от показателя до источника, от источника до интерфейса, а затем определить способ проверки.
После такой декомпозиции «всё» перестаёт быть бесконечным объёмом проекта. Оно превращается в реестр требований, из которого можно собрать ограниченный, проверяемый и действительно используемый аналитический контур.
