Привет, меня зовут Влад, я 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), но и на то, как прямо сейчас устроена та самая изначальная большая команда. Думаю, там будут отличные идеи по развитию, в уже существующей структуре.
Обязательно рассказывайте, что у вас получится в масштабировании мобильной разработки! Очень любопытно сравнить с нашим опытом.
