Вы читаете перевод статьи "10 things I learned from Jason Fried about Building Products". Над переводом работали: Ольга Жолудова и Ринат Шайхутдинов.
Мы с Джейком Кнаппом ведем подкаст о разработке продуктов (Product Breakfast Club Podcast). В десятом выпуске у нас был такой мощный гость, что впору закрывать передачу — потому что, кажется, по нашей теме больше нечего добавить. Директор и “продуктовый монстр”, выдающийся Джейсон Фрайд поделился своими секретами продуктового дизайна, и я вдруг понял, что почти все свои идеи я, так или иначе, почерпнул у него.
Когда Джейсон возглавлял 37 Signals (в дальнейшем Basecamp), он написал две книги: ReWork и Getting Real. Принципы, описанные в этих книгах, легли в основу наших работ: Джейк написал книгу Design Sprint, а я основал свою компанию AJ&Smart. В общем, Джейсон Фрайд здорово повлиял на нас и мы мечтали взять у него интервью.
Как же он оказался в нашем подкасте? Все началось с твита Джейсона, который потряс нежные умы дизайнеров:
Итерации возможны только когда продукт уже запущен. До релиза нет никаких итераций — вы просто создаете продукт. Даже если вы что-то меняете — это не итерации, это процесс разработки. Итерации начинаются, когда мы вносим изменения/улучшения в готовый продукт. Так что сначала ЗАПУСТИТЕ ПРОДУКТ, а потом работайте итерациями сколько угодно.
Заявление, мягко говоря, противоречивое и в Твиттере уже начались обсуждения по поводу необходимости тестирования, поэтому мы связались с Джейсоном и предложили обсудить все в подкасте. И — бойся своих желаний — несколько недель спустя мы уже болтаем в эфире!
1. Работать итерациями можно только над готовым продуктом
На протяжении своего жизненного цикла, продукт претерпевает тысячи изменений — крупных и мелких. Но с какого момента можно считать эти изменения “итерациями”? Джейсон считает, что пока продукт не выпущен, пока реальные люди не начнут использовать его в реальных ситуациях, все — теория.
Все правки, которые вносятся в неработающий, находящийся на стадии разработки продукт, а также все размышления на этот счет — все это гадание на кофейной гуще.
Первую настоящую обратную связь вы получите только от первых клиентов — это и есть основа, от которой можно отталкиваться при планировании дальнейших итераций.
Все это казалось мне правильным. Было непонятно одно: по логике Джейсона выходило, что польза от обратной связи до запуска сомнительна. В основе концепции Проектного спринта (Design Sprint) лежало как раз тестирование, поэтому нам было интересно разобраться в вопросе.
2. Тестирование не гарантия безопасности
Чтобы объяснить свою точку зрения, Джейсон рассказал историю из жизни Basecamp. Недавно они выпустили продукт, который вся команда уже использовала довольно долго.
Когда внутри Basecamp все были довольны продуктом, его выпустили на рынок, где он и провалился с треском.
Пользователи были недовольны, а ребята из Basecamp просто в шоке. Ведь их продукт устраивал, что же пошло не так?
Любое тестирование дает смоделированные результаты. Посмотреть на продукт и сказать, что думаешь, это не то же самое, что попользоваться продуктом и сказать, что думаешь. Это не скин в игре сменить — невозможно сымитировать напряжение, в котором пользователи работают с программой в реальной жизни. (По этой же причине не нужно спрашивать людей, сколько они готовы заплатить за ваш продукт).
Контекст решает. Продукт нельзя оценивать в изоляции. Кроме того, всегда есть риск, что “реальные истории”, под которые вы подстраиваете свой продукт, сильно преувеличены — если вообще не выдуманы.
Важен не только контекст пользователей, но и контекст разработчиков: насколько они “в теме” использования своего продукта?
Например, мы в Basecamp сами пользуемся своим продуктом, но если бы мы производили, скажем, медицинское оборудование, то вряд ли запускали бы продукт так легко и уверенно. В некоторых случаях без тестирования не обойтись, а в некоторых — не стоит заморачиваться. Всегда нужно взвешивать ценность тестирования и затраты на его проведение.
3. Учитывать затраты и ценность
Во всех сферах своей деятельности, команда Basecamp старается выявить действия, которые принесут значительную ценность, а также свести к минимуму задачи, которые всех тормозят. Они буквально “отжимают” все отвлекающие факторы: избавиться от бессмысленной работы для них, пожалуй, даже важнее, чем определить ценные задачи.
Тестирование улучшит продукт? Без сомнения. А добавит достаточно ценности, чтобы оправдать издержки? На этот вопрос команда Basecamp часто отвечает отрицательно. Если тестирование выявляет важные моменты в 5% случаев, то на остальные 95% время потрачено впустую.
Готовы ли они рискнуть и выпустить продукт, чтобы потом вносить правки на основании реального фидбэка? Конечно!
Невозможно с первой попытки создать идеальный продукт, а при таком подходе, благодаря сотням пользователей Basecamp, мы сразу получим качественную обратную связь.
4. Внести изменения в софт — проще простого
Программное обеспечение нужно постоянно итеративно улучшать.
В отличие от физических объектов (например, машин или часов), софт — штука очень гибкая.
Тут вообще нет такого понятия, как “законченный продукт”: софт можно улучшать постоянно.
Раньше изменения в софт вносились медленно и через кучу костылей. Приходилось использовать Filemaker Pro, чтобы выгрузить базу данных на AOL, и после успешного обновления сервера пользователям приходилось скачивать новую версию или переносить данные в индивидуальном порядке. Да, сейчас мы сами с трудом можем такое представить, но когда обновление софта — такое большое дело, дважды подумаешь, прежде чем выпускать обновления.
Сегодня ситуация в корне изменилась. Запустить обновление можно очень быстро, правки и улучшения иногда занимают считанные минуты, а обновление происходит практически автоматом — так что с технической точки зрения вас почти ничего не ограничивает.
5. Чем дольше просчитываете варианты, тем сильнее тормозите
Бесконечная “полировка” продукта — не повод откладывать релиз. Если у вас есть крепкая, взвешенная первая версия продукта (будь то продуктовая функция или статья на Medium), не нужно тратить время на просчет разных сценариев, это будет вас лишь тормозить. Чем больше вариантов вы просчитаете, тем меньше вероятность, что каждый из них произойдет.
Если вы начнете сомневаться в своей изначальной концепции, появится желание внедрить новые идеи — в результате запустится бесконечный цикл хаотичных доработок и попыток достичь согласованности и целостности. Вы будете все сильнее отклоняться от курса, не зная наверняка, как отнесутся к этому пользователи. Как говорит Джейсон: “Лучше начинать просчитывать варианты через полгода после релиза”.
Сегодня можно встретить кучу длиннющих кейсов о том, как какая-нибудь команда провела 8-месячный процесс редизайна по 7 разным дисциплинам и с участием 42 человек. В Basecamp не так: последний редизайн был сделан за 7 недель силами одного дизайнера. Так что это вопрос подхода.
6. Делать то, что срабатывает
Многие компании слепо гонятся за трендами: внедряют какие-то неприменимые стандарты, пытаются скопировать истории успеха Apple или Google. Очень важно трезво оценивать свой размер и статус и адаптировать наставления “менторов” рынка под свои реалии. Google, Apple, Netflix и Spotify — исключительные компании. Они располагают огромными ресурсами и редкая компания сравнится с ними по масштабу.
Еще бывает, что компания внедряет какой-нибудь новый инструмент или методику, не задумываясь о том, насколько это уместно в контексте их уникальной корпоративной культуры. А потом приходит новый тренд — и компания переключается на него. Короче, смыть и повторить 🙂 В итоге революционные методы не приносят, как правило, никаких выдающихся результатов.
Джейсон тщательно взвешивает все решения, связанные с управлением Basecamp: у ребят уже сформировался индивидуальный набор методик, которые точно сработают. Они применяют lean, работают 6-недельными циклами, часто выпускают обновления. Это означает, что любой проект в Basecamp (от идеи и до разработки) должен укладываться в цикл. Эти рамки, собственно, и определяют, что компания разрабатывает и как.
7. Беречь время и ресурсы команды
Самая главная задача — убедиться, что у сотрудников есть все условия для максимально эффективной работы.
Необходимо устранить любые стрессы и отвлекающие факторы.
Вот несколько принципов, которые помогают беречь время и ресурсы команды:
- Никакой работы в неурочные часы. Рабочий день длится 8 часов. Вы когда-нибудь летели через Атлантику без смартфона или книги? Тогда вы знаете, насколько это долго! Джейсон уверен, что работать надо часовыми отрезками, а более мелкие интервалы только снижают производительность труда. Зимой рабочая неделя в Basecamp длится 40 часов, а с мая по сентябрь — 32. 32 часа! Некогда терять время.
- В течение дня сотрудники занимаются своими задачами. Человеку требуется достаточно много времени, чтобы полностью погрузиться в задачу. Отвлекая специалистов от работы для выполнения других задач, вы теряете больше, чем выигрываете. Поэтому в Basecamp практически нет совещаний. Знаю, звучит невероятно, но у них все отлично.
- У сотрудников есть возможность перезарядиться в конце рабочего дня: заняться личными делами, выспаться, насладиться солнцем без чувства вины — и вернуться в офис отдохнувшими.
- Нет общих календарей. Каждый сотрудник — хозяин своего времени и коллеги это уважают. Никого не заставляют доделывать чужие хвосты.
Сам Джейсон — большой сторонник концентрации на одной задаче. Он работает с 12-дюймового ноутбука, и это уже не очень-то располагает к многозадачности. По его мнению, некоторые ограничения нужны и даже полезны, как для команды, так и для продукта. Когда у тебя не так уж много времени, приходится принимать решения быстро и не тратить ресурсы на предположения и догадки.
8. Принять решение и двигаться дальше
В 2016 году, в своем обращении к акционерам Джефф Безос рассказал о методе ускоренного принятия решений, который применяется в Amazon. Принцип называется “Не соглашаться и принимать” (“Disagree and Commit”). Кто-то из команды может выразить свое несогласие с тем или иным решением, и их аргументы обязательно будут учтены. Но когда решение утверждено, вся команда должна его принять.
В Basecamp такой же подход. Они принимают как данность, что любая функция, которую они добавят в продукт, считается приемлемой и в конце концов не будет играть решающей роли. Поэтому когда обсуждения затягиваются, специально назначенный человек принимает решение и вся команда движется дальше.
9. Нанять звездную команду не получится — стройте ее сами
Джейсон признает, что команда Basecamp — своеобразная, но оно того стоит. Они нанимают 2-3 человек в год: так с 2006 года их коллектив вырос с 12 до 56 человек. Сейчас вакансии заморожены — но не потому что работы мало, а потому что они подходят к пополнению команды очень осознанно.
У них свой подход к найму: они не переманивают звездных разработчиков из Airbnb, а скорее ищут недооцененные таланты с большим потенциалом. В подборе сотрудников участвуют также и “ветераны” компании. Так, со временем, Basecamp удалось построить (не нанять!) поистине звездную команду.
В среднем сотрудники работают в компании 5 лет — и это гораздо выше среднестатистических 18 месяцев в остальных компаниях. А, значит, безумные идеи о балансе работы и жизни действительно работают!
10. Как управлять продуктовой компанией
И напоследок, вот краткий список всех убеждений и принципов, на которых строится успех Basecamp:
- Доверяйте своей работе и хватит гадать на кофейной гуще. Делай по максимуму, запускай и верь в силу своей команды.
- Пусть команда будет маленькой как можно дольше. Маленькие команды мобильнее.
- Не ждите от людей сверхчеловеческих усилий. Заботьтесь о своих сотрудниках, обеспечьте возможности для роста и не перегружайте их сверхурочными.
- Вся суть компании в том, чтобы принимать решения и воплощать их в жизнь. Осознанно подходите к тому и к другому и умейте двигаться дальше.
- Тщательно планируйте. Ставьте реальные сроки, трезво оценивайте силы. Не перенапрягайте лишний раз свою команду.
- Определите, какие действия принесут значительный результат. Избавьтесь от всего остального. Сведите к минимуму отвлекающие факторы.
- Не внедряйте методики вслепую. Разберитесь, что сработает для вас.
Если у вас есть на примете какая-нибудь классная статья по UX и не только — скиньте нам ссылку, и мы будем рады над ней поработать.
Нас можно найти в Facebook: Ольга Жолудова и Ринат Шайхутдинов.