Как трансформировать работу в команде, когда проект перерос определение «стартап»: опыт «Персея»
Что делать, когда возникают сложности из-за расширения команды, связанные с бесконечными планнингами, невовлечённостью и потерей контекста.
Мы уже рассказывали в нашем блоге об одном из передовых проектов «БКС Мир инвестиций» — «Персее», о главной идее и истории его создания, а также о новых разработках и внедрении полезных функций. Проект продолжает успешно развиваться: увеличивается число процессов и задач, расширяется команда. Возникают новые вызовы, требующие взвешенных и смелых решений.
Сейчас мы находимся на том этапе, когда можно оглянуться назад и посмотреть на историю проекта с точки зрения развития самой команды. Тем более, что опыт «Персея» может быть полезен и поучителен для других команд, следующих методологии 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, которая делает торговую систему.
Сейчас мы можем говорить о том, что благодаря трансформированию команды нам удалось оптимизировать разработку и решить все те задачи, с которыми столкнулись в начале пути. Но время бросает новые вызовы, и мы готовы двигаться дальше, чтобы искать оптимальные решения.
У БКС часто технические сбои случаются? Тинькофф с утра не работает, никакой официальной информации (пресс релиз) нет, в поддержке говорят ждите. Как с этим обстоят дела в БКС, есть ли некий SLA?
Илья, добрый день!
Со сложностями могут сталкиваться любые компании. Для наших клиентов мы поддерживаем и развиваем возможности получать поддержку во всевозможных каналах коммуникаций. Также, у нас есть такой уникальный сервис как финансовые советники, которые поддерживают связь с клиентами в удобной для них форме.
Комментарий недоступен
Мы такие крутые и передовые, что для закрытие ИИСа в 21 веке надо ехать в офис БКС
Василий, нет предела совершенству!
Комментарий удален модератором
Зачем мне как клиенту ваш Персей или глючный Пенькофф, если есть Interactive Brokers?
Добрый день!
Свобода выбора - то главное, что есть у каждого из нас в современном мире. Мы стремимся дать нашим клиентам лучший сервис и максимум возможностей для успешного инвестирования. Уверены, что и наши коллеги из других компаний исповедуют такой же подход. Выбор всегда за клиентом, и мы всегда искренне рады, если выбирают нас.
Комментарий удален модератором