Давайте разберемся: чем продуктовая отличается от проектной или аутсорс-разработки?
Ответ: Тем, кто отвечает за конечный продукт. Ещё в аутсорс-разработке есть конкретное задание, а в продуктовой мы просто хотим максимизировать прибыль. Также есть отличия в сроке: проект, в отличие от продукта, имеет конец.
Всё верно. Продукт — бесконечно развивающаяся штука, и да, есть отличия в сроках, потому что у проекта есть конец. Так как продукт — зона высокой неопределенности, наша задача постепенно все превращать в мини-проекты. Они будут называться историями, про них поговорим чуть позже. Основное различие в том, что заказчик может быть клиентом, а может быть группой пользователей.
Когда заказчик один, и мы говорим про проектную разработку, то с ним можно договориться и понять, чего он хочет. Вы наверняка сталкивались с ситуациями, когда люди, которые готовы оплачивать дорогих специалистов, не могут сами определиться, что им нужно, и постоянно меняют свои требования.
Но как быть, когда заказчиков-клиентов тысячи и десятки тысяч, и всем нужно угодить, а они также не могут определиться с запросом?
Я бы хотел вспомнить бородатую цитату Генри Форда: «Если бы я спросил людей, чего они хотят, они бы ответили — более быструю лошадь». Есть много трактовок этой цитаты, но мне бы хотелось восстановить истину. Как вы понимаете эту фразу?
Ответ: Не нужно ждать от людей решения. С них нужно собирать требования, чтобы понять, чего они добиваются — какие задачи хотят выполнить, какие цели достичь.
Люди обычно говорят не то, что хотят в реальности, потому что есть разные уровни контекста. Есть цель «получить богатство», а есть — «пойти работать». «Пойти работать» может включать «получить богатство», а может и не включать.
Давайте приведу пример. Раньше коммунальные платежи оплачивались в почтовых отделениях, и все с этим жили. Как только появилась возможность оплачивать онлайн, все очень быстро туда перебежали. Остальные в этот момент мучались, ели кактус, ходили стоять в очереди, потом в последний момент перед ними закрывались окна.
Другой пример — про покупку и продажу автомобилей. Сейчас этот процесс сильно автоматизирован с помощью платформ вроде «Авто.ру», маркетплейсов типа «Авито» и подобных. А раньше автомобили покупались через знакомых, люди писали объявления в газетах и обращались на авторынки. Оказывается, что до сих пор есть страны, где так делают. Люди выпускают продукцию, аналогичную «Авто.ру» в местах, где люди своими ногами ходят на авторынки.
Давайте вернемся к Генри Форду. Слушал он или не слушал людей? Слушал. Люди говорили, что им важно быстро добраться из точки А в точку В и перевозить больше грузов, чтобы лошадь не уставала. Он это слушал и ему пришла идея с автомобилем. Он дал то самое решение, которое люди не могли сформулировать, но оно им подошло.
Когда люди поняли, что нужно делать и определили требования, это ставится в проектную разработку с понятным definition of done, критериями приемки и сроками.
Pipeline (конвейер) и команда
Хотел бы упрощенно пробежаться по конвейеру разработки и поговорить про продуктовую команду: уточнить, кто в каких процессах задействован, кто из бизнесовой, а кто из технической команды.
Итак, команды в продуктовой разработке обычно кросс-функциональны. В них есть продакты, разработчики и команда тестирования. Причем, QA и разработчики работают вместе, а продакту необязательно все время находиться внутри команды. Но важно быть на расстоянии вытянутой руки — если возникают вопросы, нужно быть готовым на них ответить.
Первый этап здесь обозначен как генерация идей. Идеи становятся гипотезами, гипотезы генерируют продакты, и команда тоже в этом участвует. Гипотезы генерируются из совершенно разных источников, таких как общение с пользователями и аналитика.
Мы смотрим, как люди пользуются нашим сайтом или продуктом, видим какие-то отвалы по воронкам и добавляем улучшения. Ещё можем подсмотреть идеи у конкурентов или в продуктах из совсем других сфер, которые могут нам как-то подойти.
Продакты пишут истории вместе с командой — это, наверное, одно из основных отличий проектной разработки. Бывает такое, что команде разработки приходит готовое ТЗ, но в продуктовой разработке продакты пишут историю вместе с командой.
Дальше история попадает в бэклог. Из бэклога команда берет её в работу, параллельно с этим подключается отдел маркетинга — он занимается SEO, публикацией материалов и почтой. Потом все это дело релизится, DevOps’ы и дизайнеры подключаются на этапе истории. Затем мы собираем данные, выясняем, как повлияли наши изменения — положительно или отрицательно? И в конце получаем новые результаты и знания.
Истории вместо требований (ТЗ)
Как это может работать. Приходит продакт и говорит: «Давайте добавим авторизацию через Гугл». Задача понятная: ясно, куда кнопку добавить, куда метрику растить. С этого момента команда берет шаблон истории и прописывает возможные сценарии: что будет если нажать на кнопку, какие могут быть пограничные ситуации, что будет, если у пользователя уже есть почта, с которой он регистрировался. Дальше ответственность передается команде, и она уже без продакта сможет ответить на все эти вопросы.
Или, например, приходит продакт и говорит: «Мы заметили, что пользователи с медленным интернетом отваливаются, так как у нас тяжелый инсталлятор». Это пример из разработки, где есть софт, как в десктопных приложениях.
Здесь продакт приходит с проблематикой, а не с решением. Нужно уменьшить вес, желательно кратно, надо подумать, как. Этим уже занимается команда — предлагает решения, пробует варианты и на чем-то останавливается. Это в итоге и попадает в историю.
Когда продакт приходит с проблемой, а не с конкретным решением, как в ТЗ, команда прокачивает бизнес-мышление. В дальнейшем, они увидят фичу в каком-то другом продукте, и сами начнут приносить ценные идеи, задавать вопросы. Когда команда повзрослеет, продакт сможет быть спокойным за результат: он отдал задачу с такой верхнеуровневой формулировкой, команда её сама продумает и реализует.
Гипотеза
Гипотеза — звучит красиво, но на деле это всего лишь наше предположение об устройстве реальности, которое можно проверить. Например, если перекрасить кнопку Explore models из фиолетового в красный, её станут чаще кликать. Как это проверить? Только на практике, просто перекрасить и проверить.
Мы не знаем, как будет на самом деле, но можем только выдвинуть предположение и понять, улучшит ли наше изменение продукт. Чтобы это понять, мы проводим сравнительный тест, или A/B-тест.
Есть интересный вопрос-сравнение: почему лучше строить сарай, чем бетонный бункер? Даже у опытных в своем продукте и сегменте команд, около 28% гипотез — удачные, остальные 80%+ либо никак не влияют, либо влияют негативно, и их нужно выпиливать.
В продуктовой разработке нужно отучивать себя от мышления вроде: «Давайте изучим Best practices, основательно подготовим фундамент, зальем все бетоном и построим многофункциональный бункер». Лучше так — «Из глины и палок сколотим сарай и посмотрим, зайдет идея или нет. Зашла? — отлично, отрефакторим, забетонируем. Если нет — безжалостно выпилим».
Для демонстрации приведу пример нескольких A/B-тестов. Давайте попробуем угадать, какие из них были самые кликабельные.
Не очень хорошо видно, но в правом нижнем углу есть два варианта письма. Первый — обычный текст и кнопка «Заказать». И рядом с ним письмо с таким же посылом, но в красивом желтом шаблоне.
Левая версия с простым текстом — версия А. Красивая желтая — В. В этом случае выиграл вариант А (обычное письмо) и CTR у него был 13,6% против 9% у варианта с шаблоном. С чем это связано? Возможно, с той базой, по которой рассылали письма. Люди могли ассоциировать шаблон с маркетинговым предложением, поэтому они его даже не читали и не кликали. А обычный текст они воспринимали как письмо.
Второй пример — про тренировку. Слева два варианта поп-апа. В одном из них написано «Начните прямо сейчас, попробуйте бесплатную тренировку» и есть просьба ввести email, второй тоже просит почту, но в заголовке «Мы дарим вам меню на три дня» и дальше что-то про «никакой гречи и кефира». В итоге конверсия варианта А — почти 4%, варианта В — 6,5%.
Вариант В выиграл, потому что для тренировки надо трудиться, а для меню — есть. Вариант А побуждает что-то сделать (ты что-то должен), а Б говорит о пользе, которую ты получишь (тебе что-то должны).
Еще пример: наверху два экрана телефона, тоже поп-апы, но это пример с театром. Такая же задача — собрать почту. Первая надпись: «Узнавайте о премьерах первыми», и вторая — «Оставьте почту» и кнопка «Отправить». У первого варианта конверсия — 1,16%, у второго — практически 4%. Вывод: люди не читают мелкий текст. В случае А люди не понимают, что от них хотят, потому что «Оставьте email» у них написано мелким текстом под большой красной надписью. В случае В — прямой призыв к действию —«Оставьте email». Выяснилось, что он работает лучше.
Последний пример — с доктором, тут нужна конверсия в телефонные номера. У варианта А конверсия выше, как раз по той же причине: люди не читают мелкий текст, а видят прямой призыв.
Какой можно подвести итог? То, что нам кажется, не всегда совпадает с реальностью. Красная кнопка действительно может лучше конвертить, чем фиолетовая.
Когда-то Яндекс, чтобы отучить людей мыслить шаблоном «я думаю, что надо делать так, потому что видел у других», выпустили футболки «Я нерепрезентативен».
Представим ситуацию. Я предложу вам идею для стартапа: придумать софт для переноса DVD в формат, пригодный для телефона. Вы скажете: «Что? Ты спятил? DVD в 21-м году?». На самом деле, это реальный случай — в Японии люди хранят на DVD записи фильмов, семейные архивы, и для них это очень востребованный функционал. Поэтому нужно идти к пользователям и конкурентам, и проверять всё на цифрах.
MVP и RAT: подход к проверке гипотез
Есть подходы к проверке гипотез: MVP и RAT. MVP — это не продукт, а способ проверить с минимальными трудозатратами, интересует он пользователя или нет. Если проблема пользователя в том, чтобы быстрее передвигаться, можно на коленке прикрутить к доске 4 колеса и посмотреть, будут ли они этим пользоваться. После этого уже итеративно улучшаться до автомобиля.
Давайте ответим на вопрос: нужно ли облачное хранилище РПЦ?
Мы же не будем делать облачное хранилище, а потом предлагать в церкви. MVP пусть будет лендингом с текстом. Его мы покажем церковнослужителям, и проследим, будут они кликать или нет. То есть, с MVP мы даже не приступаем к разработке облачного хранилища.
А RAT — это проверка самых рискованных предположений. RAT задает вопрос: а облачные хранилища вообще нужны церквям? В данном случае, можно найти 100 церквей, прозвонить их и спросить. Таким образом, можно без разработки лендинга получить ответ.
У нас как раз недавно в проекте был похожий случай. Мы занимались разработкой модели по удалению фона на фото под мобилку, и в нашем случае надо было разослать письма разработчикам приложений — узнать, интересно ли им предложение.
С точки зрения MVP можно проверить так. Есть некий лендинг, но нет «подмобилки». Можно добавить кнопку «Get for mobile» и посмотреть, будут на неё кликать или нет. Но мы не уверены, ходят ли к нам разработчики мобильных приложений, поэтому не факт, что MVP с кнопкой сработает.
Есть история о том, почему нужно вовремя проверять гипотезы, а не строить бетонный бункер. Помните стартап Iridium? Это самый дорогой проваленный стартап, который разрабатывал спутниковые телефоны.
Идея появилась, когда один из инженеров Motorola отдыхал на островах с женой, и телефон там не ловил. Он решил сделать так, чтобы телефоном можно было пользоваться из любой точки мира с помощью звонков через спутник.
Компания отнеслась к этому серьезно, с инженерным подходом. Они выстроили огромную инфраструктуру, запустили спутники в космос, собрали 6 млрд долларов инвестиций. Это были уважаемые и опытные люди, однако за время до запуска спутника в космос сотовые операторы поставили вышки на островах. В итоге стоимость сотовой связи сильно упала. Продукт на момент выхода оказался в десять раз дороже, чем стоимость сотовой связи, и оказался никому не нужен.
Вопрос: А как можно было отловить эту ситуацию и понять, что дальше этим заниматься не стоит?
Поставим вопрос так: какое у нас самое рискованное предположение? — Что люди готовы платить за использование телефонов там, где нет связи. Нужно узнать, сколько их и как дешевле удовлетворить их потребности. А ещё рассмотреть, есть ли места с большим скоплением людей, не покрытые связью. Так и вышло: операторы поставили вышки, пока чьи-то корабли бороздили космос.
Суть в том, что важно вывести продукт на рынок не слишком поздно и не слишком рано. Взять, например, историю, как «Яндекс.Такси» опередили большинство похожих сервисов.
Раньше люди заказывали такси по номеру телефона, и не просто в агрегатор, а в колл-центр, и компаниям приходилось ещё содержать операторов. Дальше колл-центр распределял заказы между таксистами, а таксисты договаривались с операторами. У последних были любимчики, поэтому тех водителей, у кого больше заказов, приходилось долго ждать в очереди.
Что сделал «Яндекс»? Взял и сократил затраты на автопарк — люди приходят работать работать на своих машинах. Все, что им нужно, это телефон с навигатором и GPS. Компания отказалась от колл-центров — пользователь сам поставит точку на карте, откуда забрать и куда поехать. Получилось так, что технология GPS стала доступна, и появился продукт, который убил конкурентов. Это отличный пример того, как всё случилось вовремя.
Ответ: С этим утверждением можно поспорить. Мы не знаем, на самом ли деле дешевле нанимать операторов для инфраструктуры; не знаем стоимости разработки и техподдержки в сравнении. Я думаю, что «Яндекс» выиграл по двум причинам:
- Пользователь заказывает такси, и видит, сколько он заплатит; GPS уже много лет, но Яндекс позволяет сказать, что я здесь и приедет такси, не надо называть адресов.
- Яндекс сделал удобно. А ещё он отодвинул от себя вопросы ответственность, лицензий, техобслуживания и техосмотра, то, что такси обязаны делать по закону. Говорить, что это экономически эффективно, я бы не стал, у нас нет цифр.
Команда мыслит ценностью для бизнеса, а не задачами
Важно разворачивать свое мышление в сторону ценности, которую мы принесем бизнесу или клиенту. Вместо того, чтобы говорить «Я прокачался в React» лучше сказать «Улучшилось качество кода, и разработка гипотез ускорилась в два раза». В этом как раз есть ценность для бизнеса.
Обязательно нужно замыкать цикл обратной связи. То есть, мы замеряем, как история повлияла на пользовательские бизнес-метрики, и от этого делаем выводы: оставляем или выпиливаем.
Что главное в продуктовой разработке
Самое главное в продуктовой разработке — это быстрая поставка ценности. Отсюда же теория про сараи и бетонные бункеры. Весь остальной процесс выстраивается от этого.
Как это сделать? Предлагают разные фреймворки — Kanban, Scrum, экстремальное программирование, «Кеневин» и другие. Для продуктового мышления нам помогает AGILE-философия. Что для этого нужно:
- Понимание, что люди и взаимодействия важнее процессов и инструментов. Рабочий продукт важнее исчерпывающей документации. Мы не отрицаем важность, того что справа, но всё же больше ценим то, что слева.
- Готовность к изменениям даже на последней стадии истории. Мир и бизнес быстро меняются. Когда мы писали историю, мы думали одним образом, но реальность так устроена, что к концу все может измениться. Проджект может вернуться к команде, когда разработка уже начата, и выдвинуть новые требования.
- Сохранение гибкости мышления чтобы учитывать множество точек зрения.
- Постоянное саморазвитие и совершенствование системы. Чтобы поддерживать высокую скорость разработки, нужно следить, чтобы система оставалась стабильной и быстрой несмотря на наши сараи и костыли. Главное — чтобы система была поддерживаемой, чтобы стоимость внедрения изменений в код была низкой.
- Принятие собственной ответственности за результат.
Продуктовое мышление (mindset)
Продуктовое мышление можно применять не только к продуктам, но и к задачам. Пример — офис как продукт. Мы недавно переезжали в новый офис, поэтому решил разобрать, может, будет полезно.
Давайте порассуждаем, зачем нам нужен офис. Зачем и чтобы что? Чтобы создать комфортные условия для работы. А комфортные — это какие? Необходимое оборудование, тишина, настрой, свет, тепло.
По-хорошему, эти условия нужно узнать у пользователей, чтобы понять, что им важно, какие задачи стоят перед ними. Наверное, ещё нужен быстрый интернет, наличие кофеварки и переговорок.
Вот мы поговорили, доказали себе необходимость офисов, пошли анализировать рынок. Посмотрели, как в других компаниях они устроены, учли наши потребности, стали искать предложения в нашем городе: какие они бывают, сколько стоят. Дальше выбираем подходящие.
Было бы здорово, если бы мы без заключения договоров взяли наших пользователей и отправили их пару дней там поработать. Так мы бы собрали бы обратную связь, и выяснили, например, что кофеварка не так важна, или вылез бы другой критерий, который мы упустили.
С учетом этого мы меняем свои требования и находим тот вариант, который нас устраивает по цене и расположению. Но если мы на этом остановимся, будет стремно. Дальше мы мониторим, сколько человек туда ходят, получают ли они достаточную тишину и комфорт. То есть мы следим за некоторыми метриками, получаем обратную связь, улучшаемся и повторяем цикл заново. Спустя какое-то время мы получаем самый подходящий под наши нужды и запросы офис.
Ещё этот подход можно применять не только для задач, но и для процессов. Допустим, мы уже как-то работаем, что-то случилось и мы облажались — не отправили заказчику апдейт в пятницу. Мы не думаем, что виноват человек, а думаем, что виноват процесс. Мы решаем, что нужно сделать, чтобы процесс не допускал возникновение таких пожаров.
Таким же способом мы устраняем баги в коде: сначала тушим пожар, потом думаем, как создать условия, чтобы этих пожаров не было. Ретро в этом плане — инструмент для улучшений. После того, как что-то случилось, надо собраться всей командой и понять весь контекст: кто что делал, какие были условия. Здесь же мы придумаем несколько вариантов, как это улучшить, остановимся на чем-то одном, замерим, помогло это или нет, и закрепим новый процесс.
Для найма такое мышление тоже подходит. Нашли хорошего кандидата? — Давайте проведем ретро и разберемся, что мы делали, как с ним договаривались, улучшения зафиксировали. Нашли хорошего, но он не принял оффер? — Запросили обратную связь, пообщались с кандидатом, внедрили изменения, посмотрели, работает или нет.
Уволился сотрудник, провели интервью. Хотим узнать что-то до увольнения? — Ищем инструменты, как получить данные раньше, например, one-on-one.
Проведу семинар? — Запрошу обратную связь, и так далее. На самом деле, такое продуктовое отношение можно применять не только к задачам, но и к процессам. Соответственно, если наша задача — двигаться как можно быстрее, такие мелкие улучшения помогают нам ускоряться.
Почему быть первыми не всегда хорошо
Когда я учился в университете, меня вдохновляла идея запустить первым в Нижнем или в России какой-нибудь Проект Х. Я часто вижу, как студенты в группах пишут о том, что они первыми запустили какой-то проект. Но есть нюанс: если вы первые что-то сделали, в голову приходят два варианта — либо вы самый умные, либо оно никому не нужно.
Чаще всего — второе. Если смотреть на причины, почему стартапы проваливаются, то они сделали продукт «для никого».
Если посмотреть на реальную историю, все известные нам гиганты не были первыми. Соцсети существовали до Facebook: например, Classmates — она до сих пор функционирует, у нее аудитория 50 млн человек. По сравнению с ФБ — это капля в море, но она вышла на 9 лет раньше.
Поисковики тоже существовали до Google. Если Yahoo! еще кто-то помнит и пользуется, то что такое Wandex я сам даже и не слышал.
Пионеры в какой-то области часто сталкиваются с риском, что это никому не нужно. Бывают такие моменты, что спрос ещё не сформировался — не понятно, будет ли бизнес востребован в течение 5 – 10 лет. Этим пользуются те, кто пришел позднее — вторым, третьим. Они легко копируют список фич, проверенных первопроходцами. Они могут видеть, есть ли на рынке деньги и сколько их.
Как сейчас делают крупняки типа «Яндекса»? Не так давно они заходили в нишу онлайн-образования с «Практикумом». До них это делали Skillbox и множество других онлайн-университетов. «Яндекс» зашел на рынок, когда он достиг оборота 1 млрд рублей в РФ. Тут же вопрос: когда рано и когда поздно? Крупняки могут себе позволить заходить позже, стартапам приходится запускаться раньше.