Совместное проектирование в agile-командах

Как интегрировать дизайн в методологию agile

Laura Daly Laura Daly
Просмотр тем

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

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

  • вовлечь всю команду в процесс разработки дизайна;
  • интегрировать дизайн в процесс разработки по методологии agile;
  • изучить клиентские предпочтения для более быстрого проведения тестирования и разработки идей.

Вопросы и ответы

В этих вопросах и ответах обсуждается ряд тем — от инструментов для дизайна до способов обработки пользовательских отзывов, используемых в Atlassian.

Вопрос 1. Дизайнеры и разработчики — это всегда разные люди? Сложно ли дизайнерам обходиться без базовых навыков программирования при повсеместном использовании HTML5 и современных техник реализации пользовательского интерфейса?

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

Вопрос 2. Участвуют ли в семинарах по дизайну люди, не входящие в группу разработчиков продукта, например, маркетологи?

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

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

Вопрос 3. Как вы убедили своих людей работать над эскизами, рисовать и придумывать идеи? Мне кажется, что PO и разработчики неохотно занимаются этой работой из-за страха или других причин.

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

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

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

Вопрос 4. Как вы вводите новых участников команды дизайна в курс дела?

Ответ 4. У нас есть вводный курс для всех новых участников команды дизайна. Он начинается со знакомства с дизайном в Atlassian, нашим процессом и методами работы с остальной командой разработчиков. Мы тщательно рассматриваем наши принципы разработки дизайна и показываем примеры их применения на практике. Есть тренировочные классы, позволяющие узнать больше о наших ресурсах по дизайну: об использовании типов клиентов, о руководствах по разработке дизайна Atlassian и о сборнике Playbook.

Кроме того, на первые несколько недель мы приставляем к новым дизайнерам куратора, который вводит их в курс дела и постепенно расширяет зону их ответственности.

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

Вопрос 5. Какие методы исследования клиентов вы считаете наиболее полезными? Полевые исследования, наблюдение, удобство использования, что-то другое?

Ответ 5. Я считаю, что все виды исследований клиентов полезны, просто на разных этапах проекта требуются разные типы исследований.

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

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

A/B тестирование, в свою очередь, — это отличный способ оценить, насколько эффективно ваше решение.

Вопрос 6. Какие инструменты используют дизайнеры в Atlassian?

Ответ 6. Для работы дизайнеры Atlassian используют правильный инструмент. Иногда это старомодные ручка и бумага, иногда HTML и CSS.

Для создания дизайна высокого качества большинство сотрудников используют Sketch, но также используется и пакет Adobe. Все элементы пользовательского интерфейса из библиотеки шаблонов Atlassian были созданы в виде векторных объектов, поэтому собрать базовый макет довольно просто. Для простого прототипирования используется InVision или Marvel, для более сложных взаимодействий применяются Framer Studio, Origami, Axure или рукописный код.

Кроме того, мы делаем тонну заметок на самоклеящихся листочках и магнитно-маркерных досках. :)

Вопрос 7. С какими проблемами вы сталкиваетесь, работая по гибкой методологии разработки?

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

Вопрос 8. Вы упомянули несколько способов сокращения количества документации. Какую форму документации вы поддерживаете? Или вы отказались от всей документации?

Ответ 8. Для обмена работой и сбора отзывов от более широкой команды мы используем Confluence. Стандартная страница будет содержать некоторую информацию о контексте проблемы, которую мы пытаемся решить, и ценность, которую дает предлагаемое решение. Для демонстрации решения на странице будут представлены фотографии эскизов, эталонные макеты или ссылки на прототипы. Люди будут добавлять комментарии и вопросы, а дизайнер будет публиковать обновленные версии дизайна по мере развития проекта. Это не совсем «ведение документации», это постоянно дорабатываемая страница, на которой собраны отзывы и ресурсы по разработке.

Вопрос 9. Как вы работаете над дизайном при распределенной работе, когда команда не находится в одном месте?

Ответ 9. Atlassian является транснациональной компанией, поэтому мы работаем с распределенными командами каждый день. В Jira Software у нас есть команды в Сиднее, Гданьске и Сайгоне, и мы всегда ищем способы преодоления этого разрыва. Очень помогают технологии: мы используем Hipchat для видеозвонков и обмена сообщениями, Confluence для публикации, обмена и комментирования работы, а Jira Software — для организации работы в целом. Но это не идеальный вариант, поскольку ничто не может заменить личное общение. При работе над ключевыми частями проекта мы стараемся собрать людей в одной комнате, если есть такая возможность. В противном случае хорошим правилом является активное общение с удаленными участниками команды и стремление делать все возможное, чтобы держать их в курсе дела.

Вопрос 10. Как вы контролируете и фильтруете «шум», который маскируется под «отзывы клиентов»?

Ответ 10. Мы получаем огромное количество отзывов от клиентов, и это здорово! У нас есть инструмент для работы с отзывами, который собирает комментарии пользователей и сохраняет их как задачи в проекте Jira Software. Первую часть своего дня я знакомлюсь с последними задачами за кружечкой кофе. По мере чтения комментариев я отмечаю появляющиеся общие темы или шаблоны и добавляю соответствующие метки для их группировки. С помощью этих меток я могу отфильтровать все отзывы, чтобы узнать, сколько людей сообщило о подобной проблеме. Затем, после определения шаблона, я могу передать эту проблему группе разработчиков продукта и указать конкретные случаи использования, которые мы можем решить.