Связь ITSM и SDLC: цикл непрерывного совершенствования

Этой теме был посвящен вебинар SimpleOne «SDLC и ITSM: процесс непрерывного совершенствования продукта». Эксперты поделились своим видением того, почему так важно рассматривать SDLC и ITSM в совокупности, и каким образом можно наладить эффективное взаимодействие между продуктовыми командами и командами поддержки. В ходе вебинара было продемонстрировано, как использование единой платформы позволяет интегрировать процессы управления жизненным циклом разработки и управления услугами, обеспечивая непрерывный поток создания ценности для клиентов.

Ключевые идеи вебинара легли в основу данной статьи. Мы рассмотрим, почему продуктовым компаниям необходимо выступать в роли поставщиков услуг, как наладить коллаборацию между командами разработки и поддержки, и каким образом связаны практики управления проблемами, инцидентами и формирования бэклога продукта. Особое внимание будет уделено значению единой информационной среды и платформенных решений в реализации интегрированного подхода к SDLC и ITSM.

Продуктовая организация как поставщик услуг

Для начала введем понятие «продуктовая организация». Это может быть как целая компания, например, крупный вендор программного обеспечения, так и небольшая группа по автоматизации внутри ИТ-департамента на предприятии.

Ресурсы продуктовой организации

Ресурсы включают в себя сотрудников (персонал), информационные технологии, информационные системы, инфраструктуру, кодовую базу и другие средства производства, связанные с IT. Кроме того, к ресурсам относятся процессы, которыми пользуется команда, а также партнеры и поставщики, с которыми взаимодействует продуктовая команда

Элементы продуктовой ценности

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

Что необходимо сделать, чтобы продукт начал приносить ценность потребителю?

Чтобы продукт начал приносить реальную ценность, необходимо представить его потребителям в виде услуг и сервисных предложений. Именно услуги являются тем самым связующим звеном между продуктом и пользователями, обеспечивая доступность, удобство и качество его эксплуатации. Сервисные предложения могут включать в себя различные варианты предоставления продукта — от полной передачи его экземпляра клиенту до организации доступа к функциональности по модели SaaS. При этом один продукт может лежать в основе множества сервисных предложений, ориентированных на разные группы потребителей.

Сервисные предложения как правило бывают 3 видов и могут включать в себя:

• Передача экземпляров продуктов для потребителя;
• Предоставления доступа к продуктам и ресурсам;
• Определенные сервисные действия.

Продуктовая организация становится поставщиком услуг

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

Предоставление ценности

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

Непрерывное совершенствование

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

SDLC и ITSM — единый поток создания ценности

Осознание продуктовой организацией своей роли как поставщика ИТ-услуг — это лишь первый шаг на пути к эффективному управлению жизненным циклом продуктов и услуг. Следующая задача — обеспечить бесшовную интеграцию практик разработки (SDLC) и управления ИТ-услугами (ITSM). Несмотря на то, что обе методологии нацелены на предоставление ценности конечным пользователям, они имеют ряд принципиальных различий.

Различия в инструментах и системах

• Команды разработки используют различные системы разработки и такс-трекеры для управления бэклогом, задачами и дефектами, а также системы контроля версий и CI/CD.
• Команды поддержки применяют ITSM-системы для обработки обращений, управления инцидентами, проблемами, запросами и предоставления услуг.

Различия в объектных моделях и процессах

• SDLC оперирует элементами бэклога (эпики, фичи, истории, дефекты, релизы и т.д.); процессы сфокусированы на разработке, тестировании и поставке продукта.
• ITSM работает с услугами, инцидентами, проблемами, запросами на обслуживание и изменения, конфигурационными единицами; процессы направлены на обеспечение стабильности и доступности сервисов.

Организационное разделение

• За разработку и поддержку часто отвечают разные подразделения или организации.
• Специалисты обладают различными компетенциями и говорят на разных профессиональных языках.
• Использование разных систем учета затрудняет коммуникацию и передачу знаний.

Единый поток создания ценности должен охватывать как процессы разработки продуктов, так и процессы предоставления услуг. Для построения такого потока важно рассматривать практики SDLC и ITSM в совокупности, обеспечивая:

• Сквозную прослеживаемость от потребностей клиентов до конкретных задач в бэклоге разработки, избегая накопления технического долга;
• Эффективную приоритизацию задач на основе ценности для бизнеса и обратной связи от пользователей;
• Быструю обработку инцидентов и запросов на изменения с вовлечением необходимых экспертов;
• Непрерывное улучшение продукта и услуг на основе собираемой аналитики и метрик.

Реализация интегрированного подхода требует как организационных изменений, так и соответствующих инструментов. Необходимо наладить тесную коллаборацию между командами разработки, поддержки и взаимодействия с клиентами. Кроме того, большое значение имеет создание единой информационной среды, обеспечивающей бесшовную интеграцию процессов SDLC и ITSM.

Взаимодействие команд разработки и поддержки

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

1. Анализ обратной связи пользователей

Большинство обращений, поступающих в службу технической поддержки — это «живая» обратная связь от людей, которые каждый день используют продукт. За каждым запросом стоит реальный человек со своими потребностями, болями и ожиданиями. Относиться к этой информации нужно крайне внимательно и бережно.

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

2. Инциденты как точки роста

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

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

3. Управлять изменениями сообща

Запросы на изменения, которые формируют пользователи — еще один важный канал обратной связи, позволяющий держать руку на пульсе меняющихся потребностей клиентов. Грамотная обработка этих запросов требует плотного взаимодействия между продуктовыми командами и специалистами поддержки.

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

4. Унифицировать процессы, интегрировать инструменты

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

Платформенные решения позволяют реализовать бесшовную интеграцию на базе единой системы. Продукты SimpleOne SDLC для управления жизненным циклом разработки ПО и SimpleOne ITSM для автоматизации сервисных процессов образуют единое информационное пространство. Это открывает возможности для кросс-функционального взаимодействия и позволяет выстроить полноценный цикл разработки на основе обратной связи от реальных пользователей.

Роль обращений в формировании бэклога

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

Управление инцидентами и управление проблемами — это два взаимодополняющих ITSM-процесса, которые, тем не менее, имеют разные цели и фокус.

Управление инцидентами нацелено на скорейшее восстановление нормальной работы сервисов для пользователей. Главный приоритет — как можно быстрее решить проблему пользователя и минимизировать негативное влияние инцидента на бизнес. При этом глубинные причины возникновения инцидента часто остаются неизвестны.

Управление проблемами, напротив, фокусируется на поиске и устранении корневых причин инцидентов. Его задача — предотвратить повторное возникновение инцидентов в будущем.

Разделение этих процессов позволяет и оперативно устранять последствия инцидентов для клиентов, и системно работать над качеством и стабильностью предоставляемых услуг. Но важно понимать, что в конечном итоге оба процесса должны быть интегрированы в единый поток непрерывного совершенствования.

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

Вовлечение продуктовых команд в процесс управления инцидентами и проблемами имеет ряд преимуществ:

• Разработчики получают из первых рук информацию о реальном опыте использования продукта, что помогает лучше понять потребности пользователей;
• Продуктовые команды могут быстрее и точнее диагностировать технические причины проблем и предложить варианты решения;
• Совместная работа над инцидентами и проблемами способствует развитию культуры качества и ответственности за конечный результат.

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

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

Реализация подобной интеграции на практике позволяет реализовать сквозной процесс от обращения пользователя до разработки и выпуска улучшений продукта:

1. Инциденты и запросы пользователей регистрируются службой поддержки в ITSM-системе;
2. На основе инцидентов выявляются проблемы, требующие более глубокой проработки;
3. Информация о проблемах и запросах на улучшения автоматически передается в системы SDLC в виде задач на разработку;
4. Продуктовые команды, используя практики Agile, включают эти задачи в свой бэклог и планируют их реализацию в рамках спринтов;
5. После выпуска обновлений продукта информация о решенных проблемах и реализованных улучшениях передается обратно в ITSM;
6. Служба поддержки информирует пользователей о произведенных изменениях и собирает обратную связь.

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

Интеграция процессов на базе платформы

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