Комментарии 9
Критиковать уже можно? :) в приложении очень много пунктов, я даже читать устал, если выполнять хотя бы половину, проект не закончится никогда.
Хранилища не являются вещью в себе и их проектируют с двух сторон - сверху, от отчетов/дашбордов и снизу от исходных систем. Практически всегда у бизнеса уже есть понимание, какие отчеты они хотят видеть, обычно даже избыточное :).
В целом, для отчетов определяются необходимые сущности в исходных системах, после этого целиком их забираем (это называется поддержка неизвестного), фиксируем состав основных данных, мастер систему, набор атрибутов. Фиксируем связи между транзакционными данными и алгоритмы обогащения. Прописываем состав витрин, соответствие полей витрин отчетам.
Пишем документы ролевая модель и проектное решение на основе всего выше (иногда из двух частей, для бизнеса и для айти). И для проектирования этого достаточно. Все равно практика показывает, что проектное решение хорошо, если на 70% совпало с реальностью.
У вас же все в кучу, и предпроектное обследование, и проектирование, и выбор инструментов реализации, и даже куцая разработка и почему-то поддержка опэ.
З.ы. Существенную часть из написанного должны делать разработчики, которые понимают возможности инструментов и систем, бизнес-аналитики как правило это сделать в принципе не могут, да и не должны.
Тут скорее вопрос внешняя разработка или внутренняя. При внутренней - как Вы описали. При внешней скорее как в статье. Я бы не рискнул делать разработку на заказ, без подготовленных и согласованных заказчиком бизнес требований и технического задания и без документирования каждого шага. Иначе, потом сдавать заколеблешься.
Я как раз работал преимущественно во внешней и говорю про неё. Бизнес требования, безусловно, нужно фиксировать, как и весь объем проекта, вы правы, я недостаточно на этом акцентировал внимания. Но и то, что написано в статье - большой перегиб.
А знаете, что самое интересное? мне довелось поработать и на западных проектах, и там гораздо меньше этой всей бюрократии с обеих сторон, просто отношение другое. Заказчик не стремится поиметь разработчика, а тот в свою очередь налюбить заказчика, и как-то умудряются договориться без согласования цвета кнопки ок на каждом дашборде :)
Возможно, нужно лучше управлять взаимоотношениями с заказчиком ?
Набор общих фраз на тему 'делай хорошо и не делай плохо'.
У меня вопрос, как в анекдоте, а что в армии один солдат "бизнес-аналитик"?
Сам процесс построения описан корректно. Но где разделение по ролям? Где архитектор? Где системный аналитик?
Имхо, бизнес аналитик заканчивается на этапе информационного обследования и построение бизнес требований, а дальше дело архитектора, системных аналитиков и разработчиков.
Конечно, тут вопрос терминологии видов аналитиков, но как минимум архитектор должен быть на проекте точно.
Вы правы, в моей статье действительно не хватает четкого разделения ролей и зон ответственности между участниками проектной команды. Это важный момент, который стоит добавить.
Как вы верно заметили, основная роль бизнес-аналитика сосредоточена на начальных этапах - сборе и анализе требований бизнеса, проведении интервью с заказчиками, формализации и согласовании бизнес-требований.
В то же время, на последующих этапах ключевая роль переходит к архитектору, который отвечает за проектирование целевой архитектуры DWH, и к системным аналитикам, которые детально прорабатывают модель данных, процессы ETL, интерфейсы.
Бизнес-аналитик на этих этапах участвует в валидации разрабатываемых решений с точки зрения соответствия бизнес-требованиям. Он помогает контролировать, что проект движется в правильном направлении и конечный результат будет отвечать ожиданиям заказчика.
При подготовке статьи я действительно больше сфокусировалась на задачах бизнес-аналитика, не уделив достаточного внимания другим важнейшим ролям в проектной команде. Это упущение с моей стороны.
В следующей статье по этой теме я обязательно добавлю раздел с описанием функций архитектора, системных аналитиков, разработчиков, тестировщиков на каждом этапе проекта DWH. Это позволит читателям составить более полную и сбалансированную картину процесса реализации хранилища данных.
Благодарю вас за внимательное прочтение статьи и ценную обратную связь! Ваш комментарий помог мне посмотреть на материал под другим углом и увидеть возможности для его улучшения.
ми тожи умеем в чят гипитэ
пишите по-человечески
Мне тоже показалось, что читаю монолог робота. Или не показалось? :)
вообще не показалось))) из того, что я осилила прочесть (тройку абзацев) сложилось впечатление, что идет просто перечисление общих фраз и терминологий. 0 конкретики. 0 понимания - "А как же все таки бизнес аналитику выстроить работу в проектах DWH". Тема очень интересная, но к сожалению, совершенно не раскрыта.
Если мы говорим об аналитике - то стоило остановиться на описании конкретно его работы, и если уж очень хочется описать весь процесс - отличная тема для другой статьи. Но увы, тут сплошная вода, и да, след GPT явно прослеживается. Это грустно
Как бизнес-аналитику выстроить работу в проектах DWH (Data Warehouse). Структура работ