Как эффективно работать над продуктом? Четыре принципа из книги «It Doesn’t Have to Be Crazy at Work»

Евгений Эшану рассказал про принципы, которые помогут создать хороший продукт. Это перевод его статьи, цитаты взяты из книги «It Doesn’t Have to Be Crazy at Work».
Ян Австрейх
Редактор, технический писатель, переводчик

Дизайн-процесс: больше заморочек vs меньше заморочек

Если вы хотите создать что-то великое, нужно не тратить больше времени и ресурсов на решение проблемы, а меньше заниматься ерундой

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

Есть способ упростить процесс и сделать его более эффективным. Недавно я прочитал книгу ребят из Basecamp «It doesn’t Have to Be Crazy at Work», в которой они делятся практическими советами по управлению компанией, продуктом и командами. Я почерпнул из неё четыре принципа, которые помогут создать качественный продукт.

1. Найдите время спокойно обдумать идею

Реакция на чужую идею: «у нас нет ресурсов на это» vs «давай уделим время, чтобы всё обдумать»

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

Так бывает не всегда. Обычно кто-то быстро вскакивает с места и говорит, почему идея никогда не сработает. Это неправильно.

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

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

Почему не сэкономить время и не решить всё на месте?

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

Braintrust от Pixar

То, о чём я писал выше, очень похоже на метод Braintrust.

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

Braintrust — это совещание, на котором все делятся своими взглядами. Его цель в том, чтобы узнать разные точки зрения и обогатить вашу

На Braintrust нет руководителей и подчинённых. Это важно, потому что человек, который отвечает за проект, не обязан подчиниться мнению начальства. После Braintrust он сам должен решить, что делать дальше.

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

2. Трёх человек достаточно, чтобы создать продукт

Меньше команда — лучше продукт

В Basecamp используют отличный подход — работают над продуктом командой из трёх человек.

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

Этот подход можно использовать в компании любого масштаба, от стартапов до многомиллиардных корпораций. Его применяют не только ребята из Basecamp, но и сотрудники Nike — один из лучших продуктов Nike был создан тремя людьми. Сейчас я расскажу о нём.

HTM

HTM — это название экспериментального дизайн-проекта Nike, запущенного в 2002 году. Название состоит из первых букв имён его авторов: Хироши Фудзивары, Тинкера Хэтфилда и Марка Паркера (генеральный директор и дизайнер Nike).

В чём изюминка HTM?

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

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

Что если набрать команду из четырёх-пяти человек?

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

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

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

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

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

3. «Ничего не делать» может быть правильным решением

Не обязательно заставлять всех обновляться. Пусть люди используют версию продукта, которая им больше нравится

Люди не любят перемен, в том числе в продуктах. Им неприятно, если мы заставляем их пользоваться новой версией, когда они этого не хотели.

Допустим, вы работаете над V2 (новой версией) вашего продукта и собираетесь её выпустить. Что делать с теми, кому удобно пользоваться V1 и кто не хочет обновлений? Большинство компаний не принимают это во внимание, они думают: «V2 лучше, разве они могут не хотеть перейти на неё?»

Когда Basecamp работали над редизайном своего приложения, они остановились в середине процесса и спросили себя: «Что если люди привыкли к текущей версии и не хотят переходить на новую?». В их случае переход с V1 на V2 означал перенос данных, конвертирование форматов и работу с абсолютно новым интерфейсом.

Basecamp решили не менять версию насильно. Обновление было необязательным, пользователь мог остаться с V1, если она нравилась больше. Так компания сэкономила ресурсы и порадовала клиентов.

Иногда приходится бороться с очевидным. Приходится признать, что «улучшить» не всегда равно «принести пользу». Решить ничего не делать очень трудно, но это может быть лучшим вариантом

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

Когда они выпустили новую версию продукта, переход на неё был необязательным — переключиться на V2 можно было в любой удобный момент. Более того, можно было повышать и понижать версию, чтобы посмотреть, какая из них больше подходит. Дав человеку поиграться с программой, Freshbooks избавили его от стресса и сэкономили его время, в результате пользователь остался доволен.

Через две недели я перешёл на новую версию приложения. Прелесть в том, что это было моё решение, а не компании — у меня было время поиграть с V2, привыкнуть и убедиться, что она мне подходит.

4. Чтобы узнать, хорош продукт или нет, выпустите его на рынок

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

Если вы хотите узнать правду о том, хорош ли продукт, его нужно выпустить на рынок. Можно тестировать, проводить мозговые штурмы, спорить, опрашивать людей, но только выход на рынок покажет, утонете вы или поплывёте

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

Чтобы сэкономить ресурсы, лучше запустить продукт и посмотреть, как им будут пользоваться.

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

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

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

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

Ребята из Basecamp используют эту идею по полной. Они ничего не показывают клиентам до запуска продукта, не делают бета-тесты, не спрашивают людей, сколько те готовы заплатить и что думают о продукте. Они запускают продукт, и рынок скажет им правду.

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

Я говорил на эту с другом, он гейм-дизайнер. Мы обсуждали людей, которые разработали легендарные игры — они тоже двигались на ощупь и не были уверены, что проект удастся. Конечно, есть технологии, знания о психологии поведения, прошлые релизы, уже выученные ошибки и другие вещи, которые помогают не сесть в лужу. Но, пока вы не рискнёте выпустить продукт, вы не узнаете, будет ли он успешным.

Выводы

Не сводите себя с ума, работая над продуктом или функцией. Процесс будет легче и эффективнее, если следовать этим принципам:

  1. Продумайте идею;
  2. Работайте в команде из трёх человек;
  3. Помните, что иногда «ничего не делать» — лучший вариант;
  4. Исследования не дадут точных ответов. Выпустите продукт на рынок, посмотрите, как его приняли, и делайте выводы.

Обсуждение