Псевдо Agile – в банковской и финансовой сферах. В современных условиях перед банком, его структурными подразделениями встает вопрос о четко сформулированной и грамотно проводимой политике. Этап экстенсивного роста, в том числе и в банковском секторе, сменился полномасштабным финансовым кризисом и определил необходимость переориентации реализуемой политики банковских структур. Проанализируем основные принципы Agile Manifesto, принятого в феврале 2001 года: гибкость в кредитной организации практически отсутствует. Анализ: Первый принцип: «Люди и взаимодействие важнее процессов и инструментов». Данный принцип не соответствует так как процессы и инструменты в банковской сфере всегда были и будут важнее человеческих ресурсов. Люди приходят и уходят, а процессы остаются. Если что-то не нравится, то «дверь на выход» всегда открыта. Второй принцип: «Работающий продукт важнее исчерпывающей документации». Документация всегда была и будет на первом месте при разработке программного обеспечения в банковской сфере. Как бы мы не говорили про то что данный принцип присутствует в кросс функциональных командах, на самом деле он не работает. Третий принцип: «Сотрудничество с заказчиком важнее согласования условий контракта». Данный принцип практически соответствует и присутствует в ведении ИТ проектов. Но в банковской сфере речь должна идти не о сотрудничестве, а о слепом подчинении команд разработки бизнесу. Так как показывает практика им виднее, как должен выглядеть тот или иной продукт. Четвертый принцип: «Готовность к изменениям важнее следования первоначальному плану». Данный принцип тоже увы не работает в банковской сфере так как все планы заведомо утверждаются на заседаниях правления. А если кто-то с этим не согласен, то как правило долго не прорабатывает в банковской сфере и покидает кредитную организацию. Собственно, требования к документации и продукту со стороны ИБ постоянно растет в банковской сфере. А также постоянно меняются требования к банковским продуктам со стороны регулятора. Делать надо было сразу. Не ожидая согласования документации. А вот кому делать – непонятно никому. За последние годы спрос на программистов и тимлидов в банковской среде вырос очень сильно, а вакантные места заполнялись очень медленно. Собственно, именно программист сегодня – самый востребованный банковский сотрудник. На самом деле очень много лет в банках работал и работает до сих пор консервативный подход, или так называемый Waterfall подход считался уже давно «бунтарским». Растущее внимание компаний «не из IT» к Agile-подходам объясняется тем, что многие отрасли попали в ситуацию высокой неопределенности, а Agile традиционно востребован именно в таких условиях. Данная методика родилась внутри IT-индустрии, потому что в ней как в сравнительно новой сфере долгое время не было алгоритма действий, гарантирующих успех, что требовало постоянных экспериментов с быстрой обратной связью. В последние годы компании из многих индустрий — финансового сектора, телекоммуникаций и даже тяжелой промышленности — столкнулись с проблемой, которую можно сформулировать так: появляются новые способы решения задач, которые раньше решали только эти компании, из-за чего снижается маржинальность их услуг. Если спросить любого специалиста по внедрению Agile в организациях, то он вам скажет – «Все принципы должны соблюдаться одновременно. Если хоть что-то не соблюдается – это уже не Agile, а черт знает, что». 12-15 Мая 2019 в Дублине состоялся PMI EMEA Congress 2019, который был организован одним из лидеров отрасли в области разработки методологии управления проектами – Project Management Institute (PMI). Конгресс собрал более 700 делегатов из 70 стран и 450 организаций и стал мировой площадкой по обмену знаниями и опытом в применении современных методов и подходов в области управления изменениями. Во многих крупных российских банках и финансовых учреждениях на текущий момент происходит Agile трансформация структуры управления изменениями, поэтому анализ опыта аджайлизации в других подобных организациях является важным фактором успешного и эффективного внедрения Agile. В результате анализа Agile-трендов и презентаций, представленных на конференциях, были сделаны следующие заключения и выводы: Методология Agile изначально разрабатывалась для гибкого управления небольшими продуктами с помощью команд 7-15 человек для эффективного использования имеющихся ресурсов. Масштабирование подхода на большие организации требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации. Внедрение гибких методологий в некоторых крупных организациях привели как к позитивным результатам, а именно, к повышению эффективности, уменьшению показателей Time to Market (T2M) и к уменьшению затрат на изменения, а в отдельных, к негативным последствиям: ухудшению сроков реализации проектов, качества планирования и увеличению операционных затрат. Эффективным способом при внедрении гибких методологий является совмещение классических подходов проектного управления с гибкими методиками. Необходимо учитывать национальный и региональный менталитет сотрудников при внедрении методологии Agile. Национальные особенности должны отражаться в программах обучения Agile. В общем случае недооценивается роль обучения философии Agile и изменению мышления сотрудников организации. Для успешного внедрения необходимо кардинально поменять отношение персонала к процессам внутри организации, к роли работы в команде, при этом высококвалифицированные индивидуумы могут покинуть компанию, поскольку они теряют ощущение незаменимости и уникальности, возможности быть единственным умеющим плавать на пляже героемспасателем. Для успешного использования гибких методологий зачастую требуется кардинально пересмотреть бизнес-модель и структуру организации. Роль проектного офиса, программного и портфельного управления проектами при переходе на гибкие методологии обычно упраздняется в процессе трансформации, что является негативным фактором. В результате происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью гибкости команд. Отсутствует явное бюджетирование новых инициатив, поскольку бюджет выделяется на цели и задачи стрима. Механизмы расширения и видоизменяя стрим не являются ключевыми в методологии. Это приводит к замедлению внедрения инноваций внутри организации. Качество продуктов снижается из-за выделенном акценте на уменьшении T2M. Регуляторные требования могут реализовываться с использованием Agile принципов, но с особым акцентом на качество конечного результата. Уровень и качество коммуникаций между подразделениями при использовании гибких методологий должны быть существенно увеличены. При недолжном уровне взаимодействия и взаимопонимания использования гибких методологий только увеличит T2M и стоимость внедрения изменений. Использование специализированного программного обеспечения для единого управления задачами, проектами, портфелем и программой проектов, целевыми показателями эффективности организации, интеграция процессов изменения с ERP и CRM системами, существенно увеличивает эффективность применения Agile и взаимодействия команд. Во всех Agile практиках особое внимание уделяется обратной связи, анализу спринтов внутри команд, но на уровне выше (продукты, программы, трайбы) эта связь теряется для рядовых членов команд. Внедрение Agile в крупной организации это не вопрос одного месяца, полугода или года. Это системная стратегическая работа на несколько лет с кардинальным изменением всех процессов и принципов работы организации. Рекомендации: Высший менеджмент организации должен стать проводником, лидером Agile изменений. Необходимо ежемесячно на уровне каждого стрима выступать перед сотрудниками с обзором текущих целей, прогрессом их выполнения, анализом текущих уроков. Ежеквартально организовывать аналогичные meetup между лидерами стримов с веб-трансляцией и открытым участием всех желающих сотрудников организации. Необходимо усилить роль и объем обучения Agile методикам. Обучение должно акцентироваться не только на техниках, таких как Scrum, Kanban, но и идеологии и философии Agile, изменению принципов мышления, инновационным и нестандартным аналитическим подходам. Обучение должно опираться на конкретные примеры и практики крупных финансовых институтов, стран и регионов. Дополнительно необходимо проводить психологическое тестирование и выявлять сотрудников, которые не готовы к новым изменениям внутри компании. Проектный офис должен выполнять координационную и коммуникативную роль (ежемесячные и ежеквартальные meetup), быть во главе стратегического планирования и обеспечивать мониторинг качества деятельности стримов. Agile принципы не должны быть обязательны для всех проектов, особенно если речь идет о регуляторных и нормативных изменениях. В каждом конкретном случае необходимо принимать обоснованное решения при использовании Agile в таких случаях. Допускается совмещение классических и гибких подходов к реализации проектов. Необходимо уделять особый и выборочный акцент качеству конечного продукта. Работающий продукт важнее исчерпывающей документации, но качественно работающий продукт невозможно создать без должной документации и QA, поэтому необходимо постоянно балансировать на этой грани, при этом не в ущерб качеству продукта. Взаимодействие между подразделениями необходимо вывести на новый уровень. Бюрократические препоны, беспочвенные отсылки на процессы и внутренняя нормативная документация во взаимодействии должны жестко пресекаться высшим руководством стрима, и оперативно разрешаться. Должен быть создан соответствующий on-line механизм внутри стрима и между стримами с соотвествующими КПЭ у всех руководителей. Необходимо создать атмосферу общей командной работы внутри организации, а не перекладывания ответственности между подразделениями и блоками. Принцип люди и взаимодействие важнее процессов и инструментов необходимо сделать базовым при коммуникации между стримами. Мотивационная составляющая работы, нацеленность на изменения, нестандартность мышления должны быть объединены в единой оценке сотрудников всех уровней с понятной и прозрачной обратной связью. При этом, чтобы выражение таких идей не воспринималось, как увеличение нагрузки на лидеров, кластеры и стримы, должны быть созданы прозрачные механизмы расширения команд, увеличение бюджета, а не его перераспределение внутри уже выделенного. Используемые ИТ-решения для ведения бэклога, дашборды для Scrum, Kanban не должны ограничиваться только в их использовании для DevOps процессов и реализации спринтов, а являться информационной основой для выполнения пользовательских историй и проектов, портфелей и программ проектов, иметь связь с ERP системой, связь с КПЭ лидеров, кластеров, стримов и организации в целом. Влияние типа клиентов на выгоды: Финансовые и торговые компании очень высоко оценивают достигнутый ими эффект ускорения delivery / сокращения Time to Market.
