Как привить Agile-культуру на российской земле

Как ИТ-подразделению банка научиться понимать бизнес?

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

Здесь помогут принципы, заложенные в Agile-манифест, частично они приведены далее:

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

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

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

Подводные камни Agile

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

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

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

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

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

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

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

Из главных принципов Agile вытекают и основные проблемы:

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

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

DEVOps + Agile — следующая эволюционная ступень

Принцип предоставления рабочего программного обеспечения меньшими и более частыми релизами хорошо укладывается в методологию Agile, в отличие от подхода «большого взрыва», который присущ каскадной методологии. Команды, работающие по принципам Agile, стремятся иметь готовый продукт в конце каждого спринта (как правило, раз в 2–4 недели).

Высокие темпы развертывания приводят к тому, что перед админами накапливается гора задач. Клайд Лог, основатель «StreamStep», говорит об этом так: «Agile сыграл важную роль для восстановления доверия у бизнеса, но нечаянно оставил ИТ процессы позади. DevOps — это способ восстановления доверия ко всей ИТ- организации в целом».

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

Изменяя процессы и метрики разработчиков и администраторов, DevOps в том числе изменяет культуру. Джон Уиллис и Дэймон Эдвардс (соавторы Cookbook DevOps) подробно написали об этом в своей статье DevOps Culture (Part 1).

Как Agile прижился в одном из ТОП-20 банков РФ

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

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

В 2008 году в Банке был принят релизный подход: перед совместной командой стояла задача выпускать 8 релизов в год. Так как проект требовал тесного сотрудничества исполнителя и заказчика, для оптимизации процессов разработки команда специалистов «Инфосистемы Джет», специализирующихся на Oracle Siebel, реализовывала проект на территории Банка. Постепенно мы начали процесс внутренней оптимизации, благодаря которому производительность нашей команды увеличилась втрое, и мы вышли на оптимальные показатели эффективности, постоянно наращивая проектную команду.

Результаты не заставили себя долго ждать. Если раньше новая задача, перед тем как поступить в разработку, большую часть времени находилась на внутреннем согласовании, теперь команду Исполнителя стараются ознакомить с ней как можно раньше, чтобы всесторонне ее проработать и прийти к оптимальному решению. Разработчики, аналитики и тестировщики нашей компании участвуют в формировании требований. Таким образом, общее видение проекта и заложенного в него функционала формируется на ранней стадии. Далее зафиксированный объем задач в рамках готовящегося релиза распределяется среди участников команды самостоятельно. Каждый сам выбирает те задачи, которые хочет сделать в текущем релизе. Это помогает снизить Bus factor (метрика, которая показывает, продолжится ли проект, если его кто-то покинет. Если автобус покидает водитель, автобус, естественно, не поедет. — Прим. редакции) и расширить матрицу компетенций всей команды в целом.

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

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

JetDocer

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

JetDocer установлен на рабочих местах в точках продаж банка и компаний-партнеров. В зависимости от занимаемой должности специалисты Банка имеют доступ к разным функциям JetDocer.

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

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

Руководители отделов кредитования имеют возможность в режиме реального времени анализировать производительность сотрудников и уточнять временные нормативы.

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

Siebel

Создание CRM-системы в Банке стало одним из наиболее объемных и масштабных проектов по внедрению Oracle Siebel CRM банковском секторе России. Единая CRM- система охватила 84 подразделения сети банка, с ее помощью обслуживается более 600 тыс. клиентов — физических лиц и свыше 17 500 юридических лиц.

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

На следующих этапах на основе соответствующих модулей Oracle Siebel CRM были автоматизированы процессы продажи кредитных продуктов для физических лиц. Был реализован автоматический расчет параметров кредитной сделки по описанию продукта в каталоге, разработаны интерфейсы по автоматической генерации кредитных сделок в АБС, интерфейсы с внутренними служебными базами данных, со скоринговой и почтовой системами банка. Были также разработаны шаблоны документов, необходимых для выдачи и сопровождения каждого кредитного продукта.

Через CRM проходят все заявки на выдачу розничных кредитов и отслеживаются все стадии их прохождения. Централизация процесса обработки заявок в головном офисе позволила банку перевести на другие участки более 120 штатных сотрудников бэк-офисов. Встроенный интерфейс с Национальным бюро кредитных историй (НБКИ) позволяет «в один клик» отправить туда запрос, получить информацию о заемщике и занести ее в соответствующие поля CRM- системы. Информация анализируется с помощью скоринговой модели, в результате выдается рекомендация о решении по выдаче/невыдаче кредита.

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

Недавно завершен проект по автоматизации кредитного процесса для малого и среднего бизнеса.

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

FLEXCUBE Corporate History Storage

Уже более 10 лет в Банке функционирует хранилище данных FLEXCUBE Corporate History Storage (FCCHS), разработанное специалистами компании «Инфосистемы Джет». Оно обеспечивает потребности банка в формировании отчетности на основании исторических данных. К FCCHS подключено множество отчетных систем Банка. Обращаясь к хранилищу через специальный интерфейсный слой, они получают все необходимые данные с нужной исторической глубиной — от текущего момента до десятилетней давности.

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