Практика бизнес-анализа для BI-систем

Большой / Огромный: Всякий раз, когда Вы входите в зал заседаний с Бизнес Аналитиками, Менеджерами или Бизнес Пользователями, Вас могут спросить, насколько большое данное приложение или набор данных? Не говорите, что оно маленькое/большое/огромное. Вместо этого назовите число, потому что слова «маленький», «большой» и «огромный» субъективны в восприятии каждого человека. Вместо этого придите с готовыми числами в голове или если есть потребность — запишите их (если Вы можете их помнить, так будет лучше всего). Дайте приблизительные цифры, если нет точных: размер на Диске, размер в оперативной памяти, Количество Таблиц, Число Строк и Столбцов. Точные цифры не столь важны, поскольку они могут измененяться, пока Вы говорите. Я сравниваю эти цифры с количеством «Лайков на Facebook или Твитов», где нам все равно будь то 60,648 или 60K строк. Знание приблизительных цифр помогает нам принимать обоснованные решения.

Никогда: Все разработчики QlikView страстно увлечены тем, что делают. Мы всегда стремимся предложить лучшее решение для бизнеса. В этом процессе, мы устанваливаем некоторые правила и говорим, что возможно, а что нет. Иногда эти правила вызваны эмоциональным желанием и мы попадаем в условный пузырь, пытаясь защитить наше эмоциональное желание. Например, в крупном предприятии, мы не хотим сохранять логику ETL в QlikView. Вместо этого мы хотим подтолкнуть логику ETL для добывающих систем, но это не всегда возможно. В этом случае, нам будет предложено работать с ETL в QlikView, а это противоречит нашей стратегии развития. Эта ситуация может вызвать эмоциональный желание сказать: «Мы НИКОДА не работаем с ETL в QlikView». Хотя, это может быть не очень хорошей практикой, наше эмоциональное состояние заставляет нас говорить «Никогда». Вместо этого, мы должны предупредить бизнес о потенциальных рисках при таком подходе и, если возможно, дать им примеры из реальной жизни. Лично я предпочитаю следовать всем теоретическим правилам разработки программного обеспечения на каждом проекте, но это не всегда возможно при управлении бизнесом.

Быстро/Медленно: Производительность QlikView AJAX имеет два основных направления в измерении. Первое — время загрузки приложения. Это первое место, где пользователи могут встретится с задержкой. Второе — среднее время ответа на запрос, когда пользователь делает выбор. Когда кто-то жалуется на производительность, важно определить, где происходит задержка производительности. Не менее важным является определение длительности задержки, сколько секунд/мс. Таким образом, мы не должны полагаться на субъективные впечатления от работы — «быстро» или «медленно». Кроме того, полезно говорить с другими разработчиками, а не ссылаться на скорость/ медлительность.

Иногда: От случая к случаю мы произносим слова «иногда», когда код/логика не работают. Когда мы говорим «иногда» мы имеем в виду симптом проблемы, а не фактический основной вопрос. Как разработчики, мы должны знать подоплеку/причину сбоя работы кода/логики. Это нормально — говорить пользователям, что «иногда эта функция не работает из-за определенной проблеме». Это допустимо, потому что Вы имеете в виду сценарии, где можно получить неожиданные результаты/функциональность. Однако, как разработчик, Вы не можете использовать слово «иногда» для описания проблемы.

Доклад(ы): Существует распространенное заблуждение, касающееся использования терминов «Отчет QlikView» против «Приложения QlikView «. Многие разработчики QlikView, как правило, считают эти термины взаимозаменяемы, но есть принципиальное различие между ними. Несмотря на определенное общее значение, я считаю, что приложения более интерактивны и мы используем их в качестве инструментов, чтобы лучше понять бизнес-данные. Кроме того, отчеты могут быть статическими, а иногда печатаются или публикуются в формате PDF и содержат заранее разработанные инсайты, чтобы обеспечить понимание определенной схемы или события. Помимо этого, термин отчет звучит, как в 90-х годах, когда разрабатывались и публиковались факты, не позволяя пользователям взаимодействовать с данными.

Спасибо Бренту Озару за вдохновение!

Найти решение у бизнес-партнера QlikTech (QlikView) в России.

Форум разработчиков QlikView и Qlik Sense. Получите ответы на все вопросы по QlikView и Qlik Sense!