А как у других?
Мы тут недавно побывали в банке, который тоже уже несколько лет движется по пути Agile-трансформации и с удивлением обнаружили, что проблемы перед у ребят ну совершенно такие же, как и у нас - как перейти от 23 моно-команд к работе над продуктами и клиентскими сегментами, как измерять ценность, как приоритезировать беклог, как формировать стратегические цели, как получить автономность от стейкхолдеров. Так что обо всем по порядку. И заранее просим простить за качество фото, не было возможности получить другие материалы, только шпионская съемка)
Продукт и продуктовая команда
Все активности ребята делят на три группы: продукты, платформы, сервисы. Продукт, как и в нашем случае, коллеги определяют как то, что мы делаем для внешнего клиента, достаточного масштаба и у чего есть отдельный P&L (ура! совпало! смотрите нашу версию здесь).

Расходимся мы в критериях, что обязательно должна быть ИТ-часть (для нас продукты - не только ИТ и тут мы дальше коллег продвинулись) и потребность в быстром развитии (на наш взгляд это не критерий выделения продукта, а критерий включения продукта в программу Change).

Развитием продукта занимается продуктовая команда, которая состоит из 50 и более человек. Эти люди управляют полным циклом разработки, продвижения на рынок и продажи продукта. Внутри все сгруппированы в несколько фича-команд разработки и есть одна growth team (куда входит маркетинг, продвижение, иногда юристы или другие компетеции

Также в продукте есть тех лид и скрам-мастер. В целом структура внутри продукта выглядит как на слайде ниже (growth team не показана)
Обратите внимание, что команды сформированы максимально универсально и любая команда может реализовать любую фичу из беклога продукта. Они даже названы не по технологии (команда мобильного приложения, команда личный кабинет), а как ребята сами придумали

Так же обратите внимание, что никаких фича-оунеров во главе команд нет, команды напрямую общаются с одним и тем же владельцем продукта и он управляет их беклогом (о нем позже)

Если про роли разработчиков, маркетологов, владельцев продукта и скрам-мастеров нам более-менее все понятно, роль тех лида оказалась незнакомой, вот как ее себе видят коллеги:
И конечно наша любимая тема - метрики, продуктовые, не продуктовые, бизнесовые, еще какие-то. Вот вам метрики продукта. Все стильно и просто
Думаете у них с самого начала все так было задумано? Ничего подобного. Они как и мы с вами нарезали сначала 23 моно-продукта, как-то их сгруппировали и долго не знали как этим управлять, но совсем недавно решили переопределить, что считать продуктом, а что нет, пересмотреть подходы к разработке и оценке и внедрить LeSS (Large Scaled Scrum, такой фреймворк масштабирования). Причем такое решение принял совет директоров банка по собственной инициативе. Представляете? Мы - нет.

Совершенно новая история - как они достраивают свои пока еще недо-продукты до соответствия критериям "продуктовости". Для этого используется Feature Adoption Map
По горизонтали откладываются компетенции от нынешних к будущим, по вертикали - компоненты, которые потребуются в работе от самых частых (нужны каждый спринт) до самых редких (нужны раз в квартал и реже). Далее прямоугольником на пересечении компетенций и нужных компонент отмечается текущий объем команды (на картинке более темный прямоугольник SME account team - команда сегодня) и будущий (Digital SME - будущая конфигурация команды с большим набором компетенций)
Инструмены владельца продукта
Bладелец одного из таких комплексных банковских продуктов поделился с нами набором инструментов, которые он использует. Во-первых он говорит, что да, команды используют JIRA, но он никогда там не бывает, не знает что там есть и работает в обычной эселечке. Но в этой экселечке, народ, у него чистый космос!
Структура вкладок такая:

- Roadmap продукта с целями до конца следующего года. Может постоянно меняться, но горизонт всегда один
- Цели (квартальные, цели спринта).
- CJM полностью оцифрованный на каждом этапе воронки, начиная от заявки и анкеты
- Беклог продукта и скоринговая модель приоритезации
- Беклог спринта

Теперь по порядку. Вот так выглядит Roadmap. От общего к частному: фазы развития продукта, цели и метрики на каждой фазе, и потом уже фичи в последовательности разработки. Это история гибкая, может меняться, отвечает Владелец продукта за деньги, а не за выкатку фич, поэтому он прав, если есть деньги, неправ, если их нет.

Цели квартала и из них следующие напрямую цели спринта.
Boт беклог продукта. Он расписан по большим эпикам, не назначен еще как видите ни на какую команду, но зато приоритезирован по скоринговой модели (вверху есть критерии приоритезации с определенным весом). Владелец продукта комментирует: "Я должен быть всегда в состоянии объяснить любому сотруднику почему именно так расставлены приоритеты"
А вот беклог который уже в работе у команд. Обратите внимание, что обозначен тип задачи (бизнес-задачи это те, которые не требуют разработки).
Как насчет продуктовых метрик? Сколько угодно! Весь CJM полностью оцифрован и на каждом малейшем этапе воронки за каждый месяц собираются значения и наносятся на одну большую карту:
Платформы и сервисы
Но не одними продуктами жив этот банк). Если какой-то технологический компонент входит в 2 и более продукта (то есть нужен более чем одной продуктовой команде), его разработку выводят в отдельную платформенную команду. Вот примеры платформ этого банка (Думаю, вы найдете там знакомые слова ;)
Платформенные команды также имеют владельца платформы, тех лида, скрам-мастера. Команда сама выбирает себе методы организации работы - Scrum, Kanban или что-то еще, главное, чтобы соблюдались общие страндарты и требования релизной политики.

Отвечает команда платформы как и положено за две вещи - быстродействие и отказоустойчивость (понятно, что еще и безопасность, но коллеги акцентов на этом не делали, а еще банк называется :)

Важно, что команда платформы разрабатывает клиентские и прочие сервисы только в порядке исключения. Команды сами занимаются разработкой "бэкенда" - вы наверное заметили в составе продуктовой команды Siebel -разработчика. Задача платформенной команды сделать так, чтобы у всех разработчиков разных команд были четкие требования, которые предъявляются к готовому коду. Также она может проводить ревью кода, ну и инженерные практики тоже помогают вручную не отсматривать тысячи строк кода.

Команда платформы имеет один беклог, синхронизированный со всеми заинтересованными сторонами (продуктами и сервисами, которые от нее зависят).

Обратите внимание, обеспечить техническую возможность нескольким командам независимо друг от друга "лить код" на одну платформу - это тоже задача платформенной команды
Продукты, платформы, сервисы как и у нас группируются в сегменты, которыми управляют лидеры сегментов. В сегмент (например нам показывали сегмент SME) может входить например два продукта: "классический" и цифровой. Причем и в том и в другом выделяют создание различных каналов привлечения и сопровождения клиентов. Пример на картинке
Ну как вам? Круто? Сможем также?
Обсудим на гильдии ;).
Made on
Tilda