Сколько нужно кросс-функциональных команд, чтобы открыть один склад
В разработке всегда участвует много людей. Над одной фичей могут одновременно трудиться и веб-разработчики, и бэкендеры, и аналитики, и тестировщики и еще, и еще, и еще. А если все это разнообразие навыков реализовать в каждой отдельной команде? Здесь нам пригодится концепция кросс-функциональности.
Меня зовут Вика Плешкова, я руководитель IT PM в Lamoda Tech. В этой статье я хочу поделиться нашим опытом перехода к кросс-функциональным продуктовым командам — VTeams. А еще я расскажу, каких успехов мы добились на примере большого кейса по открытию второго склада.
Как мы работали до VTeams
Исторически в Lamoda Tech все разработчики были разделены по системным командам, у каждой из которых был свой отдельный бэклог. Все бы хорошо, но стоило прилететь задаче от внешних заказчиков из соседнего отдела, как все процессы начинали трещать. Как минимум задачи было очень сложно добавить в бэклог в связи с приоритезацией на уровне стейкхолдера: не совсем было понятно, когда она пойдет в работу.
А теперь представьте, какие большие проблемы начинались в тот момент, когда нам необходимо было реализовать кросс-функциональный проект. Приоритизация в каждом бэклоге работала по-своему, процессы во всех командах разнились. Когда мы хотели сложить эту картинку воедино, у нас получалась невероятно сложная схема.
В общем, отправной точкой для изменений стало то, что в компании наступили времена, когда начали превалировать кросс-функциональные проекты. Мы начали понимать, что сроки по ним абсолютно непредсказуемы, и стали думать о возможных изменениях, чтобы процесс стал для всех понятным, прозрачным, а главное — предсказуемым.
Мы не захотели выдумывать ничего нового, ведь все основные фреймворки управления кросс-функциональными командами уже известны и испытаны множеством других компаний. Решили внедрить один из наиболее популярных фреймворков компании Spotify, адаптируя его под наши потребности.
Переход на систему VTeams
Вдохновляемся Spotify
Суть истории Spotify в том, что с 2010 по 2012 годы команда разработки выросла в 8 раз — с 30 до 250 инженеров. И тогда компания провела длительный эксперимент, разрабатывая удобную модель управления продуктовой разработкой. Логика такова: команда раскладывается в матрицу, где по одной оси оказываются отряды (squad), по другой — гильдии (chapter).
Отряды объединяют разных специалистов под предводительством лидера (продакт-менеджера или продукт-овнера). И такая команда может решить почти все задачи воронки совсем или почти без привлечения дополнительной экспертизы со стороны.
Людей, которые работают в рамках одинаковой технологии, объединяют в горизонтальные команды — гильдии. Это нужно для того, чтобы каждый из этих сотрудников был взаимозаменяем (вдруг кто-то заболеет или уволится). А еще для того, чтобы все развивались и работали в едином стиле и при этом не накапливалось критическое количество технического долга.
Именно эту идею мы и взяли за основу своих VTeams (Virtual Teams).
Что такое VTeams в Lamoda Tech
VTeams — это кросс-функциональные команды, которые собираются для реализации определенной задачи: бизнесового стрима, продуктового или технического проекта. Команды разделяются по крупным направлениям — мы их называем Big VTeams. Внутри них уже могут формироваться отдельные команды, которые объединяются общей целью — бизнесовой или продуктовой.
В состав одной VTeam входят несколько специалистов, которые необходимы для реализации проекта или продуктового бэклога. Это может быть IТ РМ, продакт-менеджер, техлид, разработчики различных стеков, QA, системный аналитик, дизайнер, UX-researcher и другие роли.
А еще VTeams бывают продуктовыми и проектными.
Продуктовые VTeams строятся на основе единой продуктовой цели или бэклога из гипотез. Состав и приоритет бэклога может пересматриваться на протяжении жизненного цикла команды. Такие команды ориентированы на достижение продуктовых метрик: то есть им ставят цели на определенный срок и затем оценивают, насколько все справились с поставленными задачами. Например, продуктовой VTeam будет считаться команда навигации, которая занимается внедрением разнообразных фичей на сайте и в приложениях для улучшения пользовательского опыта.
В проектных VTeams бэклог основан на BRD (Business Requirements Document). Зачастую он фиксируется на весь жизненный цикл проекта или разбивается на фазы, где после каждой мы получаем определенные результаты. Например, проект по запуску второго склада — это четко очерченный скоуп, ограниченный бизнес-требованиями, и он будет выполняться проектной VTeam.
Что мы получили в итоге
Переход на систему VTeams позволил нам достичь прозрачности процессов и постановки целей. Она заключается в том, что заказчики знают, какой объем ресурсов у нас есть, а разработчики понимают, над чем они работают и к каким целям стремятся. Чтобы поддерживать эту прозрачность, мы внедрили ряд инструментов планирования и отчётности, а также проводим презентации для бизнес-заказчиков и ретро внутри команд. А еще отслеживаем, каких успехов команды достигли за предыдущие итерации.
Также у нас появилось сквозное квартальное планирование для всех бизнес-заказчиков. Для этого был внедрен единый скоринг проектов по ROI (Return On Investment), который позволяет нам грамотно распределять имеющиеся инициативы в порядке приоритетности и рассчитывать эффект, который мы ожидаем получить от работы команд.
Мы также гибко можем корректировать потребность в ресурсах в случае резких изменений. Единый план аллокации ресурсов по всем направлениям помогает оперативно отслеживать текущую загрузку и перераспределять их в случае необходимости.
И немаловажный момент — это единый процесс постановки пересогласования целей. Все цели наших продуктовых команд максимально прозрачны и наглядны как для команд, так и для стейкхолдеров и всех заинтересованных лиц, отображены в карточке VTeam.
Также мы добились прозрачности работы наших команд за счет того, что внедрили новые инструменты контроля статуса жизненного цикла. Теперь у нас есть единое место в Confluence, где в карточках собрана вся информация о каждой VTeam, их процессах, целях, жизненном цикле, рисках.
Карточка VTeam
Еще добавили отчеты VTeams, которые обновляются еженедельно. Там можно увидеть все основные показатели: статус достижения целей, ближайшие планы на спринт, итерацию или на квартал. Здесь же подсвечивается матрица рисков, чтобы было понятно, на что в первую очередь стоит обратить внимание.
Благодаря таким информативным отчетам, мы смогли изменить наш подход ко встречам. Вместо большого количества статусных встреч появилась еженедельная встреча, на которую собираются сразу все команды. Плюс такого шага в том, что заказчики к назначенному времени могут ознакомиться с отчетами и задать все интересующие вопросы. С учетом большого количества команд мы успеваем уложиться в час — это большое достижение, значительная экономия времени и повышение прозрачности работы.
Что касается метрик, то они подбираются и отслеживаются по каждой команде индивидуально. Мы фиксируем тренды изменений и наглядно видим, где у нас улучшения, а где возникают риски. Также наблюдаем за влиянием текучки кадров на каждую команду и можем вносить изменения в нашу стратегию найма.
Проект FC2: открываем второй склад
Чтобы лучше понять, как работают наши VTeams, я попросила Руслана Аскерова, тимлида команды PM Lamoda Tech, поделиться одним из крупных кейсов, над которым мы работали в прошлом году.
Изначально все процессы Lamoda были заточены под один склад. Кстати, о бизнес-процессах склада рассказывали в одной из наших статей. Но мы растем, поэтому со временем уперлись в его физические ограничения с точки зрения хранения товаров. Стало понятно, что нам нужны новые площади, несмотря на то, что мы постоянно расширяли действующий склад.
Появление второго склада означало, что нам придется внедрять мульти-складские решения и процессы. При этом нельзя было останавливать процессы текущего склада с ежедневной отгрузкой в 30–50 тысяч товаров. Такая задача ставила перед нами серьезные вызовы.
Во-первых, с точки зрения технологий, нам предстояло изменить более 10 систем, создать 3 новые, а еще внести изменения более чем в 20 сервисах.
Во-вторых, такой масштаб работ задействует огромное количество людей из разных IT-подразделений Lamoda Tech.
В-третьих, необходимо было унифицировать процессы, потому что до этого каждая команда работала по своим инструкциям.
К каждой задаче нужно было подходить поэтапно. Прежде всего мы выписали все процессы, которые так или иначе касались склада. Составив общую картину проекта, мы перешли к распределению ресурсов. Собрали проектную Big VTeam под названием FC2. Она состояла из 13 отдельных команд, каждая из которых отвечала за разработку своего WMS-сервиса или другой функциональности склада.
Inbound — сервисы, связанные с первичным товародвижением на складах.
WMS Core — сервисы для управления складами.
Customer Orders WMS — сервисы для сборки и отгрузки заказов.
Customer Orders — асинхронная модель обработки заказов.
Non-customer Orders — система управления неклиентскими заказами (например, для съемки на фотостудии).
Inventory — сервисы инвентаризации.
Automatisation — автоматизация складских процессов.
Returns WMS — сервисы для приема возвратов.
Returns — процессы доставки и возврата.
WMS Service DM Pool — сервисы для резервации и обмена DataMatrix-кодами.
Infrastructure FC2 — развертывание инфраструктуры для запуска склада.
Ручная консолидация — сервисы WMS для запуска без автоматизации.
Техдолг для запуска — доработка задач, не вошедших во все вышеперечисленные VTeams.
До каждой команды мы провели серию встреч, чтобы все участники понимали концепцию VTeam —, а это более 120 человек. В рамках встречи важно было выровняться в вопросах, как мы будем работать и каким образом пойдем к поставленным целям.
Первичное погружение было организовано со стороны лидов каждого направления разработки. Они приходили к бэкендерам, веб-разработчикам, аналитикам и другим ребятам и рассказывали о том, что такое VTeams, отвечали на вопросы, доносили ценность этого подхода. После этого мы организовывали встречи с участниками каждой отдельной VTeam — с системными аналитиками, разработчиками, тестировщиками, системными лидами, тимлидами, архитекторами. На них мы рассказывали, что конкретно необходимо сделать и обсуждали план-график.
Каждую VTeam контролировал один РМ. Все задачи мы вели и структурировали в Jira, чтобы было проще отслеживать процесс работы и видеть картину целиком: как работает конкретная команда, где какие задачи, какой у них статус, сколько времени потрачено на выполнение, где есть просадка и так далее. Также внутри команд соблюдались классические ритуалы: дейли-встречи с обсуждением задач, ретро после пары спринтов.
Все VTeams запускали свою функциональность по плану даже с учетом всех рисков. Всего у нас было четыре этапа: сначала мы запустили возвраты, потом клиентские заказы, за ними — первичное товародвижение, а потом сопутствующие процессы, связанные с транспортными компаниями, инвентаризацией и неклиентскими заказами.
У нас не было крупных провалов или срывов работы за все время реализации проекта — все работали слаженно и с уважением друг к другу. Конечно, были незначительные отставания на полторы-две недели. Были и переработки, когда ребята сидели ночами и правили баги. Так бывает всегда в рамках любого крупного и сложного проекта. А VTeams позволили быстрее и эффективнее решать проблемы такого рода, потому что мы понимали, где мы теряем при ребалансировке ресурсов.
Запуск и завершение работ в рамках FC2 показал высокую эффективность фреймворка. Мы запустили проект с нуля за 2 года. Если бы мы не использовали фреймворк VTeams, то у нас ушло бы еще минимум 6 месяцев на реализацию проекта, а также мы бы не смогли параллельно работать над 20 другими стримами по разным направлениям. Такой результат убедил нас, что нам следует придерживаться такого же подхода в построении процессов для работы над следующими большими и непростыми проектами.
Кому помогут кросс-функциональные команды
Создать и поддерживать эффективную работу нескольких кросс-функциональных команд сложно. Но если в следующих пунктах вы узнаете свою компанию, то, скорее всего, вам подойдет этот подход.
Вы работаете над созданием и развитием масштабного продукта или сервиса, который требует больших затрат с точки зрения бизнеса и стека технологий;
Вам нужно нужно действовать быстро, потому что любая задержка может привести к потере клиентов;
В своем продукте или сервисе вы научились разделять работу на фазы, каждой из которых соответствует бизнес-метрика, на которую можно влиять.
В целом, кросс-функциональные команды можно создавать в любом бизнесе, но нужно учесть некоторые важные моменты. Во-первых, команда может комфортно работать в этом формате только тогда, когда вся компания придерживается такого подхода. А во-вторых, подобная структура является более эффективной для компаний, достигших определенного уровня зрелости, когда линейные процессы перестают быть эффективными и не поддаются масштабированию.
