design and transition

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

Частая ошибка — воспринимать «проектирование и переход» как синоним практики «проектирование услуг» или как узко техническое «развёртывание». Практика «проектирование услуг» задаёт методы и компетенции, тогда как «Проектирование и переход» — это конкретная деятельность цепочки ценности, которая объединяет несколько практик и доводит замысел до готовности к эксплуатации. Аналогично, «переход» шире, чем релиз или развёртывание: релиз — это пакетирование и выпуск изменений, развёртывание — их доставка в среду, а «проектирование и переход» также включает валидацию, оценку рисков, подготовку поддержки и актуализацию сервисных конфигураций. Ещё одно распространённое заблуждение — считать, что эта деятельность неизбежно означает длительные «водопадные» циклы; на самом деле она применима и в Agile/DevOps, где переход может быть частым и небольшими порциями, но при этом контролируемым через модели изменения и критерии приёмки. Также важно не перегружать эту деятельность излишней бюрократией: стандартные изменения и малорисковые улучшения могут проходить облегчённый путь, иначе страдает скорость организации и время вывода на рынок.