Разработка требований для проекта Qlik Sense

qliksense-expert — Fri, 15 Mar 2019 08:25:08 +0000

Список ресурсов, которые могут помочь при разработке требований проекта Qlik Sense:

https://www.reqview.com
Мой старый шаблон с требованиями для проектов QlikView (очень давно составлял, сделал бы какие-то пункты по-другому сейчас, но вдруг поможет).

Возможная структура документа с требованиями для проекта внедрения Qlik Sense

Общая информация
Цели реализации
Краткая постановка задачи от заказчика (исходные бизнес-требования)
1. Прототип отчета/отчетов в Excel
2. Вложенные файлы или письма, относящиеся к задаче (неформализованные требования)
3. Ссылки на ранее реализованные решения или их описание, плюсы и минусы существующих решений
Проработка требований (структуризация)
1. Источники данных
2. Структура приложения
  1. Измерения
  2. Показатели
  3. Листы | Визуализация
3. Группы пользователей, необходимое количество лицензий (рекомендуется завязываться на Active Directory – Windows Server)
Рассылки отчетов
1. Рассылки по Email (Excel, PDF, PPTX)
  - NPrinting
  - PowerShell
2. Telegram (PDF)
3. Группы пользователей (рекомендуется завязываться на Active Directory – Windows Server)

Про разработку требований

Разработка требований – важный этап работ при внедрении любой BI системы. Очень важно на старте понять, что хочет заказчик (руководитель, бизнес-подразделение, партнер и т.д.). Если требования написаны очень поверхностно без проработки, то на приемке аналитического приложения обязательно всплывут вопросы типа – а “почему считается вот так, а не так?”, “у нас в ТЗ под этой фразой подразумевалось совершенно другое”, “можно сделать округление не до сотых, а до десятых в каждом отчете”.
К сожалению без опыта разработки бизнес-аналитики на определенном ПО сложно сформулировать полные требования к аналитике (да и зачастую это не нужно). Самое главное в требованиях – отсутствие собственных домыслов. Если Вам (как разработчику) или Вашему коллеге (если Вы аналитик, а коллега разработчик) не понятны те или иные требования – это повод позвонить/написать письмо/сходить в гости к заказчику.

На моей практике самыми идеальными ТЗ были проработанные мини-модели в Excel. И вот почему:

Заказчик сам погружается в данные, смотрит что есть в системе, как эти данные нужно преобразовать (т.е. заказчик проводит моделирование на реальных данных и отлаживает модель до приемлемого вида).
Все формулы, зависимости ячеек видны в Excel. Нужны только минимальные комментарии по расчетам.
Разработанные аналитические модели не приходится переделывать, т.к. заказчик исправил в модели большую часть ошибок. Останется обработать только некоторые “частные случаи (исключения)”.
Заказчик хорошо представляет себе конечный рабочий результат и понимает что он будет с ним делать.

Самые отвратительные ТЗ – почтовая переписка, состоящая из множества писем. Всегда легко потерять ключевые хотелки заказчика.

Немного лирики:
Если Вы разрабатываете аналитическую систему для внешнего клиента – обязательно делайте аудит качества данных (аудит состояния учетных систем). Иногда (очень редко) лучше отказаться от проекта, чем лезть в проекты, в которых придется иметь дело с плохо структурированными данными. На таких проектах можно потерять репутацию, плюс есть шанс, что Вас заставят доработать проект до конца. В итоге у Вас будет куча таблиц с меппингами, в которых Вы обрабатываете те или иные исключения, чтобы очистить данные заказчика.
На этапе выявления требований обращайте внимание на атрибуты справочников в учетных системах и узнавайте как связаны разные системы между собой. Где хранятся меппинги, кто за них отвечает. Ну и многое другое
Мое личное мнение

И еще: некоторые заказчики пытаются переложить на плечи Qlik Sense те вещи, которые этому продукту не свойственны. Сложные расчеты с большим количеством условий, статистику, прогнозирование и т.д. Для этих целей есть другие инструменты, например, на базе того же Python существует огромное количество бесплатных библиотек, которые можно бесшовно (почти бесшовно ) интегрировать с Qlik Sense.

К тому же, в Qlik Sense можно создавать свои собственные Extentions, которые через JS размывают все ограничения этой платформы (jQuery, Node.js и т.д.). Самое главное – проектирование архитектуры на старте, продумывание деталей взаимодействия с разработанными инструментами после приемочных испытаний.