«Оседлать хаос»: Как 1000+ инженеров повысили сходимость бэклога до 95%. Часть 2

100 команд. Это 1000 инженеров, которые ежедневно развитивают 90 продуктов и сервисов интернет-банка. У каждой команды свои амбиции и насмотренность, своя скорость и опыт. Все они вместе генерируют более 7000 релизов в год. Это полный хаос, но мы смогли его оседлать и синхронизировать работу команды. В этой статье я хочу рассказать вам о производственном процессе, а точнее о практиках и подходах, которые мы в Альфа-банке выбрали для создания интернет-банка Альфа-бизнес.

Это уже вторая статья на тему производственного процесса, по этой ссылке вы можете найти первую публикацию с рассказом про практики планирования бэклога.

Пара слов обо мне: Я занимаюсь созданием digital-сервисов 19 лет, с 2004 года. Начинал с собственной дизайн-студии, был Product Owner в Яндексе и Mail. ru (теперь VK), отвечал за создание B2B-экосистемы Сбербанка от ID и API до запуска и монетизации околобанковских сервисов, а сегодня развиваю digital-каналы (web, mobile, API) для юридических лиц в Альфе-Банке. Чаще об этом я пишу в моём канале — подписывайтесь, если тема вам интересна.

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

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

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

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

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

Вот почему в крупных организациях так много MVP, а дорожные карты похожи на фабрику арбузов — зелёные снаружи, но красные внутри. У нас тоже так было, но мы пошли другим путем и инвестировали в 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, ни о каких переделках нет речи. Команда или фокусируется на прокачке метрик, или уходит в разработку новой прорывной идеи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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