Кстати, хороший кейс, который я еще не видел - "как выгонять сотрудников с работы, чтобы не перерабатывали". Реально же сложно )

Тут кстати поднимался вопрос про "каждому проекту свою методологию". У меня сейчас в отделе два проекта внедрения одного продукта, один по водопаду, второй - скрам. Параллельно с этим доработка продукта по чему-то типа скрама. Грустное наблюдение - внедрение скрама у нас в сущности свелось к внедрению спринтов и митингов. Обнажилось несколько явных проблем в управлении разработкой. Решили, что скрам нам не подходит, нужно, чтобы методология управления учитывала особенности сложившихся процессов. В  такой формулировке это даже звучит красиво. а на деле ощущается, что методология выбирается для прикрытия проблем)).

Ну и ощущение, что и текущие процессы не планировались, а возникли "стихийно". Как оно обычно и бывает. И пока не будет отрефлексировано "зачем и как", хорошо не выйдет.

именно)

Коллеги, есть какие-то лучшие практики в индустрии, как делится ответственность между бизнес владельцем и внутренней ИТ службой  за ту иную систему, изначально написанную и внедренную третьей стороной (вендором), переданную на поддержку в ИТ, в которую периодически вносятся изменения разного уровня, как ИТ, так и самим вендором? (ядро->  хранилище -> витрины -> визуализации). Кто отвечает за архитектуру в целом, кто отвечает за бизнес-логику, кто в деталях должен знать, как работает система и т.д.? Что почитать по теме может из классиков? Основной вопрос - именно распределение между ИТ и бизнесом с точки зрения governance.

С кем-то – да.

Ну так реклама чудодейственных средств как стать здоровым, богатым счастливым за три дня действует всегда.
"Методология" это удобный способ сбросить с себя бремя думать головой и работать над процессами.
Результат предсказуем.


Покуда живы жадины вокруг,
Удачи мы не выпустим из рук.

Какое небо голубое!
Мы не поклонники разбоя:
На жадину не нужен нож,
Ему покажешь медный грош
И делай с ним, что хошь.

Пока живут на свете дураки,
Обманывать нам, стало быть, с руки.

Какое небо голубое!
Мы не поклонники разбоя:
На дурака не нужен нож,
Ему с три короба наврешь
И делай с ним, что хошь.

(c) песня кота базилио

Есть байка: В IBM однажды поставили эксперимент, сотрудников заставили платить за электричество в переговорках – длительность собраний резко сократилась.

Я не видел оригинала. Например, причины, по которым от этой практики все-таки отказались )

Это судьба скрама в любой относительно крупной компании же

у меня был сложный опыт в госах, когда первые линии поддержки системы были в одной компании, а третья (и частично вторая) - в другой. И получалось, что никто не знает особо ничего, грызня между компаниями, знания передаются друг другу через ленивую переписку. Заказчик выставляет приоритеты словами "у нас все приоритетное!".  Но это было весело, надо признать))

а как так организовано, что изменения вносятся и теми, и теми? Кто в итоге за них отвечает?

А у кого бюджет на развитие и поддержку?

О как бы у нас так не вышло, делаем ГИСы как раз

У бизнеса, но, поскольку много чего пилится внутренними силами, бюджета как такового нет.
Если надо привлекать вендора - бюджет у бизнеса, но в бизнесе нет глубокой экспертизы по самому решению.

Байки, там митингов дофига. 😊

Правда можно с раб места по телефону

Интересно! А причины понятны ?

Бывает нетривиальная мотивация: например, фикс не помещается в закупочные критерии "без тендера", а рамку под t&m при некоторых обстоятельствах можно протащить.

эксперимент просто закончился)

Ядро - вендор пилит, хранилище - вендор по большим изменениям, ИТ по мелким.
Витрины - ИТ, визуализации - ИТ или аналитик в бизнесе.