С праздниками, друзья! Готовясь к началу нового рабочего года, мы завершаем серию материалов с конференции FrontTalks 2018. Это лекция Андрея Саломатина filipovskii_off — разработчика из компании Polychops. Андрей предлагает сбалансированный подход к прототипированию: чтобы из ремесленников, которые выполняют заказы, превратиться в исследователей — научиться работать с неопределённостью и, возможно, сохранить рассудок даже без четкого плана.
— Всем привет! Я хотел бы поговорить о прототипировании: зачем делать прототипы, что мы от этого получаем и как их делать, на примерах.
Начну с небольшой истории. В 2012 году я присоединился к этому стартапу, замечательному оленю. У нас было нечто вроде рекламной платформы, я пришел как Java-разработчик. Понятно, что большие объемы трафика, интересные задачи, команда просто чумовая — все замечательно. Мы работаем примерно восемь месяцев, положа головы на клавиатуры, делаем очень крутые фичи, быстро все проворачиваем. Но в 2013 году олень идет вверх копытами.
Что произошло? Я очень долго об этом думал, впоследствии пошел работать разработчиком фронтенда и бэкенда в разные компании, потом был тимлидом, потом продакт-менеджером. Работал как в стартапах, так и в аутсорс-компаниях, в больших энтерпрайзах. В основном фокусировался на стартапах.
Также я делал некоторые из этих проектов. Мне посчастливилось работать над MoscowJS, Frontend Union Conf и RadioJS. Может, мы где-то там с вами пересекались. Сейчас я делаю Code Podcast, подкаст на английском языке об общих концепциях в программировании, и Polychops, проект для музыкантов, который работает в браузере и помогает вам практиковаться с инструментом, получать больше времени и практики.
Что случилось с HeyMoose? В компании были очень умные люди, которые сейчас работают senior-девелоперами в Microsoft или стали СТО. Мы делали то, что у нас получалось лучше всего: решали сложные технические задачи быстро и интересно. Но что-то пошло не так.
И что-то идет не так с большим количеством компаний, особенно стартапов. Стартапы в основном выгорают по двум причинам: либо не понимают продукт, где-то промахиваются с продуктом, либо у них заканчиваются деньги. Очень часто у них заканчиваются деньги, потому что они ищут продукт и не могут его найти достаточно долго.
Но почему заказная разработка в аутсорс-компаниях не закрывается? Или почему большие энтерпрайзы не закрываются? Кажется, они работают медленнее. Как правило, команды там по крайней мере слабее мотивированы. В чем разница? Механизмы работы одни и те же: в заказной разработке мы пишем ТЗ или просим ТЗ у заказчиков, они нам его расписывают, отдают, мы делаем макеты, код, ши́пим — такой же процесс. Что в стартапе, что в больших компаниях могут быть эджайл-практики. Все одно и то же. Так почему стартапы выгорают?
Давайте сначала представим гипотетическую ситуацию: к нам приходит менеджер продукта и спрашивает, можем ли мы забабахать метроном, который будет работать в браузере, издавать звук с периодическим интервалом и синхронной визуализацией, чтобы разные огоньки сверкали в темпе с метрономом один в один. И чтобы все это было точно, независимо от происходящего на компьютере, других процессов и т. д.
Кто на 100% уверен, что мы можем это сделать средствами браузера и средствами API браузера? Ни одного человека. Кто уверен на 80%, что мы, наверное, можем это сделать? 3–4 руки. Кто уверен 50 на 50? Большинство. Кто уверен, что мы вообще никак не можем этого сделать? Порядочно.
Следующий пример. Допустим, мы работаем в другой компании над мобильным банком. Мы больше думаем о продукте и думаем, что надо вырастить количество пользователей, которые пользуются нашим мобильным банком. Мы придумали фичу: теперь пользователь может расшарить покупку или пополнение счета в социальных сетях. Пришла ему денежка, он такой в Фейсбуке — смотрите, мне денежка пришла. Как вы думаете, это поможет привлечь больше пользователей? Кто на 100% в этом уверен? Ни одного. Кто на 100% уверен, что это не поможет нам никаким образом? Две-три руки. Остальные где-то между.
И последний пример. Мы делаем облачный сервис, открываем свою компанию. Облачный сервис будет собирать логи с проектов, с фронтенда и бэкенда в малом и среднем бизнесе, агрегировать их, machine learning, AI и все такое. Будем это продавать. Кто уверен, что это на 100% успех или на 100% проигрыш? Пара человек.
Существует только один правильный ответ на все эти три вопроса: «наверно». В ответах на часть вопросов мы уверены на 50–80%. Очень многое зависит от контекста, от выполнения. Тот же метроном с визуализацией — я работал над ним, его нельзя сделать так, чтобы он работал во всех контекстах: например, с Bluetooth наушниками. Но можно сделать для двух-трех обобщенных кейсов. В моем понимании это «наверное» — и есть причина, по которой стартапы закрываются, по которой HeyMoose пошел вверх копытами. Может, мы сделаем что-то хорошее, а может, просто тратим время. И у нас нет никакого способа понять, насколько мы уверены в том, что делаем.
Немного теории. В чем разница между заказной разработкой и стартапом? Разница — в контексте. Мы находимся в этом контексте неопределенности, у нас есть вероятность успеха и вероятность неуспеха. Это как если мы попытаемся использовать одинаковые методы и практики, когда бегаем по земле и когда бегаем в космосе без гравитации. Казалось бы, мы бежим, но ничего не получается. Что мы делаем не так?
Эта неопределенность идет из трех основных направлений. Она идет из рынка — потому что мы не знаем четко, какие еще компании занимаются агрегацией логов. Может, этот рынок уже захвачен кем-то? Какая демография на рынке, какие цены? Неопределенность может идти из продукта. Мы не знаем, какая проблема у нашего клиента и как ее решить. Это из примера с мобильным банком. У нас вроде как есть понимание, но мы не уверены, существует ли у пользователей эта проблема и как ее решить.
И есть вопросы имплементации. Пример с метрономом. Мы не знаем на 100%, это теоретически возможно или нет.
Или еще пример. У нас нет проблемы с рынком или продуктом, если мы изобретем лекарство от рака, которое просто таблетка — принял и здоров. Но есть огромное количество неопределенностей в том, как заимплементировать эту таблетку. Мы находимся в тумане войны, но при этом ведем себя, как будто тумана не существует, потому что у нас те же принципы, которые работают в заказной разработке. Мы их просто перемещаем в наш контекст неопределенности.
Мы как бы притворяемся, что этого тумана не существует, неопределенности нет. И мы пытаемся предсказывать будущее. Когда я начал работать продакт-менеджером, меня поразило после процесса разработки, насколько много гадания продакт-менеджер должен производить. Когда ты отчитываешься директору или кому-то еще, ты должен выглядеть уверенно, должен сказать, что мы сделаем это или это, захватим рынок к сентябрю, все будет зашибись. Все такие — молодец, все продумал. Хотя на самом деле я понимаю, что ничего этого нет, я просто гадаю по картам и пытаюсь выглядеть при этом уверенно. У нас нет культуры работы с неопределенностью, с вероятностью. Плюс, чтобы выглядеть экспертами, нам нужно постоянно бороться за репутацию, быть уверенными, говорить о том, что мы должны сделать, вместо того, что мы должны проверить, или того, в чем мы не уверены.
У нас, особенно у разработчиков, еще есть тенденция думать над тем, что мы знаем, понимаем и можем контролировать. Как разработчики, мы очень любим планировать архитектуры, думать о будущем, don’t repeat yourself, паттерное программирование и все такое.
Дизайнеры тоже этим болеют. Им нравится думать о будущем, делать идеальные макеты и т. д. Мы эксперты, хотя на самом деле нам, возможно, надо стать кем-то другим.
Как нам бороться с неопределенностью? Какие методы борьбы у нас есть? Первый метод самый важный — положить все карты на стол, признать, что мы не уверены в каком-то вопросе. Возможно, мы уверены на 50%, но чтобы проверить гипотезу, нам нужно два дня. Тогда почему бы нам просто не пойти и не проверить гипотезу? Возможно, мы уверены на 90%, что продукт взлетит, но нам нужно восемь месяцев, чтобы этот продукт заимплементить и проверить гипотезу. Мы просто пойдем и будем проверять? Или, возможно, задумаемся, как уменьшить неопределенность до 90 или 100%?
Это первый способ. Нужно повесить бейджик на эту неопределенность, сказать, какая она, большая или маленькая, какое количество работы требуется для ее разрешения и т. д.
Второй способ, над которым человечество работает последние 500 лет, это научный метод. Он не идеален, там есть свои баги, но это лучший механизм, который у нас есть на данный момент. Научный метод говорит: чтобы разрешить неопределенность, мы сначала гадаем, придумываем гипотезу на основе своих умозаключений, потом продумываем эксперимент, который подтвердит или опровергнет эту гипотезу, потом запускаем эксперимент, смотрим на числа и понимаем, верна ли наша гипотеза.
В разработке, особенно во фронтенде, у нас есть уникальная возможность запускать эти эксперименты с очень большой скоростью. Этот способ называется прототипированием. Прототип — способ бороться с неопределенностью. Это не изобретение продукта, не создание чего-то идеального, что пользователи будут использовать. Это возможность узнать больше о мире вокруг нас. Мы узнаем это, создавая иллюзии. Прототип — иллюзия, а не продукт. Мы как бы строим декорацию на театральной сцене или на площадке для снятия кино. Это всего лишь иллюзия. Цель — уменьшить неопределенность.
Прототипирование работает в двух контекстах: в контексте имплементации, когда мы не знаем теоретически с точки зрения API, возможно это или нет, и в контексте продукта, когда мы не знаем, какая проблема есть у пользователя и как ее решить. Прототипирование не особо работает при исследовании рынка — для этого существует Excel.
Смысл в том, что когда мы работаем над прототипом, нам нужно отказаться от способа мыслить как эксперты. Нам нужно забыть эти паттерны программирования, нужно забыть, как мы делаем идеальные продукты — потому что мы их не делаем. Мы пытаемся провернуть исследование, становимся учеными.
Таким образом, вместо того, чтобы продумывать архитектуры, нам нужно найти способ итерировать очень быстро. Вместо того, чтобы аппроксимировать и думать о будущем, нужно думать о том, как это провернуть сейчас, за короткие сроки.
Вместо того, чтобы думать о своей репутации, о том, что будет, если я скажу, что уверен или не уверен… Вместо этого нужно отказаться от репутации и стать новичками. Балбесами. Как мы это делаем? Какие конкретные вещи мы можем применить, чтобы стать новичками?
Первый и самый важный момент — обратная связь. Еще до того, как мы планируем свой прототип, рисуем макет или что-то еще, мы думаем о том, кому эти макеты или прототип мы будем показывать, как будем тестировать продукт, что пытаемся получить из этого эксперимента. Чем короче этот цикл обратной связи, тем лучше для нас.
Пример из личной жизни. Productive Mobile — компания, в которой я работал в последнее время, стартап, они придумали платформу, которая позволяет вам из веб-сайта сделать мобильное приложение таким drag and drop-способом. Мы продавали его большим корпорациям, потому что у них есть продукты вроде SharePoint или SAP, которые невозможно использовать на мобильном телефоне, пинч-зум, вот это все. Мы им предложили вариант: вы можете сделать мобильное приложение на основе реального сайта, скажем, за неделю. Проблема в том, что у нас была очень сильная команда разработчиков и очень долгий цикл продаж. Когда вы продаете продукт компании размера Daimler или BMW, цикл продаж — минимум 8 месяцев. За этот срок команда талантливых разработчиков может напилить очень много.
Что мы сделали и что нам помогло? Мы создали миникоманду пользователей внутри нашей компании, которые пользовались продуктом. И количество фич, которые мы стали делать и релизить, сократилось. Но при этом качество фич увеличилось в n раз. И когда мы приходили к нашему пользователю и говорили, что у нас такая-то платформа, давайте ее попробуем, почему-то перестали возникать экстренные ситуации, когда мы такие: мы об этом не подумали, это что-то новое. Мы стали делать фичи, которые на самом деле стали приносить результат. Это за счет того, что мы просто уменьшили цикл обратной связи.
Пример с метрономом, проект Polychops, над которым я работаю сейчас. Перво-наперво мы создали за короткие сроки видео, которое запостили где-то в интернете. В нем мы спросили, как вам вообще эта концепция, что вы об этом думаете. По отзывам мы не только оценили, насколько это интересно. Мы еще получили лидов, с которыми могли пообщаться, которых могли пригласить на звонки, на интервью, дать им попробовать прототип и т. д.
Мы пытаемся получить обратную связь очень рано. И не просто любую обратную связь, а качественную, не количественную.
В чем разница? Количественная обратная связь — это АВ-тестирование, бинарные результаты, когда выигрывает либо вариант А, либо вариант В. Вот и все, что мы можем получить из количественных циклов. Это как если мы находимся в темной комнате и ничего не видно, но у нас есть лазерная указка. Мы время от времени светим ей по углам, высвечиваем какие-то точки и понимаем, что в них.
Чего бы нам хотелось вместо этого? Пользователь, который опишет эту темную комнату, который знает ее гораздо лучше, чем мы сами. Нам нужны качественные интервью, звонки, что-то еще, чтобы получить информацию от пользователей в развернутом виде.
Пример компании, которая сильно полагается на количественный фидбек, — Booking.com. По-моему, на их сайте есть над чем работать.
Один из прототипов проекта, над которым я работаю, это фича, с помощью которой человек может записать себя и в этот же момент воспроизвести себе то, как он сыграл под метроном — хорошо или плохо. Эту фичу мы придумали, потому что просили качественный фидбек у людей, которые тестировали прототип. Один из людей написал, что все здорово, мне нравится часть с метрономом, но было бы круто экспортнуть этот трек с метрономом как звуковую дорожку. Мы такие — это нелогично, зачем? Он говорит: «Я вставляю это в свою программу для работы с музыкой, потом поверх записываю себя, а потом могу услышать, попадаю я в ритм или нет». Мы такие — это же гениально.
Но вместо того, чтобы просто сделать экспорт, мы решили проверить гипотезу. Поговорили с людьми, спросили, слушают ли они себя вообще, когда играют с метрономом. Многие сказали, что да, у нас часто одна программа — метроном, другая программа — диктофон на телефоне или где-то еще, мы просто себя записываем и слушаем. Мы такие — мы же программисты, можем соединить это в одном приложении. В итоге мы получили эту фичу. Мы никогда бы не догадались до этого, если бы просто проводили АВ-тестирование.
Самая важная часть прототипа — интерфейс. В глобальном понимании. Если у нас какой-то сервис с каким-то API, то наш интерфейс — API, то, с чем пользователь взаимодействует. Если мы работаем над метрономом, наш интерфейс — визуальная часть и звук. Если мы работаем просто над мобильным приложением, наш интерфейс — визуальный интерфейс. В прототипе интерфейс — единственная важная часть. Все остальное мы можем подделать, заменить на плюш.
Еще один пример из Productive Mobile. В какой-то момент мы решили переписать внутренний API в этом drag and drop-редакторе мобильных приложений. API позволяет оживить JS какие-то сложные части вашего мобильного приложения. Как менеджер продукта, я просто мог написать спецификацию и дать ее разработчикам. Уверен, что максимум через месяц все было бы готово, протестировано и замечательно. Но мы решили попробовать другой путь. Мы просто задокументировали API, которое было у нас в голове, на бумаге и отдали эту бумагу людям, которые занимались созданием мобильных приложений. Спросили: если бы у вас было такое API, как бы вы в теории построили ваши приложения?
Они взяли другую бумагу, на ней все проверили. Без имплементации. API не работало на этой стадии. Так мы провернули 5–10 итераций, прежде чем поняли, какой формы должно быть API. Мы сэкономили огромное количество времени на имплементацию. Уже после того, как мы поняли форму, мы задокументировали спецификацию, заимплементили. Все стало замечательно.
Еще один пример из метронома. Самая первая идея для Polychops — метроном для работы с полиритмами. Первый прототип мы сделали примерно за 20 минут, написали на Flash. Вот как он выглядел. Там даже звук был. Мы просто ходили и показывали его друзьям-музыкантам, спрашивали — как вам вообще? Это единственная важная вещь.
Потом мы сделали реальный метроном в браузере, все заработало, анимация, бла-бла, все красиво.
Но это заняло примерно месяц-полтора, а предыдущий прототип — 20 минут.
Сосредоточьтесь на интерфейсе.
Чтобы сэкономить время, используйте дизайн-систему. Быстрый пример из Polychops.
Слева начальный прототип, где мы просто все кнопки, всю интеракцию продумали сами. Через какое-то время мы решили, что нам нужны меню, навигация, дропдауны, что-то еще. Мы могли бы сесть и продумать с дизайнерами каждый дропдаун, каждую кнопочку, но это огромное количество времени, которое в принципе нам не нужно тратить. Поэтому мы взяли готовую дизайн-систему, взяли material-дизайн, у них все отлично задокументировано. Прикрутили, все хорошо.
Воруйте. Воруйте не у конкурентов. У конкурентов воровать бессмысленно. Если что-то работает у конкурентов, не нужно это проверять, нужно просто скопировать. Воруйте из продуктов, которые параллельны вашему, которые не совсем ваш продукт, но что-то похожее.
Еще один пример из Polychops. Интерфейс записи практически слизан с существующих программ для работы со звуком, таких как Logic. Естественно, мы его сильно упростили, но люди уже понимают, как пользоваться Logic, значит, они могут понять, как пользоваться Polychops.
В процессе прототипирования вы уйдете в долг. Например, не стоит рефакторить. Я буду говорить очень противоречивые вещи.
У меня правило такое: пока я не скопировал кусок кода хотя бы три раза, я ничего не выношу в абстракции. Потому что то, что кажется одинаковым на первый взгляд, может быть разным впоследствии.
Я раскопирую компонент на три части, посмотрю, как он будет эволюционировать. В конечном итоге, может, это три разные компоненты. Или, может, это одна абстракция, но я уже пойму четко, какой формы эта абстракция, какие там параметры и т. д.
Тесты — это спецификация. Когда мы прототипируем, мы ищем спецификацию, у нас нет возможности писать тесты. Еще мы не рефакторим, поэтому забываем про тесты.
Одна вещь, которую стоит абстрагировать, — фреймворки и библиотеки. Но тут уже на ваш вкус и цвет. Например, React очень сложно абстрагировать. Если вы пишете на React, там все будет на React. Но идеально писать таким образом, что если вы, например, захотите переключиться с Redux на Apollo, у вас не возникнет никаких проблем. Тут поможет разделение на умный и глупый компоненты. Абстрагируйте библиотеки и фреймворки.
И — не обанкротьтесь. В конечном счете все, что мы делаем с техническим долгом, — это одалживаем время у будущих себя. Смысл этого долга в том, чтобы проверить какую-то гипотезу и понять, в каком направлении нам двигаться. Но как только мы поняли направление, нам нужно вернуться назад, и либо все переписать, либо переписать отдельные кусочки, абстрагировать, покрыть тестами. Важно объяснять это продакт-менеджеру, директору и т. д. Когда вы показываете что-то, что блестит и отлично работает, они такие — всё, завтра запускаем в продакшен. С самого начала, еще до того, как мы начали работать над прототипом, объяснить, что это прототип, всего лишь декорация.
Итак, у нас есть контекст определенности и неопределенности, вероятности. И не имеет смысла работать по одинаковым принципам в обоих контекстах. Важно обозначать, какое количество определенности у нас есть. Важно обозначать количество — наверное, на основе проекта, задачи или компании.
Когда мы в контексте определенности, у нас режим имплементации. Мы делаем лучший продукт, который можем сделать. Мы эксперты. А когда мы в контексте вероятности или неопределенности, то мы в режиме исследования. Это другой режим. У него другие задачи. Задача исследования — найти спецификацию, разрешить неопределенность. Для этого нам нужно стать новичками, открыть разум.
Какие результаты? «Ну и что?» — такой была одна из претензий, когда мы прогоняли доклад. К чему это привело?
Результаты не важны. Процесс принятия решения в контексте неопределенности значит гораздо больше, чем результат. Это природа вероятности. Если у нас есть 10% шанса, что мы будем успешны, и мы просто попадаем в эти 10%, и говорим, что мы знали результат с самого начала — то мы не должны так работать.
Или другая ситуация. Может быть, мы на 90% уверены, что это правильное решение. Потом запускаем его в продакшен и понимаем, что никому оно не нужно, мы попали в эти 10%. Процесс принятия решения — нам важно научиться им управлять, научиться его улучшать. Результаты придут.
Конкретные результаты в продуктах, над которыми я работал в последнее время. В Productive Mobile один из самых главных результатов состоит в том, что мы не делали фичи. С огромным количеством фич мы после быстрого прототипа решали, что это фигня, мы чего-то не понимаем, не знаем или это просто не работает для пользователей.
Вот один из конкретных примеров. Почти все приложения в РМ написаны на React, большая часть — на React Native. Но приложение, которое мы генерим, — на React, не на React Native. В какой-то момент мы такие: «Блин, было бы круто все переписать на React Native, у нас производительность, приложения будут крутые». Как разработчикам нам было это интересно.
Что мы решили? Мы решили сделать эксперимент. Переписали, может, 10 основных компонентов в системе на React Native и попытались посмотреть, как итоговые мобильные приложения смотрятся и ведут себя с этими React Native-фрагментами. Получилось, что мы потратили на это примерно две-три недели, вспотели будь здоров, а преимуществ очень мало. Еще мы поняли, что будем поддерживать этот код, а это очень сложно, и на самом деле это не «write once — use anywhere». На самом деле вам для Android и iOS нужно написать отдельные фрагменты. Это неидеально и в нашем случае точно бы не сработало. Или мы бы потратили, может, год, чтобы все переписать и потом еще поддерживать. Для меня главный результат — то, что мы чего-то не делали, не потратили на что-то время. А время — деньги.
Ну и сейчас, только в ноябре прошлого года, РМ подняли большой раунд инвестиций… Но зачем говорить о деньгах?
Polychops начался два-три месяца назад, там рано говорить о результатах. Для меня личная гордость в том, что мы только запустились, а у нас уже есть люди, которые попробовали приложение, им интересно, они уже им пользуются. Мы общаемся с этими людьми два-три месяца, столько же, сколько работаем над прототипом. И они предложили очень много фич. Для меня это самый важный момент.
Надеюсь, вы у себя тоже это попробуете. Может, вы не работаете в стартапе, но в вашей компании есть проекты, в которых существует неопределенность. Мне важно, чтобы вы подумали об этом, поговорили со своей командой, со своими менеджерами, подумали, как работать с неопределенностью, как построить ваши процессы, чтобы процесс принятия решения улучшился, чтобы вы перестали тратить время на вещи, которые не нужны.
Если у вас все это получится и вы сделаете прекрасный продукт, то, надеюсь, в какой-то момент я буду одним из ваших очень счастливых пользователей. Спасибо.
Количественная обратная связь — это АВ-тестирование, бинарные результаты, когда выигрывает либо вариант А, либо вариант В. Вот и все, что мы можем получить из количественных циклов. Это как если мы находимся в темной комнате и ничего не видно, но у нас есть лазерная указка. Мы время от времени светим ей по углам, высвечиваем какие-то точки и понимаем, что в них.
Чего бы нам хотелось вместо этого? Пользователь, который опишет эту темную комнату, который знает ее гораздо лучше, чем мы сами.
— Всем привет! Я хотел бы поговорить о прототипировании: зачем делать прототипы, что мы от этого получаем и как их делать, на примерах.
Начну с небольшой истории. В 2012 году я присоединился к этому стартапу, замечательному оленю. У нас было нечто вроде рекламной платформы, я пришел как Java-разработчик. Понятно, что большие объемы трафика, интересные задачи, команда просто чумовая — все замечательно. Мы работаем примерно восемь месяцев, положа головы на клавиатуры, делаем очень крутые фичи, быстро все проворачиваем. Но в 2013 году олень идет вверх копытами.
Что произошло? Я очень долго об этом думал, впоследствии пошел работать разработчиком фронтенда и бэкенда в разные компании, потом был тимлидом, потом продакт-менеджером. Работал как в стартапах, так и в аутсорс-компаниях, в больших энтерпрайзах. В основном фокусировался на стартапах.
Также я делал некоторые из этих проектов. Мне посчастливилось работать над MoscowJS, Frontend Union Conf и RadioJS. Может, мы где-то там с вами пересекались. Сейчас я делаю Code Podcast, подкаст на английском языке об общих концепциях в программировании, и Polychops, проект для музыкантов, который работает в браузере и помогает вам практиковаться с инструментом, получать больше времени и практики.
Что случилось с HeyMoose? В компании были очень умные люди, которые сейчас работают senior-девелоперами в Microsoft или стали СТО. Мы делали то, что у нас получалось лучше всего: решали сложные технические задачи быстро и интересно. Но что-то пошло не так.
И что-то идет не так с большим количеством компаний, особенно стартапов. Стартапы в основном выгорают по двум причинам: либо не понимают продукт, где-то промахиваются с продуктом, либо у них заканчиваются деньги. Очень часто у них заканчиваются деньги, потому что они ищут продукт и не могут его найти достаточно долго.
Но почему заказная разработка в аутсорс-компаниях не закрывается? Или почему большие энтерпрайзы не закрываются? Кажется, они работают медленнее. Как правило, команды там по крайней мере слабее мотивированы. В чем разница? Механизмы работы одни и те же: в заказной разработке мы пишем ТЗ или просим ТЗ у заказчиков, они нам его расписывают, отдают, мы делаем макеты, код, ши́пим — такой же процесс. Что в стартапе, что в больших компаниях могут быть эджайл-практики. Все одно и то же. Так почему стартапы выгорают?
Давайте сначала представим гипотетическую ситуацию: к нам приходит менеджер продукта и спрашивает, можем ли мы забабахать метроном, который будет работать в браузере, издавать звук с периодическим интервалом и синхронной визуализацией, чтобы разные огоньки сверкали в темпе с метрономом один в один. И чтобы все это было точно, независимо от происходящего на компьютере, других процессов и т. д.
Кто на 100% уверен, что мы можем это сделать средствами браузера и средствами API браузера? Ни одного человека. Кто уверен на 80%, что мы, наверное, можем это сделать? 3–4 руки. Кто уверен 50 на 50? Большинство. Кто уверен, что мы вообще никак не можем этого сделать? Порядочно.
Следующий пример. Допустим, мы работаем в другой компании над мобильным банком. Мы больше думаем о продукте и думаем, что надо вырастить количество пользователей, которые пользуются нашим мобильным банком. Мы придумали фичу: теперь пользователь может расшарить покупку или пополнение счета в социальных сетях. Пришла ему денежка, он такой в Фейсбуке — смотрите, мне денежка пришла. Как вы думаете, это поможет привлечь больше пользователей? Кто на 100% в этом уверен? Ни одного. Кто на 100% уверен, что это не поможет нам никаким образом? Две-три руки. Остальные где-то между.
И последний пример. Мы делаем облачный сервис, открываем свою компанию. Облачный сервис будет собирать логи с проектов, с фронтенда и бэкенда в малом и среднем бизнесе, агрегировать их, machine learning, AI и все такое. Будем это продавать. Кто уверен, что это на 100% успех или на 100% проигрыш? Пара человек.
Существует только один правильный ответ на все эти три вопроса: «наверно». В ответах на часть вопросов мы уверены на 50–80%. Очень многое зависит от контекста, от выполнения. Тот же метроном с визуализацией — я работал над ним, его нельзя сделать так, чтобы он работал во всех контекстах: например, с Bluetooth наушниками. Но можно сделать для двух-трех обобщенных кейсов. В моем понимании это «наверное» — и есть причина, по которой стартапы закрываются, по которой HeyMoose пошел вверх копытами. Может, мы сделаем что-то хорошее, а может, просто тратим время. И у нас нет никакого способа понять, насколько мы уверены в том, что делаем.
Немного теории. В чем разница между заказной разработкой и стартапом? Разница — в контексте. Мы находимся в этом контексте неопределенности, у нас есть вероятность успеха и вероятность неуспеха. Это как если мы попытаемся использовать одинаковые методы и практики, когда бегаем по земле и когда бегаем в космосе без гравитации. Казалось бы, мы бежим, но ничего не получается. Что мы делаем не так?
Эта неопределенность идет из трех основных направлений. Она идет из рынка — потому что мы не знаем четко, какие еще компании занимаются агрегацией логов. Может, этот рынок уже захвачен кем-то? Какая демография на рынке, какие цены? Неопределенность может идти из продукта. Мы не знаем, какая проблема у нашего клиента и как ее решить. Это из примера с мобильным банком. У нас вроде как есть понимание, но мы не уверены, существует ли у пользователей эта проблема и как ее решить.
И есть вопросы имплементации. Пример с метрономом. Мы не знаем на 100%, это теоретически возможно или нет.
Или еще пример. У нас нет проблемы с рынком или продуктом, если мы изобретем лекарство от рака, которое просто таблетка — принял и здоров. Но есть огромное количество неопределенностей в том, как заимплементировать эту таблетку. Мы находимся в тумане войны, но при этом ведем себя, как будто тумана не существует, потому что у нас те же принципы, которые работают в заказной разработке. Мы их просто перемещаем в наш контекст неопределенности.
Мы как бы притворяемся, что этого тумана не существует, неопределенности нет. И мы пытаемся предсказывать будущее. Когда я начал работать продакт-менеджером, меня поразило после процесса разработки, насколько много гадания продакт-менеджер должен производить. Когда ты отчитываешься директору или кому-то еще, ты должен выглядеть уверенно, должен сказать, что мы сделаем это или это, захватим рынок к сентябрю, все будет зашибись. Все такие — молодец, все продумал. Хотя на самом деле я понимаю, что ничего этого нет, я просто гадаю по картам и пытаюсь выглядеть при этом уверенно. У нас нет культуры работы с неопределенностью, с вероятностью. Плюс, чтобы выглядеть экспертами, нам нужно постоянно бороться за репутацию, быть уверенными, говорить о том, что мы должны сделать, вместо того, что мы должны проверить, или того, в чем мы не уверены.
У нас, особенно у разработчиков, еще есть тенденция думать над тем, что мы знаем, понимаем и можем контролировать. Как разработчики, мы очень любим планировать архитектуры, думать о будущем, don’t repeat yourself, паттерное программирование и все такое.
Дизайнеры тоже этим болеют. Им нравится думать о будущем, делать идеальные макеты и т. д. Мы эксперты, хотя на самом деле нам, возможно, надо стать кем-то другим.
Как нам бороться с неопределенностью? Какие методы борьбы у нас есть? Первый метод самый важный — положить все карты на стол, признать, что мы не уверены в каком-то вопросе. Возможно, мы уверены на 50%, но чтобы проверить гипотезу, нам нужно два дня. Тогда почему бы нам просто не пойти и не проверить гипотезу? Возможно, мы уверены на 90%, что продукт взлетит, но нам нужно восемь месяцев, чтобы этот продукт заимплементить и проверить гипотезу. Мы просто пойдем и будем проверять? Или, возможно, задумаемся, как уменьшить неопределенность до 90 или 100%?
Это первый способ. Нужно повесить бейджик на эту неопределенность, сказать, какая она, большая или маленькая, какое количество работы требуется для ее разрешения и т. д.
Второй способ, над которым человечество работает последние 500 лет, это научный метод. Он не идеален, там есть свои баги, но это лучший механизм, который у нас есть на данный момент. Научный метод говорит: чтобы разрешить неопределенность, мы сначала гадаем, придумываем гипотезу на основе своих умозаключений, потом продумываем эксперимент, который подтвердит или опровергнет эту гипотезу, потом запускаем эксперимент, смотрим на числа и понимаем, верна ли наша гипотеза.
В разработке, особенно во фронтенде, у нас есть уникальная возможность запускать эти эксперименты с очень большой скоростью. Этот способ называется прототипированием. Прототип — способ бороться с неопределенностью. Это не изобретение продукта, не создание чего-то идеального, что пользователи будут использовать. Это возможность узнать больше о мире вокруг нас. Мы узнаем это, создавая иллюзии. Прототип — иллюзия, а не продукт. Мы как бы строим декорацию на театральной сцене или на площадке для снятия кино. Это всего лишь иллюзия. Цель — уменьшить неопределенность.
Прототипирование работает в двух контекстах: в контексте имплементации, когда мы не знаем теоретически с точки зрения API, возможно это или нет, и в контексте продукта, когда мы не знаем, какая проблема есть у пользователя и как ее решить. Прототипирование не особо работает при исследовании рынка — для этого существует Excel.
Смысл в том, что когда мы работаем над прототипом, нам нужно отказаться от способа мыслить как эксперты. Нам нужно забыть эти паттерны программирования, нужно забыть, как мы делаем идеальные продукты — потому что мы их не делаем. Мы пытаемся провернуть исследование, становимся учеными.
Таким образом, вместо того, чтобы продумывать архитектуры, нам нужно найти способ итерировать очень быстро. Вместо того, чтобы аппроксимировать и думать о будущем, нужно думать о том, как это провернуть сейчас, за короткие сроки.
Вместо того, чтобы думать о своей репутации, о том, что будет, если я скажу, что уверен или не уверен… Вместо этого нужно отказаться от репутации и стать новичками. Балбесами. Как мы это делаем? Какие конкретные вещи мы можем применить, чтобы стать новичками?
Первый и самый важный момент — обратная связь. Еще до того, как мы планируем свой прототип, рисуем макет или что-то еще, мы думаем о том, кому эти макеты или прототип мы будем показывать, как будем тестировать продукт, что пытаемся получить из этого эксперимента. Чем короче этот цикл обратной связи, тем лучше для нас.
Пример из личной жизни. Productive Mobile — компания, в которой я работал в последнее время, стартап, они придумали платформу, которая позволяет вам из веб-сайта сделать мобильное приложение таким drag and drop-способом. Мы продавали его большим корпорациям, потому что у них есть продукты вроде SharePoint или SAP, которые невозможно использовать на мобильном телефоне, пинч-зум, вот это все. Мы им предложили вариант: вы можете сделать мобильное приложение на основе реального сайта, скажем, за неделю. Проблема в том, что у нас была очень сильная команда разработчиков и очень долгий цикл продаж. Когда вы продаете продукт компании размера Daimler или BMW, цикл продаж — минимум 8 месяцев. За этот срок команда талантливых разработчиков может напилить очень много.
Что мы сделали и что нам помогло? Мы создали миникоманду пользователей внутри нашей компании, которые пользовались продуктом. И количество фич, которые мы стали делать и релизить, сократилось. Но при этом качество фич увеличилось в n раз. И когда мы приходили к нашему пользователю и говорили, что у нас такая-то платформа, давайте ее попробуем, почему-то перестали возникать экстренные ситуации, когда мы такие: мы об этом не подумали, это что-то новое. Мы стали делать фичи, которые на самом деле стали приносить результат. Это за счет того, что мы просто уменьшили цикл обратной связи.
Пример с метрономом, проект Polychops, над которым я работаю сейчас. Перво-наперво мы создали за короткие сроки видео, которое запостили где-то в интернете. В нем мы спросили, как вам вообще эта концепция, что вы об этом думаете. По отзывам мы не только оценили, насколько это интересно. Мы еще получили лидов, с которыми могли пообщаться, которых могли пригласить на звонки, на интервью, дать им попробовать прототип и т. д.
Мы пытаемся получить обратную связь очень рано. И не просто любую обратную связь, а качественную, не количественную.
В чем разница? Количественная обратная связь — это АВ-тестирование, бинарные результаты, когда выигрывает либо вариант А, либо вариант В. Вот и все, что мы можем получить из количественных циклов. Это как если мы находимся в темной комнате и ничего не видно, но у нас есть лазерная указка. Мы время от времени светим ей по углам, высвечиваем какие-то точки и понимаем, что в них.
Чего бы нам хотелось вместо этого? Пользователь, который опишет эту темную комнату, который знает ее гораздо лучше, чем мы сами. Нам нужны качественные интервью, звонки, что-то еще, чтобы получить информацию от пользователей в развернутом виде.
Пример компании, которая сильно полагается на количественный фидбек, — Booking.com. По-моему, на их сайте есть над чем работать.
Один из прототипов проекта, над которым я работаю, это фича, с помощью которой человек может записать себя и в этот же момент воспроизвести себе то, как он сыграл под метроном — хорошо или плохо. Эту фичу мы придумали, потому что просили качественный фидбек у людей, которые тестировали прототип. Один из людей написал, что все здорово, мне нравится часть с метрономом, но было бы круто экспортнуть этот трек с метрономом как звуковую дорожку. Мы такие — это нелогично, зачем? Он говорит: «Я вставляю это в свою программу для работы с музыкой, потом поверх записываю себя, а потом могу услышать, попадаю я в ритм или нет». Мы такие — это же гениально.
Но вместо того, чтобы просто сделать экспорт, мы решили проверить гипотезу. Поговорили с людьми, спросили, слушают ли они себя вообще, когда играют с метрономом. Многие сказали, что да, у нас часто одна программа — метроном, другая программа — диктофон на телефоне или где-то еще, мы просто себя записываем и слушаем. Мы такие — мы же программисты, можем соединить это в одном приложении. В итоге мы получили эту фичу. Мы никогда бы не догадались до этого, если бы просто проводили АВ-тестирование.
Самая важная часть прототипа — интерфейс. В глобальном понимании. Если у нас какой-то сервис с каким-то API, то наш интерфейс — API, то, с чем пользователь взаимодействует. Если мы работаем над метрономом, наш интерфейс — визуальная часть и звук. Если мы работаем просто над мобильным приложением, наш интерфейс — визуальный интерфейс. В прототипе интерфейс — единственная важная часть. Все остальное мы можем подделать, заменить на плюш.
Еще один пример из Productive Mobile. В какой-то момент мы решили переписать внутренний API в этом drag and drop-редакторе мобильных приложений. API позволяет оживить JS какие-то сложные части вашего мобильного приложения. Как менеджер продукта, я просто мог написать спецификацию и дать ее разработчикам. Уверен, что максимум через месяц все было бы готово, протестировано и замечательно. Но мы решили попробовать другой путь. Мы просто задокументировали API, которое было у нас в голове, на бумаге и отдали эту бумагу людям, которые занимались созданием мобильных приложений. Спросили: если бы у вас было такое API, как бы вы в теории построили ваши приложения?
Они взяли другую бумагу, на ней все проверили. Без имплементации. API не работало на этой стадии. Так мы провернули 5–10 итераций, прежде чем поняли, какой формы должно быть API. Мы сэкономили огромное количество времени на имплементацию. Уже после того, как мы поняли форму, мы задокументировали спецификацию, заимплементили. Все стало замечательно.
Еще один пример из метронома. Самая первая идея для Polychops — метроном для работы с полиритмами. Первый прототип мы сделали примерно за 20 минут, написали на Flash. Вот как он выглядел. Там даже звук был. Мы просто ходили и показывали его друзьям-музыкантам, спрашивали — как вам вообще? Это единственная важная вещь.
Потом мы сделали реальный метроном в браузере, все заработало, анимация, бла-бла, все красиво.
Видео с метрономом Polychops
Но это заняло примерно месяц-полтора, а предыдущий прототип — 20 минут.
Сосредоточьтесь на интерфейсе.
Чтобы сэкономить время, используйте дизайн-систему. Быстрый пример из Polychops.
Слева начальный прототип, где мы просто все кнопки, всю интеракцию продумали сами. Через какое-то время мы решили, что нам нужны меню, навигация, дропдауны, что-то еще. Мы могли бы сесть и продумать с дизайнерами каждый дропдаун, каждую кнопочку, но это огромное количество времени, которое в принципе нам не нужно тратить. Поэтому мы взяли готовую дизайн-систему, взяли material-дизайн, у них все отлично задокументировано. Прикрутили, все хорошо.
Воруйте. Воруйте не у конкурентов. У конкурентов воровать бессмысленно. Если что-то работает у конкурентов, не нужно это проверять, нужно просто скопировать. Воруйте из продуктов, которые параллельны вашему, которые не совсем ваш продукт, но что-то похожее.
Еще один пример из Polychops. Интерфейс записи практически слизан с существующих программ для работы со звуком, таких как Logic. Естественно, мы его сильно упростили, но люди уже понимают, как пользоваться Logic, значит, они могут понять, как пользоваться Polychops.
В процессе прототипирования вы уйдете в долг. Например, не стоит рефакторить. Я буду говорить очень противоречивые вещи.
У меня правило такое: пока я не скопировал кусок кода хотя бы три раза, я ничего не выношу в абстракции. Потому что то, что кажется одинаковым на первый взгляд, может быть разным впоследствии.
Я раскопирую компонент на три части, посмотрю, как он будет эволюционировать. В конечном итоге, может, это три разные компоненты. Или, может, это одна абстракция, но я уже пойму четко, какой формы эта абстракция, какие там параметры и т. д.
Тесты — это спецификация. Когда мы прототипируем, мы ищем спецификацию, у нас нет возможности писать тесты. Еще мы не рефакторим, поэтому забываем про тесты.
Одна вещь, которую стоит абстрагировать, — фреймворки и библиотеки. Но тут уже на ваш вкус и цвет. Например, React очень сложно абстрагировать. Если вы пишете на React, там все будет на React. Но идеально писать таким образом, что если вы, например, захотите переключиться с Redux на Apollo, у вас не возникнет никаких проблем. Тут поможет разделение на умный и глупый компоненты. Абстрагируйте библиотеки и фреймворки.
И — не обанкротьтесь. В конечном счете все, что мы делаем с техническим долгом, — это одалживаем время у будущих себя. Смысл этого долга в том, чтобы проверить какую-то гипотезу и понять, в каком направлении нам двигаться. Но как только мы поняли направление, нам нужно вернуться назад, и либо все переписать, либо переписать отдельные кусочки, абстрагировать, покрыть тестами. Важно объяснять это продакт-менеджеру, директору и т. д. Когда вы показываете что-то, что блестит и отлично работает, они такие — всё, завтра запускаем в продакшен. С самого начала, еще до того, как мы начали работать над прототипом, объяснить, что это прототип, всего лишь декорация.
Итак, у нас есть контекст определенности и неопределенности, вероятности. И не имеет смысла работать по одинаковым принципам в обоих контекстах. Важно обозначать, какое количество определенности у нас есть. Важно обозначать количество — наверное, на основе проекта, задачи или компании.
Когда мы в контексте определенности, у нас режим имплементации. Мы делаем лучший продукт, который можем сделать. Мы эксперты. А когда мы в контексте вероятности или неопределенности, то мы в режиме исследования. Это другой режим. У него другие задачи. Задача исследования — найти спецификацию, разрешить неопределенность. Для этого нам нужно стать новичками, открыть разум.
Какие результаты? «Ну и что?» — такой была одна из претензий, когда мы прогоняли доклад. К чему это привело?
Результаты не важны. Процесс принятия решения в контексте неопределенности значит гораздо больше, чем результат. Это природа вероятности. Если у нас есть 10% шанса, что мы будем успешны, и мы просто попадаем в эти 10%, и говорим, что мы знали результат с самого начала — то мы не должны так работать.
Или другая ситуация. Может быть, мы на 90% уверены, что это правильное решение. Потом запускаем его в продакшен и понимаем, что никому оно не нужно, мы попали в эти 10%. Процесс принятия решения — нам важно научиться им управлять, научиться его улучшать. Результаты придут.
Конкретные результаты в продуктах, над которыми я работал в последнее время. В Productive Mobile один из самых главных результатов состоит в том, что мы не делали фичи. С огромным количеством фич мы после быстрого прототипа решали, что это фигня, мы чего-то не понимаем, не знаем или это просто не работает для пользователей.
Вот один из конкретных примеров. Почти все приложения в РМ написаны на React, большая часть — на React Native. Но приложение, которое мы генерим, — на React, не на React Native. В какой-то момент мы такие: «Блин, было бы круто все переписать на React Native, у нас производительность, приложения будут крутые». Как разработчикам нам было это интересно.
Что мы решили? Мы решили сделать эксперимент. Переписали, может, 10 основных компонентов в системе на React Native и попытались посмотреть, как итоговые мобильные приложения смотрятся и ведут себя с этими React Native-фрагментами. Получилось, что мы потратили на это примерно две-три недели, вспотели будь здоров, а преимуществ очень мало. Еще мы поняли, что будем поддерживать этот код, а это очень сложно, и на самом деле это не «write once — use anywhere». На самом деле вам для Android и iOS нужно написать отдельные фрагменты. Это неидеально и в нашем случае точно бы не сработало. Или мы бы потратили, может, год, чтобы все переписать и потом еще поддерживать. Для меня главный результат — то, что мы чего-то не делали, не потратили на что-то время. А время — деньги.
Ну и сейчас, только в ноябре прошлого года, РМ подняли большой раунд инвестиций… Но зачем говорить о деньгах?
Polychops начался два-три месяца назад, там рано говорить о результатах. Для меня личная гордость в том, что мы только запустились, а у нас уже есть люди, которые попробовали приложение, им интересно, они уже им пользуются. Мы общаемся с этими людьми два-три месяца, столько же, сколько работаем над прототипом. И они предложили очень много фич. Для меня это самый важный момент.
Надеюсь, вы у себя тоже это попробуете. Может, вы не работаете в стартапе, но в вашей компании есть проекты, в которых существует неопределенность. Мне важно, чтобы вы подумали об этом, поговорили со своей командой, со своими менеджерами, подумали, как работать с неопределенностью, как построить ваши процессы, чтобы процесс принятия решения улучшился, чтобы вы перестали тратить время на вещи, которые не нужны.
Если у вас все это получится и вы сделаете прекрасный продукт, то, надеюсь, в какой-то момент я буду одним из ваших очень счастливых пользователей. Спасибо.
