Многие команды по разработке программного обеспечения прилагают большие усилия для эффективной интеграции дизайна в их Agile-процесс. Дизайнеры, которые не работают в тесном сотрудничестве с остальной частью команды, обычно создают дополнительные сложности для всех (в том числе и для самих себя) и могут становиться причиной пагубной разрозненности знаний внутри группы разработчиков продукта.
Мы в Atlassian ведем совместную работу, чтобы включить в процесс создания дизайна всю Agile-команду. Поскольку в процесс создания дизайна вовлечены все участники команды, мы получаем множество точек зрения на одну проблему и не полагаемся на документацию для обмена идеями. В этой презентации затрагиваются следующие темы.
- Вовлечение всей команды в разработку дизайна
- Интеграция дизайна в процесс разработки по методике Agile
- Изучение клиентских предпочтений для ускорения тестирования и разработки идей
Вопросы и ответы
В этих вопросах и ответах обсуждается ряд тем — от инструментов для дизайна до способов обработки пользовательских отзывов, используемых в Atlassian.
Вопрос 1. Дизайнеры и разработчики — это всегда разные люди? Сложно ли дизайнерам обходиться без базовых навыков программирования при повсеместном использовании HTML5 и современных методов реализации пользовательского интерфейса?
Ответ 1. Граница между дизайнерами и разработчиками становится размытой. В Atlassian есть дизайнеры, которые имеют опыт работы разработчиками, и есть те, что не могут написать ни строчки кода. У нас трудятся сильные визуальные дизайнеры, информационные архитекторы и исполнители. Каждый из них имеет свои сильные стороны, которые важно распознавать и использовать в команде.
Вопрос 2. Участвуют ли в семинарах по дизайну люди, не входящие в группу разработчиков продукта, например маркетологи?
Ответ 2. В наших семинарах обычно участвуют представители разных отраслей знания, но каждый из них участвует по определенной причине. Обычно здесь бывают менеджеры по продукту, технические специалисты и дизайнеры, но мы можем привлечь и представителей службы поддержки или отдела маркетинга, если они могут предложить другую точку зрения.
Семинары могут идти несколько дней, и это большой срок для одного события. Я люблю делиться программой заранее, чтобы люди знали, где они будут полезны, а где смогут отлучиться на несколько часов. Однако основная группа должна присутствовать все время.
Вопрос 3. Как вы убедили своих сотрудников работать над эскизами, рисовать и придумывать идеи? Мне кажется, что владельцы продукта и разработчики неохотно занимаются этой работой из-за страха или по другим причинам.
Ответ 3. Пугает уже сама необходимость делиться идеями с группой, но рисовать на публике может быть еще страшнее! Именно поэтому на данном этапе семинара я люблю разбивать большую группу на пары. Это избавляет от давления лежащего перед вами чистого листа. Кроме того, это позволяет людям обмениваться друг с другом идеями и поддерживает темп работы.
Я обнаружил, что после участия в одной из таких сессий всем становится комфортно работать с процессом и действительно нравится принимать в этом участие. В комнате всегда стоит гул. Все общаются на важные темы.
Не менее важно, чтобы все знали, что вам не нужно произведение искусства. Вам нужна только визуализация идеи. Это может быть эскиз интерфейса, схема или просто маркированный список — все, что поможет остальным участникам группы достичь понимания. Если идея зафиксирована на бумаге, вы также можете сохранить ее в качестве справочной информации после завершения семинара.
Вопрос 4. Как вы вводите новых участников команды дизайна в курс дела?
Ответ 4. У нас есть вводный курс для всех новых участников команды дизайна. Он начинается со знакомства с дизайном в Atlassian, нашим процессом и методами работы с остальной командой разработчиков. Мы тщательно рассматриваем наши принципы разработки дизайна и показываем примеры их применения на практике. Есть тренировочные занятия, позволяющие узнать больше о наших ресурсах по дизайну: об использовании типов клиентов, о руководствах по разработке дизайна Atlassian и о сборнике Playbook.
Кроме того, на первые несколько недель мы приставляем к новым дизайнерам куратора, который вводит их в курс дела и постепенно расширяет зону их ответственности.
Еще один способ ускорить работу новых дизайнеров — это привести их в течение первой недели на семинар. Для них это отличный способ встретиться с командой разработчиков и воочию увидеть, как мы работаем вместе. В первые несколько месяцев им нужно многому научиться, но семинар — это отличное место, чтобы подробно разобрать небольшую проблему и попытаться ее решить.
Вопрос 5. Какие методы изучения клиентов вы считаете наиболее полезными? Полевые исследования, наблюдение, проверка удобства использования или что-то другое?
Ответ 5. Я считаю, что все виды изучения клиентов полезны, просто на разных этапах проекта требуются разные типы исследований.
Например, в начале проекта вам нужно полностью понять проблему и контекст, в котором работают участники. Для этого очень полезны контекстные исследования: вы посещаете команду по месту работы и обсуждаете с ней процесс, каким образом проблема сказывается на ее работе и что ей требуется для повышения собственной эффективности. Очень полезно увидеть своими глазами, как участники пытаются решать задачи и с какими разочарованиями сталкиваются.
Тестирование пользователей и разговоры с клиентами отлично подходят в случаях, когда вы развили свои идеи немного дальше. Вы можете получить ценную аналитическую информацию, наблюдая за тем, как пользователи работают с простым прототипом, или просто побеседовав о предлагаемом решении.
Сплит-тестирование, в свою очередь, — это отличный способ оценить, насколько эффективно ваше решение.
Вопрос 6. Какие инструменты используют дизайнеры в Atlassian?
Ответ 6. Для работы дизайнеры Atlassian используют тот инструмент, который лучше всего подходит для решения задачи. Иногда это старомодные ручка и бумага, а иногда — HTML и CSS.
Для создания дизайна высокого качества большинство сотрудников используют Sketch, но также используется и пакет Adobe. Все элементы пользовательского интерфейса из библиотеки шаблонов Atlassian были созданы в виде векторных объектов, поэтому собрать базовый макет довольно просто. Для простого прототипирования используется InVision или Marvel, в то время как для более сложных взаимодействий применяются Framer Studio, Origami, Axure или рукописный код.
Кроме того, мы оставляем кучу заметок на самоклеящихся листочках и досках. :)
Вопрос 7. С какими проблемами вы сталкиваетесь в процессе разработки по методике Agile?
Ответ 7. Самая большая проблема — это научиться отпускать перфекционизм и вместо этого быстро поставлять результаты итерациями. Будучи дизайнером, вам всегда хочется делать качественную работу, однако нужно уметь предоставлять результат, готовый на 90 %, а затем улучшать его.
Вопрос 8. Вы упомянули несколько способов сокращения документации. Ведете ли вы документацию в какой-либо форме? Или вы полностью от этого отказались?
Ответ 8. Для обмена промежуточными результатами работы и сбора отзывов от более широкой команды мы используем Confluence. Стандартная страница содержит некоторую информацию о контексте проблемы, которую мы пытаемся решить, и сведения о ценности предлагаемого решения. Для демонстрации решения на странице используются фотографии эскизов, эталонные макеты или ссылки на прототипы. Пользователи добавляют комментарии и вопросы, а дизайнер публикует обновленные версии дизайна по мере развития проекта. Это не документация в привычном виде, а постоянно дорабатываемая страница, на которой собраны отзывы и ресурсы по разработке.
Вопрос 9. Как вы работаете над дизайном при распределенной работе, когда участники команды находятся далеко друг от друга?
Ответ 9. Atlassian является транснациональной компанией, поэтому мы работаем с распределенными командами каждый день. В Jira у нас есть команды в Сиднее, Гданьске и Сайгоне, и мы всегда ищем способы преодоления этого разрыва. В этом нам очень помогают технологии: мы используем HipChat для видеозвонков и обмена сообщениями, Confluence для публикации и комментирования результатов работы, а также обмена такими сведениями, а Jira — для организации работы в целом. Но это не идеальный вариант, поскольку ничто не может заменить личное общение. При работе над ключевыми частями проекта мы стараемся собрать людей в одной комнате, если есть такая возможность. Если нет, то лучше всего поддерживать активное общение с удаленными участниками команды и стараться делать все возможное, чтобы держать их в курсе дела.
Вопрос 10. Как вы контролируете и фильтруете «шум», который маскируется под «отзывы клиентов»?
Ответ 10. Мы получаем огромное количество отзывов от клиентов, и это здорово! У нас есть инструмент для работы с обратной связью, который собирает комментарии пользователей и сохраняет их как задачи в проекте Jira. В первой половине дня за чашкой кофе я знакомлюсь с последними задачами. По мере чтения комментариев я отмечаю общие темы или ситуации и добавляю соответствующие метки для их группировки. По этим меткам можно отфильтровать все отзывы, чтобы узнать, сколько людей сообщили о подобной проблеме. Затем, когда установлена некоторая закономерность, я могу передать эту проблему команде разработчиков продукта и указать конкретные примеры использования, для которых мы можем ее решить.
