Для многих разработчиков, инженеров по автоматизации контроля качества и инженеров по надежности сайтов, участвующих в группах гибкой разработки, работа по доставке начинается с определения пользовательских историй и их выполнения в спринтах. Иногда пользовательская история требует «внутренней» реализации, такой как настройка интеграции данных, кодирование API микросервисов, устранение технической задолженности или повышение производительности приложений. Это все еще пользовательские истории, потому что их реализации обеспечивают ценность для бизнеса, но владелец продукта может указать целевой опыт пользователя с техническими критериями.

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

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

Истории пользователей Agile определяют формулировку проблемы

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

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

  • Кто заказчик или конечный пользователь?
  • Какую проблему или возможность необходимо решить?
  • Какие выгоды должна достичь реализация?
  • Почему это важно для покупателя?
  • Какие критерии приемки определяют «готово» для этой пользовательской истории?

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

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

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

Процесс дизайнерского мышления

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

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

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

  • Сочувствуйте клиентам в их потребностях и старайтесь идти на их месте.
  • Определите проблемы, возможности, ценности и факторы конкуренции, связанные с потребностями конечных пользователей.
  • Придумывайте различные сценарии, концепции и инновации
  • Прототипные потоки, разработка доказательства концепции или пилотный проект с небольшим пользовательским сегментом
  • Тестируйте решения, собирайте отзывы, делайте выводы и расставляйте приоритеты в областях улучшения

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

Проектирование и разработка продуктов, эпиков и функций

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

Меньше всего, чего хотят цифровые и технологические организации, – это разрозненный или конфликтующий процесс, когда специалисты по пользовательскому опыту и дизайнеры следуют методам дизайнерского мышления, а разработчики – независимому процессу схватки.

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

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

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

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

Сэнди Маккаррон, старший директор Moody’s Analytics, использовала дизайнерские спринты с инновационными командами. Она говорит: «Дизайн-спринты оказались для нас очень эффективными, когда у нас есть четкое представление об идее, но кросс-функциональные команды должны вносить свой вклад. Настоящая сила дизайнерского спринта заключается в небольших затратах времени и денег на подтверждение вашей догадки ».

Как гибкие фреймворки и инструменты способствуют дизайнерскому мышлению

Фреймворки Agile по-разному трактуют дизайн-мышление. SAFe предписывает три аспекта гибкой доставки продукта, с ориентацией на клиента и дизайнерским мышлением, ведущими к постепенной разработке и выпускам по запросу. Подход Института управления проектами к дизайн-мышлению в Agile заключается в том, что команды применяют дизайнерское мышление, чтобы сопереживать, определять и выдвигать идеи, а затем используют Agile для итеративного создания и доставки продукта. StarCIO Agile включает дизайн-мышление в практику непрерывного планирования, применяемую к продуктам, эпикам и функциям и определяемую по приоритетам междисциплинарными группами, в состав которых входят специалисты по взаимодействию с пользователем и специалисты по дизайну.

Выбор, интеграция и применение инструментов совместной работы между менеджментом продукта, дизайнерами, разработчиками, отделом контроля качества и ИТ-отделами также помогает установить клиентоориентированность. Рассмотрим такие инструменты, как:

  • Jira Align и Aha! которые помогают менеджерам по продуктам определять личности и дорожные карты
  • SurveyMonkey и Qualtrics для сбора отзывов клиентов
  • Balsamiq и InVision для моделирования и создания дизайнов
  • AccessiBe, AudioEye и UsableNet для проверки на соответствие стандартам доступности
  • Testlio, UserTesting и UXCam для тестирования пользовательского опыта
  • Jira Software, Asana и Monday.com за сбор требований и содействие процессу схватки.
  • Оптимизируйте и LaunchDarkly для отметка функции и A / B-тестирование
  • DataDog, Dynatrace, Micro Focus AppPulse Suite и ThousandEyes для мониторинга цифрового опыта

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

Авторские права © 2021 IDG Communications, Inc.


#Когда #включать #дизайнмышление #scrum

Source link