Что вы представляете, когда вам говорят про IT-проекты с банками? Бюрократия, куча интеграций, разработчики из разных команд. Что вижу я? Отличный шанс организовать сложный и трудоёмкий процесс. 

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

Отличие банковской сферы

Всем привет, меня зовут Денис Косарев, я Project Manager в Luxoft. 

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

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

• ускоряет подбор членов команды;

• защищает от сговора;

• позволяет в момент закрыть открывшуюся позицию;

• сокращает стоимость разработки;

• повышает качество продукта;

• уменьшает корпоративное влияние вендора на разработку продукта;

• позволяет членам команды быстрее развиваться.

При этом возникают интересные вызовы для менеджмента, scrum-мастера и тимлидов:

• организация команды;

• настройка процессов;

• недопущение конфликтов;

• защита от внешнего влияния;

• ускорение разработки продукта.
  
  Хотелось бы выделить ещё некоторые отличия работы над IТ-проектами банка помимо состава команд:

  • программное окружение (из банковского окружения не выйти в интернет и не написать письмо на адреса вовне банка; в части банков эта проблема решается с помощью второго экрана);

  • число интеграций, смена стеков, наложение архитектур (переезд в сторону продуктов с открытым программным кодом);

  • банковский фреймворк, накладывающийся поверх стандартного SCRUM (для повторяемости системы в Confluence документируются артефакты);

  • отсутствие ГОСТов (не нужно выпускать мешки документов для того, чтобы просто было).

  Вот в таких условиях работают команды. Я в том числе.

  CRM для банка + пул задач

  Сейчас я руковожу разработкой двух модулей CRM-системы для юридических лиц. Задачи проекта — автоматизация процессов и расчётов, упрощение интеграции данных, ускорение коммуникации и сбора информации. Если говорить глобально, нужно получить продукт поддержки принятия решений, который закрывает все запросы менеджмента банка.

  На проекте работает 48 человек, стек Java React. Команда занимается микросервисной архитектурой в условиях переезда с Oracle на PostgreSQL, сменой дизайн-систем и редизайном, где львиная доля у фронтенд-разработчиков. Дополнительно я провожу ежедневную воронку найма для двух стримов численностью примерно 150 человек каждый. Стрим — это группа проектов, объединённых одной бизнес-составляющей. В моём случае это CRM и корпоративный клиент 360. Особенно интересно это делать, не будучи сотрудником банка.

  В своей работе я выделил несколько первостепенных задач.

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

  2. Выстраивание процессов и правил в команде. Всё должно быть чётко, и каждый участник должен понимать и принимать условия.

  3. Фиксирование того, что мы действительно делаем и что хочет увидеть заказчик.

  4. В процессе я занялся ещё одной — оценкой трудоёмкости, сроков и скоупа.

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

  Поиск, отбор и интервью

  Технические специалисты должны заниматься техническим направлением, бизнес — бизнесом, а организационные — организацией. И так получилось, что именно в этих двух продуктах (CRM и корпоративный клиент 360) организационные вопросы доверили мне. За 14 лет я прошёл путь от разработчика до директора проектов, и мой опыт позволял организовать команды до 1000 человек. Сейчас я сделал шаг назад, чтобы улучшить знания на стыке организации scrum-команд, решения бизнес-задач и принятия технических решений. Будучи директором проектов, сделать это крайне сложно, зато потом я сделаю пять шагов вперёд. 

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

  Четыре команды были собраны на 100, 50, 20 и 0 процентов соответственно. Кандидатов в команды предлагали восемь вендоров (разных компаний, в том числе и Luxoft). Следовательно, ни о каких директивных методах управления не могло быть и речи. Тем более это удалёнка со специалистами, находящимися в разных городах России и Беларуси. Состав команд обычно следующий: один системный аналитик, четыре бэкенд-разработчика (2 senior, 2 regular), два senior фронтенд-разработчика, три QA (2 senior и 1 regular), тимлид. На две команды по одному IT-лиду и одному архитектору, и на четыре команды один scrum-мастер и один DevOps.

  

  Поиск

  Первое, с чем я столкнулся, — с некорректностью части вендоров в предложении кандидатур, так как на senior-позиции присылали людей без высшего образования с опытом в разработке или тестировании от двух до четырёх лет. В день в общем приходило от 5 до 30 резюме; нужно было выбрать подходящих кандидатов для заключительного клиентского интервью и дать обоснованный ответ при отказе от назначения интервью. Данную задачу я решил в течение двух недель, и до интервью у меня стало доходить не 10%, а 30% присланных кандидатов, впоследствии мы эту цифру увеличили до 80%. 

  Качественные кандидаты приходили от тех вендоров, где было первоначальное техническое и менеджерское интервью. 95% таких кандидатов дошли до общения с клиентом, и на них была очередь.

  Отбор

  При первом диагональном просмотре резюме я обращал внимание на:

  • опыт (на senior-позиции имеет смысл смотреть людей от пяти–семи лет работы в соответствующем стеке);

  • длительность работы в прошлых компаниях (несколько мест подряд по два–три месяца работы — нам не по пути с таким специалистом);

  • релевантность опыта (опыт в финтехе не является уникальным, а вот технологический стек критически важен);

  • наличие профильного высшего образования и год его окончания (в моей команде есть ребята без высшего образования или с гуманитарным профилем, у части чувствуется отсутствие базы).

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

  Интервью

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

  Сошлись на том, что для КИ:

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

  • интервью длится час;

  • этапы примерно следующие:

  

  • место проведения — предпочтительно Zoom;

  • время проведения — после обеда в зависимости от графика (утро нужно тратить на работу);

  • фидбэк и решение в течение 30 минут после интервью. Бывало, что оставалась последняя позиция в нише и на неделе были назначены несколько интервью, тогда рекрутера оповещали об этом и по завершении последнего собеседования сообщали результат отдельно каждому кандидату.

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

  Процессы: SCRUM в банке

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

  Сперва мы начали следить, чтобы только что нанятые команды придерживались процессов, и искать Scrum-мастера. Наняли его в штат Luxoft в мою структуру. Квалифицированного и творческого специалиста мы нашли в течение месяца. У него на тот момент был опыт работы с одной командой, но имелся отличный потенциал и бэкграунд. Уже в банке, я думаю, его озадачил объём работы: была задача внедрить фреймворк в пяти командах.

  Вот как поступили мы. Надеюсь, что это будет полезным:

  • изучили процессы в командах;

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

  • провели ряд one-on-one мероприятий с тимлидами. У каждого были свои слабые стороны, которые необходимо было усилить. Одному пришлось объяснить важность ежедневных стендапов, двум другим — демократичность (крайне деспотичный был поход, код-ревью только через него, исправление кода без объяснений), четвёртому — необходимость организации планирования, когда члены команды сами берут задачи из бэклога; 

  • описали мероприятия, ответственных и временные рамки. Когда стендап длится час, то это замедляет всю команду;

  • ввели ретро, затем дейли, после сделали упор на оптимизацию планирования и наконец демо.

  Тут хотелось бы чуть отступить. У нас была ситуация, когда Product Owner немного побаивался внешних сотрудников. Мы не хотели, чтобы PO отгородился от команды, потому что говорит с ними на разных языках. Поэтому проговорили отдельно с ним важность демо, объяснили смысл с прицелом на продукт и заинтересованные стороны. Демо делает первый шаг по преодолению таких внутренних границ, потому что участвуют все. Кажется, что это достаточно банальная история, но для тех, кто объясняет scrum-процессы впервые, может стать непреодолимым препятствием; 

  • затем перевели фокус на другие две команды и начали ликвидировать провалы в них;

  • сейчас занимаемся командами, состоящими из сотрудников банка.

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

  Пара коротких кейсов

  В одной из команд при разработке и тестировании возник конфликт между тимлидом и senior джавистом (вендоры разные). Оба грамотные специалисты и ценные члены команды. Но разработчик не принимал требований по качеству продукта и подходам для унификации написания кода. В результате подыскали ему проект, где качество продукта не является критичным и повторяемость продукта не требуется. Грубо говоря, написал и забыл. После того, как перевели специалиста, производительность команды осталось на прежнем уровне, а микроклимат вырос. Сейчас мы закрыли эту позицию, и капасити команды поднялось ещё на 20%.

  Или вот ещё пример: DevOps не имел опыта работы с инфраструктурой банка и не привык работать без админских прав (был нанят до моего прихода), и это значительно замедляет вывод инкремента в прод до сих пор, хотя уже и не так сильно, как в первый раз. То есть работать всегда есть над чем.

  Как итог

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

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

  В последнее время у меня самого появилось время для управления (погружения в детали продуктов, планирования, контроля) проектами. Что уже сказывается на качестве выполняемых работ.

  Выводы 

  В банке высокая степень неопределённости и бюрократизированности, но это не делает IT-проекты в этой сфере менее творческими. Как и везде, требуется время и ресурсы на поиск и обучение хорошей команды. Надо постараться доверять и делегировать, допускать гипотезы, периодически снимать корону. Но главное, что вы должны помнить, встав на путь управления проектами в банке: работа должна приносить удовольствие. Как бы банально это ни звучало. Вот такой вот опыт управления проектами в банке у меня. Делитесь своим!