Построение "гибкого" конвейера производства программных продуктов для финансового сектора

Толмачев А.М.  

выпускник группы MBA CIO-48

Школы IT-менеджмента 

РАНХиГС при Президенте РФ

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

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

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

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

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

Для достижения цели были выполнены следующие задачи:

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

2.      Автоматизированы рутинные операции процесса производства для повышения прозрачности и контролируемости процесса, а также для сокращения издержек (как временных, так и финансовых);

3.      Обеспечена отказоустойчивость сервисов производства для удовлетворения потребностей команд разработки.

Главной целью работы было удовлетворение требований клиентов в части:

·        Гибкости;

·        Соблюдениясроков;

·        Мульти-платформенности;

·        Быстройинтеграции.

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

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

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

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

Автоматизация процесса производства, во-первых, сделала возможным переход на гибкую методологию разработки, а во-вторых значительно снизила трудозатраты на выполнение рутинных операций, которые были при разработке программных продуктов. Автоматизация сборки позволила значительно оптимизировать время разработчика на эти операции и, как следствие, расходы на каждый проект, что увеличивало его рентабельность. В среднем на ручную сборку одного релиза тратился 1 час времени разработчика. При количестве сборок 20-50 в месяц на один проект и средней ставке разработчика 800 рублей в час экономия в результате автоматизации сборки на один проект составила от 16 до 40 тыс. рублей в месяц. При количестве среднем количестве активных проектов 300-400 экономия по всем проектам составила до 10 млн. рублей в месяц при единоразовых затратах в 500 тыс. рублей.

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

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

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

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