Agile - непростая задача для UX: Как с этим справляться?

Аннотация: Agile и UX успешно взаимодействуют между собой: когда руководство высоко ценит UX специалистов, которые в свою очередь являются компетентными и инициативными кадрами и проявляют лидерство.

Введение

Agile занял мир разработки программного обеспечения. В последние годы он стал самой популярной методикой разработки программного обеспечения. Развитие Agile имеет множество преимуществ: постепенный подход, способность изменять направление, основанное на обращении клиентов и заинтересованных сторон, короткие таймфреймы, которые помогают командам сосредоточиться.

Однако, методики Agile ориентированы на разработчиков. Они выросли из попыток программистов решить общие болевые точки, возникающие во время крупных проектов разработки программного обеспечения. Известно, что Agile Manifesto (все еще основной документ, определяющий принципы Agile) не включал UX специалистов, а также не учитывал время, ресурсы и исследования, которые нужны профессионалам UX для создания отличных дизайнов.

В рамках парадигмы Agile, вся команда работает над одними и теми же элементами проекта одновременно, чтобы избежать «самоустранения от участия в дальнейшем процессе» (т. е. Передать ее из одной команды в другую, по принципу каскадной модели). Работа выполнена в «спринте» - обычно 2-недельные периоды, когда команда фокусируется на определенных функциях, а затем движется дальше. В результате, дизайнеры находятся под огромным давлением, чтобы создавать, тестировать, совершенствовать и доставлять свои результаты нереально быстро, с небольшим погружением, которые соответствуют согласованным, ориентированным на пользователя дизайнам.

Нет ничего плохого в том, если вы хороший специалист UX, но не справляетесь с работой Agile в вашей компании. Это трудно.  Жесткий способ, с которым Agile часто реализуется в крупных организациях (как правило, с использованием Scrum или аналогичных методов), может сделать вещи еще более сложными. Двухнедельные спринты могут вызвать узкое видение ситуации проектной команды, которые могут быть настолько сосредоточены на определенной функции или user stories , что могут игнорировать крупномасштабные проблемы с продуктом и дизайном, такие как интеграция, консистенция многозначности или архитектура пользовательского интерфейса.

Однако все не потеряно! На протяжении многих лет мы говорили со многими профессионалами UX, которые работают в среде Agile, и многие из них не только выжили, но и процветали. Несколько общих тем возникли из разговоров с теми, кто успешно охватил гибкий рабочий процесс. Здесь нет схемы игры - большинство из них - это масштабные, стратегические и организационные факторы, которые отдельные игроки UX могут, в лучшем случае, контролировать только в умеренных количествах.

Когда Agile работает для UX дизайнеров, это связано с несколькими ключевыми факторами:

1. Менеджеры и руководство понимают ценность UX

Многочисленные успешные профессионалы Agile UX говорят, что менеджеры и руководство в своих компаниях «в теме» - они понимают, что такое UX, почему он ценен для процесса разработки продукта и как он обеспечивает ключевое конкурентное преимущество. Это еще один способ описания зрелости UX, концепция, которую мы долго обсуждали, является ключом к успеху UX (и, следовательно, успеху в бизнесе). Лица, принимающие решения в этих организациях, знают, что UX - это не просто дополнительный слой краски; скорее, это тщательный и ориентированный на пользователя подход к стратегии продукта, функциям, структуре, взаимодействию, контенту и эстетике. Эти менеджеры и руководство не просто просят дизайнеров UX взять функции и рабочие процессы пользователей, которые уже были решены остальной частью команды и сделать их красивыми; вместо этого они с самого начала приходят к UX дизайнеру , чтобы определить, как эти вещи должны работать.

В этих командах менеджеры также понимают, что для создания действительно ориентированных на пользователя продуктов, требуются исследования с пользователями, и что тип исследования должен выходить за рамки простого тестирования A / B (что не дает поведенческой информации, необходимой для понимания того, почему тот или иной проект работает).

Менеджеры и руководители этих организаций выражают неопределенность и понимают, что «бережливый» подход означает всегда выдвижение гипотез, тестирование и повторение идей продукта. Хорошие решения, которые необходимы разработчикам UX для их работы, требуют качественных методов исследования пользователей. В то время как организации, которые плохо интегрируют Agile и UX, часто пристрастны к количественным данным как к наиболее важным или наиболее убедительным доказательствам для принятия решений, в Agile-организациях, где UX процветает, менеджеры и руководство понимают, что качественные идеи столь же ценны, как и количественные идеи, и что команды изучают разные вещи из этих разных типов данных.

2. UX-специалисты проявляют лидерство

Хотя руководители и заинтересованные стороны, которые понимают и поддерживают UX, чрезвычайно важны, верно и обратное: UX дизайнеры , которые преуспевают в Agile-среде, демонстрируют лидерские качества. Они указывают на предположения о поведении пользователей, которые могут оказаться катастрофическими, если не вовсе ошибочными. Они уделяют время, для того чтобы помочь объяснить коллегам процесс и принципы UX, и почему они производят лучшие продукты. Они подталкивают своих коллег к тестированию удобства использования продукта, для того чтобы понять и наблюдать за пользователями. Они борются за время, затрачиваемое на исследование пользователей, и на разработку чего-то правильного. Профили UX, которые процветают в Agile, подталкивают команду к более широкой картине и ситуации, в которой люди будут использовать разрабатывающиеся, для них, продукты.

3. Гибкий процесс Agile

Agile изначально не был задуман как ряд правил и церемоний, он был изобретен как набор принципов, которыми руководствовались команды для достижения маневренности, или способности корректно реагировать на изменения вокруг них. Группа разработчиков, которая написала Agile Manifesto, поняла, что они потратили огромное количество времени и энергии на управление изменениями: изменение ожиданий заинтересованных сторон, изменение рыночных ландшафтов, изменение требований и т. д. Если изменение является постоянным, зачем пытаться бороться с ним? Создайте процесс, который учитывает это изменение, и рассматривает его не как хаос, а ожидаемый ввод.

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

К сожалению, традиционный процесс Scrum не подходит для UX, потому что UX первоначально не рассматривался в определении Scrum. Это технологически ориентированный процесс, ориентированный на небольшие независимые единицы работы (как правило, в виде user stories), которые имеют смысл с точки зрения компьютерной науки, но сложны с точки зрения пользователя.

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

UX работает хорошо, когда Agile-процесс не контролируется не строго. Если у организации есть сторонники Agile-process, которые устраивают скандал, если, например, UX дизайнер работает над проектами спринта до разработчиков, для людей специалистов UX становится очень сложно стать кем-то больше, чем "пиксель пушерами". Профессионалы UX, которые преуспевают в Agile, находятся в среде, в которой больше заботятся о том, чтобы вежливо откликаться на изменения, чем указывать на то, как долго может продолжаться stand-up meeting. Команды, которые хорошо используют UX, будут определять, как управлять задачами и user stories, чтобы UX успевал опередить производство и создать проверенные, исследованные и продуманные проекты.

4. UX-специалисты и разработчики,  являются частью одной и той же команды

Действующие команды Agile должны хорошо взаимодействовать между собой и иметь общее представление о том, каковы цели проекта (как большие, так и малые). UX-специалисты могут выйти за рамки "нажатия и передвижения пикселей", только если они являются ключевой частью команды. Когда UX организован как изолированное отделение, которое «консультируется» для различных групп продуктов, UX дизайнеры могут чувствовать совершенно разный уровень вовлечения в проект и могут испытывать трудности с доверием и общей позиции с членами основной команды.

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

Вывод

Трудно заставить UX и Agile работать вместе. И если вы UX дизайнер борющийся с Agile, знайте, вы не одни.

Типичные процессы Agile не учитывают время, ресурсы и область действия, которые нужны UX дизайнерам для разработки продуктов, ориентированных на пользователя. Несмотря на это, UX и Agile могут хорошо сосуществовать при условии, что:

• руководство организации понимает и поддерживает работу UX дизайнера
• UX специалисты демонстрируют лидерство и тратят время на информирование своих коллег
• рабочие процессы Agile достаточно гибкие, чтобы удовлетворить потребности UXа
• UX дизайнеры являются частью команды продукта, где они могут взаимодействовать в условиях уважения и взаимопонимания с разработчиками.