От монолитов к модульности команд
Большие компании частенько печалятся от проблемы адаптируемости и маневренности. Точнее, почти от полного отсутствия и того, и другого.
Представьте: все платформенные команды заняты одной фичей, а у бизнеса появляется срочное требование сделать что-то другое или скорректировать уже разрабатываемый функционал. И в этот момент останавливается работа над одной фичей и начинается работа над другой. В следующий момент появляются уже новые требования от бизнеса, а фича так и остается недоделанной. Разработчики в обиде и бизнес страдает.
Вот еще ситуация: меняется API, нужно срочно бежать в отдел бэкенда узнавать подробности, потом обратно к фронтам (iOS / Android / web). Дальше, обсудив с фронтами свои корректировки, нужно идти обратно к бэку и говорить наши требования. Это очень изнуряло, терялось время команд, отдельного разработчика и нервы всех заинтересованных людей.
Меня зовут Валерий, наша команда занималась QIWI Кошельком под iOS. Но всегда нужно было держать коммуникации с другими командами, иначе получался полный рассинхрон. Что касается наших неудобств, то бизнес всегда идет навстречу и дает свободу для экспериментов. Поэтому встал вопрос об изменении существующей структуры. Благоприятной средой для тестирования наших идей по изменению был скрам. Каждые две недели мы внутри платформы могли редактировать курс, чтобы это хоть как-то согласовывалось с другими командами. На проверку теорий давалось много времени. От месяца до полугода. Какие варианты мы перепробовали:
Фича оунер
Один человек из команды назначался ответственным за фичу на следующий спринт. Этот человек часть своего времени проводил с дизайнерами и с фича оунером из другой фронт-команды (бэк решил не использовать фич оунера), выясняя подводные камни и тонкости предстоящей работы, договаривался с бэкендом насчет контракта. А также следил за всеми изменениями бекенда и бизнеса. И вроде бы все хорошо. Никто не бегает в панике, кроме этого человека, который принимает удар переменчивой среды на себя. Все на мгновение умиротворились.
Но счастье продолжалось ровно до тех пор, пока фича оунер не заболел точнехонько перед своим спринтом. И вся иллюзия умиротворения растворилась, а мы вернулись к тому, с чего начали.
Общие грумминги
Приглашали представителей разных платформ на грумминг одной платформенной команды. Стало чуть получше, но ребятам не нравилось (от слова совсем) сидеть на нескольких встречах подряд. Но главная причина — это изменяемость API и контрактов, изменение целей спринта, и хорошо, если это изменялось только в первый день спринта. Но обычно все равно изменения валились на протяжении всех двух недель. Итог — цели не выполнены, ребята перерабатывают, бизнес страдает.
Чаты
Одним из нестандартных вариантов было создание чатов. На каждую фичу создавался отдельный чат. Помимо этого были еще чаты команд, где обсуждались проблемы. А еще общий чат специально для проблем, где были все команды. Поначалу казалось, что проблема решена.
Но чаты быстро расплодились, и, сами понимаете, это стало обузой. При появлении проблемы стало непонятно, где искать информацию — то ли в чате по разделу профиля, то ли в чате по рефакторингу сетевого клиента или замене модуля информации пользователя. В итоге стало только еще более запутано. Опять пришлось бегать между отделами.
Фича-тим
Потом пришел продуктовик и предложил попробовать формат фича-тимы. Что это подразумевает: берется по два разработчика с каждой платформы (iOS, Android, web, backend) и два тестера) и формируется новая команда.
Такой подход должен был решить несколько главных проблем, помимо слаженности и быстроты выпуска релизов:
Автономность
Команда, которая вместе ходит на встречи, максимально независима от других. Главным связным от внешних зависимостей является продуктовик.
Быстрая проверка теорий
Ведь раньше вся команда кошелька делала какой-то новый функционал и случалось так, что этот самый крутой функционал не заходил пользователям. Получается, что вся разработка пилила никому не нужные вещи и бюджет уходил в никуда.
Вся команда понимает, что такое «продуктовая разработка»
Делаются фичи или прилетают бизнес-требования, а разработчик не всегда понимает, зачем, почему и кому это нужно.
Вся команда влияет на продукт. Вплоть до придумывания новых фичей
В итоге такой подход всем понравился, и на данный момент у нас 3 независимых команды, которые занимаются своими продуктовыми задачами. Теперь при изменении контракта не нужно бегать по отделам и искать ответственных, также нет необходимости в куче запутанных чатов, достаточно просто ткнуть рядом сидящего разработчика. Встречи проходят всей фичатимой, где сразу присутствуют представители всех платформ и QA.
Вопросы решаются на словах за пару минут и никто не испытывает прежней боли. Вдобавок еще одна большая польза для бизнеса — если вдруг фича не зашла пользователям, то потратится время только одной фича команды (на данный момент из трех), а не всей разработки, как это было раньше.
В итоге нам удалось достичь следующих плюсов:
- Автономность от других команд.
- Максимальная гибкая разработка, безболезненно можем поменять курс, если того требует ПО.
- Быстрое и просто решение проблем.
- Быстрая проверка теорий фич.
Надеюсь, этот пример поможет вам в решении коммуникационных проблем среди команд. Если у вас есть другие крутые варианты, то жду фидбэк)
Спасибо.
