Мы-таки провели этот вебинар (давно уже собирались). Вопрос поднимался неоднократно, системного ответа не было. Теперь, как мне кажется, есть: https://cleverics.ru/subject-field/webinars/46-core/webinars-and-video/380. Если есть вопросы – велкам, обсудим. Специально для этого и создал этот пост.
Я встречал. Но все имена – приватно.
“у коммерческого сервис-провайдера он, надо понимать, обязан быть именно длинным”
Как раз в этом я очень сомневаюсь. Внешний провайдер обычно отвечает или за разработку (тогда про него вообще REQ-DEV-REL), или за эксплуатацию, или за сопровождение и эксплуатацию. В последнем случае у него “средний” CHG – с доработками, но без бизнес-анализа, поскольку точкой входа в этом случае, как правило, являются функциональные требования (бизнес-анализ – на стороне заказчика). А значит услуга опять system-centric (SaaS).
То есть наверно бывают и другие сценарии, но утверждение “обязан быть именно длинным” мне кажется слишком сильным.
Интересно, что делается при ‘длинном варианте’, если надо реализовывать SP на ПО вендора или прошить оборудование. Предположим, что работа потоковая\постоянная, в некоторых случаях требует downtime оборудования, иногда сервиса. Так как это часто процесс идет на инфраструктуре, то небольшое изменение может вызвать downtime не одного сервиса.
Да, верно, тут нужна поправка. Под “внешним провайдером” я имел ввиду тот самый аутсорсинг, который, как говорят, не растет на нашей почве, во многом – из-за моды на дочерние структуры с теми же функциями. А равно – самих этих дочек. То есть сервис-провайдера полного цикла, претендующего на то, чтобы полностью взять на себя заботы об информационных технологиях у/для заказчика.
Коллеги, предлагаю сортировать вединары по дате desc
Ну, вопрос очевиден. Как ты это делаешь? Я тоже хочу такой мозг.
Как всегда, очень убедительно и системно. Спасибо.
***
А еще у меня вопрос ко всем, не только к ДИ. Коллеги, кто-нибудь встречал в жизни организацию, где во внутреннем ДИТе работал бы “длинный” процесс управления изменениями? Во внутреннем – ибо у коммерческого сервис-провайдера он, надо понимать, обязан быть именно длинным…