Срыв сроков, рост дефектов, неконсистентый дизайн, переработки и выгорание команды — это реальность для всех крупных цифровых проектов. Хочу поделиться опытом построения производственного процесса, который мы применяем для создания интернет-банка Альфа Бизнес. У нас получилось. Мы уже увеличили сходимость бэклога с 45% до 95% и в целом смогли синхронизировать работу 100 команд, а это около 1000 инженеров.
В этой статье я расскажу про практики планирования, которые мы заимствовали из методолгии SAFe ©, но сперва представлюсь. Я занимаюсь созданием digital-сервисов 19 лет, с 2004 года. Начинал с собственной дизайн-студии, был Product Owner в Яндексе и Mail.ru (теперь VK), отвечал за создание B2B-экосистемы Сбербанка от ID и API до запуска и монетизации околобанковских сервисов, а сегодня развиваю digital-каналы (web, mobile, API) для юридических лиц в Альфе-Банке. Кажется, у меня было всё: интуитивная разработка, каноничный Waterfall по PMBok и, конечно же, Agile.
Чаще об этом я пишу в моём канале — подписывайтесь, если тема вам интересна.
Предыстория
Над развитием цифровых каналов для юридических лиц работает 100 команд и 1000 специалистов. Они разрабатывают 70 банковских продуктов и 20 платформенных сервисов. Весь функционал мы реализуем в трёх каналах: web, mobile app и API, и персонализируем его под свой сегмент бизнеса. Грубо это 7 000 релизов в год.
Бешеная скорость и доступная каждой команде DevOps-труба создавали массу проблем. Общая консистентность интернет-банка страдала, интерфейс варьировался от продукта к продукту. Время реализации крупных функциональных модулей постоянно увеличивалось. Количество ошибок в продакшн-среде росло. Мы проводили много времени на встречах по синхронизации и часто переделывали функционал на этапе бизнес-приёмки, потому что изначально не было согласованного видения и из-за желания быстрее получить результат.
Копились проблемы в командах, стейкхолдеры были недовольны, менеджеры тушили пожары. Стало очевидно, что нужно что-то менять. Agile-подход и его манифест помогали нам во многих аспектах, но не решили ключевые проблемы. Мы начали строить производственный процесс под наши требования 2,5 года назад. В статье я сосредоточусь на наших подходах к планированию и синхронизации и расскажу о фреймворке, с которым мы ежедневно создаём продукты и сервисы.
Начнём с планирования
Большинство известных мне компаний, которые говорят об Agile и гибкости в разработке, по факту работают с длинными промежутками времени и каждые две недели планы не меняют. Да, мир очень изменчив. Toyota в начале 2000-ых представила стратегию на 10 лет, в 2012-м Apple показали стратегию на 5 лет. Twitter в 2020-м и AMD в 2021-м уже презентовали стратегию на 3 года. Кстати, в Альфе мы сейчас тоже планируем на 3 года.
Трёхлетние планы мы раскладываем на годовые дорожные карты, которые лишь незначительно корректируются. И это нормально: если каждое подразделение будет менять дорожные карты, они разойдутся с общей стратегией компании, и мы не оправдаем ожидания рынка и акционеров.
Сфокусируемся на непосредственном планировании внутри года. Наша задача — реализовать дорожную карту качественно, а не закрыть задачи формально.
В конце года мы разбиваем годовые дорожные карты на квартальные эпики без глубокой детализации. Наша задача — равномерно распределить нагрузку на команды и учесть зависимости смежных команд.
А вот квартал мы планируем суперподробно. Этот процесс помогает нам синхронизировать сверхсложные инициативы и в нём задействованы все 100 команд.
Для квартального планирования мы выбрали подход PI Planning — Программное инкрементное планирование. Это кусок методологии SAFe (Scaled Agile Framework) для больших Agile-команд. У нас это мероприятие проходит в два дня. Собираются все команды и обсуждают планы, риски и зависимости. Каждая команда уходит с детальными планом, который согласован со всеми участниками и подкреплён общим пониманием цели — это суперважно в больших и разрозненных командах.
Например, мы сейчас работаем над реализацией режима работы «Холдинг» в интернет-банке — это режим, который позволяет в рамках одной функциональной области смотреть и работать с документами разных компаний. В инициативе задействовано 50 команд. Мы пересматривали информационную и системную архитектуру, планировали доработки ядровых продуктов банка и синхронизировали готовность компонентов для новых агрегирующих экранов дашбордов, для головных компаний.
На квартальное планирование Product Owner не может прийти с пустыми руками. Каждый спринт мы проводим сессии PBR (Product Backlog Refinement). У нас проходят две сессии PBR за спринт. Первый сосредоточен на задачах текущего спринта, второй — на задачах следующего квартала. Каждый ивент занимает 1-2 часа. Про PBR хорошо описал Роман Пичлер, упростив идею до тезиса: «Важность регулярного и эффективного планирования и уточнения продуктовой очереди не может быть переоценена. Это нужно для поддержания адаптивности и быстрой реакции на изменения». Так что берите на вооружение.
Нам регулярные сессии PBR помогают нормировать нагрузку команд при оценке задач следующего квартала. Без PBR мы бы просто не смогли выдержать возрастающую нагрузку в последние дни любого квартала.
Подготовка к PI Planing — особый процесс. Сначала мы использовали платформу GetCourse с обучающим материалом и контролем выполнения заданий, затем перешли на Telegram-бот. В конечном итоге просто сделали PDF-файл с расписанием PBR, инструкцией по декомпозиции задач и их оценке и шаблоны описания задач. Жаль, что найти простые решения сложно.
Вот наш подробный чек-лист подготовки к квартальному планированию. Под постом можно задать вопросы по нему.
Процессы планирования у нас лидируют скрам-мастера. Ребятам они помогают вписать подготовку к планированию в расписание спринтов, фасилитируют встречи по разбору бэклога, обучают методам оценки задач, помогают управлять зависимостями и готовят РО к защите квартальных целей. Без этой роли ни одно планирование бы не состоялось.
В общем, круто. Готов проработанный квартальный план. Теперь нужно наладить производственный такт. Мы выбрали канонические двухнедельные спринты. У меня простая цель: каждые две недели Product Owner должен показать полезный результат. Пропускать срок недопустимо. Это создаёт ритм подобно конвейерному производству. Звучит жёстко, но с большим количеством команд ритм очень помогает поддерживать высокий темп. Взаимосвязанные команды понимают, когда ожидать своего зависимого инкремента.
Публичность важна, чтобы постоянно выдавать полезные инкременты в рабочую среду. Представители команд каждые две недели на общем мероприятии демонстрируют друг другу, что они запустили. Стремление не оказаться тем, кто ничего не показывает, стимулирует более качественно планировать и грамотно разбивать большие инициативы на маленькие результаты. Этот элемент самоорганизации мне нравится больше всего, потому что его не нужно контролировать.
И что?
100 команд, каждая со своими индивидуальными целями, амбициями, опытом и насмотренностью, работают сообща над созданием единого интернет-банка. С марта 2022-го мы провели шесть квартальных планирований. Мы улучшили качество прогнозов и прозрачность. Вопросы вроде «Почему вы так мало взяли?» и «Что будет результатом?» исчезли из обсуждения.
Мы не изобретаем велосипеды и просто применяем проверенные рыночные фреймворки, такие как PI Planning и PBR. Основа нашего конвейера — единый производственный такт с элементами публичной самоорганизации. За последние пару лет мы прокачали сходимость бэклога с 45% до 95%. Это очень круто.
На этом про планирование все. В следующей статье (уже опубликована) расскажу какой фреймворк разработки продуктов мы используем и как. И конечно, приглашаю подписаться на мой telegram канал - OxParshikov. Там я чаще пишу чаще и на разные темы: от банковских продуктов, практик менеджмента до лайфхаков, которые помогают мне прокачивать свою продуктивность.