Привет, меня зовут Влад, я iOS-разработчик в команде мобильной разработки Ozon.

У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей.

Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. Однако с ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше времени он может уделить каждому и меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать. 

Решение мы нашли в распределении команд по стримам. 

В этой статье расскажу как у нас организована работа для 30+ мобильных разработчиков и 14 QA: как мы планируем, делимся знаниями и что нам даёт этот подход.

Как распределена мобильная команда и с чего всё началось 

Началось всё с небольшой команды из нескольких iOS, Android и QA, вместе работающих над приложением.

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

Как устроены стримы

Каждый стрим — это отдельная продуктовая команда, состоящая из 3–6 человек (iOS, Android, QA), вместе работающих над одной задачей. Состав всегда фиксированный и не меняется от проекта к проекту. 

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

В общем и целом, лид организовывает работу своего стрима. Это даёт возможность каждой команде работать как самостоятельный юнит.

Вопросами архитектуры, скорости работы приложения и тому подобным занимается команда стрима платформы. Её курирует два лида, которые одновременно являются тимлидами всей iOS и Android–команды. 

Вопросами обновления приложений занимаются релиз-мастера. Это двое разработчиков (по одному на каждую платформу – iOS и Android), которые занимаются всем, что связано с обновлением: от создания релиз-кандидатов до исправления или делегирования релизных багов. У нас еженедельный цикл обновления, поэтому новые релиз-мастера назначаются каждую неделю.

Как мы планируем работу

У нас существует три типа планирования: 

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

• между всеми командами мобильной разработки; 

• внутри каждой команды.

Командное планирование с внутренними заказчиками

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

Лиды стримов самостоятельно планируют ресурсы своей команды, задачи и приоритеты с вертикалями. По новым задачам назначаются собрания, на которых встречаются: менеджер вертикали, фронт, бэк, мобильная разработка и дизайнеры. Все вместе разбираем дизайн, планируем реализацию, а потом прорабатываем контракт – то, как будут приходить данные с бэка, приступаем к разработке.

Планирование между командами

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

С приходом удалённой работы Lead Sync стали проводиться в формате видео–конференции, куда может прийти любой сотрудник. Своего рода политика открытости. 

Отдельно от Lead Sync проводим короткий Release Sync, где встречаются все причастные к обновлению: представители или лиды из продуктовых команд, команд Travel, Express, релиз-мастера, руководители QA и мобильной разработки. Вместе смотрим критичные баги, определяем, какие задачи идут в обновление, проверяем метрики. Release Sync также открыт для всех желающих. 

Из особенностей: команды Travel и Express – обособленные. У них свои внутренние заказчики, своё планирование задач и свой бэклог, но мы живём в одном приложении, поэтому релиз планируем все вместе.

Локальное планирование на уровне команды

Каждый разработчик пишет Daily Report в чат своего стрима: что удалось сделать вчера и что планирует сделать сегодня. Дополнительно может проводиться общий звонок, на котором лид рассказывает новости, а также проходит обсуждение статусов, рабочих вопросов или разбор новых задач.

Обмен знаниями между командами

С приходом удаленной работы основным способом шаринга знаний между командами стали: комментарии и обсуждения на merge request, переписки в чатах, общие звонки по рабочим вопросам, Lead Sync и Tech Talk.

Мы придерживаемся концепции: каждый разработчик проводит code review каждого. На практике, на свой merge request нужно получить два апрува. Если разрабатывается core–компонент, обязательно code review от кого-то из платформенного стрима, для всего остального один апрув нужен от своего стрима, а второй от любого разработчика из своей команды (iOS или Android). Такой подход позволяет получить code review с глубоким пониманием контекста и немного делиться знаниями между разработчиками. 

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

Эту проблему помогает решить Lead Sync, то есть шаринг знаний о проекте между лидами стримов. Остальное покрывает еженедельный Tech Talk , один для iOS, другой для Android-разработчиков основного приложения. 

На время удалённой работы Tech Talk проводим онлайн. На нём делимся новостями, рассказываем, что интересного сделали за последнее время, выступаем с докладами или обсуждаем новые технологии. 

Ещё проводим Mobile Demo, на котором менеджеры проектов презентуют разработанные фичи, отвечают на вопросы и собирают обратную связь. Это позволяет шарить знания о проекте между вертикалями и командами приложения для покупателей.

Что нам даёт распределение по стримам

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

Состав стрима – от 2–6 человек, (или по 1–2 тройки iOS+Android+QA), позволяет лиду уделять должное внимание каждому человеку из команды. При условии, что каждая пара iOS+Android работает одновременно над одной задачей, это даёт возможность прорабатывать весь поток задач от менеджеров вертикалей, а также качественно планировать и контролировать результат. 

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

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

Кому подходит схема масштабирования мобильной разработки по стримам

Тут в статье я рассказал о борьбе с проблемами масштабирования команды мобильной разработки – о нашем опыте, но не методологии. 

Для нас сработали стримы, три уровня планирования и ритуалы удалённого шаринга знаний. Если разобраться, то новая структура – это воспроизведение старой схемы, только в меньшем масштабе, с вариациями; не революционное изменение, но эволюционное. 

Пойдёте делить у себя одну большую команду мобильной разработки на несколько небольших, посмотрите не только на чужой опыт (вроде нашего в Ozon), но и на то, как прямо сейчас устроена та самая изначальная большая команда. Думаю, там будут отличные идеи по развитию, в уже существующей структуре. 

Обязательно рассказывайте, что у вас получится в масштабировании мобильной разработки! Очень любопытно сравнить с нашим опытом.