«Круги Громова» занимается сравнительными исследованиями ИТ-решений. Начинали мы с исследований именно BI-систем (системы бизнес-аналитики, business intelligence) и разбираемся в них, как считаем, весьма хорошо. По задумке наши исследования (кстати, ежегодные) должны быть чем-то вроде карты для ИТ-отделов и руководителей, чтобы помочь им разобраться в дебрях множества современных BI-решений. Одним из основных параметров, влияющих на объективность исследования, является его методика. Поэтому мы постоянно думаем над тем, как сделать нашу методику еще более точной, учитывающей еще больше факторов и позволяющей раскрыть максимум информации о решениях, которые попали к нам под микроскоп.
Мы не берем никаких денег с вендоров, участвующих в исследовании и стараемся, чтобы каждый наш выпуск объективно отражал плюсы и минусы участвующих решений, а также чаяния заказчиков – это помогает разработчикам понимать, в каком направлении им развиваться. Сегодня мы расскажем о том, как в очередной раз усовершенствовали методику наших исследований, добавив туда секретный ингредиент. И для начала пара цифр из работ по подготовке последнего исследования за 2023 год:
3 728 человеко-часов – столько мы суммарно потратили на исследование;
4 346 писем – в такое число вылилось общение с вендорами в рамках исследования.
Теперь давайте подробнее расскажем о методике и ходе исследований.
Сначала был критерий
Как мы вообще начинаем работать над исследованием? Изначально формируются критерии, по которым оно (исследование) будет производиться.
Затем составляем чек-лист, основываясь на уже имеющихся у нас данных о том, каковы должны быть функциональность и интерфейс BI‑инструментов. Откуда же изначально появились эти данные? В самом начале мы подробно изучили зарубежные решения, которые, чего уж греха таить, на тот момент были наиболее развитым предложением на рынке.
Выбираем несколько сильных разработчиков в компании, которые круто разбираются в BI-инструменте. Обычно это ведущие разработчики и технический директор. Этим немногим – избранным (кто поймет отсылку?) – мы даём время разобраться в решениях, идущих «под микроскоп», а затем – заполнить чек-листы. Таким образом проверяем, насколько наш чек-лист актуален, репрезентативен и удобен для заполнения.
После них чек-лист так же тестируют отдел продаж и т.п., изучая в том числе на предмет того, соответствуют ли наши критерии тем, которые действительно волнуют заказчиков.
Так вот. Всегда ранее мы создавали критерии исследования наподобие технического задания. В этом году всё изменилось. С одной стороны стало проще, с другой – сложнее (для нас). А как – расскажем дальше.
А теперь – пилот
В 2023 году мы решили, что для полноты исследования нужно провести по каждой системе нечто вроде небольшого пилотного проекта.
Вендорам были предложены 3 формата участия:
Заполнение общих критериев по продукту BI, реализация Технического задания - подробная оценка системы, включая выполнение тестовых заданий.
Заполнение общих критериев по продукту BI - оценка только по заполненным критериям.
Только упоминание - предоставление общей информации о системе.
Для участия в исследование вендоры предоставили такую информацию по своей BI-системе:
заполненный файл с критериями (порядка 600 критериев);
техническую документацию;
информацию по релизам за прошедший год;
доступ к демо-стенду с полными правами;
дорожную карту развития (roadmap того, какие фичи планируются, как часто выходят новые продукты).
Проверка систем проходила в несколько этапов. Сначала проверяли функциональность и выполняли ТЗ, все это фиксировалось в результатах исследования.
Затем шли сразу три этапа с проверкой функционала систем по чек-листу.
В этом году мы проверяли базовый функционал BI-систем. Тестовое задание состояло из трех блоков.
Продажники тестировали базовый функционал BI. Потом шла проверка трансформаций и части визуализаций, которые еще не были протестированы в рамках проверки базового функционала. Затем вендоры выполняли тестовое задание под запись от загрузки и трансформации до построения виджетов и дашбордов. Если у системы нет ETL-инструмента, то использовалось архитектурное решение, которое считает вендор лучшим. Далее вендор предоставлял нашей команде доступ к системе бизнес-аналитики с полными правами на версию, которая будет указана в исследовании. Команда круга Громова повторяла приложение на предоставленном стенде по записи вендора и в процессе проверяла критерии по чек-листу (этап 2). Цель данной итерации – убедиться в работоспособности функционала.
На этапе выполнения вендором технического задания оценивалась полнота выполненных работ, соответствие ТЗ и проводилась валидация данных, т.е. оценка внешнего интерфейса. В этом этапе участвовали аналитики и разработчики.
На следующем этапе – проверке выполнения вендором ТЗ и повторении командой Громова оценивались выполнение ТЗ: ETL, объекты интерфейса и другие критерии. А в команду этапа входили уже только разработчики. При этом у каждого вендора был свой «куратор» - разработчик, который проверял тестовое задание №1 и тестовое задание №2.
В обоих случаях предусматривалось три варианта оценки:
«0» - критерий не реализован в ТЗ;
«1» - критерий реализован в ТЗ, но выполняется не из «коробочного» решения;
«2» - критерий реализован в ТЗ и выполняется из «коробочного» решения.
На третьем этапе оценивались критерии, заполненные вендором. Оценки ставились, исходя из ответов вендора по чек-листу. На четвертом этапе, соответственно, эти ответы проверялись нашей на достоверность заполнения командой из аналитиков и разработчиков.
По общим критериям проверки были разбиты по блокам – у каждого блока был «отдельный проверяющий» разработчик, чтобы результаты общих критериев были более объективными.
В работе использовался демо-стенд, документация на систему, видеозапись ТЗ и иные материалы, предоставленные вендором в процессе работы.
Методика тестирования
При расчете итоговых оценок мы используем метод аддитивной свертки показателей по Постникову В.М, который он описывает в работе «Многокритериальный выбор варианта решения на основе аддитивной свертки показателей, являющихся членами арифметических прогрессий». Данное решение применяется с целью уравновешивания всех категорий оценки систем и приведения их к соизмеримым значениям, то есть для разрешения ситуаций со значительным превосходством входящих критериев в одни категории по сравнению с другими.
Порядок методики таков:
Определение ранга значимости критериев внутри категорий.
Определение кол-ва групп значимости в категории.
Расчет весовых коэффициентов критериев (по методике).
Расчет итоговых значений по критериям (индикаторов: произведение оценки и весового коэффициента).
Расчет итоговых значений по категориям (баллов: сумма индикаторов внутри категории).
Вес критериев определялся экспертами команды и компании с 14-летним опытом в проектах внедрения BI. Коэффициент приведения – 4-балльная система оценки.
В итоговый рейтинг попадали суммы оценок после проверки по каждому разделу критериев.
Немножко про коллизии
Различия в оценках обусловлены использованием разных методологий. При реализации MVP оценивалось конкретно выполнение технического задания и соответствие ему. Например, в ТЗ по графикам были включены не все параметры из общего списка, поэтому балл может быть выше. Возможно, оценивались критерии, по которым у вендора изначально не было готовых настроек. То есть в ТЗ вошли конкретные требования, которые повлияли на балл ниже, чем при общем рейтинге.
Совместная работа с вендором по чек-листу
В целях сохранения объективности системы оценивания после проверки критериев командой Круга Громова были проведены встречи с вендорами, в рамках которых вендор имел возможность продемонстрировать заявленный функционал, который, например, был не обнаружен при тестировании.
Причины, по которым команда Круга не подтвердила функционал на этапе 4, оказались следующими:
интуитивно функционал в системе не найден;
нет описания в документации заявленного функционала;
вендор предоставил доступ к морально устаревшей версии платформы, а критерии заполнял по новому релизу системы.
По итогам встреч ряд вендоров доработал документацию, обновил стенды и, как следствие, увеличил вес в итоговом рейтинге.
Заключение
Таким образом, с помощью своеобразных микро-пилотных проектов, многократного тестирования разными командами по самым различным направлениям и проверок нам удалось обеспечить объективное и достаточно полное сравнение решений по широкому спектру показателей, которые являются действительно важными.
Похожие методологии применяются и в других наших исследования - СУБД-круг Громова, ETL-круг Громова, Data Catalog-круг Громова.
