Роль программного обеспечения в современном банке очень велика, как и риски, связанные с внедрением некачественно разработанного ПО или его неаккуратной модернизацией. Многие банки страдают от простоев или нестабильной работы ключевых банковских ИТ-систем в ходе их внедрения или просто не получали в требуемые сроки необходимый функционал. О том, как системно решать эту проблему, в интервью НБЖ рассказал директор департамента систем управления компании Helios IT Сергей ЯМОВ.

НБЖ: Сергей, вопросы качества разработки и внедрения программного обеспечения в последние годы активно поднимаются на «круглых столах» и конференциях. В чем, на ваш взгляд, причина этого?

С. ЯМОВ: Борьба за рынок предъявляет все новые требования к бизнесу, который, в свою очередь, ставит дополнительные задачи перед службами, отвечающими за информационные технологии. И очень часто поставленная задача не решается так, как того хочется бизнес-руководителям: реализован не тот функционал, он работает плохо, в ходе внедрения возникают болезненные простои, результат не в срок и дороже запланированного. Часто именно в информационных технологиях видят «тормоз» развития банка и источник серьезных операционных рисков.

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

НБЖ: Считается, что зрелость ИТ-служб в банковской сфере - одна из самых высоких, если сравнивать различные отрасли в России. Почему качество программного обеспечения остается проблемой?

С. ЯМОВ: При всей зрелости большинства банковских служб ИТ сложность проблемы   нарастает   быстрее,   чем меры, которые пытаются предпринимать для ее решения.

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

К этому добавляется совокупность факторов.

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

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

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

НБЖ: Действительно, сейчас все больше организаций пользуются услугами внешних разработчиков. Разве это не их зона ответственности - обеспечить качество ПО?

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

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

НБЖ: Почему ваша компания начала заниматься новым для ИТ-рынка направлением - организацией управления качеством программного обеспечения?

С. ЯМОВ: Одно из важных направлений Helios IT - услуги в области управления информационными технологиями. У нас очень профессиональная команда в части использования сервисного подхода к управлению информационными технологиями (ITSM) в части автоматизации управления ИТ-инфраструктурой. Задачи, которые мы решаем вместе с заказчиком, - это повышение эффективности ИТ-служб, выстраивание эффективного взаимодействия между бизнесом и ИТ-службами, повышение качества работы ИТ-систем.

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

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

НБЖ: На что направлены ваши услуги?

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

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

НБЖ: На что надо обращать внимание при организации обеспечения качества ПО?

С. ЯМОВ: Мы выделяем три составляющих: организационная составляющая, автоматизация обеспечения качества, тестовая среда.

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

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

Что касается автоматизации, то она требуется в двух разрезах. Во-первых, автоматизация взаимодействия участников обеспечения качества ПО и информационное обеспечение их работы: хранение реестра требований, информации о дефектах, распределение заданий тестирования на участников тестирования, хранение результатов тестирования и т.п. Во-вторых, требуется автоматизация самого тестирования, в первую очередь, регрессионного и нагрузочного.

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

НБЖ: Вы рассказали о необходимости автоматизации обеспечения качества ПО. Какие решения есть на рынке?

С. ЯМОВ: На рынке представлен широкий класс решений как узкоспециализированных, так и комплексных. Мы провели анализ рынка и отдаем предпочтение решениям известной компании HP, линейке продуктов Application Lifecycle Management - HP ALM, HP Performance Center/LoadRunner, QTP, ServiceTest. Это гибкие, удобные и функциональные продукты, признанные во всем мире. На наш взгляд, они лучше других комплексных решений подходят для автоматизации управления качеством ПО внутри заказчиков.

НБЖ: Когда у банков возникает потребность позвать кого-то на помощь для организации обеспечения качества ПО?

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

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

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

НБЖ: Что получает банк, внедрив систему управления качеством программного обеспечения?

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

НБЖ: А как меняются отношения банков, умеющих контролировать качество внедрения ИТ-систем, и разработчиков, которые на них работают?

С. ЯМОВ: Безусловно, в лучшую сторону. Банк может очень четко контролировать качество заказных работ и фактами и цифрами влиять на подрядчика, если качество разработки или устранения дефектов слабое. Повышается эффективность взаимодействия банка и разработчиков за счет более четкой постановки задачи, обоснованных решений по релизам, при-оритизации требований в случае решения задач с жестко фиксированными сроками.

НБЖ: Сколько времени занимают проекты по управлению качеством, и сколько они стоят?

С. ЯМОВ: Это сильно зависит от постановки задачи. Чтобы решить очень частную задачу, например, наладить управление дефектами для одной ИТ-системы, может быть достаточно и 1-2 месяцев. А если говорить о серьезных преобразованиях, то может потребоваться небольшая программа из нескольких проектов с первыми значимыми результатами через 4-6 месяцев и общей длительностью до 1,5-2 лет. Сроки обусловлены темпами организационных изменений, ведь мы меняем принцип работы подразделений, а чтобы начать работать по-новому, требуется время.

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