Алексей Макеев, AT Consulting: «До внедрения Agile в банке еще надо дорасти»

Алексей Макеев, партнер компании AT Consulting, рассказал Bankir.Ru о тонкостях внедрения Agile, о балансе между традиционными и гибкими методологиями разработки и о том, почему гибкость проникает даже в самые формализованные организации.

— Agile в банковском бизнесе активно обсуждается уже несколько лет, однако и по сей день у гибких методологий много противников. Какие аргументы в пользу Agile видятся вам основными?

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

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

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

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

— Возможно ли совместить внутри одного банка Waterfall- и Agile-подходы? Есть ли направления, где Agile не приживается в принципе?

— По нашему опыту, в крупном проекте Waterfall в чистом виде невозможен в принципе и с вероятностью 100% ведет к неуспеху.

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

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

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

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

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

— С чего стоит начать при принятии решения о переходе на гибкие методологии?

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

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

— Одной из серьезных проблем в банках становится объединение всех IT-компетенций в одном информационном и физическом пространстве. Есть ли способы внедрить Agile «по частям», когда разработчики и менеджеры разделены территориально?

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

— Каких результатов следует ждать от внедрения Agile, и, главное, когда они начинают появляться?

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

— Бывает ли, что «все пошло не так»?

— Применение гибкой методологии позволит хорошей и слаженной команде внутри банка добиться еще более выдающихся результатов. Но Agile не может решить проблему, с которой сталкиваются большинство банков. Трудности, которые мы видим у своих клиентов, связаны в первую очередь с нехваткой компетентных специалистов. Невозможно внедрять Agile в ситуации, когда в проектной команде 0,25 банковского технолога, 0,3 аналитика по АБС, 0,1 архитектора по интеграции. При наличии ресурсных проблем внедрение Agile не поможет, а скорее усугубит ситуацию. Недостаток ресурсов по одному или нескольким направлениям будет тормозить всю проектную команду.

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

— Какие шаги следует предпринять для нормализации ситуации?

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