Я не очень понимаю, почему об этом мало кто рассказывает.

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

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

Думаю, вы и сами представляете, как оно происходит в банках. Именно поэтому многие разработчики <sarcasm>так стремятся</sarcasm> в них работать.

Когда я прикоснулся в Газпромбанке к организации производства, то как раз застал несколько «ГОСТ-команд» с совершенно безнадёжным TTM и много аджайл-команд, бьющихся в истерике от требований.

Что хотелось поменять

Как и в любом другом месте, конечно, хочется разрабатывать код быстро, релизить с минимальным TTM и вообще говорить модные слова вроде «лид-тайм» и «сиайсиди». Если бы не желание хоть как-то зарабатывать, «ГОСТ-сторона» банка давно бы уже победила, и всё шло бы по хорошо понятным предсказуемым процессам без сюрпризов, зато с греющей душу бюрократией. Но победить ей мешало то, что без гибкой разработки в дивном новом мире ни один проект уже давно не взлетает. Аджайл, конечно, зло, но попробуйте руководить хоть чем-нибудь крупным без него — и вы поймёте, что это ещё не худшее, что может случиться. А если сильно задуматься, то это такое зло, которое в сравнении с ещё большим злом очень даже добро. Короче, это добро, которое никто не любит, но другого выхода просто нет.

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

Нам надо было построить свой, для начала хотя бы кривой и косой, но аджайл – для того, чтобы можно было заниматься нормальным производством кода. И помирить его с банковскими требованиями, то есть требованиями регуляторов и нормативами Центробанка, регламентирующего правила внутренних процессов и документы, которые при этом создаются. Если вы не в курсе, как устроена банковская разработка, рекомендую прочитать и содрогнуться. Как я уже говорил, уже было несколько аджайл-команд (делающих самые быстрые и при этом далёкие от ядра вещи вроде мобильного приложения), которые страдали, но пытались гибко разрабатывать.

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

Что начали менять

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

Выяснилось, что в процессе разработки есть около 30 разных ролей, причём из них около двадцати — это внешние подразделения, с которыми надо всё согласовать. Первое, что мы сделали, — это уменьшили количество этих ролей до 11. 

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

Ввели эти чек-листы в процесс как обязательные на стадии постановки задачи. Почему так? Потому что некоторые продуктологи обожали пропускать этот шаг. Для них участие любых внешних людей в процессе — это что-то противоестественное. В итоге они доделывали что-то, а потом внешние люди всё же приходили, чтобы выпустить это что-то на прод, и говорили: «Ну, теперь надо вернуться в прошлое на два месяца и сделать вот эту штуку заранее». В итоге кончалось переделыванием иногда чуть ли не на уровне архитектуры.

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

Параллельно не забываем про инструменты разработки и тестирования, планомерно приводим к единообразию. Команды не держат у себя под столом чего-то, что им захотелось. То же касается всяких практик, подходов, стандартов, разработки, тестирования — это всё централизованно. Также касательно документации. Это требование — обязательное для банковского производства, потому что не должно быть систем, которые не проверены (в том числе на предмет информационной безопасности) и не ложатся в нормативы. Единый инструментарий контролировать куда эффективнее, чем зоопарк отдельных решений для каждой команды. Команда не может для себя решить, что сегодня у них TeamCity, а завтра будет Jenkins, допустим. Нет. В банке есть стандарт. Есть TeamCity централизованный. Все на нём живут. Точно такая же история с процессами: они одинаковые, потому что они рождают в автоматическом режиме одинаковые документы, которые при проверке от ЦБ будут поднимать. Соответственно, при одинаковом наборе инструментов можно автоматизировать большую часть бюрократии. Точнее, автоматизировать-то можно при любом наборе инструментов, но при одинаковом для всего банка это можно более-менее нормально поддерживать.

У нас достаточно чётко зафиксирован в процессе набор документов, которые должны быть. Естественно, переходим в сторону автоматизации. Уходим от Word-овых и Exсel-евских артефактов, естественно, в Confluence. Что-то замещается задачами в Jira и в сопутствующих инструментах. Но тем не менее есть чётко определённый состав артефактов и набор опций для команд в этих артефактах, которые нужно делать. На каждом этапе есть определённый критерий перехода на следующий этап. Они контролируются.

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

Что получается

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

Многие вещи крайне очевидны, просты и прямо напрашиваются, поэтому их годами не делают. Те же банальные чек-листы по взаимодействию с подразделениями могут с ходу в разы снизить поток документов, с которыми к ним раньше ходили. Сидим и думаем: «А что мы раньше до этого не додумались? Ну, окей, хорошо хоть сейчас додумались». Есть какие-то простые вещи, которые вроде бы на поверхности. Или те же роли: по сути, ничего в самом процессе не меняется. Но людям воспринимать процесс с меньшим количеством сущностей проще. Начинают уже легче в нём ориентироваться, то есть меньше сюрпризов всплывает перед выкаткой на прод. 

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