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