Анастасия Михалицина — Старший PR-менеджер
тел.: +7 (495) 748-05-75 | доб. 3053
E-mail: amikhalitsina@at-consulting.ru
Пресс-центр — СМИ о нас
22 августа 2016 , Bankir.ru
Алексей Макеев, партнер компании AT Consulting, рассказал Bankir.Ru о тонкостях внедрения Agile, о балансе между традиционными и гибкими методологиями разработки и о том, почему гибкость проникает даже в самые формализованные организации.
_______
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. А для крупных, комплексных изменений, требующих слаженных действий объединенных команд, скорость внедрения остается по-прежнему низкой.
Михаил Коленкин, первый заместитель руководителя блока ИТ Альфа-Банка
Стратегическим партнером Альфа-Банка в развитии Business Intelligence выступает компания AT Consulting, с помощью которой мы успешно осуществили ряд важных инфраструктурных и бизнес-проектов, например таких, как миграция хранилища данных на новую платформу, запуск системы управления маркетинговыми кампаниями.
Мария Вожегова, член правления, вице-президент по ИТ и операциям ОАО «Росгосстрах»
Я ценю наше партнерство с AT Consulting и тот подход, который компания использует в работе с заказчиком. Особенно для наc важно то, что специалисты AT Consulting всегда нацелены на выстраивание долгосрочных отношений на взаимовыгодных условиях.
ООО «ЭйТи Консалтинг»
127015, Россия, Москва, ул. Большая Новодмитровская, д.14, стр.7, офис 523, БЦ "Новодмитровский"
Телефон: +7 (495) 748 0575
Факс: +7 (495) 748 0125
E-mail: clients@at-consulting.ru