Кирилл Кибалко: «Управление разработкой ПО – это сфера, в которую необходимо инвестировать»
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
апрель    2024
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

показать все 

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

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

09.04.2024

OS Day 2024: «Архитектурные аспекты безопасности операционных систем»

Читать далее 

09.04.2024

Биометрические пароли и карманные дата-центры: россияне рассказали, чего ждут от «Экономики данных»

Читать далее 

показать все 

Статьи

11.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

22.09.2023

Эпоха российской ориентации на Запад в сфере программного обеспечения завершилась

Читать далее 

22.09.2023

Сладкая жизнь

Читать далее 

22.09.2023

12 бизнес-концепций, которыми должны овладеть ИТ-руководители

Читать далее 

22.09.2023

Проще, чем кажется. Эталонная модель документооборота или краткое руководство по цифровой трансформации

Читать далее 

показать все 

Кирилл Кибалко: «Управление разработкой ПО – это сфера, в которую необходимо инвестировать»

Главная / Интервью / Кирилл Кибалко: «Управление разработкой ПО – это сфера, в которую необходимо инвестировать»


Кирилл Кибалко:
«Управление разработкой ПО – это сфера, в которую необходимо инвестировать»

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

Кирилл Кибалко
Досье
Кирилл Кибалко, заместитель директора по информационным технологиям банка «Хоум Кредит».

– Кирилл, расскажите, пожалуйста, подробнее о программе проектов по технологическому развитию ИТ в вашем банке: с какой целью она была разработана? Почему возникла необходимость в комплексном подходе к управлению требованиями к ПО в банке?

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

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

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

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

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

– Что вы получили в результате аудита?

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

Эта связь требований разных уровней является своего рода матрицей. Ее использование называется Requirements Traceability Matrix.

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

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

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

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

– Что должен знать руководитель предприятия о подобных системах? Какие плюсы от ее внедрения видите вы лично как руководитель подразделения?

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

Вместе с инструментарием от IBM мы получили стандартные модели процессов разработки софта. Для CIO это в том числе возможность внедрить best practice, лучшие практики по разработке ПО на своем предприятии.

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

Что это внедрение дало лично мне как руководителю? Процесс по реализации отдельных элементов конвейера разработки ПО стал более прозрачен. Раньше мы не могли, например, в автоматическом режиме понять, на каком этапе находится решение той или иной задачи, согласованы ли уже по ней требования или нет. А с учетом того, что одновременно таких задач у нас 60-90 штук… Приходилось вручную собирать информацию и сводить ее в отдельную таблицу. Видеть объективную картину было сложно. Сейчас вся информация по состоянию любой задачи доступна в онлайн-режиме по запросу. Раз в неделю мы собираемся и смотрим статус по всем нашим текущим релизам. Это своего рода интегральный контроль за процессами в целом, благодаря которому можно узнавать заранее о возможных точках задержки и регулировать ход проекта, вовремя их устраняя. Мы сразу видим проблемы и заранее принимаем меры по их устранению. У нас пять релизов в год, в каждом из которых, напомню, 6-7 тыс. человекодней работы. Мы всегда работали в жестких рамках по срокам. Ни один deadline по выходу релиза мы не срываем. Все внедряется в соответствии с датами, запланированными год назад.

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

– Еще один интересный проект, завершенный в вашем банке, – автоматизация тестирования – Test Automation. Есть ли уже какие-то положительные или интересные результаты?

– Да, есть. Активно внедряя релизы в течение года, банку требуется обеспечить стабильное качество работы своих систем. Внедрение проекта Test Automation позволило обеспечить процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически с помощью инструментов для автоматизированного тестирования. В процессе проверки роботы-тестировщики проводят более 700 тест-кейсов основных функций информационных систем банка.

Если раньше на один прогон регрессионного теста мы тратили порядка 60 человекодней (шесть человек за 10 дней проводят тестирование), сейчас «робот» это делает за один день.

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

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

– У нас для обозначения принципа функционирования удаленных центров разработки есть даже собственный термин – Cloud Development – облако разработчиков. Созданы удаленные центры в разных локациях, где все работают на единых технологиях и средах, базах данных, в единой производственной системе. Независимо от того, где разработчик находится физически, из облака он получает одинаковый для всех инструмент, в единой форме – задание, имеет единый для всех доступ к необходимым порталам и шаблонам. Для создания облака мы использовали платформу Jira, на которой мы выстроили свои процессы.

Сейчас у нас девять удаленных центров: в Днепропетровске, Обнинске, Саратове, Тольятти, Ижевске, Челябинске, Ростове-на-Дону, Рязани, еще три будут открыты в ближайшее время. В среднем в этих центрах занято по 20 человек. В Днепропетровске – 50 человек. В Обнинске и Ижевске – около 20.

Банк Хоум Кредит
Банк Хоум Кредит, обслуживший за двенадцатилетнюю историю своей работы более 29 млн клиентов, – пример высокотехнологически развитого финансового института.

В блоке ИТ банка Хоум Кредит трудятся более 900 человек, 200 из них вовлечены в процесс разработки программного обеспечения. Банк постоянно реализует проекты, направленные на повышение эффективности и ускорение внутренней разработки.

В 2013 году в банке была завершена первая фаза программы проектов по технологическому развитию ИТ, в рамках которой банк внедрил платформу для автоматизации управления требованиями к программному обеспечению (Requirements management), технологию Test Automation, позволившую снизить затраты ресурсов на тестирование ПО, а также процесс Code Review, обеспечивший единый стандарт разработки кода в банке.

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

– Позволяет ли создание подобных центров оптимизировать затраты на разработку?

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

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

Экономия бюджета благодаря созданию удаленных центров разработки может превышать 70%.

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

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

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

– Каков в целом общий итог всех этих проектов?

– Судите сами. В 2013 году в программе технологического развития у нас было три проекта, в аналогичной программе на 2014-й мы открыли уже семь проектов. Мы поняли, что управление разработкой – это сфера, в которую нужно вкладываться. Внедрение этого инструментария эффективно, позволяет снижать затраты и обеспечивать высококачественную разработку внутри организации в срок. И, конечно, главный результат – бизнес-подразделения банка довольны. На комитетах по развитию банка высшее руководство высоко оценивает наше качество работы.

Беседовала Агунда Алборова

В начало⇑

Выпуск №02 (135) 2024г.
Выпуск №02 (135) 2024г. Выпуск №01 (134) 2024г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика