От монолитов к модульности команд

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

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



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

    Меня зовут Валерий, наша команда занималась QIWI Кошельком под iOS. Но всегда нужно было держать коммуникации с другими командами, иначе получался полный рассинхрон. Что касается наших неудобств, то бизнес всегда идет навстречу и дает свободу для экспериментов. Поэтому встал вопрос об изменении существующей структуры. Благоприятной средой для тестирования наших идей по изменению был скрам. Каждые две недели мы внутри платформы могли редактировать курс, чтобы это хоть как-то согласовывалось с другими командами. На проверку теорий давалось много времени. От месяца до полугода. Какие варианты мы перепробовали:

    Фича оунер


    Один человек из команды назначался ответственным за фичу на следующий спринт. Этот человек часть своего времени проводил с дизайнерами и с фича оунером из другой фронт-команды (бэк решил не использовать фич оунера), выясняя подводные камни и тонкости предстоящей работы, договаривался с бэкендом насчет контракта. А также следил за всеми изменениями бекенда и бизнеса. И вроде бы все хорошо. Никто не бегает в панике, кроме этого человека, который принимает удар переменчивой среды на себя. Все на мгновение умиротворились.

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

    Общие грумминги


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

    Чаты


    Одним из нестандартных вариантов было создание чатов. На каждую фичу создавался отдельный чат. Помимо этого были еще чаты команд, где обсуждались проблемы. А еще общий чат специально для проблем, где были все команды. Поначалу казалось, что проблема решена.

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



    Фича-тим


    Потом пришел продуктовик и предложил попробовать формат фича-тимы. Что это подразумевает: берется по два разработчика с каждой платформы (iOS, Android, web, backend) и два тестера) и формируется новая команда.

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

    Автономность
    Команда, которая вместе ходит на встречи, максимально независима от других. Главным связным от внешних зависимостей является продуктовик.

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

    Вся команда понимает, что такое «продуктовая разработка»
    Делаются фичи или прилетают бизнес-требования, а разработчик не всегда понимает, зачем, почему и кому это нужно.

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

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

    В итоге нам удалось достичь следующих плюсов:

    • Автономность от других команд.
    • Максимальная гибкая разработка, безболезненно можем поменять курс, если того требует ПО.
    • Быстрое и просто решение проблем.
    • Быстрая проверка теорий фич.

    Надеюсь, этот пример поможет вам в решении коммуникационных проблем среди команд. Если у вас есть другие крутые варианты, то жду фидбэк).

    Спасибо.

    А ещё у нас скоро будет митап для iOS-разработчиков.
    • +20
    • 2,8k
    • 8
    QIWI
    58,61
    Ведущий платёжный сервис нового поколения в России
    Поделиться публикацией

    Комментарии 8

      +1
      Просьба всегда в таких статьях обозначать одну очень важную вещь: все эти подходы работают в командах, где большинство разработчиков это самостоятельные боевые единицы и где концентрация джунов на уровне примесей, а не основное наполнение.
        0
        Тут вроде как по два разработчика. Один может быть джуном, а другой — нет. Другое дело, что делать, если второй заболеет…
          +1
          Да, так и есть. А вот насчет заболеет, то команда развивается в T-shape. В час нужды работа не встанет)
        +1
        Мне кажется, это очень близко к LeSS, разве что не упомянуты ретроспективы, дейли, sprint review из классического скрама
        Крутой формат, круто что получилось!
        Удачи в будущем, рассказывайте об опыте, неважно хороший или плохой)
          +1
          Спасибо. Да, будем держать в курсе наших экспериментов
          –1
          «всегда нужно держать коммуникации с другими командами, иначе получался полный рассинхрон».
          Советы по тимбилдингу от Qiwi. Хохотался.

          Повторю свой каммент недельной давности:
          Спросил у одного кивиста как продать им их же баг, из-за которого я не мог делать платежи. Он отослал к другому. Другой сказал, что это не профиль его отдела и они покупают только дыры в безопасности.
          На этом все. То есть кивистам пофигу на «командный дух» и что их соседи налажали.
          Вдобавок у меня заблокировали кошелек с 1200, хотя ИГИЛ и Навального я не спонсировал. У меня был абсолютно легальный базовый статус без верификации. А теперь qiwi незаконно ТРЕБУЮТ сделать полную верификацию и предоставить:
          – Договор с сотовым оператором
          – Фото с паспортом в руках
          – Экономическое обоснование операций
          Иначе они скрысят МОИ денежки.
            +1
            Приходи на митап продавать баги)
              –1
              Ага, а на входе светить свой паспорт, чтобы выписали пропуск. А там уже скажете: ну раз уж засветил, то давай и счет с 1200 заодно верифицируем.
              Хорошая попытка Qiwi, но нет.
              Лучше уж буду пописывать анонимно в вашем бложике.
              Проблемы с багами и «статусами» — не мои проблемы. И справляетесь вы с ними отвратно.

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

          Самое читаемое