БКС Мир инвестиций

Как трансформировать работу в команде, когда проект перерос определение «стартап»: опыт «Персея»

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

Мы уже рассказывали в нашем блоге об одном из передовых проектов «БКС Мир инвестиций» — «Персее», о главной идее и истории его создания, а также о новых разработках и внедрении полезных функций. Проект продолжает успешно развиваться: увеличивается число процессов и задач, расширяется команда. Возникают новые вызовы, требующие взвешенных и смелых решений.

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

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

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

На старте «Персея» любую строчку кода разработчик либо писал сам, либо ревьюил, при этом любой другой мог легко подключиться к задаче. Так делала половина команды.

Когда же система разрослась, появились отдельные модули, в которых многие никогда не работали. Поэтому и общий планнинг перестал быть эффективным.

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

И был ли на самом деле альтернативный путь?

Изначально мы рассматривали две концепции развития «Персея». В рамках первой предполагалось формирование 2-4-х абстрактных команд со своим набором задач, которые берутся из единого бэклога, своим flow, своим спринтом и отдельным стендапом. Но этот вариант решает половину проблем, в частности, разрастания команды, бесконечных планнингов и невовлеченности. Он упрощает процессы, но остается вопрос размытия контекста из-за того, что сама система стала большой.

К проблеме невовлеченности относились еще и трудности с онбордингом. Когда новый разработчик вливался в команду, ему приходилось постоянно заниматься разными вещами: например, сначала он делал работу по расчету VаR’а (Value-at-Risk, модель оценки инвестиционных рисков), в следующем спринте – по портфелю, потом из области OMS (Order Management System, специализированная комплексная система управления ордерами). Проходило четыре спринта, в течение которых ему постоянно давали маленькие задачи. При выполнении следующих задач он мог забывать предыдущие, в результате чего уровень погружения в отдельные домены у него оставался низким.

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

Для того, чтобы выделить домены, мы представили брокерский бизнес как комплекс областей, знакомых любому брокеру:

Эти области могут пересекаться частично или не пересекаться совсем; есть области, например, market data, которые пересекаются со всеми другими. Есть автономно существующие сервисные области, такие, как мобильное приложение. В процессе проработки концепции некоторые доменные области мы объединили, поскольку очень много задач возникает на стыке и ресурсов не так много – relations и advisory стали одной командой, отвечающей за клиентские отношения. Accounting и market data слились в команду портфеля, а задачи трейдинга взяла на себя отдельная команда OMS. Команда разработки мобильного приложения «Персея» слилась с подразделением, занимающимся мобильными приложениями для всего «Мира инвестиций» БКС. Но это уже другая история.

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

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

Мы не стали делать разные стендапы для команд, ограничив время общего митинга 20-30 минутами. Поскольку система единая, все комитят одну и ту же кодовую базу, большой позитив в том, что ребята знают о том, что делают другие. При этом у команд разные бэклоги, планнинги и приоритеты задач. Мы ввели процедуру грумминга бэклога, когда уточняем детали по задачам и багам, понимая, что сможем реализовать в следующем спринте, и пытаемся дать предварительные оценки. Появилась практика дежурства, когда выделенный человек в течение спринта делает работу по устранению багов и пожаров.

Команда проработала в экспериментальном режиме несколько спринтов, и на очередной ретроспективе был собран фидбэк. Мы выделили те самые «боли», послужившие исходной точкой наших преобразований, и попросили ребят оценить их текущее состояние:

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

Плюсы и минусы реализованной концепции

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

Самый главный минус – возникновение конфликтов в доменах. Условно говоря, разработчики могут делать разный функционал в один и тот же сервис, что может привести к конфликту. В основном это касается областей market data и клиентских отношений. И поскольку, несмотря на дробление, все работают в рамках одного большого проекта, такие вопросы старались решать оперативно, хотя это было сложно. По сути, пытаясь синхронизировать работу нескольких команд, мы сталкивались с огромными издержками по времени. Делать перекрестное ревью по коду между командами не всегда получалось в силу интенсивности потока задач. Следовали этому правилу через раз еще и по причине предпочтения комфорта идее тотального контроля. Но при этом понимая высокую стоимость ошибки, если интеграция не взлетит.

Сюда же относится ситуация с задачами в серой зоне, которые трудно отнести к какой-либо конкретной команде, поскольку каждая из них отвечает только за свой домен. Например, возникла задача поиска по позиции – необходимо найти всех клиентов, у которых в портфеле нет акций Сбербанка. Начался небольшой холивар: с одной стороны, это выглядит как история клиентских взаимоотношений и нужно искать конкретного клиента, к которому относится этот параметр. И очень много технических аспектов связано с клиентским доменом. С другой стороны, необходимо запустить поиск по позиции, а это относится уже к портфелю. Ситуация была довольно спорная, в итоге решили, что это будет делать команда CRM в силу меньшей загруженности на тот момент. Хотя по факту это скорее область команды портфеля. Таким образом, данный подход позволяет варьировать выбор.

Как это выглядит сейчас и что дальше

На настоящий момент у нас три команды, работающие по двухнедельным спринтам:

  • Команда клиентского портфеля. Скоро из более узкого сегмента «Персея» произойдет ее переход в область поддержки портфеля для всего «БКС Мира инвестиций».
  • Команда CRM и Аdvisory. Эта команда делает улучшения взаимоотношений с клиентами, в том числе логирование событий. В дальнейшем мы планируем сделать две части и, возможно, это повлечет за собой перестроение команды, поскольку будут отдельно выделены:

— клиентские триггеры, алёрты и общение. Например, клиенту нужна ребалансировка портфеля или у него появилась какая-нибудь нерекомендованная бумага – это мы ему будем показывать в виде уведомлений-алёртов;

— IPS, расчет VaR’а и составление финансового плана для клиента.

  • Команда OMS, которая делает торговую систему.

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

{ "author_name": "БКС Мир инвестиций", "author_type": "editor", "tags": [], "comments": 7, "likes": 0, "favorites": 33, "is_advertisement": false, "subsite_label": "bcs", "id": 185538, "is_wide": true, "is_ugc": false, "date": "Thu, 10 Dec 2020 11:02:31 +0300", "is_special": false }
0
7 комментариев
Популярные
По порядку
Написать комментарий...
0

У БКС часто технические сбои случаются? Тинькофф с утра не работает, никакой официальной информации (пресс релиз) нет, в поддержке говорят ждите. Как с этим обстоят дела в БКС, есть ли некий SLA?

Ответить
0

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

Ответить

Точный лолипоп

0

"Рабочий процесс по задачам мог растягиваться от 8 часов до двух дней, всем находиться в контексте было уже невозможно по объективным причинам." - вот это не дошло с 5-го раза. Рабочий процесс по задачам  - что это такое ? Всем находиться в контексте было не возможно - как это ?

P.S. Может нафиг этот бэклог, скрам и прочую ересь ? Может по классике, есть проект, план, время, ресурсы - работаем.

Ответить

Террористический череп

0

Мы такие крутые и передовые, что для закрытие ИИСа в 21 веке надо ехать в офис БКС

Ответить
0

Василий, нет предела совершенству! 

Ответить

Комментарий удален

0

Зачем мне как клиенту ваш Персей или глючный Пенькофф, если есть Interactive Brokers?

Ответить
0

Добрый день!
Свобода выбора - то главное, что есть у каждого из нас в современном мире. Мы стремимся дать нашим клиентам лучший сервис и максимум возможностей для успешного инвестирования. Уверены, что и наши коллеги из других компаний исповедуют такой же подход. Выбор всегда за клиентом, и мы всегда искренне рады, если выбирают нас.

Ответить

Комментарий удален

Комментарии

null