Вы когда-либо сталкивались с ситуацией, когда мобильное приложение или веб-сервис напоминают лоскутное одеяло? Action-кнопки прыгают по экрану, навигационные паттерны неожиданно меняются, а дизайн элементов интерфейса разнится в частях проекта?

А теперь представьте, что вы не просто пользователь, а непосредственно участвуете в создании цифровых продуктов в роли PO, CPO или CTO. Тогда вы столкнётесь не только с несогласованным дизайном, но также с неуправляемым бэклогом (план против реальности), задержками выпуска новых версий и постоянными переделками уже реализованного функционала после выхода в продакшн.

Крупные цифровые проекты живут с подобными проблемами. Но у меня для вас хорошие новости: их можно решить. В статье я поделюсь опытом организации производственных процессов для 100 команд разработки, чтобы упорядочить этот хаос.

Я занимаюсь созданием 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%. Это очень круто.

Как мы делаем продукты

Но даже самое продуманное планирование не будет успешным без грамотного подхода к созданию продуктов. Мы взяли фреймворк Double Diamond. У подхода классная философия, которая в равной степени качает фазу исследования и проектирования и фазу разработки. Скажу сразу, мы немного затюнили подход под себя и у нас получился Triple Diamond.

Жиза до 

Многие делают так: когда появляется идея, мгновенно бросаются её реализовывать. У нас же Agile, мы же очень гибкие. Люди важнее документации, и каждые две недели можно переосмыслить текущие задачи. Но признайтесь, мы не хотим на старте вовлекать специалистов по безопасности или Enterprise-архитекторов: одни заставят интегрироваться со смежниками, другие найдут потенциальные векторы атак. Product Owner’у на порядок проще быстро описать задачу, передать дизайнерам и уже в процессе разбираться со всеми тонкостями.

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

Что в итоге?

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

Дофаминовая ловушка

Я считаю, корень проблемы лежит глубже и связан с так называемой «дофаминовой ловушкой». Когда мы пропускаем или поверхностно подходим к этапу Discovery, мы делаем больше задач и демонстрируем внешнюю активность в отчётах, которые так любят в крупных компаниях. Однако долгосрочный результат всегда один: переработки, а иногда и полный откат функционала, например, из-за проблем с безопасностью.

Вот почему в крупных организациях так много MVP, а дорожные карты похожи на фабрику арбузов — зелёные снаружи, но красные внутри. У нас тоже так было, но мы пошли другим путем и инвестировали в Discovery, чтобы делать действительно качественно.

Discovery

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

На базе Double Diamond можно выстроить прекрасную коллаборацию всех, кто, создаёт продукт: от маркетинга, безопасников, архитекторов до QA. Discovery лидируют Product Owners, они собирают продуктовую команду, включают все компетенции, сформированные в рамках PBR.

Команда собирается или в Зуме или очно — у нас есть классная UX-лаборатория. Discovery стартует с воркшопов: команда продукта проектирует CJM — это карта последовательных шагов клиента к получению услуги. Под каждым шагом указываются не только цель, но и цитаты с жалобами или восторгом, так мы видим, насколько верными были наши решения.

На следующем шаге под каждую проблему генерируются идеи, как её решить. Здесь используем крутую технику из Design Sprint — How Might We. В итоге CJM превращается в Blueprint. CJM, Blueprint — это воркшопы, заимствованные из дизайн-мышления. 

Когда определена общая канва обновлённого пути клиента и лучшие идеи выбраны, мы переходим к дизайн-спринту. Опять же мы ничего не изобретали, а зашили в сердце Discovery лучшую практику из Google Ventures. Общий коллаборативный формат круто вовлекает разных участников из банка.

В результате у нас готов прототип, который валидируется на клиентах в той самой UX-лаборатории. Этот проработанный концепт далее показывается сотрудникам банка в формате Pitch Day.

Ключевой артефакт, который определяет готовность задачи к началу разработки — DoR (Definition of Ready). Это согласованный прозрачный набор критериев, чтобы все члены команды понимали, когда задача готова к переходу в следующую фазу жизненного цикла.

DoR вместе формируют участники Discovery. Он включает бизнес-ожидания, соответствие архитектуре, дизайн-системе, технологической стратегии, тестирование прототипа на клиентах. Артефактом готовности является постановка соответствующего чекбокса по каждой компетенции в Jira.

Что мы увидели через 1,5 года такой работы? Если команда проводит эталонный Discovery, ни о каких переделках нет речи. Команда или фокусируется на прокачке метрик, или уходит в разработку новой прорывной идеи.

Delivery: взяли Scrum, соблюдаем ритуалы

Выстраивая конвейер разработки, мы снова не стали ничего изобретать и взяли самые известные правила игры в мире Agile — фреймворк Scrum. Всё просто и понятно: веди бэклог и прорабатывай его на PBR, планируй работу итерациями, работай по спринтам, проводи ежедневные DSM, рефлексируй над ошибками на ретро. 

За процессами на Delivery у нас присматривают скрам-мастера. А ещё у них есть сакральная задача. Классные компетенции всегда в дефиците, а грамотных скрамов вообще днём с огнём не разыскать. 1,5 года назад, когда началось внедрение нового процесса, мы пошли на эксперимент и пропилотировали в банке командных скрам-мастеров, сокращённо КСМ. Это роль, которой наделяется член команды: разработчик, аналитик,QA или PO. 

КСМ обучается в банке и помогает поддерживать процессы в командах, а скрам-мастер менторит его. Конструкция помогает держать руку на пульсе и внедрять лучшие практики равномерно и контролируемо. Эффективно? Цифры говорят, что в командах с КСМ предсказуемость на 10-15% выше, чем в командах без КСМ. Поэтому мы развиваем эту практику и считаем её полезной.

Все работают по единому workflow 

Фундаментальной единицей Scrum является небольшая команда. Но если очень хочется масштабировать, то можно, правда? Тем более у нас была задача — повысить управляемость процессом на большом масштабе. А для этого нужно единообразие и синхронная работа команд. 

Мы сделали Scrum стандартом производства, внедрили единую статусную модель в Jira, оцифровали разработку на всех этапах и теперь без труда можем получить Helicopter view по всему циклу поставки. Мы видим, на каком этапе конвейера образуются очереди, оперативно чиним процесс, собираем метрики, можем сравнить данные за периоды и составить план улучшений. 

Единообразие позволяет сделать health check 

В конструкции Scrum есть такая штука как DoD. На первый взгляд, это простые условия готовности фичи, которые команда определяет достаточными для выкатки. 

Мы посмотрели на DoD шире и сделали его стандартом производственного процесса. Именно DoD не пропускает в прод фичи, которые не соответствуют стандартам каналов. Это означает, что готовность функционала проверяет не только QA, но и смежные компетенции: 

• Заказчики в банке принимают функционал на стадии тестирования

• Дизайн-лиды проверяют, что при реализации ничего не потеряли, и функционал вписывается в дизайн-систему

• Исследователи смотрят, чтобы вся критичная обратная связь была учтена

• Маркетинг, кибербезопаность и другие отделы проставляют согласование  

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

Rollout & Support 

Есть пара фаз, которые Diable Diamond затрагивает не полностью — это процесс выкатки в прод и сбор обратной связи. Поэтому мы дополнили классический «двойной алмаз» новой фазой или алмазом — Rollout & Support.

Да, мы любим лучшие практики и хотели бы отдать весь релизный цикл в руки команд, но мы обязаны бесперебойно обслуживать клиентов 24/7. Поэтому решили контролировать последнюю милю выхода в прод.

CI/CD автоматизирован через платформу — это как BPM, но для инженеров

Когда команда на этапе Delivery сделала всё для подготовки функционала к поставке, код отправляется в Альфа-платформу, мощный инструмент CI/CD. Платформа ведет задачу сквозь все технические проверки DoD: от анализа кодстайла, использования библиотек с помощью SonarQube до SAST (Static Application Security Testing) и проставляет технические согласования в Definition of Done (DoD) задачи.

Если все проверки пройдены, поток задач также через платформу попадает в отдел сопровождения. Наши администраторы балансируют процесс выкатки, учитывая смежные поставки, и обязательно проверяют соблюдение критериев DoD — от технических до согласования фичи бизнес-заказчиком.

Дополнительно на этой фазе мы используем подход Canary deployment c поэтапной раскаткой обновлений. Сначала новый функционал доступен небольшой группе пользователей. Если не возникает проблем, открываем его на всех пользователей. С этим подходом мы быстро выявляем и устраняем проблемы, не затрагивая всех пользователей системы.

Support или Тираж

Ключевая задача Тиража и отправная точка развития продукта — сбор и анализ обратной связи от пользователей. В нашем подходе мы используем систему оценки VoC (Voice of the Customer), чтобы точно понимать, как клиент воспринял решение.

Мы подробно изучаем продуктовые метрики, чтобы оценить внедрённый функционал и его влияние на ключевые показатели эффективности (KPI). Это концепция Lean UX и Agile с упором на итеративное развитие продукта, короткий цикл обратной связи рынка, постоянный анализ того, что говорят клиенты.

Собранные данные запускают новый цикл разработки, и команда возвращается к фазе Discovery. Так мы запускаем бесконечный цикл улучшений, адаптируясь под меняющиеся потребности пользователей, ситуацию на рынке и потребности бизнеса.

Нам нравится

А получилось? Да. За полтора года сходимость бэклога выросла с 45% до 95%, и это несмотря на то, что мы выросли в два раза. То есть у нас не только не выросла энтропия с ростом команд, но и выросло качество продукта. Только представьте, что у нас есть команды у которых 0 багов в продакшн. Оценка удовлетворённости клиентов VOC (наш аналог CSI) составляет 4,79 из 5. 

Мы сократили градус напряжения наших команд. Результат оценки удовлетворённости сотрудников у нас выше среднеотраслевого, мы кратно упростили онбординг сотрудников и главное — у нас появилось время на продуктовое развитие каналов. 

Можно ли прожить без этого? В маленьких командах да, но в масштабных проектах это базовая гигиена. 

Ребята, я недавно выступал на конференции на тему нашего производственного процесса и в поддержку этого выступления подготовил серию постов в своём Telegram-канале. Там можно найти ссылки на первоисточники, полезные материалы и отдельные слайды с практическими примерами, ну а вообще, в канале, можно просто почитать про банкинг, технологии, менеджмент, Web 3 и другие мои увлечения.

Надеюсь, вы узнали что-то полезное для себя. Пишите в комментариях вопросы и ваши способы упорядочивания хаоса.