Уроки, извлеченные из создания команды Dropbox Paper
Наша отрасль постоянно в погоне за тем, кто работает лучше или быстрее, кто более продуктивен или креативен. Несомненно, важно иметь умных разработчиков, дизайнеров или мыслителей в команде. Но миф о гении, который работает в одиночку, месяцами изолирован в комнате, а затем приходит с идеальным решением, это просто... миф. Правда беспощадна. Выполнение отличной работы означает объединение групп талантливых людей и поиск путей, позволяющих им блистать, как команде. В Dropbox мы всегда думаем о том, как сделать наши команды успешными. И создание отдела развития (команды, которая отвечает за рост продукта) стало для Dropbox Paper хорошей возможностью. Не только потому, что формирование хорошо работающей команды требует времени и проведения итераций. Но также потому, что отдел развития должен разрабатывать специальные процессы, которые позволяют быстро определять, тестировать и подтверждать гипотезы. В процессе создания команды Paper мы определили две ключевые области для создания высокоэффективного отдела развития: 1) разработка процессов взаимодействия с различными дисциплинами в вашей команде и с другими командами; 2) быстрое движение без каких-либо проблем.
I. Развивайте коммуникацию внутри команды, а также выстраивайте отношения с другими командами
1. Взаимодействие разных дисциплин внутри вашей команды
В вашей команде, вероятно, есть довольно много дисциплин, с которыми вы, как дизайнер, ежедневно работаете: исследования, инженерия, маркетинг, UX копирайтинг, аналитика и многие другие. Чтобы сделать отличный продукт, важно взаимодействовать со всеми этими дисциплинами. Но пока давайте обратим внимание на два главных фактора роста: инжиниринг и продукт.
Хорошо работайте с разработкой
(или как дизайнеры роста могут обрести суперспособности) Хорошая работа с разработкой означает почти никогда не слышать: «Я ни за что не смогу это реализовать. Создай что-нибудь другое!». Если хотите наверняка услышать эти слова – действуйте, как «одинокий гений»: обдумайте проблему и придумайте дизайнерское решение самостоятельно или только с другими дизайнерами. Создав отдел Paper, мы поняли, что не можем допустить такого расхождения между разработкой и дизайном, если хотим быстро двигаться вперед. Нам нужно было вовлекать инженеров на ранних стадиях процесса проектирования и быть прозрачными в отношении рассматриваемых дизайнерских решений. В нашей повседневной работе это означает, что:
- Когда дизайнер начинает новый проект, он встречается с разработчиком, чтобы согласовать цели проекта. Они обсуждают основные сценарии проекта и важные технические ограничения.
- По мере того, как дизайнер начинает создавать различные варианты, он делится ими с разработчиком. Дизайнеры обычно добавляют к своей работе дизайн-документ, в котором изложены плюсы и минусы каждого варианта.
- Дизайнер также приглашает разработчика для критического анализа, чтобы они обдумали идеи, которые изучают для проекта.
Общение с разработчиками на протяжении всего процесса определенно помогает уменьшить нестыковки. Но это также помогает нам лучше работать, потому что:
- Разработчики привносят уникальный технический опыт в мышление продукта. Они указывают на крайние случаи, которые влияют на дизайн, и помогают сформировать обоснованное дизайнерское решение.
- Открытый диалог с инженером помогает нам определять качество эксперимента. Общаясь с инженерами, мы можем убедиться, что компромиссные дизайнерские решения, которые мы принимаем, не влияют на знания, которые мы хотим получить с помощью эксперимента.
- Работая над проблемой дизайна и формируя решение, разработчики инвестируют в проект и воодушевляются его созданием.
Работа с продуктом
(или как дизайнеру максимизировать свое влияние) Так же, как мы поддерживаем связь между дизайнерами и разработчиками, мы также следим за тем, чтобы дизайн способствовал планированию продукта. Есть две основные области, где дизайнеры поддерживают продукт. Во-первых, дизайнеры участвуют в разработке продуктов высокого уровня. Во-вторых, мы помогаем планировать индивидуальные эксперименты. Для продумывания продуктов высокого уровня дизайнеры предлагают новые области, в которых мы можем проводить эксперименты. На основе проектов, над которыми мы работали в прошлом, мы предлагаем новые или последующие эксперименты. И это делает работу лучше. Дизайнеры проявляют эмпатию к пользователям, поэтому мы можем выступать за проведение экспериментов, направленных на решение проблем пользователей, в дополнение к изменениям показателей. Когда дело доходит до отдельных экспериментов, дизайнеры помогают задавать цели для наших экспериментов. Мы делаем это, работая с продакт-менеджерами, чтобы определить гипотезы и прогнозы для каждого проекта. Как только мы начинаем работу по проектированию, мы делимся сгенерированными артефактами с нашими продакт-менеджерами: исследования, прототипы низкой и высокой детализации. Делиться работой на раннем этапе очень важно, потому что дизайн может повлиять или даже изменить цели, которые мы ставим для определенного проекта. Таким образом, дизайнеры, работающие в тесном сотрудничестве с продуктом, помогают убедиться, что:
- Эксперименты, которые мы проводим, направлены на решение реальных проблем пользователей.
- Дизайнеры никогда не получат спецификации продукта, не понимая смысла экспериментов, над которыми мы работаем.
- Когда мы начинаем работу над проектом и собираем новую информацию в процессе проектирования, мы соответствующим образом адаптируем наши экспериментальные цели.
2. Построение взаимоотношений с другими командами
Дизайнеру, важно хорошо работать с другими дисциплинами в вашей команде, но этого недостаточно. Уникальная проблема, с которой сталкивается отдел развития, заключается в том, что у него нет сферы, в которой он имеет собственный опыт. Это означает, что отдел развития должен развивать отношения с теми командами, в сфере деятельности которых он проводит эксперименты. Например, недавно мы провели эксперимент, в котором добавили информацию о Paper в обучении новых пользователей Dropbox. Для этого было важно иметь хорошие отношения с командой, работающей над обучением Dropbox. Сообщать о ценности определенного эксперимента другим командам может быть сложно. Один из используемых отделом развития Paper для этого подходов заключается в том, что мы пытаемся найти общий язык на основе общих целей наших команд. И способ сделать это – сосредоточиться на бизнесе и на пользователе.
- С точки зрения бизнеса, чтобы найти общие цели, мы стараемся ориентироваться на цели высокого уровня, которые есть у нашей организации или компании.
- На стороне пользователя мы фокусируемся на проблемах пользователей. Если в нашем эксперименте рассматриваются проблемы пользователей в плоскости, принадлежащей другой команде, эта команда будет рада поработать с нами, чтобы решить эту проблему.
II. Двигайтесь быстро, не ломайте вещи
Хорошие процессы для кросс-функциональной работы помогут вам создать эффективный отдел развития. Хорошо работать важно, но вам также нужно работать быстро. Отдел развития, которому требуется очень много времени для запуска экспериментов, вряд ли будет иметь успех по двум причинам:
- Во-первых, у команд развития есть четкие показатели, которые они пытаются улучшить. Если эти показатели не меняются, очевидно, что что-то не работает.
- Кроме того, развитие продукта почти всегда является непосредственным приоритетом для бизнеса. Если отдел развития не справляется с этим, значит, что-то не так с продуктом / целевым рынком или самим отделом, который выводит этот продукт на рынок.
Итак, есть еще один важный аспект, который необходимо учитывать при создании отдела развития. И именно так вы позволяете команде двигаться вперед с высокой скоростью, сохраняя при этом высокую планку по выпуску дизайнов отличного качества.
1. Как работать быстро
Мы, в Paper, поняли, что, если мы хотим учиться у наших пользователей с помощью экспериментов, нам нужно ускорить итерационные циклы. Так как мы хотели двигаться быстро, но при этом создавать великолепный опыт, это поставило вопрос о том, сколько лоска мы должны вкладывать в каждый эксперимент. Чтобы ответить на этот вопрос, мы решили, что вместо MVP – минимально жизнеспособного продукта, мы хотим создать MPP – минимально гордый продукт. Это означает, что мы пытаемся работать как можно быстрее, но когда мы запускаем что-то, мы хотим ответить «Да!» на два вопроса:
- Горжусь ли я, как дизайнер развития, созданным пользовательским интерфейсом?
- С инженерной стороны: гордится ли инженер тем, что он создал?
Поскольку в том, чем можно гордиться, есть очевидная субъективность, мы также определились с некоторыми объективными вещами, которые необходимы для проведения эксперимента – набор общих принципов качества эксперимента. Мы все согласны с тем, что эксперименты не должны быть доведены до ума на 100%. Но они должны быть опытом, который при небольшой «полировке» будет готов к релизу для всех пользователей. Эксперименты должны быть достаточно хороши, чтобы проверить гипотезы и сделать выводы, и почти достаточно хороши, чтобы уйти в релиз. 
2. Не ломайте вещи... или ломайте как можно меньше
Когда вы работаете быстро, все неизбежно сломается. В отделе развития Paper мы стараемся исправить все как можно скорее. Мы все признаем, что в большинстве случаев мы идем на компромисс, чтобы быстро продвигаться вперед и отправить эксперимент подгруппе наших пользователей. Поэтому, когда эксперимент успешен, мы выделяем время для исправления ошибок и улучшения пользовательского опыта. Даже, когда мы выделяем время на исправление, вполне вероятно, что мы будем пропускать или игнорировать ошибки, или несоответствия. Вот почему мы также устанавливаем время для периодического аудита сфер, где мы проводим много экспериментов. Мы все собираемся вместе: инженеры, продакт-менеджеры, копирайтеры, дизайнеры, исследователи –и мы пробуем и проводим стресс-тестирование нашего собственного продукта. Это позволяет нам убедиться в том, что: 1) наши эксперименты не конфликтуют друг с другом и, более того, что 2) эксперименты, которые мы запустили в определенных сферах, имеют смысл вместе, как сквозной пользовательский опыт.
III. Вывод
Развитие продукта – это всегда сложно. Когда вы собираетесь развивать продукт, который вам действительно нравится, то это может быть невероятно радостно, когда он работает, и очень сложно, когда это не так. Вот почему очень важно создать отличную команду для решения этой задачи. Мы считаем, что развитие тесного взаимодействия с людьми, с которыми вы работаете, и повышение скорости обучения – это два ключевых компонента. И, как настоящая команда, мы попробовали и проверили гипотезы методов собственной работы, и доработали наши процессы, чтобы добиться того, что мы имеем сегодня. Мы будем опираться на имеющиеся знания, чтобы бросить вызов и изменить наши рабочие процессы в поисках дальнейших улучшений. Если у вас есть какие-либо идеи о том, как улучшить работу отдела развития, пишите в комментариях! Мы будем рады узнать, что вы думаете! Спасибо Justin Tran за иллюстрацию, John Saito и Angela Gorden за фидбек, и всему отделу развития Dropbox Paper за вклад в написание этой статьи. Хотите больше статей от команды дизайнеров Dropbox? Подписывайтесь на наш блог, Twitter и Dribbble. Хотите творить волшебство вместе? У нас открыты вакансии!
Перевод статьи Liana Roxana Dumitru
Топ коментарі (0)