"Видоизмененный скрам не есть скрам", с одной стороны, звучит логично, а с другой звучит как догма. Мужики тем самым заявляют, что их скрамгайд это очень точно выверенный скелет, на который нам остаётся лишь нарастить мяса. Перелом же одной косточки приведёт к поломке всего организма. Единственная моя претензия - это невероятно смелое заявление.
В здоровой, прозрачной среде аналитик виноват ровно настолько насколько он нааналитил. Честному взору всегда понятно где фундаментальный косяк проектирования, а где отдельный вызов лезет куда ему не надо.
Иначе обстоят дела когда аналитикам вменяют несвойственные им обязанности...
Дело в том, что в BI технологии и внедрение — это только ⅕ успеха. Остальное определяют культура, процессы, команда и бизнес-кейсы.
Это верно практически для любого софтверного проекта.
Для DWH/BI проектов главное четко позиционировать проект и результаты в пространстве data management и максимально четко формулировать связанные риски проекта. А они полезут после первого же "где данные, Зин?"
Кейс в статье вырван из контекста, конечно. Обычно это как раз преднастроенные дашборды на витринах с известной структурой, типичный хранилищный кейс. Колоночная база - и вашему сеньору не придется делать сравнение полдюжины способов расчета "количества уникальных" чтобы выиграть какие-то миллисекунды. Вместо этого он может пойти порешать действительно интересные и важные таски.
Главная проблема визуализации это -сюрприз! - абсолютное нежелание заказчика что-либо делать со своей стороны при абсолютном желании видеть все предельно красиво, по делу и вчера.
На втором месте вот это все что описано в материале
Ваш текст очень хорошо иллюстрирует, что много чего придется «побеждать» — и не тимлиду или руководителю, а каждому члену команды лично. Условия труда, свою лень, нежелание менять привычный уклад и способ общения, внутренних демонов. В очном формате все это как-то самобалансируется и компенсируется, да и начальственное внушение «в глаза смотри» временами незаменимо.
Короче, задача для многих команд просто непосильная по факту.
Как насчёт тестирования изменений, которые подразумевают еженедельные или ежемесячные ETL или аналитику, или завязанные на закрытие периодов по МСФО? T vs T-1 в этом случае не работает, и автомат бесполезен, или смогли как-то решить это?
Про архитектора то лукавство — позиции может и нет, но ведущая роль по-любому на ком-то висит. И это ещё один сигнал, что копятся риски, связанные с командой.
"Видоизмененный скрам не есть скрам", с одной стороны, звучит логично, а с другой звучит как догма. Мужики тем самым заявляют, что их скрамгайд это очень точно выверенный скелет, на который нам остаётся лишь нарастить мяса. Перелом же одной косточки приведёт к поломке всего организма. Единственная моя претензия - это невероятно смелое заявление.
В здоровой, прозрачной среде аналитик виноват ровно настолько насколько он нааналитил. Честному взору всегда понятно где фундаментальный косяк проектирования, а где отдельный вызов лезет куда ему не надо.
Иначе обстоят дела когда аналитикам вменяют несвойственные им обязанности...
Это верно практически для любого софтверного проекта.
Для DWH/BI проектов главное четко позиционировать проект и результаты в пространстве data management и максимально четко формулировать связанные риски проекта. А они полезут после первого же "где данные, Зин?"
Кейс в статье вырван из контекста, конечно. Обычно это как раз преднастроенные дашборды на витринах с известной структурой, типичный хранилищный кейс. Колоночная база - и вашему сеньору не придется делать сравнение полдюжины способов расчета "количества уникальных" чтобы выиграть какие-то миллисекунды. Вместо этого он может пойти порешать действительно интересные и важные таски.
Главная проблема визуализации это -сюрприз! - абсолютное нежелание заказчика что-либо делать со своей стороны при абсолютном желании видеть все предельно красиво, по делу и вчера.
На втором месте вот это все что описано в материале
Даже у Бога-Императора после наложения путинских эффектов морщины разгладились
Короче, задача для многих команд просто непосильная по факту.
Как насчёт тестирования изменений, которые подразумевают еженедельные или ежемесячные ETL или аналитику, или завязанные на закрытие периодов по МСФО? T vs T-1 в этом случае не работает, и автомат бесполезен, или смогли как-то решить это?
Автору бы везде дописать self-service instance, но он не знал/забыл/забил.
Про архитектора то лукавство — позиции может и нет, но ведущая роль по-любому на ком-то висит. И это ещё один сигнал, что копятся риски, связанные с командой.