Эмпирическая обратная связь определяет решение о развороте (pivot — это изменение бизнес-модели или стратегии развития компании) или продолжении инвестирования в фичи и централизованные дизайн-стандарты; управление повышает согласованность и автономность тестирования и реализации фич Agile-командами.
SAFe выступает за интеграцию Lean UX на всех уровнях масштабируемой разработки от потока создания ценности до Agile-команд. Кросс-функциональные Agile-команды ориентированы на решение, а не централизованы по функциям (программирование, тестирование и т.д.). Каждая Agile-команда может определять, создавать и тестировать и — при необходимости — внедрять элементы, представляющие ценность для решения.
Одним из краеугольных камней SAFe является децентрализация процесса принятия решений. В Lean UX это означает, что большинство решений должно приниматься как можно ближе к проблеме. Таким образом, внедрение функциональности Lean UX становится основной обязанностью каждой Agile-команды. Хотя экспертов по Lean UX, как правило, недостаточно для индивидуальной работы с Agile-командами, их должно быть достаточно, чтобы иметь прочные отношения с несколькими командами и быть как можно ближе к встраиванию в гибридную децентрализованную модель.
Дисциплина Lean UX и опыт Agile-команды являются жизненно важными составляющими для внедрения, совместного проектирования UX и децентрализованного принятия решений, необходимых при тестировании гипотез MMF.
Однако, чтобы устранить потенциальную нехватку согласованности и управляемости между компонентами решения, мы предлагаем создать небольшой централизованный центр экспертизы Lean UX (LUXCE) для каждого потока создания ценности. Обычно под руководством ведущего эксперта по UX, имеющего влияние во всем потоке создания ценности, LUXCE совместно определяет стандарты дизайна (например, библиотеки шаблонов, пользовательские элементы управления, принципы навигации, корпоративный брендинг, руководства по стилю и другое), которые внедряются как средства обеспечения UX во всем потоке создания ценности. Предоставляя Agile-командам ресурсы для поддержки децентрализованного принятия решений, они обеспечивают разработку новых фич, жизненно важных для внедрения Lean UX именно на уровне команд, в то время как LUXCE определяет согласованность продукта с различными смежниками.
Хотя каждый LUXCE работает в рамках потока создания ценности, при масштабировании Lean UX на уровень портфеля возникают дополнительные обязанности. Проще говоря, полный набор решений для портфеля должен работать как можно более согласованно. Каждый поток создания ценности должен обладать собственным LUXCE, обеспечивающим управление решениями и согласованность. Но для согласования портфелей организации необходим другой уровень управления. В таких ситуациях у организаций будет профессиональное сообщество Lean UX, ориентированное на портфолио (Community of Practice, CoP), для распространения стандартов брендинга и других соображений на уровне портфеля во всех решениях в сотрудничестве с LUXCE каждого потока создания ценности.
Перед PI-планированием дизайн Lean UX включается в расстановку экономических приоритетов кандидатов на реализацию в течение PI. С момента поступления Эпиков в состояние Воронка на Канбан Портфеля и до их внедрения LUXCE является ценным партнером владельцев Эпиков и Lean-управления портфелем (Lean Portfolio Management, LPM). Когда в рамках упрощенного финансового обоснования (Lean Business Case) исследуется гипотеза о результатах Эпика, эксперт Lean UX из LUXCE уточняет потребности пользователей, ориентируя работу на результат, а MVP — на гибкость.
Как только Эпик будет одобрен и достигнет бэклога на Канбан Портфеля, эксперты LUXCE проконсультируют по дальнейшей доработке Эпика в связанных фичах. Цель состоит в том, чтобы создать MMF, гипотезы о выгоде которых ясны, измеримы, поддаются проверке и могут вписываться в PI. Эта работа обеспечивает экономически взвешенный показатель «Сначала ценная короткая работа» (Weighted Short Job First, WSJF) для определения приоритетности Эпика по Канбан Портфеля. Затем мы можем установить приоритетность связанных с ним фич по сравнению с фичами других одобренных Эпиков в Бэклоге ART.
Перед началом PI-планирования (во время IP-итерации или ранее) крайне важно сообщить о приоритетных фичах, чтобы позволить поездам и командам начать планировать, как они будут реализовывать и проверять гипотезы с заказчиками самым простым способом. В преддверии мероприятия следует использовать практику Set-Based Design (SBD), которая как можно дольше в процессе разработки сохраняет гибкость требований и вариантов дизайна, и SAFe-принцип №3 – предполагать вариативность, сохранять варианты для разработки гипотез о выгоде для проверки на ранних этапах предстоящего PI. Эмпирические данные и обратная связь, которые они дают, будут постоянно использоваться при разработке совместных историй для реализации MMF. Прозрачность Канбан ART и четко определенный набор гипотез о выгоде могут быть спасти PI-планирование от катастрофы.
Артефакты дизайна Just-in-time, который разрабатывается на основе известных данных и текущих требований, а не на основе грубых предсказаний, необходимы для подготовки к PI-планированию, помогая объяснить контекст и ограничения, в которых работает система. Их уровень полировки будет отличаться в каждой команде, поезде, и фиче, в зависимости от лежащей в основе проблемы. Например, это зависит от зрелости команд и поезда, но артефакты могут включать базовые каркасы и рудиментарные конструкции, детализирующие клиентские пути. Это не означает, что команда должна разрабатывать все решение целиком. Вместо этого она должна сделать ровно столько, чтобы визуализировать способы просмотра гипотезы о выгоде и понимать, как ее проверить в рамках технических ограничений и ограничений пользователя. Это начало процесса совместного проектирования, который в дальнейшем послужит основой для разработки и оценки MMF. Это также дает возможность выявить, оспорить и сократить фичи, цели или гипотетические выгоды, которые недостаточно поняты.
Как и архитектурная полоса (Architectural Runway), дисциплина Lean UX, которую поддерживает LUXCE, имеет своего рода UX-полосу. Для быстрого продвижения необходимо включить гипотезы о преимуществах и MMF, подлежащие тестированию. Lean UX включают в себя создание систем проектирования, библиотек, руководств по стилю и шаблонов в качестве вспомогательных средств. LUXCE предоставляет эти системные рекомендации для экспертов по встраиваемому UX и Agile-команд по созданию нестандартных визуальных дизайнов и простых каркасов, которые можно быстро преобразовать в рабочие прототипы для тестирования с заказчиками. Если эти факторы Lean UX будут проигнорированы, полоса будет израсходована, а скорость реализации значимых циклов обратной связи будет снижена. Чтобы эксперты по Lean UX поддерживали работоспособность системы, не перегружая UX-полосу и не создавая проблем с обратной связью, жизненно важно, чтобы в Agile-командах были запланированы ресурсы на разработку UX-энейблеров.
После помощи в подготовке успешного PI-планирования, LUXCE предстоит сыграть еще одну важную роль во время самого этого мероприятия. Он должен быть полностью представлен для общения, консультаций, уточнения и планирования в соответствии с видением PI с Agile-командами, а также заинтересованными лицами от ART и бизнеса. Он должен координировать приоритетные фичи, гипотезы о преимуществах и минимально необходимые артефакты. Лидерство и управление продуктами определяют видение программы и бизнес-контекст; системная архитектура задает видение архитектуры. Руководителю LUXCE также необходимо сообщить о видении UX и объяснить, как оно дополняет стратегию. Чтобы наборы дизайна соответствовали техническим ограничениям и бизнес-результатам (и чтобы при этом не забывались потребности пользователей), крайне важно, чтобы обучаемые понимали, как бизнес-, техническое и пользовательское видения сочетаются друг с другом. Презентация видения должна проходить утром первого дня PI-планирования. Во время групповых совещаний эксперты по Lean UX должны быть доступны для консультаций с командами, с которыми они работают. Артефакты проектирования уже должны быть доведены до сведения и использоваться совместно. Но экспертам по Lean UX необходимо способствовать общему пониманию, ведя Agile-команды к совместному процессу проектирования, в котором они являются внутренними экспертами. В основные обязанности эксперта по Lean UX входят:
Эксперты LUXCE также играют важную роль в разработке результатов PI-планирования совместно с Agile-командами и поездами. PI-цели ориентированы на конечный результат, как и цели конечных пользователей в гипотезах выгоды. Чтобы выделить зависимости на уровне ART, включая средства поддержки пользовательского интерфейса, у LUXCE должно быть свое собственное место для зависимостей на доске планирования ART. Эксперты по Lean UX также могут решить эту проблему, будучи включенными в соответствующие Agile-команды. Их присутствие и вклад в PI-планирование жизненно важны для того, чтобы поезд успешно соответствовала своему общему видению.
LUXCE продолжает обслуживать Agile-команды и поезда в период реализации PI. Выступая в качестве ключевых заинтересованных лиц от LUXCE, отдельные эксперты по Lean UX также выступают в качестве внутренних консультантов в Agile-команды. Существует тонкий баланс между выполнением исследовательской работы для планирования предстоящих PI и работой точно в срок, связанной с разработкой текущей итерации. Общие бэклоги должны отражать все это, не приводя к “поэтапным итерациям”, поскольку эксперты по Lean UX могут работать на 1+ итераций раньше, чем разработка, поддерживая потребности команды точно в срок.
Поэтапные итерации и отдельные невыполненные работы создают мини-водопад и большее количество передач работы, чем оптимально или необходимо. Это не означает, что перед разработкой не нужно выполнять больше работы по UX. Но SAFe включает эту работу в обычный цикл итераций для повышения прозрачности и совместного проектирования с Agile-командой и экспертами LUXCE. В соответствии с дизайном, основанным на множествах вариантах, варианты будут устранены на первых нескольких итерациях, обучение и обратная связь на основе гипотез о выгоде возникают благодаря совместному проектированию и выполнению тестов. При взвешивании вариантов и описания историй для разработки и проверки гипотез о выгоде на ранних итерациях PI более поздние итерации могут учитывать обратную связь путем построения MMF. Во время PI-планирования важно выделить возможности встроенной эмпирической обратной связи для этого проекта, чтобы MMF — сборник совместных проектов и проверенных гипотез о выгоде — можно было выпустить для тестирования и наблюдения в процессе производства по запросу реальных пользователей.
Когда эмпирические данные становятся основой для разработки MMF ближе к концу PI (интегрируя обратную связь по крайней мере один раз за итерацию), в игру вступают средства Lean UX. Эффективная UX-полоса превращает UX-дизайн в командный вид спорта и снижает зависимость Agile-команды от результатов, зависящих от сроков. Требования, такие как пиксельный визуальный дизайн для каждого экрана, могут быстро стать узким местом при разработке. Agile-команды могут внести некоторые из этих изменений самостоятельно, как UX-нейблеры, позволяя им легче поддерживать установленные стандарты проектирования.
Другие результаты проектирования, которые считаются необходимыми (но которые вспомогательные средства не могут дополнить), поступают точно в срок и только по мере необходимости. Это сводит к минимуму потери при максимальном расширении возможностей и децентрализации процесса принятия решений. Освободившись от необходимости постоянно создавать проекты, идеальные для пикселей, эксперты по Lean UX теперь могут сосредоточиться на новых гипотезах о преимуществах, отзывах о ранее выпущенных MMF и постоянном совершенствовании средств поддержки UX. Затем эта работа планируется в следующем PI и устанавливается приоритетность по сравнению с другими работами в программе и невыполненными заданиями команды.
Ключом к масштабированию дисциплины Lean UX является то, что LUXCE необходимо сотрудничать с командами и обучать их во всех видах деятельности. Штатные эксперты по Lean UX должны участвовать в планировании итераций, уточнении бэклога, анализе итераций и ретроспективах. Их также необходимо привлекать к оценке. Добавляя свои точки зрения и делясь своей работой на ранних этапах, часто с Agile-командой, общее понимание и видение UX помогут устранить поздние обнаружения ограничений в функциональности и удобстве использования. В совокупности синхронизация циклов обратной связи и включение эмпирических пользовательских данных в MMF должны планироваться и выполняться на протяжении всего процесса PI, а не только в конце. Это удовлетворяет системный спрос и объединяет частые моменты обучения с эмпирическими данными о ценном, пригодном для использования продукте.