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

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

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

Сейчас мы находимся на том этапе, когда можно оглянуться назад и посмотреть на историю проекта с точки зрения развития самой команды. Тем более, что опыт «Персея» может быть полезен и поучителен для других команд, следующих методологии 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, которая делает торговую систему.

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

0
7 комментариев
Написать комментарий...
Илья Политов

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

Ответить
Развернуть ветку
БКС Мир инвестиций
Автор

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

Ответить
Развернуть ветку
Аккаунт удален

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

Ответить
Развернуть ветку
Василий Степанов

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

Ответить
Развернуть ветку
БКС Мир инвестиций
Автор

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

Ответить
Развернуть ветку

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

Развернуть ветку
Аккаунт отморожен

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

Ответить
Развернуть ветку
БКС Мир инвестиций
Автор

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

Ответить
Развернуть ветку

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

Развернуть ветку
4 комментария
Раскрывать всегда