Уверен, что объяснять на уровне калькуляции проще, чем на уровне уже выпущенного и не пригодного к поддержке приложения...

На практике, в крупнейших компаниях-монополистах почтовые системы мигрируют в рамках SO, без всякого плана и оценки рисков. Это просто специфика определенного «штамма» руководителей, которых отличает страстное желание замкнуть все на себя, не имея ни компетенций, ни возможностей — говоря научнум языком, создать проприетарную систему. В итоге подобного творчества возникают (кто бы мог подумать) проблемы, срабатывающие в долгосрочной перспективе, когда уже все забыли, кто и как осуществлял миграцию / разработку / итп. Зато такой «руководитель» постоянно очень нужен — ведь ИТ-системы работают плохо, чорт их подери.

Я описывал именно ситуацию с «сидением на двух стульях». Это больше связано с низким уровнем _процессной_ зрелости с одной стороны и с жестким _бизнес-прагматизмом_ с другой. Мне кажется, это как-раз подходит к теме этой ветки.

СЗ — это уже достаточно высокий уровень зрелости. На постсоветском пространстве уже успели об этом забыть и ещё не успели «опять вспомнить».

на практике в последнее время организуются службы заказчика (или хотя бы определяются ролевые функции СЗ). вот только представитель СЗ контролирует не деятельность ИТ подразделения — это задача ИТ-менеджера, а контролирует качество получаемых «бизнесом» услуг на основании SLA.

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

тут конечно вопрос непростой организационно, т.к. бизнес не хочет кормить еще одного дармоеда (представителя СЗ), особенно если не получает от него пользы. но выделение такой роли на самом деле не означает найма и содержание отдельного человека, если есть такая возможность, то можно и совмещать. только на мой взгляд этот совместитель должен быть со стороны бизнеса.

Сложность возникает только тогда, когда новая потребность бизнеса возникает до того, как закончилось выполнение отложенных этапов. А вот тут уже всё зависит от «менеджера, отвечающего за уровень предоставления услуг». В его задачу входит убедить бизнес синхронизироваться. Возможно, даже, путём снижения требований.

таких примеров на самом деле немного — повезет, если раз в год что-нить подобное увидишь. но вот в этом году встретилось мне два отечественных монополиста, которые именно так и хотели организовать стык разработки и эксплуатации. в госорганах такого скорее всего нет, хотя нет, вру — в ЦБ на эту тему была некая работа, по-моему, она пока не завершена

хватит?

разруха, она, понимаешь, в головах...

ну да, ну да, а к созданию ИТ-систем подходят как к капитальному строительству производственного объекта, включая такую хрень как землеотвод, проект организации строительства (ПОС) и прочие «крайне полезные» хитрости капстроя.

и только сданную в эксплуатацию систему передавать в использование бизнесу!

Успешные примеры на моей памяти есть только в организациях, которые эксплуатируют различные комплексы повышенной опасности или значимости. Там как правило есть единые стандарты проектирования, внедрения, эксплуатации систем (всех, не только ИТ) + жесткий контроль регулирующих органов по различным инцидентам

Тестирование же закладывают, наверняка. Понятно, что могут и без него запустить, если «сроки горят».

«счастливый миф» — вот и хочу понять: неужели любые попытки чего-то добиться в этой области заведомо провальны?

Есть ведь успешные примеры, где все работает, они «успешное исключение»?

сроки эти взяты не с потолка, а, скорее всего, согласованы с бизнесом и привязаны к ключевым точкам в их проектах, например...

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

Не разобравшись с ответственностью, можно что угодно возводить в какой угодно ранг, толку не будет.