Известный факт - тема сбора или корректнее сказать выявления требований в BI проектах - супер больная.
В BI нет места классического подходу по сбору требований в ИТ-проекте - пользователи часто не знают, чего они хотят пока они не видят данные и не кликают в первые версии отчетов. И это не изменить.
Вписываясь в agile разработку вы берете на себя риск потратить ресурс и не получить результат (ходить кругами). Этими рисками можно управлять чтобы снизить негативный эффект - через правильные вопросы, выявление рисков и структурирование ожиданий на ранних этапах.
На эту тему мало глубоких текстов, BI-вендоров такие вопросы мало интересуют - слишком это сложно и никак не помогает продавать лицензии.
Поэтому здесь растут народные методологии. Вся BI-комьюнити знает Dashboard Canvas Ромы Бунина. Вещь глубокая по сути и простая в практическом применении. Еще появилось Канвасианство свежие размышления от Саши Полоротова, Вредные советы при построении Аналитики Артемия Козыря, вероятно есть еще что-то хорошее.

В наших проектах мы тоже строили себе гайды и инструкции, пора поделиться ими с миром - в них есть как относительно оригинальное так и повторы, того что уже звучало.
Хотел назвать это каким-нибудь... канвасом, но ощущение что это уже где то было)
Поэтому появился инструмент под названием "Lords of the Boards" (скромно и резонирует моему эго) - гайд по шагам разработки отчетов в корпоративных BI проектах.
Данный фреймворк - наша версия сборника вопросов, которые BI-аналитику необходимо задавать себе и заказчику на разных этапах проекта по разработке отчета. Мне кажется именно фокусирование на правильных вопросах путь наиболее эффективный. От этого "вопросного запаса" много зависит.

Цель гайда - помочь BI-аналитику

• Ускорить сбор и выявление требований заказчика
• Не начинать заведомо неуспешных BI проектов
• Минимизировать риски фейла и максимизировать эффект от стартованного BI проекта

Гайд идейно связан с Dashboard Canvas, шедевра Ромы Бунина, но имеет другой фокус. Хотя все совпадения вероятно неслучайны.

Как это использовать?

• Гайд можно (1) открыть на втором экране на интервью с заказчиком, разлиновать листок a4 сеткой 4x4 и делать пометки по ходу встречи; (2) использовать для проверки себя, когда вы структурируйте полученный запрос и планируйте проект
• Не все вопросы будут применимы ко всем проектам, если данный гайд поможет структурировать подготовку и ведение проекта частично - уже отлично
• Оставляйте комментарии и дополнения - тема живая и я вероятно много чего не учел.

Все это не является еще полноценной системной методологией. Возможно это следующий уровень абстракции, на который мы с коллегами и community экспертами зайдем на следующих этапах зрелости.

Помимо самого гайда появились и набор полезных мыслей поверх:

Мы все примерно знаем хардовый и софтовый профиль хорошего биайщика. Это тема отдельной статьи - но грубо это бизнесово-мыслящий инженер с творческими и коммуникативными способностями. Люди приходят в профессию разные и у большинства есть перекос сильных сторон - в сторону техники, бизнеса, дизайна или коммуникаций. Прокачивать слабые стороны членов команды безусловно важная задача BI лида - но это разнообразие, с другой стороны, обогащает команду, дает больше интересной экспертизы и стимулов роста. Поэтому мы помимо развития общеизвестных скилов делаем фокус на "проповедовании" определенного майнсета в виде принципов - установок, помогающих всем, несмотря на отличия, вести BI проекты по короткому пути к успеху.

Вот некоторые из них:

• Заказчик чаще не прав - неправильно представляет себе отчет, то что он хочет
• Вы главный в проекте - вы несете ответственность за неоптимальное использование своего ресурса (=ресурса компании)
• До того как вы стартовали проект - вы должны клиенту сервис, после того как вы стартовали проект еще и он должен вам свой ресурс и адопшн. Холдите проекты где заказчик от вас бегает
• Разбивайте растущие требования на части и разносите их хронологически в разные "релизы", заставляйте принимать и выпускать проект частями
• Не рассматривай мелкую задачу как мелкую задачу, бОльшую часть требований или проблем с данными от тебя спрятали
• Не берите на себя ответственность за несовершенство процесса. Инициируя изменения в процессах и системах - подчеркивайте границу ответственности свою и владельца процесса/системы
• Много и открыто говорите о текущих и потенциальных рисках проекта и получаете подтверждение от заказчика их понимания и принятия
• Не концентрируйтесь на фичах и визуализациях дольше, чем на решении бизнес-задач и проверке бизнес-ценности разрабатываемого
• Проговаривайте и фиксируйте договоренности, в случае изменения требований аккуратно тыкайте в это заказчика носом и заставляйте осознавать вину
• Используй Fail-Fast подход, проверяя, что заказчик к нему готов.

Не все эти принципы понятны без контекста, будет интересно - опишу отдельно.

Наложив эти принципы на софтскиловость аналитика и специфику задачи, я получил несколько стратегий ролевого самопозиционирования BI аналитика в проекте:

Продуктивные стратегии:
Могут быть оптимальны в зависимости от кейса
Стратегия 1 - Like a god

• Вы делаете все от бизнес-логики до техники и визуала
• Вы определяете сроки и роли, структурируете рабочую группу и экспертов
• Вы требуйте от заказчика/экспертов необходимую активность, сами формализуете бизнес-логику
• Вы несете все риски

Условия

• Нет владельца данных
• Нет инициативы, ресурса у бизнес-функции владельца

Стратегия 1 - Like a boss

• Вы лучше знаете как надо и как не надо в части данных и визуала
• Вы определяете сроки и роли, формат взаимодействия
• Вы требуйте от заказчика/экспертов необходимую активность, бизнес-логику
• Заказчик принимает на себя риски как за системы и требования, вы за визуал и технику

Условия

• Вы реально должны иметь прокачанный скилл в домене данных и подбора эффективного визуала (а не так кажется лучше)
• На выходе клиент должен быть счастлив, если он делал все что нужно

Стратегия 3 - Like a partner

• Вы выступаете как эксперт в области визуализации и работе с данными, предлагая конечные решения, принимая от заказчика пожелания
• Вы участвуете в проработке бизнес-логики с заказчиком как консультант
• Вы делите с заказчиком риски

Условия

• Вы не готовы диктовать как должно быть по визуалу
• Заказчик не имеет нормальных требований, финальных метрик и "идет от данных", понимает риски
• Нет жестких дедлайнов, заказчик принимает работу по agile

Стратегия 4 - Like an executor

• Вы выступаете "как руки" - что вы скажите то мы и сделаем
• Вы получаете на вход требования как по логике так и по визуалу, если и предлагаете то без напора, клиент решает
• Мы даете сроки и корректируете их при смене требований
• Заказчик несет всю ответственность

Условия

• Вы не имеете экспертизы в визуализации или задача не про визуализацию а получение цифр
• Есть четкое и полное тз

Cтратегии низкой продуктивности:

Стратегия 5 - Like a friend

• Вы берете задачу на хорошем человеческом контакте с заказчиком
• Вы стремитесь "помочь" - смешиваете роли и не коммуницируете риски и ответственность до и во время проекта
• Вы мало оцениваете сроки и сдвиги, идете от ситуации

Условия

• Вы уверены, что хорошо понимаете заказчика у вас долгий опыт успешных проектов
• Заказчик не имеет нормальных требований, финальных метрик и "идет от данных", понимает риски
• Нет жестких дедлайнов
• У вас есть ресурс на это
• Проект не высокого приоритет

Стратегия 6 - Like a slave

• Вы выступаете "как руки" - что вы скажите то мы и сделаем
• Вы получаете на вход требования в общем виде и раскапываете их сами
• Вы несете ответственность за результат и не коммуницируете риски Заказчику

Условия

• Нет правильного проектного менеджмента в вашей работе, нет контакта с заказчиком (супер-топ?)
• Неадекватно выстроенные ожидания заказчика

Эти стратегии стратегии полезно осознавать и перемещать себя и заказчика в конструктивные роли в зависимости от условий в которых вы находитесь. Полная аналогия с "Games People Play" Эрика Берна.

Пользуйтесь и оставляйте комментарии.
Раз дочитали до сюда - желаю получить от процесса извращенное удовольствие перфекциониста)