Дизайн-процесс: больше заморочек vs меньше заморочек
Если вы хотите создать что-то великое, нужно не тратить больше времени и ресурсов на решение проблемы, а меньше заниматься ерундой
Я думал, технический прогресс поможет нам работать меньше, лучше и умнее. Но вышло наоборот: мы проводим кучу совещаний, собираем гигантские команды, тратим больше времени и ресурсов. В итоге много работы делается впустую.
Есть способ упростить процесс и сделать его более эффективным. Недавно я прочитал книгу ребят из Basecamp «It doesn’t Have to Be Crazy at Work», в которой они делятся практическими советами по управлению компанией, продуктом и командами. Я почерпнул из неё четыре принципа, которые помогут создать качественный продукт.
- Найдите время спокойно обдумать идею
Обычно, когда люди приходят с новыми идеями, они назначают совещание, приглашают туда тех, кто принимает решения, и презентуют свои мысли. Если никто не прервал сотрудника в первые две минуты и все загорелись, то компания будет работать над этим.
Так бывает не всегда. Обычно кто-то быстро вскакивает с места и говорит, почему идея никогда не сработает. Это неправильно.
Лучше организовать процесс по-другому. Перед совещанием выступающий должен записать идею на бумаге, это поможет ему структурировать свои мысли. Затем он даёт свои выкладки команде, чтобы те с ними познакомились. Никакой обратной связи, пусть просто прочитают, что написал их коллега. Тогда у людей появится время и они смогут спокойно всё обдумать.
На самом совещании никто не прерывает выступающего. Когда оно заканчивается, люди высказываются и дают обратную связь. Она должна быть основана на том, что сказал человек, и быть конструктивной, а не убивать идею. Затем после совещания все берут пару дней или недель на обдумывание, это поможет неспешно переварить всё, что они услышали.
Почему не сэкономить время и не решить всё на месте?
Когда вы собираетесь вместе и обсуждаете идею, у людей нет возможности подумать индивидуально. Такие встречи чаще всего заканчиваются спорами, в которых каждый тянет одеяло на себя и пытается отстоять своё мнение. Поэтому уделить время и подумать обо всём в одиночку — лучший вариант.
То, о чём я писал выше, очень похоже на метод Braintrust.
Его используют в компании Pixar при работе над новыми фильмами. Это совещание, на котором все должны забыть о должностях и дать искреннюю обратную связь человеку, который представляет идею.
На Braintrust нет руководителей и подчинённых. Это важно, потому что человек, который отвечает за проект, не обязан подчиниться мнению начальства. После Braintrust он сам должен решить, что делать дальше.
На таких совещаниях можно говорить честно и получается глубокого анализировать идеи. Braintrust доброжелательно, его цель — помочь. Все забывают о должностях и личных интересах, в этом разница между Braintrust и обычным совещанием: на совещаниях царит конкурентная среда, там люди сравнивают свою идею с чужими и устраивают споры.
QKOMP, [24.06.19 07:12]
- Трёх человек достаточно, чтобы создать продукт
Меньше команда — лучше продукт
В Basecamp используют отличный подход — работают над продуктом командой из трёх человек.
Обычно она состоит из двух программистов и одного дизайнера. С такой командой люди больше вовлечены в работу, тратят меньше ресурсов и им легче принимать решения: три человека быстрее придут к взаимопониманию, чем тридцать.
Этот подход можно использовать в компании любого масштаба, от стартапов до многомиллиардных корпораций. Его применяют не только ребята из Basecamp, но и сотрудники Nike — один из лучших продуктов Nike был создан тремя людьми. Сейчас я расскажу о нём.
HTM
HTM — это название экспериментального дизайн-проекта Nike, запущенного в 2002 году. Название состоит из первых букв имён его авторов: Хироши Фудзивары, Тинкера Хэтфилда и Марка Паркера (генеральный директор и дизайнер Nike).
В чём изюминка HTM?
Два дизайнера и один руководитель решили переосмыслить дизайн существующих продуктов, чтобы создать новый. Это фантастический пример того, как дизайнеры могут работать вместе с генеральным директором, а не просто получать от него указания.
В команде было всего три человека, поэтому у них получилось ускорить производственный процесс. Команда быстро переходила от разработки продукта к его выпуску, что раньше казалось невозможным в компаниях такого масштаба.
Что если набрать команду из четырёх-пяти человек?
Чем больше людей, тем больше заморочек. Если вы хотите упростить процесс, лишние люди будут мешать — большим командам нужен руководитель, без него им трудно саморегулироваться.
Втроём удобнее договариваться и обсуждать, маленькая команда может быстро сделать грандиозный проект. Им не придётся прерываться на совещания и ждать одобрений руководства. Будь в команде больше людей, это усложнило бы процесс.
С маленькой командой можно создать нечто великое, а в большой сделать это чертовски сложно. Работая втроём, вам придётся быть честными друг с другом и приходить к компромиссам. И, самое главное, между тремя людьми меньше недопониманий и им легче координировать работу
Втроём создать новый продукт или разработать функцию сложнее, чем в большой команде, но в этом вся прелесть ограничений.
Говорят, чтобы нарисовать хорошую картину, нужно взять холст побольше. Творческие люди знают, что это не так. Слишком большая свобода может привести к посредственности, ведь без границ нет стимула прорваться сквозь них. Если дать творческому человеку ограниченные ресурсы, он легко внедрит инновации и создаст нечто великое.
QKOMP, [24.06.19 07:13]
- «Ничего не делать» может быть правильным решением
Не обязательно заставлять всех обновляться. Пусть люди используют версию продукта, которая им больше нравится
Люди не любят перемен, в том числе в продуктах. Им неприятно, если мы заставляем их пользоваться новой версией, когда они этого не хотели.
Допустим, вы работаете над V2 (новой версией) вашего продукта и собираетесь её выпустить. Что делать с теми, кому удобно пользоваться V1 и кто не хочет обновлений? Большинство компаний не принимают это во внимание, они думают: «V2 лучше, разве они могут не хотеть перейти на неё?»
Когда Basecamp работали над редизайном своего приложения, они остановились в середине процесса и спросили себя: «Что если люди привыкли к текущей версии и не хотят переходить на новую?». В их случае переход с V1 на V2 означал перенос данных, конвертирование форматов и работу с абсолютно новым интерфейсом.
Basecamp решили не менять версию насильно. Обновление было необязательным, пользователь мог остаться с V1, если она нравилась больше. Так компания сэкономила ресурсы и порадовала клиентов.
Иногда приходится бороться с очевидным. Приходится признать, что “улучшить” не всегда равно “принести пользу”. Решить ничего не делать очень трудно, но это может быть лучшим вариантом
Не только Basecamp поняли это. Другой замечательный пример — Freshbooks, сервис автоматизации выставления счетов. Я давно пользуюсь им и смог ощутить на себе, почему не форсировать изменения — хороший выбор.
Когда они выпустили новую версию продукта, переход на неё был необязательным — переключиться на V2 можно было в любой удобный момент. Более того, можно было повышать и понижать версию, чтобы посмотреть, какая из них больше подходит. Дав человеку поиграться с программой, Freshbooks избавили его от стресса и сэкономили его время, в результате пользователь остался доволен.
Через две недели я перешёл на новую версию приложения. Прелесть в том, что это было моё решение, а не компании — у меня было время поиграть с V2, привыкнуть и убедиться, что она мне подходит.
QKOMP, [24.06.19 07:13]
- Чтобы узнать, хорош продукт или нет, выпустите его на рынок
Не тратьте время на кучу исследований и обсуждений. Создайте продукт, выпустите на рынок и смотрите, как его приняли
Если вы хотите узнать правду о том, хорош ли продукт, его нужно выпустить на рынок. Можно тестировать, проводить мозговые штурмы, спорить, опрашивать людей, но только выход на рынок покажет, утонете вы или поплывёте
В работе над продуктом легко утратить контроль и уделить проблемам больше внимания, чем планировалось: провести дополнительные тесты, ещё раз всё обсудить, вложить больше денег. Часто не хватает дисциплины, чтобы выпустить продукт в рамках бюджета и в срок.
Чтобы сэкономить ресурсы, лучше запустить продукт и посмотреть, как им будут пользоваться.
Мы много спорим, какие функции надо внедрить, чтобы дать клиенту то, что он хочет. Но узнать это получится, только когда продукт пройдёт проверку рынком — никакие опросы, пользовательские тестирования и исследования не расскажут заранее, хорош ли он.
Определитесь с идеей. Создайте продукт в небольшой команде в короткие сроки. Выпустите его рынок и смотрите, как его приняли
Этот принцип работает с фильмами, играми, музыкой и даже архитектурой. Вы не узнаете, понравится ли ваша работа людям, будут ли они её покупать и использовать, пока не выпустите её в свет. Можно пытаться предсказать это, сидя с командой в офисе, но так очень легко ошибиться.
Вы получите правильные ответы, только когда люди будут покупать или использовать ваш продукт в своей естественной среде и с собственной мотивацией. Все остальное — симуляция
Ребята из Basecamp используют эту идею по полной. Они ничего не показывают клиентам до запуска продукта, не делают бета-тесты, не спрашивают людей, сколько те готовы заплатить и что думают о продукте. Они запускают продукт, и рынок скажет им правду.
Вы можете что-то упустить, ошибиться в важных вещах, но это не главное. Риск будет в любом случае. Так зачем обсуждать, если можно создать продукт, запустить его и узнать всё от своих пользователей?
Я говорил на эту с другом, он гейм-дизайнер. Мы обсуждали людей, которые разработали легендарные игры — они тоже двигались на ощупь и не были уверены, что проект удастся. Конечно, есть технологии, знания о психологии поведения, прошлые релизы, уже выученные ошибки и другие вещи, которые помогают не сесть в лужу. Но, пока вы не рискнёте выпустить продукт, вы не узнаете, будет ли он успешным.
Выводы
Не сводите себя с ума, работая над продуктом или функцией. Процесс будет легче и эффективнее, если следовать этим принципам:
- Продумайте идею;
- Работайте в команде из трёх человек;
- Помните, что иногда «ничего не делать» — лучший вариант;
- Исследования не дадут точных ответов. Выпустите продукт на рынок, посмотрите, как его приняли, и делайте выводы.