software development and management practice

Практика управления разработкой ПО в ITSM фокусируется на том, чтобы создаваемые и изменяемые приложения действительно поддерживали достижение результатов, ожидаемых заказчиком и другими заинтересованными сторонами, и оставались пригодными для эксплуатации на всём жизненном цикле. Это включает управление требованиями к функциональности и качественным характеристикам, встроенное внимание к надёжности и ремонтопригодности, а также обеспечение соответствия требованиям (регуляторным, корпоративным, договорным) и аудитируемости, то есть возможности доказуемо показать, что изменения выполнялись контролируемо и в рамках установленных правил. На практике эта дисциплина связывает команды разработки с эксплуатацией и командами поддержки, помогает согласовывать приоритеты по изменениям, снижать технический долг, повышать прозрачность релизов и предсказуемость результата. Она тесно соприкасается с управлением релизами и управлением развёртыванием, а также с управлением информационной безопасностью и управлением рисками, поскольку качество и соответствие требованиям должны быть встроены в процесс, а не «проверяться в конце». Вне области этой практики находятся вопросы управления поставщиками как таковыми, формирование портфеля услуг и коммерческие условия соглашения об уровне услуг, хотя их требования могут задавать критерии к приложениям.

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