Завсегдатай всем известного сайта allthingsitsm.com Марк Смолли (Mark Smalley) опубликовал заметку о релизах ПО, и о том, как в среде ИТ-специалистов поступают при возникновении проблем с ними.

Марк говорит о том, что иногда при возникновении сложностей с релизами, в силу их значительной временной дискретности, некоторые компании принимают меры к "починке релиза", нежели к "починке конвейера релизов". Далее в заметке излагаются закономерные выводы о том, что именно второй подход в среднесрочной перспективе способен предоставлять результаты более стабильного качества. Для выбора способа улучшения нам приходится оценивать множество факторов: критичность приложения для бизнеса/потребителя, риски и ущерб от возможных сбоев, репутационный риск и способность поставщика услуги принять его. Исходя из этого анализа предлагается определить требуемые меры по управлению качеством развертываемых релизов.

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

• Релиз программного обепечения, дистрибутив.

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

• Релиз ИТ-услуги (ИТ-системы).

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

• Релиз Услуги. 

Мыслить в терминах ИТ-систем чревато потерей ценности. В большистве случаев изменения в информационной инфраструктуре поддерживают происходящие бизнес-изменения. Кто, как не бизнес, должен мыслить услугами, заниматься "улучшением конвейера их предоставления"? Конечно, во всем этом присутствует ответственность ИТ-подразделений, но главное в том, что этот результат должен быт достигнут совместными усилиями. Собственно, наблюдаемый взрыв применения гибких (agile) подходов только подтверждает это. Бизнес как главный получатель и выгодоприобретатель ИТ-услуг должен получать их наиболее эффективным образом и для этого он включен в процессы и команды выполняющие ИТ-изменения (а лучше предположить, что координирует и равновесно участвует, сам используя сервисно-ориентированный подход). Команда меняющая услугу целиком по своей природе должна быть разнородной, иначе она не сможет достичь цели.

Что вы думаете по этому поводу? Как выстроен механизм бизнес и ИТ-изменений у вас? В чем состоит ваша основная сложность?

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую