Как стать автором
Обновить

Комментарии 7

Как вариант решения при таком не отзывчивом отделе DWH можно посадить аналитика и программиста DWH за соседние столы.
А вы не думали, что у вас весь процесс не верный?
Что аналитик должны не ad-hoc заниматься, а заниматься требованиями, а DWH в совокупе с BI должны выдать просто инструмент для бизнеса?
Не столько у нас, сколько это часто так работает в компаниях.
Но аналитические вопросы реально распадаются на 2 типа: adhoc и регулярные отчеты. Классическая связка бизнес-аналитик + разработка более менее нормально заходит на регулярных отчетах. Правда до тех пор, пока у вас в понятие отчета не попадают АБ тесты, кластеризация, churn prediction и прочие data science штуки. Ad hoc это те задачи, в которых не требуется регулярная воспроизводимость или которые вообще не вписываются в BI, как в формат.
Какое может быть решение? Если вы хотите избавится от проблемы взаимодействия DWH и аналитиков, то вы должны сблизить компетенции DWH и аналитиков. Человек, кто совмещает эти компетенции и можно назвать аналитиком данных.

Возможно проблема не в компетенциях рядовых сотрудников а в плохом взаимодействии.
Тогда решать надо не добавлением еще одного более хорошего сотрудника а разбираться с менеджерскими компетенциями руководителей аналитиков и разрабов и с мотивированием их на более продуктивное взаимодействие.
Коммуникации — это дорогая штука, как показывает практика, на нее тратится куча времени, до 30-50% времени от рабочего. И она почти по дефолту у всех как-то хромает. Так что налаживать коммуникации так же сложно, а может и сложнее, чем повысить профессиональные компетенции. Я же топлю за то, чтобы задачей на аналитику данных владел один человек end-to-end, понимал как он ее делает, где и как берет данные, какие предпосылки использует, и как отдает пользователю.
Тут скорее вопрос в переключении между задачами.
Программист получает задачу от аналитика, решает её, аналитик начинает пользоваться инструментом и тут не хватает каких-то данных. Аналитик обращается к программисту, а тот уже начал другую задачу и либо придётся аналитику ждать, либо вторая задача пострадает.

Если же аналитик сам себе программист, доработки конвеера данных органично вплетаются в его задачу (там даже и доводить до решения с интерфейсом не нужно, достаточно пописать SQL/MDX)

На мой взгляд такое взаимодействие, иногда, добавляет слишком много накладных расходов.


Возьмём задачу ежемесячной отчётности, у условных аналитиков есть срок "когда они должны выдать результат" пусть это, к примеру 23:59:59 n-го рабочего дня.
У разработчиков/поддержки же есть текущие задачи/sla и тут на n-2 дне вдруг выясняется что витрина, на разработку которой потрачен человекомесяц и которая исправно работала пол года, выдаёт не то и нужно срочно что-то делать. :)
ИМХО лучшее что я видел это когда люди и в бизнесе(аналитик) и в ИТ(базы данных) понимают, худший вариант это когда по требованиям ИБ на рабочей станции сотрудника работающего с финансовой информацией клиентов не должно быть установлено средств разработки (sql developer — да нельзя же), при этом, по моему, важно чтобы у сотрудников хватало времени на перевод быстрых решений(костылей) в регламентный etl.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории